Researcher: Worm Infects 1.1M Windows PCs in 24 Hours

See: Computerword Article

A few days ago ronjor posted a MSRT Release^{[shadow=red]1[/shadow]} (see below) for the MS08-067 exploit, aka Downadup or Conficker).

Since then the headlines have become urgent, and I looked back to October/2008 to review how all of this started. A friend and I just shook our heads at how this exploit has gotten so out of hand.

When Microsoft released its patch for the MS08-067 exploit it created quite a sensation, since it was an out-of-band patch. Much discussion followed in the media concerning the technical details of this exploit and the various mitigating factors. Lost in all of the hoopla and not mentioned anywhere else save one article I came across, was this in Microsoft's Bulletin:

Microsoft includes this statement in the bulletins for three related exploits.^{[shadow=red]2,3,4[/shadow]}

In a moment of frankness, a Microsoft spokesman from Security and Development Lifecycle wrote in his blog about MS08-067,^{[shadow=red]5[/shadow]}

(Blaster attacked via Port 135)

The lone article that I found that mentioned firewall protection was at tmcnet.com^{[shadow=red]6[/shadow]} which reported:

Just think, of how fewer victims there would be had proper firewall protection been enabled, the patch notwithstanding.

Since then, other attack methods have been noticed, to include infection via a USB device. Sans.org refers to this as a Social Engineering attack:^{[shadow=red]7[/shadow]}

The DLL has been identified as MAGZBN.DLL by Prevx^{[shadow=red]8[/shadow]} and the attackers' file name is jwgkvsq.vmx. The forums abound with miserable victims of the USB attack, pleading for help in removing this exploit.^{[shadow=red]9,10[/shadow]}

A friend has taken me to task for referring to "social engineering" as "user stupidity," in light of very clever ruses often employed by the attacker, especially with the USB AutoRun method used in this particular exploit. Looking at the way the AutoRun.inf file is configured to use a spoofed icon adds to the cleverness. Again from sans.org:

Note this comment by a Moderator at the Avira forum:^{[shadow=red]9[/shadow]}

Bojan at sans.org continues:

Code:

[Autorun]
Action=Open folder to view files
Icon=%systemroot%\system32\shell32.dll,4
Shellexecute=.\RECYCLER\S-5-3-42-......3665\jwgkvsq.vmx,ahaezedrn

​

This is significant, because one of VISTA's features is the way it handles AutoPlay, supposedly adding protection from AutoRun.inf executing automatically. This exploit shows how a false sense of security can be bypassed.

So, perhaps "user stupidity" is a bit harsh to say here.

But you could argue that the user is at least careless in other ways. If the user's USB device has become infected from another machine, the exploit would only work when plugged into her/his own system *if the device were of the U3 type.*

If the user's AutoRun were disabled, the exploit would not run. That is the best protection.

EDIT: I have removed a test that I created because it was not based on the correct AutoRun.inf file used in the exploit.

For a discussion of the exploit see aigle's thread:

https://www.wilderssecurity.com/showthread.php?t=231106

______________________________________________________
References

1. https://www.wilderssecurity.com/showthread.php?t=230515
2. http://www.microsoft.com/technet/security/Bulletin/MS08-067.mspx
3. http://www.microsoft.com/technet/security/bulletin/Ms08-068.mspx
4. http://www.microsoft.com/technet/security/bulletin/ms09-001.mspx
5. http://blogs.msdn.com/sdl/archive/2008/10/22/ms08-067.aspx
6. http://sip-trunking.tmcnet.com/news/2009/01/15/3917136.htm
7. http://isc.sans.org/diary.html?storyid=5695
8. http://www.prevx.com/filenames/1289141969288442658-X1/MAGZBN2EDLL.html
9. http://forum.avira.com/wbb/index.php?page=Thread&threadID=81335
10. http://forum.lowyat.net/topic/907123

----
rich

 

Nice write up again Rmus.

On USB Pens i am of the understanding that a simple folder creation and naming it autorun.inf effectively prohibits these type of .inf exploits, at least on XP since i tested trying to add one and it was rejected.

The autorun.inf protection folder is required to be attributed with "hidden" + "system" from a DOS command to be effective.

Can you elaborate if this is indeed a reliable method against such an exploit as explained aboved?

Thanks

EASTER

 

Right now, are Microsoft auto-updates (download and installation of critical patches) mandatory, unless user opts out? If not, they should be. If they were, wouldn't this sort of exploitation be hamstrung?

 

I'm hesitant to muddy the waters, but I came across a Sans.org posting in this story:
sans.org

