IDS Signature Analysis

Intrusion Detection System (IDS) signature analysis is similar to the analysis that antivirus programs provide. In short, the sensor looks not only at the header information, flags set, and packet shape, but also at the contents of the datagram—typically referred to as the packet payload. The sensor is looking for the payload information, which carries the instructions to be executed at the destination. If you’ve never performed packet capture or network analysis on your own network, packet payload can seem mysterious. Figure A shows the partial payload of a recent capture posted to an incidents mailing list.

The output begins with the alert description

[**] MS-SQL xp_cmdshell -  program execution [**])

The second line shows the date and time of capture and the source and destination addresses (commented out to protect the networks in question)

11/20-08:01:48.923210 x.x.92.228:3348  -> x.x.200.115:1433

The numbers that follow each address are the source (3348) and destination (1433, the standard Microsoft SQL Server TCP port) ports. As with all ordinary IP traffic, the source address can be any ephemeral number (a randomly chosen number greater than 1024 that the source server selects), but the destination address is predictable for most common services. (You can find the standard ports in your services file, typically located in the winntsystem32driversetc directory.)

The first term on the third line, TCP, denotes that this packet was a TCP packet rather than an Internet Control Message Protocol (ICMP) or UDP packet, with a Time to Live (TTL) of 127—a number that indicates what Internet Engineering Task Force (IETF) Request for Comments (RFC) 791 determines as the upper boundary of the datagram’s lifetime (in number of network hops), as well as a standard Type of Service (TOS) of 0 (0 represents "standard messages," whereas a 3 would represent "uncontrolled" messages).

TCP TTL:127 TOS:0x0 ID:45385  IpLen:20 DgmLen:972 DF

So far, nothing appears to be unusual (unless external folks shouldn’t be talking to your SQL server to begin with), but let’s look further.

The fourth line, which contains the flag bits, is a good place to look for strange goings-on.

***AP*** Seq: 0x318F3D1  Ack: 0x1E5807AD  Win: 0x2098  TcpLen: 20

In the case of this datagram, setting both Ack and Push (which "AP" at the beginning of the line indicates), is perfectly fine from a protocol standpoint and doesn’t set off any alarms. The rest of the header looks fine as well. So far, this datagram doesn’t seem problematic. If your firewall permitted it (i.e., the source could talk to the destination on the port and protocol specified here), the datagram would pass right through.

After the header ends, the payload begins. What appears to be a "box" of gibberish, made up of the first part of each line with its 16 pairs of characters, presents the hexadecimal equivalent of the data. The second part of each line presents the ASCII equivalent of the same data. This particular capture turned out to be the payload signature for the CBlade SQL Worm exploit. The worm attempts to take over the Master database and the systems administrator account. After the worm connects, it executes the xp_cmdshell stored procedure to execute other commands. The seventh line in the payload section shows the worm trying to make an outgoing FTP connection to get the rest of the worm payload.