Introducing RDI – Reflected DOM Injection
The other day at DEFCON 21 we (Daniel Chechik and Anat Davidi) gave a talk introducing a new technique for delivering exploits by utilizing popular websites, we named the technique RDI which stands for "Reflected DOM Injection", and we explained this technique in depth during the talk.
This blog post will summarize RDI for those of you who didn't make it to our talk and are wondering what you missed!
The RDI technique is basically meant to bypass security engines that use URL blacklisting technologies in order to detect malicious websites. It makes use of the fact that it is practically impossible to blacklist popular websites (such as Google, Yahoo, etc.), as they provide many services that the average user requires. They can, however, be leveraged into helping deliver malicious content to users; and this is where RDI comes in…
So, how does RDI work?
In order to launch an attack using RDI, we will need to set up a website of our own to host our content on, and a web utility which is provided by a popular website (during our talk we used Yahoo Cache and Google Translate as our examples).
In this scenario, if the user accesses our website directly they will receive a legitimate web page.
If the web utility accesses website directly it will receive the same legitimate web page.
So basically, whoever accesses directly to the website will be safe and shouldn't suspect a thing.
But, if the user accesses the website using the specific service the code will activate and turn the page into a malicious page.
Below is an explanation of the Google Translate demo we presented at the talk:
We will generate a URL to Google Translate that accesses a website we created, and once the user browses to this URL, Google Translate will download the content from the website and translate it. The process of translation is actually generating a decryption key that will decrypt our encrypted malicious code and trigger the attack. It's important to mention that in the whole process the user doesn't access our website directly at all.
The following is a video demonstrating the attack:
The function "hello" is executed on the body onload event, the process is divided into several phases:
1. The script waits one second for the translation process to end.
2. It searches for the element id "111" which should be translated by Google Translate into the word "script" and used later to create a new SCRIPT element within the DOM of the page.
3. It then searches for yet another translated string, chosen by us, from which it will generate a unique value that we will use as a decryption key for the majority of our code.
4. The script loads the encrypted exploit from element id "333"
5. In the next steps, the code creates the key using the data provided earlier, replaces the delimiter "WAKA" with %u, and attempts to decrypt the code containing our exploit.
6. Finally, the script will attempt to execute a method which, if the process went through correctly and we were indeed using the Google Translate service, should now be defined.
If any step in this process fails, this page will be completely benign.
The second example of the technique that was presented in our talk in DefCon was related to Yahoo caching service. The concept is exactly the same as well as the code, however this time instead of using translated words as a decryption key we used a static content that was added by Yahoo caching service: "Yahoo! Is not responsible for the content of this page".
Like the previous example of Google Translate service, only if the user will access the cached page, the key will be extracted and the attack will be executed.
We expect that the materials used, as well as a recording of the talk, will be on the DefCon 21 site at some near point in time. In order to help you find it, here's a link to DefCon's information on our talk:
https://www.defcon.org/html/defcon-21/dc-21-speakers.html#Chechik