Overview
WAMP is an all-in-one package that installs Apache, MySql, and PHP on a windows system. It's the lazy man's way of getting a web-server up and running in almost no time. However, I discovered today that they have injected javascript in their page that redirects users to exploits.
WAMP
WAMP's main page. Doesn't look suspicious on the outside.
Once you check their code, it is immediately apparent there is injected script at the bottom of the page.
It's the typical exploit pack injected code of course. All it really does is take the body of 'jibberish', remove the 'a' characters and replace them with commas. Then it multiplies all the numbers by 2 which gives you an array of whole numbers to which it String.fromCharCode()s into normal javascript. It throws in a bunch of other stuff just to make de-obfuscating a little harder. Or to make it look more legit? Pastebin for the full injected code is here
Deobfuscated
Of course that Iframe redirects me to some more bad code. Here's the pastebin for this code
Deobfuscated. Another layer of obfuscation. But it's just the Dean Edwards JS packer, so no big deal.
Layer 2 deobfuscated. Heyoo PDF version enumeration
That isn't the only query that the redirect generated. It also generated a query to some obfuscated code that enumerates the system's Java version Here is the pastebin for this code
Same type of obfuscation.
I haven't notified WAMPServer.com that their site is owned yet because I'm lazy. But this just goes to show that you can never tell what sites will get owned next. So keep your Flash, PDF, Java, and browsers up-to-date all the time.
Some domain information. This reminded me a lot of a SANs blog post I read about how these malware rings alter domain information for actual legit domains in order to capitalize on SEO and other things. Maybe I'm wrong.
A quick google search on some of this information and I found at least a couple more domains that have the injected code as well, ie: marijuanapictures.com
There are probably dozens/hundreds/etc.. of domains that got blasted and now have injected redirects.
Showing posts with label pdf. Show all posts
Showing posts with label pdf. Show all posts
Thursday, October 20, 2011
Monday, July 11, 2011
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.
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
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.
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.
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
Subscribe to:
Comments (Atom)















