Gear Patrol site redirecting to malware

Gearpatrol.com , the "definitive men's resource site", had an owned javascript file linked on their main page that was redirecting users to java exploits/malware the other day. I'll show you.

The owned JS File

If you would have gone to Gearpatrol.com the other day, on their main page is a link to a JS file that you won't notice has loaded.

"The definitive men's resource"  - haha

Gearpatrol.com loads up when all of a sudden shit starts going wrong. Then you think, "What in the hell...?"


Some weird Jquery.js file is sourced in the main page that is set to load

Here is what the request/response looks like. You can see the code served by gearpatrol.com is awkward looking but doesn't look definitively malicious at first site.

Jquery javascript files always look rather fucked to me, but this one in particular looked especially strange. So I decided to determine what it was doing. I statically assigned two JS properties that were being called since Malzilla can't handle them. I changed "navigator.platform" aka operating system, and "navigator.useragent" aka web browser. After these two changes, the script simply compiled and told me exactly what it was doing, thankfully.

In the bottom pane you can see the iframe the javascript file was injecting into Gearpatrol.com's main page. Let's see where that iframe takes us.

Ahh that first redirect was most likely for statistic purposes. We then get bounced off to a risque site, teenporntubeonly.com . But we won't find porn there. Instead we find obfuscated javascript using typical techniques. It just multiplies the number by the variable 'g', then performs String.fromCharCode on each product. In the lower-pane are the results after de-obfuscating the code.

And once it's formatted you can tell it's serving various Java exploits which no doubt drop various malware. These were your typical Java exploits, nothing special, but it goes to show how you can get snagged from nearly any site these days, ESPECIALLY if you have outdated Java, Adobe anything, or web browser.

There's nothing amazing going on here. This happens to a lot of sites, and some are faster than others at removing them (this one appears to be fixed on Gearpatrol.com). Really the main thing you can do to prevent any issues is to keep your software updated and hope the malware people don't utilize 0-days or very new exploits.

PDF Exploit De-Obfuscation

The Gist

In the exploit code mentioned in my previous blog, there is code to embed a couple PDFs into the page which will exploit different vulnerabilities. Since I have a copy of one of the PDFs that exploits a vulnerability, I figure I'll show the process of de-obfuscating the exploit and determining the vulnerability. I can provide the malicious PDF, just ask. This is mainly just about de-obfuscating the JS, not really about analyzing the actual exploit TIFF and what it does.

Dump the Data Stream(s)

The easiest tool to use for analyzing PDFs is PDFStreamDumper from HERE. All you have to do is load the PDF into PDFStreamDumper and it will give you the header info and any data streams in the PDF. In this case we only have one data stream

Without much effort you can see the opening <script> tags indicating embedded javascript. The javascript is what builds and executes the exploit, so you basically just grab all the script from the opening tag until the closing </script> tag. Then just click the Javascript_UI button and it will open a javascript decoder right in PDFStreamdumper

once the Javascript_UI comes up you can simply format the code and you have your neatly formatted, yet obfuscated exploit code

 De-Obfuscate JS

The nice thing about this PDF is that the javascript is obfuscated almost identically to the exploit code that served it. As I stated previously in my previous blog post, there is one function doing all the decrypting of the obfuscated actions. In this case the function's name is 'ask'. One of the tricks used to throw off javascript decompilers is to grab data in XML fields by using rawValue. I'll highlight where the function is grabbing the other data.

 

All it's doing in this case is grabbing everything in the XML field "rye" and replacing any occurrence of Z,h,P,w,I,v,g,F,l, or P with '' aka, nothing. So it's just setting a variable equal to the value of that XML field while removing those particular letters (case sensitive).

Now to show you where the XML field "rye" is located and what it contains.

With that value, you should now be able to use the function 'ask' to decode a good portion of the javascript.

 

I basically just continue that process and follow the code until the final exploit code is constructed. At which point it is all concatenated and assigned into the 'rye' XML tags.

