Introduction to patch management |
 |
By Anne Stanton and Susan Bradley
22 Dec 2004 | Ecora |
|
|
 Get a glimpse inside the e-book "The complete patch management book" by Anne Stanton, president of Norwich Group, and Susan Bradley, Microsoft Small Business Server MVP. This series of book excerpts will help you navigate Chapter 1, "What is patch management?," courtesy of Ecora. Click for the complete book excerpt series.
Book introduction
Susan was having a quiet evening at home, a Friday night in late January, just trying to pay for an eBay purchase. "Dang, it's still not going through," she said after the paypal.com Web site refused to accept her payment information and was extremely slow in responding. "They must be having issues with their server, I'll have to try it tomorrow morning," she told her sister who had just won the online auction and wanted to pay for the item quickly. The next morning, as the computer booted up and went to Susan's home page she read the news and found out the reason why she could not complete her transaction the night before.
"Computer worm hits the 'Net," screamed the headline on CNN.
SQL Slammer, Sapphire, W32.Slammer whatever you want to call it, was tiny as worm files go, only 376 bytes of code designed for speed. Typical computer transactions involve a "hand shake" transmission process. One party offers a connection, another party accepts, and the transmission proceeds by means of traditional TCP/IP processes. SQL slammer, however, used another transmission standard. It transmitted UDP packets only, through a connectionless transmission. This worm did not wait for a response. It flooded all vulnerable connections it could find.
That high-speed little file was looking for a port that had behind it, ready and waiting, a listening application. The Internet Assigned Numbers Authority (IANA.org) maintains the listing of computer ports used by programs, applications and typical connections on the Internet. A computer system has almost 65,000 ports to transmit information back and forth. Typically, these ports sit there waiting, but sometimes they are in "listening" mode, waiting to be called upon.
Most worms would typically try to find vulnerable systems on well-known ports, those ports from 0 to 1023. SQL slammer was different. It aimed at a port not used in previous attacks, port 1434. This is a port used by database programs such as Microsoft SQL server and something called MSDE or Microsoft SQL Database Engine. Microsoft SQL Server is a very powerful database program typically run on maintained and monitored servers. The other, MSDE, it a small but powerful database engine used by developers in many applications. Furthermore, port 1434 is unique. It is not a port used to transmit data; rather it monitors SQL transmissions. All Microsoft SQL servers listen on this port. Not all MSDE installations do however.
The tiny worm's tale includes a couple of other twists. Developers use MSDE in many applications, but do not necessarily tell purchasers that their software uses MSDE to keep track of something needed for the application's operation. At the time Slammer struck, patching SQL server or MSDE was difficult and cumbersome, needing the patch installer to understand SQL instances. While the original patch to fix the vulnerability came out in July of 2002, the rollup service pack had just recently come out about three weeks before Slammer appeared.
In early 2003, three weeks was not enough time to have server admins or application developers test and install a service pack. Database administrators were (and still are) reluctant to install patches on working databases, so installing the rollup pack was not a priority. Furthermore, all the unpatched computers equipped with MSDE were primarily in installations where the administrator had no idea that he or she had MSDE installed. Their software vendors had not informed them, nor did they have a tool to identify machines that were running MSDE.
Thus, the stage was set for the worm: unpatched machines, unidentified machines that were also unpatched, a worm built for fast connections, a port never used before for worm attacks, and a port not used for data, only monitoring. Overall, we had a "perfect storm" for unleashing the worm. The news reports indicated that the major ISPs and backbone providers of the Internet knew within minutes that something was up. Realize that unlike Code Red that took 24 hours to go around the world infecting the globe, SQL slammer was around the world in 30 minutes.
Footnote: "Analysis of the Sapphire worm - A joint effort of CAIDA, ICSI, Silicon Defense, UC Berkeley EECS and UC San Diego CSE," retrieved Aug. 29, 2004.
Click for the next excerpt in this series: What is patch management?
Click for book details or get more information from Ecora.
|
|
|
|
