« July 2008 · January 2009 · February 2012 »

Calendar:

• No entries for November 2008.
• 31.10.2008: Conference Update - OWASP AppSec Asia 2008 - Taiwan
• 30.10.2008: See below.
• 28.10.2008: OWASP AppSec Asia 2008 - Taiwan
• 27.10.2008: OWASP AppSec Asia 2008 - Taiwan
• 25.10.2008: Abuse Day - Helsinki, Finland
• 24.10.2008: Abuse Day - Helsinki, Finland
• 19.09.2008: NSP-SEC Conference - Rotterdam, Netherlands
• 18.09.2008: Geographically Identifying SSH Brute Force Attacks
• 17.09.2008: GOVCERT.NL Conference - Rotterdam, Netherlands
• 16.09.2008: GOVCERT.NL Conference - Rotterdam, Netherlands
• 12.09.2008: Internet Security Operations and Intelligence (ISOI5) Conference - Tallin, Estonia
• 11.09.2008: Internet Security Operations and Intelligence (ISOI5) Conference - Tallin, Estonia
• 06.09.2008: Atrivo/InterCage - Malware Haven
• 05.09.2008: Shadowserver Bot Count Charts

Newest first Oldest first

Thursday, 30 October 2008

Gimmiv, rocks, worms, and fuzziness

Updated: More IPs listed at rvdh

Tired of all the news about the Gimmiv worm and the MS08-067 vulnerability? Wait, what, there's no more news? Is this thing already dead? There's nothing else to say about it or the vulnerability?

I live under a rock. The whole world has passed me by in a week. A week ago, Gimmiv was the belle of the ball. Now? Gimmiv...what? To be fair, it's a nice rock and I did manage crawl out of it long enough last week to grab a few files related to Gimmiv. I did some quick analysis when I grabbed them, then crawled back under my rock. Well, I was quite cozy under there, but someone came by and kicked it. While scurrying around for another rock, I paused to ponder the cache of files I had downloaded. One of them troubled me, as it hadn't really been discussed much.

But first, a recap.

Gimmiv is a piece of malware that is a trojan at its heart. In and of itself, it grabs passwords, gets information about a system, pokes at antivirus products and downloads additional components. One of the big components it grabs is a .dll that attacks MS08-067. (Quick aside: some people argue that this is just a trojan, not a worm, because the base binary doesn't have the ability to spread. However, if everything is online, the malware would always grab the .dll that did give it the ability to spread. Sounds kinda wormy to me. Frankly, it's a silly distinction. Trojan, worm. Potato, potato.)

The malware gets into a system through MS08-067. Now resident and running on a system, it send a ping to at least two IP addresses. If it can reach any of those, it connects out to home base for some more files. It will "register" its installation with one webserver, then start talking to a few others. Interestingly, if it can't ping those addresses, it goes quiet for a while. It eventually wakes up and tries to connect to hxxp://59.106.145.58//test9.php?abc=2?def=2 (this site is long gone, but if you see it any of your proxy logs, be concerned). The 9 in test9.php is a variable. It turns out that there were several .exes that the original exploit could download. Usually, it was n2.exe, but n1.exe through n9.exe were all available on the remote site. Sandboxing each of those resulted in a different number in the original request. So, n2.exe might hit test5.php and n9.exe might hit test3.php. I'm sure there's a pattern, but, well, I kinda skipped over that.

So, we have it reaching out to the mothership asking for a certain URL. It does this two more times, hitting the same URL. Each time, it downloads an image file. This image file visually looks to be the same, but the filesize is different, each time. On one sandbox run with one binary, the filesizes are 105614 bytes, 105583 bytes, then it jumps to 404038 bytes. Again, to the naked eye, all of these images appear to look the same. This is something that makes me go "hmm". I haven't finished analyzing the image files yet. If there's something further to report there, I'll follow-up. (Sorry for the tease, but I really just noticed this fact while writing this post. I need to dig into the images.)

Somewhere along the line it starts atacking other hosts. Yay, or something.

That's the recap. Now for something new.

One of the files on the mothership is icon.txt. Several of the previous analyses pointed to this file and that it had a bunch of stuff in it, but I haven't seen any real discussion of this file. There are several lines that look similar to this (IP addresses obfuscated to protect the innocent):
->1223965453 1.1.1.1 perlbody.t35.com//icon.php Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.2; .NET CLR 3.0.04506.30) t8FgqrlNGOQlhg8a1P6R4kdUD9NdWUpQJV9tM/pIcmH5kOr7+n4D99luGuULsjp7IDBN3v+KJBEo6dxyCZk1/o3HUI+jGgZFHNNIXZw+JCWHMDaraUIRQxjeCrLPxNcf

After some munging of the file, I got a list of the unique IP addresses. There were only 443 ip addresses! 0-day exploit? 443 ip addresses? Lame. From what I've heard, the exploit used wasn't very reliable. This could (should) have been much worse? However, these IP addresses to provide some interesting insight. One thing to keep in mind when looking at the graphs below; I haven't trimmed any IP addresses from the list. There are researchers in the list. Heck, our sandbox is in the list. Keep that in mind as a possible explanation of some of the outliers. When you look at the numbers and the pretty pictures, one thing is clear, this was pretty localized to south east Asia.

First, take a look at the IP addresses plotted on a world map. The localization is rather visible. Note the really big dot in Malaysia.

Now, take a look at the breakdown by country. Again, some areas stand out more than others.



That's the IP addresses. What else is in the file? A few other entries are pretty obvious. One is the request, one is the user-agent of browser that made the request (again, the researchers and those just poking around stood out here. Ubuntu? Really? C'mon, at least make it look like it could have been infected by this thing), one is an encoded/encryped string (others far smarter than I say this is AES encrypted), and then there's that first column. At first, I ignored it. Then in one pass at the data, I noticed it incrementing. Then, on a whim, I converted one of them from UNIX time to human time. Well well well, the first column is a time stamp.

The first entry is timestamped as 14 Oct 2008 06:24:13 GMT. Microsoft released the patch on October 23. Let that roll around your mind for a second.

Back? What does this mean? A few things. One, Microsoft went from "exploit released in the wild" to "update created, tested, and communicated to the world" in less than ten days. That's pretty damn good, considering I doubt they knew about it on October 14. Two, this thing was out there, loose in the wild, for at least ten days. Honestly, the fact that this thing didn't take out a good portion of Asia is also pretty damn good.

Hopefully this post gets across a few things. Malware analysis isn't easy. There's a ton of ways of looking at the problem. I'm not nearly as good at reverse engineering as, well, my cat. But there are other ways of looking at data. I think people need to understand that we all got pretty lucky on this one. Had they been a little bit better at writing an exploit, there would have been mass hysteria (dogs and cats living together, too!). The biggest point I want to get across is the power of information sharing. This was shared on a mailing list I participate on. Within minutes, a lot of us had jumped on it and started dissecting the malware. With each step, more information was discovered and shared. It was really great to have been a part of it. There were employees from Microsoft in the fray, sharing and learning from what we all found. We had folks from anti-virus vendors jumping in. Lots was shared, lots was learned. The mothership was taken down and we're not all sitting here talking about how Gimmiv was as bad as Sasser.

=>Posted October 30, 2008, at 11:03 PM by Mike Johnson