• Obfuscated JavaScript 2.0 – Building an encoder

    by  • January 13, 2012 • Uncategorized

    JavaScript is a wonderful language full of tricks, power and the element of confusion. In this day and age it is likely that most people handling PDF, JAVA, Flash or browser-based exploits has either seen, reversed or been owned due to JavaScript. To this day attackers continue to find clever new ways of hiding their exploit or making the reversing process a nightmare, but not many have turned to the web 2.0 features. 

    M86 wrote up an entry a last week detailing some malware that used AJAX to fetch a portion of its shellcode. Oddly enough, over the winter break, I decided it would be fun to write my own JavaScript encoder with the intention of making it a royal pain to reverse. My encoder also used AJAX, but in a nastier way, so I felt now was the time to do a write up on it. That and I am in Miami this week attending Infiltrate where there is nothing but offensive events happening all around me, so this is my attempt to fit in. 

    This post won’t cover the creation of the encoder as that in itself could take a couple posts alone. Instead, focus will be placed on some of the techniques I used and how the overall output product is generated. Comparisons will also be done between my output versus what is currently being seen in the wild. 

    Routines

    The routines used in my encoder are similar to what has already been put out by attackers, but with some more technical aspects to ensure the code is not easily reversed. The following describes the flow of transformation:

    1. Code to be encoded is taken in
    2. Encoder sets and splits are generated to be used later in the routines
    3. Code is ran through a function that converts ASCII to its number form
    4. Each number is than mapped to a random alpha key resulting in a single character
    5. Each character is mapped against the encoder set which results in a long string made up of 3 unique characters
    6. Alpha key is stored server side and mapped to a seed token
    7. Round one decryption routine is built taking in all variables listed above into account (additional data for round two decryption routine is stored local to the class)
    8. Output generated from routine one is fed to routine two
    9. Steps 1-5 are ran again
    10. Round two decryption routine is built taking pieces of data from round one

    Output Code and Results

    The output code is large, so here is a screenshot capturing the bulk portion of the code:

    One of the less technical or amusing pieces of the code is what I call the “detour data”. This is just essentially random code made to look interesting so the user spends time saving, reversing or trying to make sense of it. There is nothing stopping it from getting used later on, but for now it is not and just takes up space. Since it is random, it too changes giving it the appearance of being useful.

    Comment Bombs

    Screen_shot_2012-01-12_at_10

    When reversing obfuscated JS, it is normal to remove it from the live environment and throw it into a safe place where it can be ran. The first tool that comes to mind for dealing with this sort of problem is Malzilla. It does a great job making ugly code readable and assisting in the process of reversing. Unfortunately the code used to “beautify” the JS is flawed to some extent. If I throw in some specially made comments, when you hit the cleanup, it completely sprays the comment data into the code therefore breaking it. This is by no means advanced or technical, but can be confusing if done near a single instruction if/else statement. 

    Tailored Output

    The code currently generated by the encoder does not account for the browser version being used. Keep in mind that if you know the browser or have a reasonable idea of what version it is, then there are certain things you can do to make life hell or tailor your output code to make it less bulky. As an example, think of Firefox and the Firebug extension. Firebug is great, almost too great for doing live analysis or code changes. If we can detect the presence of Firebug being on, then why not kill ourselves to avoid being analyzed. The current output will not kill itself if it sense Firebug, but it will clear the console to avoid all the AJAX calls from being seen. This is just a small example, but it helps illustrate what more could be done.

    Future Improvements

    One and Done

    Following with the same trend on limiting AJAX calls, there is nothing stopping an attacker form generating a random directory to hold a randomly named JS file that deletes itself after being ran once. Imagine a user gets compromised and you now want to look to see what was used only to find that file no longer exists on the server and the payload is useless without the proper decoding handler. I have toyed around with this, but do not intend on sharing it at this time.

    Secure Chatting

    HTTP GET requests are used when making the AJAX call back to the server. This could easily be changed to HTTPS POST requests therefore hiding what was sent and killing any hope of successfully understanding what was going on between the client and server. Enabling such a setup is as simple as changing the web server configuration and AJAX call within the code.

    Conclusions

    Once again, this example goes to show that attackers can do a lot more to make life hell. The fact that they don’t is a huge relief to us, but given we are already starting to see AJAX used to fetch shellcode, I can say with certainty that these sort of techniques and more are going to show up in malicious code soon. If we start working against them now, it will be easier when they are being used for evil. At this point in time I am not releasing the encoder as that would spoil the challenge if someone wanted to accept it, but if you are interested in knowing more or discussing the process, email me. 

    About