Jump to content

FireEye Malware

Intelligence Lab

Threat research, analysis, and mitigation

7 posts categorized "Vulnerability Research"

Old Wine In A New Bottle

The recent Adobe Flash 0 Day (CVE-2011-2110) is a classic case of an old malware that has used new 0 days as a vector to spread itself. How and why I will explain shortly, first a little detail about the exploit itself. The exploit is targeting a vulnerability in the Action Script Virtual machine according to our good friends at Shadowserver. The swf file takes an info parameter and a successful exploitation leads to the download of a zlib compressed and xor encoded binary. The two GET requests in succession would look like this

Get_request_cve_2011_2110



Continue reading "Old Wine In A New Bottle" »

OMG-WTF-PDF Dénouement

You may have heard something in the news about PDF recently… By the power of Google!

What's all this then?

I recently gave this presentation at the 27th Chaos Computer Congress in Berlin. For some reason, the slides never made it from Pentabarf to the Fahrplan. (They should be here: http://events.ccc.de/congress/2010/Fahrplan/attachments/1796_27C3_Julia_Wolf_OMG-WTF-PDF.pdf Curerntly 404, not by intent.) So first order of business, here are the long sought after slides: 27C3_Julia_Wolf_OMG-WTF-PDF.pdf (I have had so many requests for these.)

Continue reading "OMG-WTF-PDF Dénouement" »

Musings on download_exec.rb

Exposition

This is not anything new and exciting¹, and should hopefully be familiar to some of you reading this. Some time ago I reversed the shellcode from Metasploit's download_exec module. It's a bit different from the rest of the stuff in MSF, because there's no source code with it, and it lacks certain features that the other shellcode[s] have (like being able to set the exit function).

When I started writing this blog post, the day before yesterday, I looked into the history of this particular scrap of code…

It's very similar to lion's downloadurl_v31.c (previously available here: http://www.milw0rm.com/shellcode/597 [archive] but now also here: http://www.exploit-db.com/exploits/13529/ and here: http://inj3ct0r.com/exploits/9712 and a zillion other places).

… Except that, that code seems to be a more recent version than the code in MSF. For example, that does the LSD-PL function name hash trick, rather than lug around the full function names for look-up (as the version in MSF does.)

So, lion was a major figure in the Chinese 红客 Honker scene — literally translated as Red Guest (or Red Visitor or Red Passenger). (Basically Hackers who are also Chinese nationalists.) His group was the Honker Union of China [HUC], http://www.cnhonker.com — this site seems to have been dead for a while. He wrote a lot of code back in 2003 and 2004. (我现在明白了一些在写这个汉字!)

I managed to dig up an older version of this 'downloadurl' code dated 2003-09-01 which is closer to the code in MSF. http://www.cnhonker.com/index.php?module=releases&act=view&type=3&id=41 [archive] The code credits ey4s (from XFocus I think) for the actual shellcode.

Anyway, big chunks of this code, like the whole PEB method, also look like they were directly copied from Skape's old stuff (Dec 2003) — which was copied from Dino Dai Zovi (Apr 2003) — which was copied from Ratter/29A (Mar 2002) etc. etc. Like I said, this is all very old stuff. None of it has really changed since 2002, and it's still in very common use.

pita's contribution to all this appears to be wrapping up the blob of code output by the lion program above into a MSF2 module:

http://www.governmentsecurity.org/forum/index.php?showtopic=18370

Continue reading "Musings on download_exec.rb" »

Who is Exploiting the Java 0-day?

Update: Oracle released an emergency patch recently to fix this major flaw. See details in the bottom.

-------------

The recent discovery of a 0-day design flaw in the 'Java Web Start' module has opened new avenues for malware drive by attacks.  This flaw was exposed by Tavis Ormandy a few days back and it did not take a long time for bad guys to start using the proof of concept code for real exploitation.  I have been reading about the exploit details for the last few days, but very few details were available on the active use of this exploit.  Who are the guys using this exploit and for spreading what?  This article is all about this, with emphasis on the post infection stuff.

Users who are interested in the inner workings of this 0-day flaw itself, can read the full disclosure here.

It all started like this... yesterday afternoon my colleague Stuart Staniford pointed me to a malicious domain hxxp://zikkuat.com (dead at the moment) which he believed seemed to be exploiting this 0-day flaw.  After a little analysis, I found it to be true indeed.  Here are the details of my findings after a detailed analysis.

Continue reading "Who is Exploiting the Java 0-day?" »

Win32 API Shellcode Hash Algorithm

1. A Modest Proposal

Daylight Saving Time

Allegedly, the purpose of Daylight Saving Time is to save energy by manipulating a unit of measurement.

Mileage Saving Time

I have a similar proposal for how to save on gasoline usage. If we redefine the mile to be 4,800 feet during Summer — when people drive the most. Then everyone will drive 10% more miles per gallon of gas. So for example, during the winter, if your car gets 30MPG, then during Mileage Saving Time, you'd be getting 33MPG!

(Actually, it's more like redefining the distance between San Francisco, and Sacramento from 90 miles to 80 miles. That way the two cities are closer together, reducing the amount of time and energy spent traveling between them.)

2. Something Technical

Simple Hash Function(s)

I occasionally spend time reverse engineering shellcode used in various attacks. And, someday, should you find yourself in a similar situation, the following information might be useful…

The Last Stage of Delerium research group, back in 2002, published a technique for doing Win32 API RVA lookups using only the hash of a string — the name of the API function — rather than storing, and performing a full compare on the very long string. (Which some shellcode still does anyway.)

Continue reading "Win32 API Shellcode Hash Algorithm" »

PDF Obfuscation using getAnnots()

Since around October 2009, Neosploit¹, a black-market exploit toolkit, has been fabricating PDF files in a slightly new way, but in a way which is difficult for many parsers to analyze for maliciousness. In summary, all of the metadata in a PDF is accessible from the Acrobat Javascript environment. And this metadata is being used for obscuring embedded Javascript code. A PDF parser would need to fill in all the document objects with the correct data, and evaluate the Javascript to find the exploit. (Needless to say, many PDF signature parsers don't do this.) These malicious PDFs ultimately install Mebroot (aka: Sinowal)².

[And, oh yeah, our product detects this.]

Breaking News

Update: There's another exploit toolkit doing similar metadata tricks to obscure a CVE-2009-4324 attack. (That's the most recent 0-day.)

Continue reading "PDF Obfuscation using getAnnots()" »

Instruction Pointer Relative Addressing (for position independent code)

So, here's an interesting trick I've been using, that I've never seen anyone mention before. One of the new features that AMD added to the x86 instruction set when they did the AMD64/x86-64, was that in "long mode" (64-bit mode), the encoding for the old 32-bit immediate offset addressing mode, is now a 32-bit offset from the current RIP, not from 0x00000000 like before. In English, this means that you don't have to know the absolute address of something you want to reference, you only need to know how far away it is from the currently executing instruction [technically the next instruction].

So, let's say you're writing a fairly generic execve() shellcode. I'm going to assume that everyone here has read Aleph One's paper on this, so I'm not going to repeat that here. (Gripe: What is it with all these shellcode tutorials, that are just slightly rewritten copies of "Smashing the Stack…"?)

This is what we want to do:

Continue reading "Instruction Pointer Relative Addressing (for position independent code)" »