Many of you may have read in the news about thousands of computers on the Internet that were infected by worms taking advantage of a vulnerability found in Windows networking (the remote procedure call, or RPC, vulnerability).

This included 5,000 computers on the Stanford campus, all of which had to have Windows re-formatted and re-installed. At SLAC, many users with unpatched off-site computers had their remote access disabled, but we had few SLAC-managed Windows computers infected. What lessons can we learn from this?

On July 16, 2003 Microsoft announced the release of a patch for the RPC vulnerability. SCS sent a notice to the user community that all Windows machines needed to be patched by July 25. For SLAC-managed Windows XP machines in Active Directory, the security patch was automatically applied. For SLAC-managed Windows NT 4 and Windows 2000 machines, the local desktop administrators applied the patches.

By July 31, there was news from Stanford University campus that an infected laptop or laptops brought from the outside and then connected to the Stanford network had infected hundreds of machines.

The computer worms responsible for the infection compromised unpatched Windows machines, then took a combination of the following actions:

• Installed code allowing hackers to control the machine remotely

• Applied the RPC patch after infecting the machine (making it more difficult to distinguish a patched machine from a compromised machine)

• Scanned the network and self-replicated to infect more vulnerable computers

• Coded the computers to attack a Microsoft web site at a predetermined date.

To date, fewer than 10 SLAC machines have been infected, and most of these were laptops infected on other networks. Among user-maintained machines (e.g., home machines, personal laptops), more than a dozen infected machines were detected when they connected to the SLAC network. Many more personal computers may have been infected that we did not detect, since these connect to other Internet Service Providers. From August 3 onwards, SLAC remote access (VPN and dialup) was disabled for users whose machines were infected or remained unpatched.

Home computers have become good targets for the recent infection, since many have high-speed connections and yet are not keeping up with security updates.

Why did these user-maintained machines remain unpatched and vulnerable to infection? Sometimes users did not install the patches correctly. Other users have a philosophy of ‘if it ain’t broke, don’t fix it’, and generally do not apply patches. But the result of such inaction may be many hours of re-formatting and re-installing after an infection.

If you do your own maintenance on a personal and home machine, keep these tips in mind:

• Apply all security patches, rebooting when instructed (common errors are stopping after the first patch, and not rebooting when instructed)

• Configure Windows to install updates automatically so that new patches will be automatically applied

• Configure your virus protection software for automatic updates

(see: http://www2.slac.stanford.edu/comp/winnt/faq/homecomputer-securityupdates.htm)

We have been fortunate that SLAC machines suffered few casualties during this round of Windows RPC infection. SCS and the local desktop administrators worked hard to prepare a managed infrastructure where security patches were quickly rolled out to client computers, and computers were scanned for vulnerabilities and then fixed. Thanks also go to the user community for joining in on this network of managed computers.

• If you have not done so already, ask your local desktop administrator to migrate your machine to Windows XP in Active Directory (security updates are automatically done for these managed computers).

• SLAC-managed Windows XP laptops normally get their security updates when they connect back onto the SLAC network. Laptop users should plan for the extra time this will take when they connect after a long absence.

We continue to see new security vulnerabilities and exploits on the most popular operating systems. The continued combination of actions from both SCS and local administrators plus from the user community will be required.