With a link to a website describing a slightly different way to disable autoruns:

http://nick.brown.free.fr/blog/2007/10/memory-stick-worms.html

 

Hello Easter,

I've not tried that method, but will say that the only tweak that has been shown to be reliable across all platforms is the one suggested by Nick Brown, mentioned above by axial.

If you can try yours on Win9x through VISTA and show it to be reliable, then this would be another option. Even so, each user should confirm that any particular tweak works on her/his specific system.

Brown mentioned his tweak last year in a long thread on AutoRun at DSLR Security. It is a brutal hack indeed, since it effectively tells Windows that there is no AutoRun function at all on the system.

I noted his comment that this was ideal in the corporate world. Whether or not home users want to completely disable the AutoRun function would be an individual decision.


----
rich

 

The patch blocks the exploit from succeeding via the first of the three infection vectors, the MS08-067 vulnerability.

It will offer no prevention against a USB attack.

----
rich

 

Hi Rmus! thanks for thr nice post agin.

Doesn,t seem to work on XP SP2. Tied with both a USB stick and a CD.

This is all I get. jwgkvsq.vmx is never executed. Only rundll32.exe is executed. I am not sure how to interprest it.


BTW what does Open means in AE? means Run? or just Read?

Thanks

 

Hello aigle,

Thanks for the test.

I see that it is not a relevant test for HIPS since I've mapped the loading of the dll to C:\ and it of course will do nothing.

You would need the actual malware files to test, and I'm sure that a HIPS product would intercept at some point what the dll attempted to do. Seach for analyses of Downadup and you will see all of the processes and Registry entries, etc.

EDIT: Here is a good analysis:

Win32.Worm.Downadup.Gen - TECHNICAL DESCRIPTION
http://www.bitdefender.fr/VIRUS-1000462-fr--Win32.Worm.Downadup.Gen.html


Anti-Executable (AE) on the other hand will block any non-whitelisted executable from running, malware or not.

(Open=Read, Run, Execute, Load), depending on the action; hence the "Error loading" message from Windows in this case.



----
rich

 

Absolutely!

If the perps involved in this massive infection send the directions to execute, AE would stop it cold. One of the best pieces of security software
available.

 

Just confirming that "AE" being discussed is Anti-Executable from Faronics, as you posted in this thread:

https://www.wilderssecurity.com/showpost.php?p=1387299&postcount=25

 

Yes, and I'll add that clarification in my Post.

Thanks,

----
rich

 

@Rmus

Rmus I tried creating that autorun.inf file and downloaded and renamed vsetup.dll to jwgkvsq.vmx and placed the two files on a usb pendrive. I enabled autoruns and inserted my usb pendrive with the files into my computer. Keep in mind that this is in a LUA with default deny SRP enabled.

