 I'm really excited to be here and present to you our latest improvements in our tool. Our tool is Rapture. It is a framework for conducting compression shape channel attacks, such as crime, time, or breach. We have implemented it for breach. The objective of the breach attack is that an attacker can steal a secret from an HTTPS website. And let's look at the attack anatomy. Here in the middle we have a victim. It's a user browsing the internet, let's say in a coffee shop. And at the bottom, we have the attacker. We assume that the attacker has access to the victim's network, can measure things, or inject things. And at some point, the victim browsers visits an HTTP website, such as CNN, Amazon. And because it's unauthenticated, the attacker can alter the response and inject some arbitrary JavaScript code. This code runs on the victim's machine, connects back to the attacker, and opens a command and control channel. Now the attacker can use this command and control channel to issue multiple requests to another website, which we call target endpoint. Here it's the Gmail. And because of same origin policy and because the JavaScript code runs, let's say in the CNN context, the attacker cannot read the data, but he can see them passing encrypted through the network. And he can measure things. Now in order for an attacker to initiate an attack, they need to know part of the secret. Here we have a response of the Gmail body. Our secret is the Gmail token. And if you imagine the Gmail webpage, there is a search field where the user can search for something and what the victim searches, the user, is contained in the response body. So if an attacker makes a victim issue multiple queries for search, we can understand that the attacker controls the reflection and thus controls part of the response body. And by using the part of the secret the attacker already knows, they can decrypt byte by byte by byte the rest of the secret. So let's say that the attacker already knows the secret up to the capital U and wants to decrypt the four here. When the attacker puts the four in the reflection, this will result in shorter response as if he tried another letter. Now, by adaptive choosing reflections, we can have full secret recovery, but this is not as it made sound and we have some challenges. The first one is noise. And by noise, we mean part of the response which is different per request and thus we can predict this. The second is some compression methods. The attack, how it really works is that it attacks the LZ77 algorithm, compression algorithm, but most websites use GZIP which is a combination of LZ77 Huffman coding. So the way Huffman coding works can alter our predictions about the length of the response. And the final one is that as the user, as the attacker issues requests for multiple different characters to decrypt the next byte, apart from the correct byte which will result in a shorter response, there may be another one which will match with another part of the response and compress as well with the right one and we will have two possible candidate letters for the next byte to decrypt and we will not be sure which is the right one. So during the last year, we've implemented the bridge attack and our framework is the rapture. It's production level and it's open source and I will describe you the different models. It's pretty much as the attack anatomy I showed you before. The first one is the injector. It's responsible for injecting the JavaScript code to the victim's machine. What it does is that it injects the code in all the unauthenticated HTTP responses and it works by our proofing the local network and forwarding the traffic in the middle manner. It's just, we use BetterCup and it's just a series of cell scripts with the appropriate BetterCup modules to inject the code and because we inject the code in every HTTP connection, this increase robustness, even if the victim closes the tab, opens another one or if he reboots their computer, the attack still works because we inject the code in every HTTP connection. The next module is client. Client is the JavaScript code we inject. It's quite minimal, quite dumb. All it does is that it waits for work from the adversarial network and issues the requests we want to. And the reason it's dumb is that if a victim wants to reverse engineer the code that is injected in their machine, they can't really figure out what's going on. The next module is Sniffer. Sniffer reads the encrypted data passing through the network and reports them back to the backend for further analysis. Sniffer and injector need to be in the victim's network and let's say they could be in a small device such as a Raspberry Pi and all the rest could be in a different network. And now in the adversarial network we have real-time service. It facilitates the communication between client and the rest of the backend. It gets work from the backend and forwards it to the client and then informs the backend whether the client has completed the work it was given successfully or not. And the backend written in Django is the core module of our framework. It makes the analysis of the data, it stores our data and makes the decisions about the next state of our attack. Now this is the endpoint we're about to attack. As you can see in the URL endpoint the reflections are the asterisks and we can see them there. And our secret is Bebendum is just a word from the Loremape Zoom text. And the rest of the context is just numbers. I chose this to avoid noise and to have better results. And our contributions is that we have a usable open source tool and we created a web user interface and a RESTful API to make the attack easy and very practical. We believe that the community doesn't pay as much attention as they should be to such attacks. We know they're sophisticated but with this work we want to show that they could really happen in the wild. So let's move to our demo. It's a series of screenshots from an attacker from yesterday. The first page is this one. The rapture gives the opportunity to perform multiple attacks at the same time. So here the attacker can see the attacks that are already completed, the ones running or the possible victims he can initiate a new attack. And there are two different ways to initiate an attack. The first is by scanning the network. To scan the network we use Nmap. It scans the ports, finds the possible victims, stores them in our database and presents them back to the attacker so that he can choose the victim. And we imagine now that the attacker chooses a victim and he has to configure the target. And after that he just clicks attack and the attack starts. What the attack button does is that we create a specific client code for the specific victim as well as an injector module for the specific victim as well. And now the attacker waits for the victim to visit an HTTP website to inject so that the Java code is injected. Another way of initiating the attack is by adding a custom victim if the attacker already knows the victim's IP so he can just add this in the field. And of course we can add our own targets. This needs some configuration and I want to explain briefly what this is. Name is just something to recognize the target. URL is where the client will make the requests. The prefix is the part of the secret that the attacker already knows. The secret length, we need this so that our bugging knows when the attack is completed. The secret alphabet is the alphabet from which its byte of the secret is drawn from. Allying alphabet is used for block alignment pretty much like the Poodle attack does. Record cardinality is a TLS parameter and we have two methods, serial and divide and conquer. Serial is slower but gives better results whereas divide and conquer is faster but it may not result in as good as the serial method. And after a while, the attacker sees this and these are the first results. Our attack is conducted in rounds. After when a round is completed we have a new state of the attack and something more is known about the secret. For example, in the serial method, after an attack, after a round is completed we have a new byte decrypted and we may need more than one, we may need multiple batches for a rounded. What is a batch? We may not have enough data to take a decision with enough confidence about which is the next byte decrypted. So we may need to reissue the same request multiple times until we get the decision. And as you can see, the possible known prefix is D. This is what we saw in our website. It was Bibandum and we decrypted D and the prefix we already knew was Biband. And this goes on and this is how the attack evolves. This took about six minutes and you can see it's a real-time attack. And this is pretty much all I had to say. This is our repo and our website and thank you very much for your attention. So in one of your diagrams, your example victim was Gmail. Does your attack actually work against Gmail or does our noise prevent it? Oh yeah, I forgot to talk about this. It's Gmail and noise make the attack much more difficult. Maybe if we first make a static analysis of the webpage with no reflection, we get a better idea of what to predict but for the time being, the attack doesn't work on a Gmail webpage. Why don't we take, we have a break now. So let's thank Ava again. Wonderful talk.