Researcher: Worm Infects 1.1M Windows PCs in 24 Hours

Hi Rmus! thanks.

I tried the autorun file with a dummy jwgkvsq.vmx. It works and is intercepted by CFP. Here are the pics.

Later when I get time( hopefully in a few days), i will try the actual malicious file myself against GesWall, OA and ThreatFire. Will also let it execute and se how CIS intercepts it further

I will write also more about interception by CFP, a potential CFP bypass possibility( due to loosely configured HIPS) and how to prevent it by CFP rules. I need time for all this and may be a new thread.

Thanks again. Very nice and interesting play with it.

 

I'm wondering if any have noticed a spike of Ports 139,445 probes in your firewall log:

​

----
rich

 

Anyone read this article yet? Some peeps are compiling new methods to try and disable INF autorun exploits. Thoughts? Opinions?

http://www.offensivecomputing.net/?q=node/989

EASTER

 

Interesting ideas!

It might be a good time for all to review their AutoRun procedures. From Win9x forward there have been all kinds of tweaks to disable AutoRun. Not all work on all platforms. Not all are really safe.

The problem is that when Windows "reads" a drive that has an AutoRun.inf file on the root of the drive, it caches that information in the MountPoints Registry Key.

Here is an item from a hijack log from a computer infected by the current exploit which creates on all network and removeable media drives: a hidden/system folder called Recycler; an autorun.inf file; and a DLL file called jwgkvsq.vmx.

Note in red the name of the Registry Key, the Recycler, the AutoRun command, and the file name to execute:

Code:

Logfile of Trend Micro HijackThis v2.0.2

[HKEY_CURRENT_USER\software\microsoft\windows\currentversion\explorer\[COLOR="DarkRed"][B]mountpoints2[/B][/COLOR]\
{18cdd5a0-dd64-11dd-816a-0016767cd1d7}]

[B][COLOR="DarkRed"]shell\AutoRun\command[/COLOR][/B]-C:\WINDOWS\system32\RunDLL32.EXE Shell32.DLL,ShellExec_RunDLL RuNdLl32.EXE
      .\[B][COLOR="DarkRed"]RECYCLER[/COLOR][/B]\S-5-3-42-2819952290-8240758988-879315005-3665\[B][COLOR="DarkRed"]jwgkvsq.vmx[/COLOR][/B],ahaezedrn

Take one of the "tricks" to disable AutoRun: to hold down the left SHIFT key as you insert the CD or USB drive. This will prevent the AutoRun.inf file from executing the commands, but does not prevent Windows from caching the information to the Registry.

This means that the AutoRun.inf file can still be executed by double-clicking on the drive icon in My Computer, which is how many people would access the drive. You can test the above with an installation CD which has an AutoRun.inf file to start the Setup.exe file.

This works on both Win2K and WinXP. I have not tried on Vista.

Two ways I know to prevent Windows from "reading" the drive are

• Nick Brown's Registry tweak, mentioned in an above post

This effectively removes completely the AutoRun.inf file function in Windows

• Using TweakUI for Windows XP

This allows the user to control the NoDriveAutorun settings in the Registry by selecting which Drives to allow:

​

Some who use Software Restriction Policies say that you can prevent AutoRun by setting Group Policies.

If you want to suppress AutoRun, the important thing is that your solution works and is reliable on your system.

What about your policies? I've contacted a number of people recently to ask them to review all of this. Some have a policy of not connecting another's USB drives to their computer, Period.

All avoid the U3 type for their own use. A non-U3 type will not execute an AutoRun.inf file should the drive become infected when connected to someone else's computer.

A digital picture frame is a U3 USB device. You may recall the devices that came infected from a store.

Examining your drive before removing it from another computer may not be reliable. In the current exploit, the malicious file changes the system's settings to not display hidden files. Both the Recycler folder and the AutoRun.inf file are hidden by the exploit when created on the drive. This happens as soon as you connect your drive to the infected computer. If you viewed the contents of your drive in the infected computer, the malicious items would not display.

A Safe Method

When connecting a USB drive, suppressing AutoRun and then accessing the drive in Windows Explorer rather than in My Computer will be safe. Clicking on the drive in the left pane displays the contents in the right pane and nothing will execute. You may see files that you know aren't supposed to be there. Be sure that Windows is configured to show Hidden Files:

​

You can try this in the above test with the CD.

All in all, this USB attack vector in the current exploit should not be a threat if you have set up a secure policy and a secure way of controlling how you want to use AutoRun. This is important, since the MS08-067 patch does not protect against this infection vector.

