Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.
Security Response

Stuxnet Before the .lnk File Vulnerability

Created: 24 Sep 2010 08:42:33 GMT • Updated: 23 Jan 2014 18:24:52 GMT • Translations available: 日本語
Liam O Murchu's picture
+8 8 Votes
Login to vote

Code to exploit the zero-day .lnk file vulnerability (BID 43073) used by Stuxnet was added to the threat around March 2010; we know this because the samples we observed before this date did not contain code to exploit that vulnerability. This leads us to the following question: how did previous Stuxnet variants spread through removable devices?

 
The answer is that older versions did not use a vulnerability but instead an AutoRun trick to spread. The worm’s trick was to create an autorun.inf file in the root of removable drives that served two different purposes. The specially crafted file could be interpreted as either an executable file or as a correctly formatted autorun.inf file. When Windows parses autorun.inf files the parsing is quite forgiving. Specifically, any characters that are not understood as being part of legitimate AutoRun commands are skipped as garbage and parsing continues. Stuxnet uses this fact to its advantage by placing the MZ file first within the autorun.inf file. When Windows parses the autorun.inf file all of the MZ content will be ignored as garbage until the legitimate AutoRun commands that are appended at the end of the file are encountered. The header and footer of the autorun.inf file can be seen in the following diagrams:
 
Header of the autorun.inf file:
 
 
Footer of the autorun.inf file:
 
 
By extracting only the strings from the footer we can see that the they are composed of legitimate AutoRun commands:
 
 
 
 
Notice that the AutoRun commands specify the autorun.inf file itself as the file to be executed (highlighted in red in the image above). Using this trick the autorun.inf file will first be treated as a legitimate autorun.inf file and then as a legitimate executable file (and thus the worm’s code is executed).
In addition to this cunning ploy, Stuxnet uses another trick to increase the likelihood that it will be executed. The AutoRun commands shown above first turn off AutoPlay and then add a new command to the context (i.e. right-click) menu. The command that is added is found in %Windir%\system32\shell32.dll,-8496, which actually works out to be the “Open” string. This means that when viewing the context menu for the removable device the user will actually see two “Open” commands, as seen in the following screenshot:
 
 
 
 
One of these commands is legitimate and the other has been added by Stuxnet. If a user chooses to open the drive via the malicious “Open” menu command then the worm will execute as per the command in the autorun.inf file. The Stuxnet code then opens an Explorer window and displays the contents of the drive to the user so it appears that nothing untoward has happened. It should be noted that the success or otherwise of the above tricks depends on the AutoPlay and AutoRun settings on the computer and that disabling such features can help to mitigate against worms that use them to spread.
 
This is just one little surprise of the many that Stuxnet has held for us. We predict that there are probably a few more still left within this threat…