 Hello. Hi. Hi, everyone. I'm Daniel Chechik and this is my colleague, another video. We are security research ‑‑ security research from Trusted for the labs and we are going to show you the eye. Pay attention. You better pay attention. I'm going to help you out in case you can't see very well, but I'm not going to tell you the cool parts. If you notice it is not in 10 minutes you will probably know what happened. This is a browser and this is our website with a cool cat picture. Fiddler which is an HTTP proxy. We are going to record all the traffic. And this is Google Translate. And that's Windows Calculator. And that's it, really. Nah, I'm kidding. Okay. That's cool because Google just exploited our machine. But before we are going to talk about what are the eyes, we are going to have one quick slide about why are the eyes. Okay. Security web scanners. That definitely looks like a really boring slide, but we are in DevCon. So let's cut the crap and face the truth. There are 38 security URLs scan engines on this list. And they are all based on the same technology. Most of them, actually. Blacklist. It doesn't matter how you call it your reputation. It's just blacklist with fancy names. Of course some of them may do some other stuff like static analysis or even dynamic analysis. But the core of the majority is blacklist. It may sound surprising that in 2013 this Asian technology is still heavily used. But the fact is that it works pretty good. The way that your reputation is done is pretty simple. It's kind of a scoring system. So new domains or IP is automatically more suspicious than veteran and popular websites. I mean, let's take Google.com for instance. It's a website that everyone trusts. Right? Right? No one is ever going to blacklist Google. Okay. So we used the virus total website to scan a different website. A popular website. YOW.com. And as you can see, the security vendors pretty much agree that it's a clean and safe website. Except for Commodore which finds YOW suspicious for some reason. I really don't know why. But let's just move on. Okay. What is RDI? You are probably wondering what the hell we are talking about and why are they talking about your reputation? Well, don't worry and don't even bother to look in the app either because we came up with this term and even Wikipedia doesn't know what it means. But in a few minutes you will know. Okay. So let's assume we have a user. We have some kind of a website that provides a service and we have a website. If the user access a website, you will receive a legitimate website. If the service access a website, it will receive the same legitimate website. So basically so far everyone who access a website is perfectly safe and shouldn't suspect anything. But if the user access a website using the service which download the content from our website and does whatever it does with it, the code is executed and turned the page into a malicious page. So that's sort of the bird's eye view on RDI. And now we are going to kind of take a look at what we need in order to execute such an attack. So the first thing we are going to need is one simple web page. And really any web page will do. We chose to use a WordPress blog to not look too suspicious and drown in internet traffic. And what we are going to need next is a trustworthy web utility. And what I mean by trustworthy web utility is we need some sort of website that people are pretty familiar with that sort of trusted. And it needs to have some sort of service that will take content that's provided by the user and manipulate it somehow. And finally in some way also return it to users. For our example, we are going to use the Yahoo Cache service. And it doesn't really matter that it's Yahoo, obviously it could be Google being Yandex, Baidu, anything, it will do it really. And the last thing we need is we are going to need a script, JavaScript code that's going to behave differently within certain contexts. And really this will be the core of the concept of RDI. This will be a script that sort of represents the behavior Daniel described earlier. The kind of thing where this code will behave completely different when it's under the context of Yahoo's cache source. And we'll dig into the details of that in a bit. And of course you need funny cat pictures. And this is by the way what Daniel looked like when I was like let's put lots of funny cat pictures in there. No, it doesn't. Yes it is. All right. So we are going to do a demo of Yahoo Cache, the attack. But this time we are going to go into a bit more detail, not just to show you a video, we are going to do it hopefully live. This is my first time gambling in Vegas, you should be proud. I'm doing it live and let's hope I win. But what we are going to do here is we are going to go to a website that we prepared in Cache on Yahoo. And this is the website, it's a regular WordPress blog. We can take a quick peek at the source, we are not going to go over it obviously, but you will be able to see that there is nothing particularly suspicious about it. I know that there are like important stuff, you will have to trust us, we are not going to go over everything. But it's a completely in WordPress website. And the next thing we are going to do is we are going to go to the Cache version of this website, which we have prepared in advance and see what happens. Now, we will get to it in the end, just sort of already I had advantages of different services, but the fun part about using a caching service is that, yeah. What's this called? Shot the new, what do we do it? First time speakers. We got one back there. There you go. First time attendee. You guys are like, I don't even have to say it anymore. Okay, cheers. Cache service is due to the nature of caching, it saves content that is no longer there. We can actually have an attack that we once had somewhere and then remove it completely once the page is cached and we will have an attack that is completely hosted by Yahoo and only by Yahoo, which is what we did here. And, you know, it's pretty nice. It's just now finished. Excellent. There you go. It's not a screen shot, see, it's an actual cal. All right, so now we're going to take a look at the one part I didn't really explain and that's going to be the script, the source code behind what happened here. Now, we're going to try to understand what happened and what we did. The first part, the first thing that the script really does is it's going to try to access a span tag that exists within the page. Because we're running under Yahoo's cache, the span tag is going to be the following. Yahoo is not responsible for the content of this page. And we thought it would be like a fun string to use and we decided to use this as a sort of key. What we're going to do now is we're going to take this string and we're going to generate some sort of pseudo unique key, just something unique enough for us. And we encrypted most of our malicious code with this key. And the next thing we're going to do is this is kind of like a sidetrack thing. It's a very simple obfuscation trick that's used constantly in the wild. What we're going to do here is we put in the page a huge div tag that contains, it's called WakaDiv and it contains WakaNumber, WakaNumber, WakaNumber. And this is basically our malicious code. It's slightly obfuscated. The Waka delimiter is meant to be a percent U. And we replaced it just really to prevent those kind of silly defenses that go, if you have a really long string that has percent U in it many times, just block it. And that's ridiculous. So we just replaced it with something and we're going to fix it back here. And once we have our code back, we're going to now try and decrypt it with the key we just generated from the, yeah, it's not responsible, the last string. And we're going to evaluate it, which means that right now we have some sort of string that has been de-obfuscated and decrypted and it's going to try to turn it into JavaScript code. So only if we are really in the context of Yahoo's caching service, only if we really have the content that we expected within the span tag that we knew exactly where it would be, only then will these two methods that we're going to try to execute actually exist. Because as you can see they're not defined anywhere else within our code. We just pretty much showed you everything. And that's sort of how the script pulled off this cool trick. Well, that's cool because we just managed to host our attack on Yahoo. But we want to take things one step further. We want to make it even more evasive. So this time we'll use Google as an example because we don't really want to pick on anyone in particular here. So here's Google Transfer Service, which I use it quite a lot. Because I don't know English, if you didn't notice. Actually that's if you haven't noticed, but no. Okay, so this time we are going to execute our attack not only by the context we are in, we are actually going to construct our attack using Google Transfer Service. So I hope you still remember the demo we presented in the beginning. We are going to get back to it now and take it step by step. So this is Google Transfer Service and we just type in the link to our website and ask Google to transfer it from Hebrew to English. Of course we can't really expect the user to browse to Google Translate and type in the link to our website and get exploited because we probably won't do it. Hopefully. So as you probably know, Google allow us to give us the ability to generate a direct link to a translated page included the languages and everything so it shouldn't be a problem. And of course with this URL we can spread it via email, social networks or any other media. And again it's Google. Who will blacklist Google? Okay, so let's take a look on the flow of the attack using Google Transfer Service. Okay, the user trying to access our website and using the Google Translate Service. So you access the Google Translate which download the content from our website and our website simply sends back the content of the page. The Google Translate wrap the content and add some translation script and finally send it back to the user. The user browser translate the content of the page and by doing so it created a decryption key for us to use. And afterwards the JavaScript code is executed and uses the key to decrypt the JavaScript code which turns the page into a malicious page. Okay, so once more we can take a look at exactly how it happens. And you'll see the concept as you could see right now. The concept is very similar. What we wanted to do by giving two different services and two different examples is just kind of show you where it differs between services and where it kind of looks the same. I'm not going to go over the things that look the same. I'm just going to show you what we did with it. So this time we added a couple of div tags into the page with text in Hebrew. And the first one contains the following text which as you can obviously see says script. Our other is going to be translated to script like Google's translation. And we needed a key as well so we used the obvious choice which is Bob Marley. And it translates to Bob Marley by the way. And we're going to use this to generate a key. Of course you can see here the Wakadev similar to before. And the code is going to look similar and yet different and I hope you can read this kind of. But the first thing that's going to happen here is we're going to try to create an actual element within the DOM. And this element is actually going to take content from within the translated page. We're going to try to dynamically fetch the word script that was just translated by Google and generate an actual script element within the DOM of the page. This means that if the Google translation scripts didn't work or if anything went wrong this will not create a script element and absolutely nothing malicious will happen. Now the next thing we're going to do is we're going to take the key Bob Marley and we're going to actually use the exact same code to generate the key and do the ideal fiscation because well we're lazy and it works so we'll be using the same concept. So what we're doing now is basically the English string Bob Marley which again only exists if Google's translation worked on our page and as opposed to the caching service which just sort of made sure that we're kind of under the Yahoo Cache context. The translation here actually we actually waited for Google to do the translation work. They actually constructed the attack for us when they did the translation of the page on the client side. And of course finally we're going to not exist anywhere besides in our obfuscated and encrypted code. So I guess what we're trying to say here is that RDI is really a technique. It's sort of a method. It's taking all these services that take content from the user and somehow reflect it back in order to construct our attack or rather in order to obfuscate or evade with our attack. As you probably noticed throughout here the point of RDI is context. That's the most important thing here. Because obviously when you think about it you might be asking yourself so why don't I just take my malicious link and put it in Google Translate. And basically the problem is that if you go to Google Translate and you try to put in a malicious link it's obviously going to be flagged as a malicious page. It's not like you're going to be able to suspicious, don't come near it, turn off your computer, throw it out of the window, do something. It's not going to let you access it. However, they do not scan the website they're about to translate within their own context. They don't scan it as if they are a user using this service. And so they will not see what we are trying to do here at all. Of course everything I just said leads us to the fact that it's very hard to detect. Because if we had a big div tag with lots of content we could have used any delimiter, we could have split it up, we could have done lots of things with it. When you consider what we did with the key for translation we could have used different languages, we could have put it in different places, we could have used any string. For the caching service we could have picked any element that's added from Yahoo cache. Which means all of this is extremely difficult. You cannot actually understand what's happening and see what's going to happen. And our conclusion from this is that RDI is pretty awesome for evasion. But our word and all that. We wanted to test it against some of the Internet and see how awesome it really is. And so we went to VirusTotal once more because it has lots of security engines to test it against. And we also this time wanted to test it against WebOat which if you don't know if the code is actually executed what they're going to see. And we first took the translation page but when accessed directly our translation attack page when accessed without the translation link. And of course as you can see VirusTotal said that zero out of 39 detections nobody said it was malicious. And well they'd be correct because as we said our code is not at all malicious when accessed directly. And when we put it on the scan it said this page is benign no exploits were identified and no evas were executed. And again when accessed this way they'd be correct because again nothing happened. But then we said okay now let's take the actual attack URL the one with all the translation features added and see what happens then. And well we put on WebOat the dynamic analysis and it broke apparently. We're going to let them know they're actually pretty cool people they fixed it before we could even tell them which is nice I think now it flags it as suspicious I believe. And more interestingly is when we put it back on VirusTotal we actually got one detection one single engine that dynamically scanned our content and figured out what was happening and that would be the security site check. So if there's any secure people in the crowd good job. They actually dynamically analyzed the content for the attack to be executed and figured out that we were attacking with this page. In the context of RDI this doesn't really concern us because as Daniel said in the boring slide at the very beginning RDI is not meant to deal with these dynamic sort of engines. It's meant to weed out the other 38 engines that use all these blacklisting sort of techniques. It's meant to kind of push us forward from really using these old technologies and force us to use to really understand and analyze the website and try to understand if it's malicious or not. So this is RDI. Thank you for listening. I don't think we're going to have questions and answers right here but we'll be in the Q&A room later if you want to come chat ask questions and all that. Thank you.