Remember how this current exploit can fool Vista users with the spoofed icon. This is a good example of a convenient, automatic function setting up a false sense of security and easily bypassed.


----
rich

 

I have a rule in CFP to prompt me on creation of autorun.inf file any where on my system, removable media etc etc. It will also pop up if autorun from an infected memory stick will execute a code.

I keep enabled autorun completely and wait for the hunt.

 

I would put that in my category of reliable solutions!

----
rich

 

Superworm seizes 9 million PCs, 'stunned' researchers say

http://www.theregister.co.uk/2009/01/16/9m_downadup_infections/

 

Thanks but of course it,s not for ordinary PC users.

 

Ok, anyone interested can test by simulating this malware.s autorun feature.

Download this beningn zip file and unzip into ur flash memory stick. Now eject and then plugin ur memory stick into ur PC. It will try to run a bening file Hasher.exe( named as worm.exe).

http://rapidshare.com/files/186258610/Downadup.Conficker_worm_simulator.zip

 

Yes that's how I did it. But you gotta be careful there are 2 locations in Group Policy where you can disable autoruns :

1) Computer Configuration -> Administrative Templates -> System -> Turn off Autoruns (Enable on All drives)

2) User Configuration -> Administrative Templates -> System -> Turn off Autoruns (Enable on All drives)

It should also be noted that if the Autoruns settings in Computer Configuration and User Configuration conflict (ie you have enable in one and disable in the other), the settings in the Computer Configuration take precedence.

 

Tried it two different ways.

1)Extracted the zip to a flash drive. Unplugged, the plugged it back in. The drive icon changed to an open folder. Is that what is expected?

2)Put in the autorun folder as described in another thread for flash drive protection. Unzipped your file to the same flash drive. I was asked if I wished to overwrite the original. Answered no. So nothing changed.

 

Yeah it doesn't work for me too. I tried it with autoruns enabled in my admin account and nothing happened. No popup window, nothing. For the record I'm running Windows Media Center Ediition with SP3.

 

Sorry, it was my blunder.

Actually I just posted it as an autorun dummy file but even in that case it was wrong. Sorry for that.

BTW the actual malware works very well.
I have posted a thread here about this.

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

 

I understand two of the infection vectors (the MS08-067 vulnerability & USB device autorun.inf file), but could someone please give an explanation of...

"It brute forces Administrator passwords on local networks and spreads through ADMIN$ shares"?

Does this pertain at all to NAT router passwords? What else? Does having file and print sharing enabled pose a threat? A properly configured firewall trusted zone is needed here, correct? What are the protections for this infection vector?

Thanks for any help.

 

More on AutoRun

Regarding AutoRun settings in Group Policy:

Axial sent a note with this web site with a Tool for controlling both configurations.
The author makes the same point as does zopzop:

http://www.uwe-sieber.de/drivetools_e.html

While the statement about TweakUI is correct, if you don't have a HKEY_LOCAL_MACHINE entry (I don't), then the point is mute. But this tool has a nice GUI as does TweakUI but with more options. These method prevent Windows from "reading" drive so that no commands are executed nor written to the Registry.

So there are many solutions to controlling AutoRun. To expand a bit on the caching of AutoRun.inf commands to the Registry:

Question: When are the Commands OPEN and EXPLORE on the right-click context menu, not OPEN and EXPLORE?

​

Consider this AutoRun.inf file from a USB Digital Picture Frame Exploit. The OPEN and EXPLORE commands
have been modified to execute malware (the file kwjkpww.exe resides on the device.):

​

Testing on a USB drive: Windows "reads" the file and writes these Shell commands to the Registry:

​

This means that even if you prevent AutoRun from executing by the old CDROM Registry entry=0, or by the old trick of holding down the SHIFT key, you can still unknowingly launch the malware by double-clicking on the Drive Letter in My Computer. This invokes the OPEN command. Or, the same by clicking EXPLORE on the context menu:

​

(SpikeyB tested this for me last year with Software Restriction Policies and aigle with Geswall, but I cannot find the screen shots showing the exploit being blocked)

Those old tricks worked until modifying the commands became part of the malware tricks.

The current conficker exploit where a spoofed icon tricks the user into thinking that the drive will open in Explorer view is another example of misusing features of the Operating system. This is too bad, for the AutoPlay prompt box is really a nice feature and can be configured to the user's preferences. Now we know that the commands can be modified by an Autorun.inf file.

To recap: the above methods (Group Policies and a Drive Tool) and the Nick Brown registry tweak mentioned in an earlier post are "considered" sure ways of preventing Windows from "reading" the drive and writing the commands to the Registry.

