We had another significant response to our monthly forensic challenge from participants of several countries around the globe. Be sure to enter this month at http://www.tigertools.net/contest.htm and remember, as the challenges become more difficult the prizes become more desirable.

From now on we will be highlighting the solutions of our participants to our monthly contest:

March Forensic Challenge (Level: easy/moderate)
Link: http://www.tigertools.net/contest1.htm

<> March Solution by stefmit

1. We will start with a minor observation in regards to the possible parties involved, as far as their Internet connectivity goes:

http://samspade.org

or

http://arin.net

would immediately reveal to us that the 12.211.x.y it is a likely address from the ones provided by AT&T (now Comcast) broadband/cable services. It is - thus - very likely that the perpetrator (later to be actually identified as a "worm generator" - perhaps even unknown to the "distributor") may have started by "poking" around the networks visible from his "segment" of the cable.

Though dynamically assigned, there is a high probability for those addresses to stay the same for most of the clients, thus making even a

$dig -x <ip-addr>

a valid query, for further info gathering (and - if worm generated - offering us the possibility of informing the appopriate parties).

2. The DNS server entry logged was probably caused by an attempt for mapping via a zone transfer of all hosts belonging to the targeted domain. If successful, such an action would have delivered on a "plate" all real hosts on the network (probably DMZ), belonging to the domain being targeted by the intruder. Hopefully this failed, so further (more intrusive) scanning would have had to follow, in order to give the intruder the information needed.

3. There is no log available in regards to possible further information gathering by the intruder (e.g. nmap, other scans, etc.) which could potentially mean one of the followings:

• a. no logs available won't mean that further scanning didn't take place;
• b. the intruder decided to launch the attack regardless of the number of hosts available (i.e. against the whole network as identified by him);
• c. the attack is not "manually" driven, but rather the result of a worm

4. The other pieces of information available - which could further point/narrow down our research - are:

• a. network congestion;
• b. sqlexec entries on the honeypot;
• c. TCP port 1433 opened on PoserToo.

Based on 4a,4b and 4c the most likely scenario is 3c above (a SQL worm of some sort). Considering the 4a (network congestion) ==> looks like the behavior of this worm is similar to the one recently found on the Internet, targeted toward UDP 1434 of unpatched SQL servers, which can have a network congestion effect as briefly described below:

*************************************

Network Based Denial of Service

*************************************

When an SQL Server receives a single byte packet, 0x0A, on UDP port 1434 it will reply to the sender with 0x0A. A problem arises as SQL Server will respond, sending a 'ping' response to the source IP address and source port. This 'ping' is a single byte UDP packet - 0x0A. By spoofing a packet from one SQL Server, setting the UDP port to 1434, and sending it the a second SQL Server, the second will respond to the first's UDP port 1434. The first will then reply to the second's UDP port 1434 and so on. This causes a storm of single byte pings between the two servers. Only when one of the servers is disconnected from the network or its SQL service is stopped will the storm stop. This is a simple network based DoS, reminiscent of the echo and chargen DoSes discussed back in 1996 (http://www.cert.org/advisories/CA-1996-01.html). When in this state, the load on each SQL Server is raised to c. 40 - 60 % CPU time. [http://www.nextgenss.com/advisories/mssql-udp.txt]

*************************************

The entries in the honeypot logs, on the other hand, lead us to believe that this was really a worm (because of attempts of "hitting" all servers available on our network, not only SQL servers), and also that the worm may have been accompanied by a mechanism similar to the ones described here:

http://neworder.box.sk/showme.php3?id=4033

and

http://neworder.box.sk/showme.php3?id=3522

thus explaining the sqlexec entries in the log

5. Other possible sources of "inspiration" for the tools utilized/associated with the worm could be found here:

http://www.sqlsecurity.com/DesktopDefault.aspx?tabindex=5&tabid=7

6. Further investigation would require:

- identification of UDP ports opened on the SQL server(s) (as the denial of service on the network side requires - at least for the known Sapphire/SQLSlammer worm - the 1434-UDP to be opened);

- patch level of the SQL server(s);

- traffic possibly generated by the SQL server(s) - if infected;

- traffic "sniffed" on the network, having as origin at least the DMZ placed SQL server (PoserToo), if not some other internal SQL-based hosts.

7. Measures to be taken: patching SQL servers and blocking TCP and UDP ports 1434 and 1433 at the border router or external interface of the firewall.

8. Relevant links:

http://neworder.box.sk/showme.php3?id=4033

http://neworder.box.sk/showme.php3?id=3522

http://securityresponse.symantec.com/avcenter/venc/data/hacktool.ipstealer.html

http://securityresponse.symantec.com/avcenter/venc/data/js.spida.b.html

http://www3.ca.com/virusinfo/Virus.asp?ID=11903

http://www.eeye.com/html/Research/Flash/AL20030125.html

http://www.eeye.com/html/Research/Advisories/AL20020522.html

http://www.nextgenss.com/advisories/mssql-udp.txt

http://sqlsecurity.com/DesktopDefault.aspx

http://sqlsecurity.com/DesktopDefault.aspx?tabindex=5&tabid=7

<> Results

Congratulations to March Forensic Challenge winners:

NortonLaw
G. Lawren
stefmit
Joe Bloom