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).

Accessing directly to the website
Accessing directly to the website

In this scenario, if the user accesses our website directly theywill receive a legitimate web page.

If the web utility accesses website directly it will receivethe same legitimate web page.

So basically, whoever accesses directly to the website willbe safe and shouldn't suspect a thing.

Accessing the website using the service
Accessing the website using the service

But, if the user accesses the website using the specificservice the code will activate and turn the page into a malicious page.

Below is an explanation of the Google Translate demo wepresented at the talk:

We will generate a URL to Google Translate that accesses awebsite we created, and once the user browses to this URL, Google Translatewill download the content from the website and translate it. The process oftranslation is actually generating a decryption key that will decrypt ourencrypted malicious code and trigger the attack. It's important to mention thatin the whole process the user doesn't access our website directly at all.

The following is a video demonstrating the attack:

RDI - Google Translate Demo

The HTML code behind the attack
The HTML code behind the attack

The JavaScript Code behind the attack
The JavaScript Code behind the attack

The function "hello" is executed on the body onloadevent, the process is divided into several phases:

1. The script waits one second for the translation processto end.
2. It searches for the element id "111" which should be translated by GoogleTranslate into the word "script" and used later to create a new SCRIPT elementwithin the DOM of the page.
3. It then searches for yet another translated string, chosen by us, from whichit will generate a unique value that we will use as a decryption key for themajority 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 codecontaining our exploit.

6. Finally, the script will attempt to execute a methodwhich, if the process went through correctly and we were indeed using theGoogle Translate service, should now be defined.

If any step in this process fails, this page will becompletely benign.

The second example of the technique that was presented in ourtalk in DefCon was related to Yahoo caching service. The concept is exactly thesame as well as the code, however this time instead of using translated wordsas a decryption key we used a static content that was added by Yahoo cachingservice: "Yahoo! Is not responsible forthe content of this page".

RDI - Yahoo Caching example
RDI - Yahoo Caching example

Like the previous example of Google Translate service, onlyif the user will access the cached page, the key will be extracted and theattack will be executed.

We expect that the materials used, as well as a recording ofthe talk, will be on the DefCon 21 site at some near point in time. In order tohelp you find it, here's a link to DefCon's information on our talk:

Trustwave reserves the right to review all comments in the discussion below. Please note that for security and other reasons, we may not approve comments containing links.