I say "considered" because in a long thread last year at DSLR one person using TweakUI to block the drive still had the cached entries in the Registry. It was a problem never solved, and even after deleting the entire MountPoints2 Key, it returned on reboot.

Windows is a complex operating system and has to interact with many applications. I don't think anyone really understands all that goes on behind the scenes in Windows.

This is why I stressed earlier that each person needs to test the preferred solution carefully
to make sure what you think should happen is really happening.

Actually, axial's solution is the best, in my view, and doesn't depend on any technology or system tweaks.
Axial's policy is

"Not to plug in any strange USB ever, ever."​

And if your own Pen drive is not the U3 type, you are covered there also!


----
rich

 

File sharing refers to Port 139. If that is open normally, the worm could infect.

I am not on a network, nor have a router, so cannot comment more. I have however, made a list of sites and some comments for discussion in the near future with a friend knowledgeable in networking.

http://episteme.arstechnica.com/eve/forums/a/tpc/f/174096756/m/973001885931/p/2

http://www.microsoft.com/security/portal/Entry.aspx?Name=Worm:Win32/Conficker.B

http://www.bestsecuritytips.com/news index.htm

http://mschat.net/forum/index.php?topic=720.0

http://www.sophos.com/blogs/gc/g/2009/01/16/passwords-conficker-worm

http://www.sophos.com/blogs/gc/g/2009/01/15/stop-conficker-worm-unpatched-pc/

 

Excerpted from Graham Cluley's blog...

"One of the ways in which the Conficker worm (also known as Confick or Downadup) uses to spread is to try and batter its way into ADMIN$ shares using a long list of different passwords."

Question is, doesn't the worm have to already have found its way onto your computer (either via USB removable device or failure to install MS patch or an improperly configured firewall) in order for it to begin to brute force admin passwords?

Also, in case anyone reading this topic isn't already aware of it (I wasn't until today ) The MS Malicious Software Removal Tool has been updated for Conficker.

Thank you for your helpful responses!

 

This is how I interpret it, which is why I didn't elaborate on this in my initial post. I am more interested in keeping the worm out in the first place!

From the Microsoft link above:

I interpret this to mean that after it has installed, it then will spread.

I interpret this to mean that the worm has already infected a machine, and this method of spreading concerns the current network.

The other method of spreading involves the worm copying to removable media as described in an earlier post. Now, it becomes an attack vector for machines outside of the current network.

Someone please correct me if this is a wrong interpretation.

----
rich

 

regarding those ports of 135-139 and 445 etc. there is also some hardening tools for xp which disables those ports like

Seconfig XP
SafeXP
Security & Privacy Complete.

 

More on AutoRun

A MUST read:

National Cyber Alert System
Technical Cyber Security Alert TA09-020A
Microsoft Windows Does Not Disable AutoRun Properly
Original release date: January 20, 2009
http://www.us-cert.gov/cas/techalerts/TA09-020A.html

This has been discussed in other places in the past year or so, and I summarized some of it in Posts 29 and 40 above.

The current conficker/downadup USB AutoRun infection vector has created a sense of urgency so that CERT has issued this special alert.

NOTE: the MS08-067 patch does not protect against this infection method.


References

CERT Vulnerability Analysis Blog
The Dangers of Windows AutoRun
April 24, 2008
http://www.cert.org/blogs/vuls/2008/04/the_dangers_of_windows_autorun.html


Vulnerability Note VU#889747
Windows Vista fails to properly handle the NoDriveTypeAutoRun registry value
April 20, 2008
http://www.kb.cert.org/vuls/id/889747


----
rich

 

Downadup/Conflicker worm: When will the next shoe fall?

http://tech.slashdot.org/article.pl?sid=09/01/24/225235

http://www.networkworld.com/news/2009/012309-downadup-conflicker-worm.html?hpg1=bn

 

Re: Downadup/Conflicker worm: When will the next shoe fall?

Who was the first responder?

 

Re: Downadup/Conflicker worm: When will the next shoe fall?

http://www.bdtools.net

 

Re: Downadup/Conflicker worm: When will the next shoe fall?

A new site for Downadup / Conficker was launched in order to bring more information and facts about this threat. The site is now http://www.downadup.org and the old bdtools is redirected to this one.

There's a new tool that enables the deployment in your network.

 

Anyone ever used TrustNoEXE? It is free, and seems to do the same thing as AE, and has the capability of easily being pushed to all computers on a network and managed centrally...

http://www.beyondlogic.org/solutions/trust-no-exe/trust-no-exe.htm

Or just google trustnoexe