eD2k hash collision attacks

2 friends (Uzi Tuvian & Lital Porat), have done a nice research on ed2k collision attacks, here you go :

About the paper:

In the paper we discuss the implications of the MD4 collision attacks that were developed in the past few years on the ed2k protocol (the protocol used in today's eDonkey network).  Since ed2k uses the MD4 hash function to generate unique file identifiers, these collisions allow a well-crafted file to exist in various different versions across the network.  Some of these versions might be legit and some might be malicious, but a user of the current network have to way to distinguish which version of the file he or she is downloading.

Just to be clear - this does not mean that an attacker might inject malicious versions of pre-existing files in the network; It does mean that an attacker (or an organization) might, for example, introduce new colliding files to the network and leverage on the popularity of the legit file to mascaraed the malicious one or even, under some circumstances, send the malicious version to targets of his choice.  One of the scenarios we discuss (one that might already be happening) is of a warez group that can use the network as an attack platform in order to gain access to a selected subset of it's users by distributing illegal content and performing such 'low-profile attacks' on well-chosen targets. These targets can be hosts residing in certain countries or networks, hosts running certain OS versions or whatever parameter which might interest the attacker.

In the paper, we discuss the different techniques that might be used to optimize and hide the attack and it's results, scenarios and attack vectors that are made possible due to this issue, and a tool we've put together that can be used to generate such malicious files in very high efficiency.

You can download the paper from here

ad_1_.jpg unpacking/analysis - Aurora

In this post we'll try to run Aurora as non-administrative user, and debug ad_1_.jpg which used by the attackers right after the attack. Well, I was very curious about other files in the attack, after not able to unpack the msconfig32.sys, and thought, maybe other files will give me clues on msconfig32.sys and might give me a way of unpacking it.

I've looked into USCERT advisory regarding the Aurora attack, and saw interesting file, with no explain of what it does, named ad_1_.jpg, it says that the file is XOR'd with 0x95, but nothing else :
Original advisory looked like this :

So it got me curious. I got the file from my friends where I write as-well : malwareint.com
It took me a while to get from this file in the advisory to the original file, the problem was, that I didn't know on how this file got dropped and that what was hard to find out how the attacker opened it in the computer of the victim. It wasn't very important if the file wasn't also packed with other packer (UPX) so every byte was important to be restored as original.

I've understood how to DeXOR it correctly (it was XOR to every byte which is not 0x00 or 0x95, with 0x95), attached python algorithm for it :

After unpacking the file to the original file (inside the UPX), I've uploaded it to virustotal, and saw the file was analyzed in the beginning of February (now, 36 out of 40 Anti-Virus catches it).

So, I had it in mind that the file might have been already analyzed, and after analyzing it myself, I've seen that the reports I've read, were from this file (Service creation name, querying important files such as rasmon.dll). So people have already analyzed it for us. I get to save time.

I also wanted to check 2 interesting stuff :
1. Why there was used a BAT file in the attack (and what it did?).
2. Can the attack run as simple user (not admin).

The answer for 1 was simple, (file name was : c:\windows\DFS.bat)
after quick reverse-engineering tricks you can get the value of it before it's deleted :

The batch file supposed to run in loop and wait for the handle that catches the exe to allow it to be deleted. If it's not deleted, it will try again. After the file was deleted (it uses dynamic name, that's why it's running from my desktop[on VM]), it deletes the bat file himself. Actually it's a nice trick to verify deletion of exe file after it's done executing, because deleting the exe within the file himself will not succeed without any trick (handle will be locked).
A little tip to this module-writer would be : next time use the /f on del command, it might give you better chances :P


2. Did it work as non-administrative-user? It didn't work as a normal user and didn't try to use any kind of privilege escalation while I was testing it. It also failed doing changes in the registry, and dropping files on c:\windows.
I didn't test it too much because of what I said above (that it's already got tested by others), but from a regular behavior-check tests, it didn't work as non-administrative user.

What can we learn from 2? That if Google have used proper user rights on their computer, initial installation of Aurora, wouldn't have work. It appears that non-admin user would have been enough since the exploit which the attackers used, runs remote code as the user who run internet-explorer.


Regarding the msconfig32.sys? Well... I've tried to implement my unpacker to do the same here, didn't go quite well yet. But I still got hope on this one :). For Mcafee, I wouldn't say it's not related to the attack, I actually think it is :
Two patterns which we see here :
1. Both files used some kind of repeating XOR in every section of the file.
2. Both files used different extension for the file from what it really was.

Under this scenario I'd say that they are related and from the same authors in the attack. Sorry Mcafee,
If it was up to me to decide, I would have suggested USCERT to put msconfig32.sys back on their advisory if it was up to me to decide.

Follow me on twitter under @ihackbanme :)

McAfee : Aurora files report contained amateur botnet files

Well... Maybe they did contain some other files. Here's the link for the article : http://bit.ly/amk2EE.
They are saying that :
"McAfee included four filenames in its original Aurora research that it now says are associated with the Vietnamese botnet: jucheck.exe, zf32.dll, AdobeUpdateManager.exe and msconfig32.sys."

But are they not related? Well.. you just need to believe them. Don't you?
 I don't know about the rest of the files, but I know about msconfig32.sys. It was really really hard to get my hands on this one. If it was a botnet regular file I would have gotten it much faster.
And when I searched for it, I did find some malware named the same. but it wasn't the binary :).
Also, I have another proof that relates msconfig32.sys to other file, which means both used same method in the attack. I cannot disclose any more details now.

msconfig32.sys is a tricky name, and that's what got McAfee's eyes wrong (in my opinion). Well, There were viruses with the same name (which was a real driver... BTW) + viruses with the name of msconfig32.exe - They were all a tricky name which wanted to sound like a system name : msconfig.exe (which is also the command to disable start-up programs [from registry] or see services which have no Microsoft's signature on it). It's like calling a trojan : svchost32.exe.

It's a bad name for a trojan. But that's what used in the attack. So, saying that it was a regular botnet's file, would be just weird (wait for my future post :) ). Yes, of course some malware used the name msconfig32.sys (as a real driver this time) sometime in history, it doesn't mean they are related.

I cannot post anymore details currently, about my new leads, so I better shut up now.

Cheers!