Since we're just decoding javascript I just simply document.write(g); to write the exploit code to the window.( I did this in malzilla because PDFStreamdumper didn't like document.write - screw it)

and then decode base64

So a PDF is generating a TIFF file.

CVE-2010-0188 Adobe PDF LibTiff Integer Overflow

Injected sites serve heavily Obfuscated JS

The Gist
 
Within the past few weeks I've discovered a decent amount of sites that have been injected with iframes that redirect to heavily obfuscated javascript. I usually do write-ups on stuff like this just for myself for future reference. However, I figure I might as well post them in a blog so others can check it out if they want.

Injected JS

 

First the injected obfuscated html tags. The injected code has appeared on several sites, and it still exists on a couple. Here is a short list of the owned sites I found:

• blogohblog.com/cool-javascript-tricks/
• thebudgetfashionista.com/archive/guest-post-fall-classics-fashion-copycat/
• countryuniverse.net/2008/11/19/review-jason-aldean-shes-country/
• beaconequity.com/wp-content/themes/Beacon3.0/js/jqueryanim.js
• cinemablend.com/television/Laurence-Fishburne-Done-With-CSI-Decides-Let-TV-Criminals-Get-Away-32685.html
• rosemont.com/js/swfobject.js 

If you decide to try and get the injected code from any of these sites with Malzilla or something, the injected code typically won't inject unless the referrer in the Http header contains "google.com" in it. This more than likely means whatever owned these sites owned a backend php file that parses the http headers.



So a random users visits one of these sites and the obfuscated JS is injected into the page, this is the basic process

The site loads, and appears normal

But behind the scenes is injected javascript that decodes to some script HTML tags that source the malicious domain

Once you decode the JS you will see it returns HTML script tags with the malicious domain as the script source

The Exploit Code

I showed how the exploit code gets served. Now it is time to check it out. For anyone who wants to check out the full exploit code on their own, I uploaded it to pasteBin: Full Obfuscated Code


The first thing to note is the hidden input value and the 8 empty divs. The hidden input value is grabbed by the first function 'fez' which is the function that de-obfuscates everything. This is hugely important because 'fez' is called to deobfuscate nearly every action in the code. Below is an example

Here is an example of what nearly every function in the code looks like. Every single action is obfuscated and then decoded by 'fez'. I added the actual values of the obfuscated variables to highlight what the code is looking for and doing.

Going back to the empty div tags mentioned above, it did not seem clear at first what they were for. However, after de-obfuscating some of the code I had an "ahh no shit!" moment. Each of those empty div tags are for a particular exploit if the version criteria is met (among other things). So I continued to de-obfuscate the entire document, all 1000+ lines of it. Once completed I was able to discern what the divs would contain if every exploit were to launch.The only div name that is not mentioned at all in the code is 'mix'. I'm not sure what that div was meant for.

I haven't been lucky enough to get a hold of most of these exploits to categorize them with their CVEs, but based on what versions the exploit code was looking for to drop some of these exploits, I determined a couple of the vulnerabilities. I ordered them by div name.

CVE-2009-0927 - Adobe Reader/Acrobat Collab.getIcon Buffer Overflow
CVE-2010-0188 - Malicious Tiff embedded in PDF

CVE-2010-0842 - Java JMF MIDI 3
Java exploit (unsure of which)
Java exploit (unsure of which)
Java exploit (unsure of which)

CVE-2011-0611 - Adobe Flash Player SWF Memory Corruption Vulnerability

It's becoming more typical to see exploit kits using more Java exploits than anything else. However it's interesting to note that the flash vulnerability they use is fairly new. The three java exploits that I was unsure of are probably your typical exploit kit java exploits. Like: skyline, deployment toolkit, etc.... I just wasn't sure so I didn't act like I was and bullshit what vulnerability they are exploiting.

Some additional reading about the same injections/exploit code described above
http://research.zscaler.com/2011/06/cotv-domains-serving-heavily-obfuscated.html
http://research.zscaler.com/2011/06/google-news-search-results-for-laurence.html