c


c
c

c
c
c

cc
c
cc
We have been made aware of a recent blog posting pointing to the fact that the print spooler
vulnerability used by W32.Stuxnet and addressed in the Microsoft Windows Print Spooler Service
Remote Code Execution Vulnerability was in fact known about since 2009. An article was published in a
security magazine that showed how the vulnerability worked in late 2009. We are currently investigating
this; however, from our initial review of that article it appears to do exactly what Stuxnet does when
exploiting the Print Spooler vulnerability͙
~Symantec.com blogs


cc


c
The Stuxnet virus had Remote Procedure Call (PRC) functionality that exploited the ͞zero-day͟ .lnk file
vulnerability. This enabled Server Client and Peer to Peer (P2P) communications and remote code
execution, among other things. Reminiscent of the agent.btz incidents of 2008-9, the stuxnet worm
utilized a Server-Client protocol to facilitate information exchange and command. By default,
W32.Stuxnet always sends the IP address, name of the computer, and name of the workgroup or
domain infected computers were a part of to the command-and-control server.

Coinciding with the disappearance of these control servers, Symantec analysis is showing the emergence
of a P2P component being added to the stuxnet code base. The highlighted functionality in this category
represented:

Server Functions

- 0: returns the version number of Stuxnet installed

- 1: Receive an exe and execute it (via injection)
- 2: load module and executed export
- 3: inject code to lsass and run it
- 4: Builds the latest version of Stuxnet and send to remote machine
- 5: create process
- 6: read file
- 7: drop file
- 8: delete file
- 9: write data records

Client Functions

Ö c


      
 c

     
   
 c      


    ! 
  c 
   
" c  
#$%
 &
 ' 

     ( 

 % (  
  
"  (  
 #
 

 Ö 

Therefore, Even in the absence of an available control server, this virus is capable of updating and
modifying its behavior through networks of Stuxnet infected computers.

p
 
 


 
The Print Spooler Vulnerability, in tandem with existing elevation of privileges, then permits additional
LAN based propagation. The ͞attacking͟ entity simply sends a print request via RPC. The client under
attack may permit this request which then saves the information into the ͞SYSTEM32͟ folder; a folder
with elevated privilege and write protection. Once the code is saved here, it is ran remotely... This
vulnerability, popularly referred to as a ͞Zero-Day͟ vulnerability, has been known about since 2009:
Patched with MS10-061.

 
 

Prior to the .lnk infection method, older versions of the Stuxnet worm contain relics of a USB infiltration
method. This is achieved through an autorun function within windows. When this function executes, the
autorun.inf file on the USB͛s root directory . The autorun file serves to direct the host operating system
as to which files to execute when loading or other actions to take. Unfortunately, the autorun function
within windows simply ignores input that it does not recognize as legitimate autorun behavior. The
function continues to parse past the unrecognized information until it reaches the end of the file, or
recognizable operations. The autorun file, therefore, has the potential to front load malicious code into
this file and then follow with legitimate autorun commands. Such autorun functionality could include:
͞.Menu\command=.\AUTORUN.INF͟
which was included in released code snippets from stuxnet. THUS, the autorun file calls itself to run the
previously disregarded code.

Alternatively, autorun is a commonly protected vulnerability. Many knowledgeable PC users typically

disable this functionality, if not for security perhaps for desire to disable pesky dialogs. Stuxnet͛s
designers preempted this case by altering the right click menu through the same autorun file to insert a
new ͞Open͟ function which called the malicious code.

USB propagation of the worm is reminiscent of a very similar attack conducted in 2008. The analysis and
the review in the articles below showed that a particular incident, ͞agent.btz worm,͟ was silently
propagating for 3 years within US CLASSIFIED SYSTEMS. It then took something like 14-18 months to
effectively root out the infections.

http://www.wired.com/dangerroom/tag/operation-buckshot-yankee

http://articles.latimes.com/2008/nov/28/nation/na-cyberattack28
propogate x3

shared drive infections

wincc database server vulnerability

PLC infection via Digital Signings