A popup appears (I've included it in my post). Now what?

 

Hello, zopzop

If nothing happens when you click as aigle did, or even r-click on the drive letter and click AutoPlay, then as I mentioned to him, my test isn't a very good one for getting the file to run.

On my Win2K system, I don't get the pop up box as you do - the shellexecute command invokes immediately as I connect the USB drive.

Also, it will attempt to run when I d-click on the drive letter in My Computer (not Windows Explorer).

----
rich

 

Only time will tell...

 

Actually Comodo can intercept dll executions( i have disabled it due to un-necessary pop ups for these) and I can still get alerts on dll injection though.

I enabled dll execution interception but still got no alerts for this dll so I suspect the dll was never exceuted in this test.

 

May be AE here is intercepting only Read function. I don,t have AE, you can confirm this by changing AE protection optrions.

 

Anti-Executable by Faronics is a Classic security program and virtually impenetratable. Couple that with it's white/Black List and it's a variable fortress no doubt.

But i grew somewhat weary of cleaning up after it daily. If anyone, especially Rmus would like to confirm, use the clean up/restore freeware app RESTORATION and look at the extreme list of deleted files it massively accummalates. Now thats no reason at all to be daunted by such a fierce stopper like AE, but can anyone use that app and confirm it? Because that confirms to me that AE is constantly non-stop discharging some kind of files, temps maybe, but the last time i used it, it shocked me to find all those AE deleted files which indicates to me that it is consistently writing to disk for some reason and then dumping a ton of leftovers.

EASTER

 

EDIT: This post was based on a faulty test I created so I have removed discussion about it.

 

Hi Easter,

Since your question is drifting off topic, I'll respond by PM!

----
rich

 

I just conferred with a friend, and she concluded with, "Well, I have to say that yes, your test is a flop."

Meaning that since the DLL will not run, there is no way for a HIPS product to respond. To have one execute properly would make changes to the system if a reader were not properly protected, which I would not want to happen.

So, we'll dispense with that!

However, as I mentioned earlier, after looking at the analyses of what this exploit does if executed, I'm sure that a good HIPS product would block any attempted changes to the system. I "assume" the same with SRP and LUA.

So I will summarize what I got out of all of this.

One lesson is that if you depend on the mainstream news reports and don't do your own research, it can lead at best to misunderstanding, at worst, panic.

Besides the headline of the article I referenced, some others were,

Now, all of these articles have some truth, but in the early months of this exploit, no writers explicitly said, Look, just get the patch, meanwhile, your firewall properly configured will prevent this exploit anyway.

That the patch was not applied by everyone led Microsoft to complain in this article,

"Waiting for the 'Worms" to come, Microsoft scolds users"

This lesson applies to all of the major outbreaks of malware: Do your own research. Challenge the hype. The information is out there, you just have to look for it.

The second lesson applies in the same way: nothing has changed.

I'm not referring to the growing sophistication of malware in what it can do in hiding itself from detection and the damage it can cause. Rather, the infection methods themselves.

There are only two: Remote Code Execution and Social Engineering. It either sneaks in, or you let it in. This attack applied a little of both.

The entrance point through an open Port is Remote Code Execution. This was explicitly referred to in the Microsoft Bulletin:

Microsoft stated emphatically to block TCP ports 139 and 445 at the firewall. This should have lessened immediately all fears about this exploit. I phoned/emailed people whose security set ups I'm familiar with, to tell them this, and assure them that they were protected.

Then, a new infection vector emerged, removeable media using an AutoRun.inf file -- also Remote Code Execution. Again, I mentioned this to the same people. I didn't have to go into details about prevention because I know that they have it covered in their own way.

The social engineering part - being tricked by how the AutoPlay box displays - is backed up by protection against unauthorized executables, should a mishap occur. Again, I contacted people to assure them of this.

No matter how sinister an exploit seems to be -- and the media love to hype it up -- the exploit still has to get onto the system before it can do anything. Who was it that said, If it can't execute, it can't infect?

That's what I mean by nothing has changed.

Just look for analyses of the exploit to see what the payload is and how it is delivered. The secrets are revealed by those who take the time to analyze. Otherwise, you are left with hype. With pertinent information about how the exploit is delivered, you'll be able to evaluate each stage of the exploit and determine whether or not you are protected.

That millions have been compromised is certainly sad, but we can be responsible only to ourselves first, and then to those in our sphere of influence who will listen.

A few good sources for analysis:

F-secure blogs
sans.org diaries
Trend-micro blogs
bitdefender blogs

Often just a search for the name of the exploit will bring up sources that aren't covered in the mainstream media.

One of my favorite quotes,

"Talking About Security Can Lead To Anxiety, Panic, And Dread...
Or Cool Assessments, Common Sense And Practical Planning..."

--Bruce Schneier​

----
rich

 

Hi, I am not sure. You know what I mesn to say- Actually dll execution is not intercepted by many HIPS( SSM, OA) or disbaled by default( EQS). I have disbled it optionally in CFP because it,s toooooo irritating, i can,t even think of keeping it enabled.

However dll injection is a separate thing and is intercepted by all HIPS. I am not sure what this autorun.inf and malware dll can do and at what stage it will be caught by a HIPS. BTW I am able to get the original malware dll( jwgkvsq.vmx). Can we use it to test? PM me pls if possible.

I am highly interested to test this scenario. Thanks

 

Thanks for the detailed explanation Rmus. I really enjoy reading your posts and learning from them

So, here is my attempt to add something constructive. Since this worm tries to access ports 139 and 445, I assume that the simple little program Windows Worms Doors Cleaner would be one workaround or solution to the remote execution method of this malware.

 

Hello, innerpeace,

I'm glad you found the explanation useful.

I am not familiar with the program, Windows Worms Doors Cleaner, so I can not comment on it.

If the user's firewall blocks Ports 139 and 445, according to Microsoft that prevents the RPC exploit. (This of course is just one of the three infection vectors in use at the moment)

It seems that those most vulnerable to this infection vector are

1) Corporate environments, where these ports are often open for needed services

2) Home users who have file and print sharing enabled.


----
rich

 

@Rmus

PM received and we got that out the way, thanks.

This is another in a really informative chain of very good details often overlooked.

EASTER