Network Security: May 2009

Sunday, May 31, 2009

The National Cyber Security Effort

Inside the last three months, I have restarted my network security business: RMF Network Security (www.rmfnetworksecurity.com). I have been in research mode and I am still in some type of stealth mode, as I think about the implications of restarting a consulting business in the ever dangerous and now crime-ridden world of network security. The last time I did this, I didn't do enough "product development" and research in advance of my marketing efforts.

However, the last year of network security 'awareness' may change my need to do extensive marketing. Our President has just announced the results of the sixty day Cyber Security Review. More than 100 source papers were consulted. See my initial analysis below. I started this obscure blog with the idea that I could use the motivation of internet publishing to gauge my re-education and business progress. Inside the first month, I have had the same extensive (web interest) in my blog from American military, military-industrial complex, telecom, educational institutions that I had with my Powershell Blog (also network centric), but this time with lots of added hits now from Russia, China, ex-Eastern bloc and Brazil IP addresses. Interestingly, 'researchers' are mostly finding their way to my blog by googling IP addresses from my script dumps!

Apparently, my visitors are either expressing interest in the same Source Internet Protocol Addresses I am logging (SIPs) simultaneously or (worse case), those SIPs are looking at me while I discuss them. The network security business has changed since I last participated in developing IDS systems with NAI and Hiverworld. Things are bigger, badder and scarier - more criminal and nation-state oriented simultaneously. Firewalls and IPS software are being pushed beyond their intended capacities and organized crime and nation-state terrorists have become systemized at IPS evasion, spamming, botnets, bot herding, inserting key stroke loggers, malware, etc. "Cyberwarfare" has a new and significant government interest. Here are some reads I have found lately to prepare myself for changes in the field:

* "The Shadow Government" (James Bamford) This book documents the build-out in the cyber capacities of the National Security Agency in the last 8 years. Among other discussions it documents how the NSA has purchased industrial strengthcontext searching software from select software companies to analyze traffic from top network access points across all U.S. telecoms. This apparently is the book that broke the "warrantless wiretapping" scandal a year or so back.

* "McMafia" Misha Glenny discusses in detail recruitment the young and poor as cyber hackers for nation state terrorists and criminal organizations in Russia, Brazil, China, ex-Eastern Bloc nations and elsewhere. He also discusses world crime and world crime sophistication to date. A downright terrifying read. Apparently, the average computer in the U.S. is seen as a potential botnet member by most of the world's criminal syndicates/hackers.

* FOIA from Wired Magazine on the FBI's CIPAV spyware : http://www.wired.com/threatlevel/2009/04/get-your-fbi-sp Also a very inetersting read...Criminals use spyware and so does our government...Surprise!

I had some difficultly searching all the 100 assorted papers on line at http://www.whitehouse.gov/cyberreview/documents/ and resorted to mixing Cygwin and cmd.exe shells to do so. I did an initial context search, which admittedly lost papers and data at each command line. In any event, the papers may prove interesting reading yet, although they appear at first glance more policy oriented than technical.

[from cmd.exe or Cygwin]

lynx -source http://www.whitehouse.gov/cyberreview/documents/ | grep pdf | gawk -F\" '{print $4}' > source.txt

[from cmd.exe]

for /f "delims==" %i in (source.txt) do wget "%i"

[from cmd.exe or Cygwin]

ls -1 *.pdf > source2.txt

[from cmd.exe]

@(for /f "delims==" %i in (source2.txt) do pdftotext -f 1 -l 1500 "%i" pdf.txt && cat pdf.txt >> pdf.all.txt)

[from Cygwin]

for i in `cat file`; do echo `pcregrep -w -i -c $i pdf.all.txt` `echo $i` >> context1.txt;done

[from Cygwin]

$ cat context1.txt | sort -nr

499 Infrastructure

215 Services

194 Financial

53 criminal

52 crime

45 organized

45 loss

41 spam

39 malware

27 losses

24 Firewalls

20 botnets

16 Firewall

15 tax

14 organize

14 crimes

14 China

12 botnet

9 Russia

7 Linux

6 Windows

5 IDS

4 trojans

4 bot

4 IPS

3 bots

2 trojan

2 Israel

2 India

1 IE

1 France

1 Firefox

1 Apple

0 tcpdump

0 syslogd

0 sysklogd

0 spamming

0 keyloggers

0 keylogger

0 key-strokes

0 key-stroke

0 evasion

0 Snort

0 QNX

0 Opera

0 OpenBSD

0 Chrome

0 Bulgaria

0 Brazil

0 BRIC

If you are interested and have the time, let me know if you find my blog approachable, and what interests you think would most drive your businesses and professions to read and think about network security. I think I am gearing up to producing some white papers tailored to many audience types: business, personal, home user, etc. The goal is to generate interest for consulting contracts.

Wednesday, May 27, 2009

Homegrown tcpdump/snort analysis

I have written a script which parses snort and/or tcpdump text files to display significant information for Source and Destination IPs and ports.This script allows for some flexibility in filtering ports and ultimately produces separate files for each query and summary statistics as shown below. Tcptrace does similar work but I thought I would contribute something homegrown before I started looking in depth at existing tcp/IDS trace analysis tools.

## bash or ksh script to sort IP addresses from tcpdump or snort text output
## version 0.1 May 23 2009
## requires one argument: file name consisting of text dump of snort or tcpdump output
## requires pcregrep, awk,nmap services file, geoiplookup

/* rest of script here: http://www.rmfdevelopment.com/UnixShellScripts/LocateIP.sh.txt */

[some sample output:]
......Summary Statistics........
248 unique Source IP/ port pairs
190 unique source addresses
155 unique source ports
125 unique Destination IP/port pairs
6 unique destination addresses
124 unique destination ports
42 Source ports recognized by nmap services file
38 Destination ports recognized by nmap services file
190 Source cities recognized by GeoLiteCity.dat

[some sample files produced]
# ls -1 uniq*
uniqDIP.txt
uniqDIPPorts.txt
uniqDestIPs.txt
uniqIPs.txt
uniqSIP.txt
uniqSIPPorts.txt
uniqSourceIPs.txt

Sunday, May 17, 2009

Host Protection: Working with Microsoft's Firewall

Both network and host protection are recommended. Each OS has native firewall host protection:

OpenBSD: pf

FreeBSD: pfsense

Fedora Cora: iptables with SELinux

Windows XP,2003,2008,Vista,7 : Windows Firewall (ICF)

Microsoft's native firewall on XP SP3 can be told to log all incoming and outgoing packets up to a maximum log size of 32676 bytes(2^15). It will turn over twice before rewriting the old log file name. A full examination of the Firewall's configuration is beyond the scope of this post. A regedt32 query of StandardProfiles and DomainProfiles for all Control Sets for all globally open ports and authorized applications is recommended as is a manual exploration of the appropriate regedt32 keys. (Netsh commands are available for all Firewalled Windows. Please see http://support.microsoft.com/kb/947709 . Powershell can also be used to configure Microsoft's Firewall. ):

regquery HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\AuthorizedApplications\List | findstr Enabled

reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\GloballyOpenPorts\List | findstr Enabled

reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\DomainProfile\AuthorizedApplications\List | findstr Enabled

reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\DomainProfile\GloballyOpenPorts\List | findstr Enabled

reg query HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\AuthorizedApplications\List | findstr Enabled

reg query HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\GloballyOpenPorts\List | findstr Enabled

reg query HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\SharedAccess\Parameters\FirewallPolicy\DomainProfile\AuthorizedApplications\List | findstr Enabled

reg query HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\SharedAccess\Parameters\FirewallPolicy\DomainProfile\GloballyOpenPorts\List | findstr Enabled

A sample partial result would be:

reg query HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\GloballyOpenPorts\List | findstr Enabled

139:TCP REG_SZ 139:TCP:LocalSubNet:Enabled:@xpsp2res.dll,-22004

445:TCP REG_SZ 445:TCP:LocalSubNet:Enabled:@xpsp2res.dll,-22005

137:UDP REG_SZ 137:UDP:LocalSubNet:Enabled:@xpsp2res.dll,-22001

138:UDP REG_SZ 138:UDP:LocalSubNet:Enabled:@xpsp2res.dll,-22002

53:UDP REG_SZ 53:UDP:LocalSubNet:Enabled:DNS-UDP

53:TCP REG_SZ 53:TCP:LocalSubNet:Enabled:DNS

500:UDP REG_SZ 500:UDP:*:Enabled:@xpsp2res.dll,-22017

The pfirewall.log gives a considerable amount of information as such:

more pfirewall.log

#Version: 1.5

#Software: Microsoft Windows Firewall

#Time Format: Local

#Fields: date time action protocol src-ip dst-ip src-port dst-port size tcpflags tcpsyn tcpack tcpwin icmptype icmpcode info path

2009-04-23 10:24:55 DROP UDP 192.168.0.4 192.168.0.255 137 137 96 - - - - - - - RECEIVE

2009-04-23 10:24:56 DROP UDP 192.168.0.4 192.168.0.255 137 137 96 - - - - - - - RECEIVE

2009-04-23 10:24:57 DROP UDP 192.168.0.4 192.168.0.255 137 137 96 - - - - - - - RECEIVE

2009-04-23 10:24:57 DROP UDP 192.168.0.4 192.168.0.255 138 138 202 - - - - - - - RECEIVE

2009-04-23 10:24:57 DROP UDP 192.168.0.4 192.168.0.255 137 137 78 - - - - - - - RECEIVE

2009-04-23 10:24:57 DROP UDP 192.168.0.4 192.168.0.255 137 137 96 - - - - - - - RECEIVE

....

Using Cygwin's Bash client and gawk, a list of src and dst ports can be obtained:

cat /cygdrive/D/pfirewall.log | awk -F" " '{print $7}' | sort -nr | uniq -c | sort -nr | more

cat /cygdrive/D/pfirewall.log | awk -F" " '{print $8}' | sort -nr | uniq -c | sort -nr | more

Gawk's conditional logic coupled with pcregrep quick searching helps us print the frequency of a destination IP and accompanying port(s) for a specified source IP:

cat /cygdrive/D/pfirewall.log | pcregrep OPEN | awk -F" " '{if ($5=="192.168.0.8") print $6 ":" $8}' | sort -nr | uniq -c | sort -nr | more

16138 192.168.0.1:53

902 192.168.0.1:80

446 74.125.242.24:80

359 65.214.57.165:80

304 216.73.87.115:80

272 85.13.200.108:110

247 70.32.92.85:80

240 216.73.87.152:80

215 75.101.163.8:80

208 68.142.93.133:80

203 74.125.127.191:80

201 128.111.41.37:80

....

Now we choose to sort by the frequency of one specific dst port for each dst IP from the specified (local) source IP:

cat /cygdrive/D/pfirewall.log | pcregrep OPEN | awk -F" " '{if ($5=="192.168.0.8") print $6 ":" $8}' | sort -nr | uniq -c | pcregrep ':443' | sort -nr

113 74.125.53.147:443

92 74.125.53.83:443

78 208.235.248.150:443

50 208.75.76.32:443

46 74.125.127.103:443

30 74.125.53.97:443

24 74.125.127.120:443

23 65.55.157.60:443

22 96.6.248.124:443

21 74.125.53.99:443

...

For example, I was surprised to find all the foreign addresses that my local computer asked NBNS queries of:

cat /cygdrive/D/pfirewall.log | pcregrep OPEN | awk -F" " '{if ($5=="192.168.0.8") print $6 ":" $8}' | sort -nr | uniq -c | pcregrep ':137' | sort -nr

42 192.168.0.4:137

39 192.168.0.6:137

36 192.168.0.2:137

16 192.168.0.9:137

15 206.51.224.187:137

14 208.117.252.85:137

14 192.168.0.1:137

13 206.72.124.93:137

11 74.125.103.33:137

10 64.94.107.20:137

10 64.236.79.54:137

10 206.191.161.8:137

...

The dates and times of those queries could be found with:

cat /cygdrive/D/pfirewall.log | pcregrep OPEN | awk -F" " '{if ($5=="192.168.0.8") print $1 ":" $4 ":" $6 ":" $8}' | pcregrep ':137' | sort -nr | more

2009-05-14:UDP:192.168.0.4:137

2009-05-06:UDP:75.52.124.131:137

2009-05-06:UDP:74.125.103.28:137

2009-05-06:UDP:69.64.6.21:137

2009-05-06:UDP:66.35.45.202:137

2009-05-06:UDP:66.35.45.201:137

2009-05-06:UDP:65.55.52.84:137

2009-05-06:UDP:65.55.52.148:137

2009-05-06:UDP:65.55.185.61:137

2009-05-06:UDP:65.55.185.29:137

2009-05-06:UDP:65.55.184.189:137

2009-05-06:UDP:65.173.218.69:137

2009-05-06:UDP:64.94.107.16:137

2009-05-06:UDP:64.236.115.52:137

2009-05-06:UDP:4.71.104.187:137

....

These two commands are also recommended:

C:\WINDOWS\system32\drivers\etc>net config server

C:\WINDOWS\system32\drivers\etc>net config workstation

Friday, May 15, 2009

Bash 4.0,awk,geoiplookup and pcregrep are fast

Bash 4.0,awk,geoiplookup and pcregrep make a powerfully fast search team. Here I find out how many sockets pairs are in my Snort dump:

bash-4.0# snort -qdevX -r May12085154PDT2009.1242143514 | pcregrep TTL | awk -F":" '{print $1}' | wc -l

372

Then I find out how many uniqe SIPs are in those socket pairs:

bash-4.0# snort -qdevX -r May12085154PDT2009.1242143514 | pcregrep TTL | awk -F":" '{print $1}' | uniq | sort -nr | wc -l

226

Then I find my top ten Source IP Addresses:

bash-4.0# snort -qdevX -r May12085154PDT2009.1242143514 | pcregrep TTL | awk -F":" '{print $1}' | sort | uniq -c | sort -nr | head -n 10

62 218.103.62.150

15 222.215.230.49

14 221.195.73.68

11 121.15.245.215

10 119.161.130.75

8 209.85.163.126

8 125.65.165.139

7 66.35.46.195

7 209.85.201.125

6 64.106.128.150

....

Then I determine what source ports my top SIP (foreign address) has initiated connections to:

bash-4.0# snort -qdevX -r May12085154PDT2009.1242143514 | pcregrep 218.103.62.150 | awk -F":" '{print $3}'| awk -F" " '{print $1}' | sort -n | uniq

113

160

1433

1434

2967

5554

6429

7212

12712

16896

17337

17681

17919

18448

18487

18488

18649

18932

19899

33436

38507

Next I find what are the top source ports for my top ten SIPs:

bash-4.0# for i in `cat temp.txt`; do echo $i && snort -qdevX -r May12085154PDT2009.1242143514 | pcregrep $i | awk -F":" '{print $3}'| awk -F" " '{print $1}' | sort | uniq -c | sort -nr; done

218.103.62.150

3 6429

3 5554

3 38507

3 33436

3 2967

3 19899

3 18932

3 18649

3 18488

3 18487

3 18448

3 17919

3 17681

3 17337

3 16896

3 160

3 1434

3 1433

3 12712

3 113

2 7212

222.215.230.49

6 7212

6 3128

3 8000

221.195.73.68

7 8000

7 7212

121.15.245.215

7 3128

4 8000

119.161.130.75

10 2967

209.85.163.126

8 33137

125.65.165.139

4 8000

4 3128

66.35.46.195

7 33436

209.85.201.125

3 18205

3 18184

1 18077

64.106.128.150

6 33442

Last, I retrieve those top ten SIP city locations:

bash-4.0# for i in `cat temp.txt`; do echo $i `snort -qdevX -r May12085154PDT2009.1242143514 | geoiplookup $i -f /usr/local/share/GeoIP/GeoLiteCity.dat` ;done

218.103.62.150 GeoIP City Edition, Rev 1: HK, 00, Kowloon, (null), 22.316700, 114.183296, 0, 0

222.215.230.49 GeoIP City Edition, Rev 1: CN, 32, Chengdu, (null), 30.666700, 104.066597, 0, 0

221.195.73.68 GeoIP City Edition, Rev 1: CN, 10, Hebei, (null), 39.889702, 115.275002, 0, 0

121.15.245.215 GeoIP City Edition, Rev 1: CN, 30, Jiangmen, (null), 22.583300, 113.083298, 0, 0

119.161.130.75 GeoIP City Edition, Rev 1: CN, 19, Chaoyang, (null), 41.570301, 120.458603, 0, 0

209.85.163.126 GeoIP City Edition, Rev 1: US, CA, Mountain View, 94043, 37.419201, -122.057404, 807, 650

125.65.165.139 GeoIP City Edition, Rev 1: CN, 32, Chengdu, (null), 30.666700, 104.066597, 0, 0

66.35.46.195 GeoIP City Edition, Rev 1: US, CO, Denver, 80216, 39.785000, -104.941498, 751, 303

209.85.201.125 GeoIP City Edition, Rev 1: US, CA, Mountain View, 94043, 37.419201, -122.057404, 807, 650

64.106.128.150 GeoIP City Edition, Rev 1: US, NJ, Hoboken, 07030, 40.745800, -74.032097, 501, 201

Wednesday, May 13, 2009

Understanding an attack

Snort can be run in daemon mode, with a configuration file that logs on certain alerts only. For demonstration, we can run Snort in 'packet dump' mode (-dev) for a day or so while using BPF filters for our own needs:

/usr/local/bin/snort -devX -i xl0 -L $(date "+%b%e%H%M%S%Z%Y") 'port not(domain or whois or http or https or syslog or ntp or smtp or 137 or 139)' and 'not(broadcast or icmp or igmp or arp)'

After some awkward awk statements and some ditzy KSH work, we have a list of ports others who are seeking our network seem interested in:

snort -vdeX -r May12085154PDT2009.1242143514 | grep TTL: | awk -F"->" '{print $1 ":" $2 ":" $3}' | awk -F":" '{print $4}' | awk -F" " '{print $1}' | sort -nr | uniq -c | sort -nr

14 2967
6 8000
6 5900
6 3128
6 22
5 23
5 1434
5 12712
4 7212
4 4899
4 1433
1 8080
1 7209
1 65535
1 56017
1 3306
1 23803
1 21
1 19756
1 19696
1 1024

snort -vdeX -r May12085154PDT2009.1242143514 | grep TTL: | awk -F"->" '{print $1 ":" $2 ":" $3}' | awk -F":" '{print $4}' | awk -F" " '{print $1}' | sort | uniq | sort -nr >> ports.txt

for i in `cat ports.txt`; do grep -w $i /usr/local/share/nmap/nmap-services;done

http-proxy 8080/tcp # Common HTTP proxy/second web server port
http-alt 8000/tcp # A common alternative http port
vnc 5900/tcp # Virtual Network Computer display
radmin 4899/tcp # Radmin (www.radmin.com) remote PC control software
mysql 3306/tcp # mySQL
squid-http 3128/tcp #
symantec-av 2967/udp # Symantec AntiVirus (rtvscan.exe)
ms-sql-m 1434/tcp # Microsoft-SQL-Monitor
ms-sql-m 1434/udp # Microsoft-SQL-Monitor
ms-sql-s 1433/tcp # Microsoft-SQL-Server
ms-sql-s 1433/udp # Microsoft-SQL-Server
kdm 1024/tcp # K Display Manager (KDE version of xdm)
telnet 23/tcp #
telnet 23/udp #
ssh 22/tcp # Secure Shell Login
ssh 22/udp # Secure Shell Login
ftp 21/tcp # File Transfer [Control]
ftp 21/udp # File Transfer [Control]

Nmap services file helps explain much here, but why the large interest in a Symantec AntiVirus port? It turns out others have noticed this recently as well and are asking for input:

http://isc.sans.org/diary.html?storyid=6319.
http://msmvps.com/blogs/harrywaldron/archive/2006/11/27/new-botnet-impacts-symantec-client-port-2967-on-unpatched-pcs.aspx
http://www.offensivecomputing.net/?q=node/403

Is this a new or mutated trojan? worm? remote exploit? Multiple addresses are interested in connecting to us on this port:

# snort -vdeX -r May12085154PDT2009.1242143514 | grep TTL: | grep 2967 | sort -nr | uniq -c | sort -nr

3 218.75.95.242:6000 -> 192.168.0.12:2967 TCP TTL:105 TOS:0x20 ID:256 IpLen:20 DgmLen:40
2 119.161.130.75:6000 -> 192.168.0.12:2967 TCP TTL:99 TOS:0x20 ID:256 IpLen:20 DgmLen:40
1 61.191.63.8:6000 -> 192.168.0.12:2967 TCP TTL:103 TOS:0x20 ID:256 IpLen:20 DgmLen:40
1 61.145.62.75:6000 -> 192.168.0.12:2967 TCP TTL:107 TOS:0x20 ID:256 IpLen:20 DgmLen:40
1 60.173.12.60:6000 -> 192.168.0.12:2967 TCP TTL:106 TOS:0x20 ID:256 IpLen:20 DgmLen:40
1 60.172.229.11:6000 -> 192.168.0.12:2967 TCP TTL:105 TOS:0x20 ID:65419 IpLen:20 DgmLen:40
1 60.172.229.11:6000 -> 192.168.0.12:2967 TCP TTL:105 TOS:0x20 ID:42349 IpLen:20 DgmLen:40
1 222.186.26.93:6000 -> 192.168.0.12:2967 TCP TTL:103 TOS:0x20 ID:256 IpLen:20 DgmLen:40
1 121.140.174.105:6000 -> 192.168.0.12:2967 TCP TTL:107 TOS:0x20 ID:256 IpLen:20 DgmLen:40
1 121.14.156.149:6000 -> 192.168.0.12:2967 TCP TTL:102 TOS:0x20 ID:256 IpLen:20 DgmLen:40
1 121.14.156.148:6000 -> 192.168.0.12:2967 TCP TTL:103 TOS:0x20 ID:256 IpLen:20 DgmLen:40

But the packet looks like a simple connection attempt to a remote port. A buffer overflow in Symantec AntiVirus port?

218.75.95.242:6000 -> 192.168.0.12:2967 TCP TTL:105 TOS:0x20 ID:256 IpLen:20 DgmLen:40
******S* Seq: 0x60B40000 Ack: 0x0 Win: 0x4000 TcpLen: 20
0x0000: 00 60 97 30 6B C4 00 09 5B 00 F3 DA 08 00 45 20 .`.0k...[.....E
0x0010: 00 28 01 00 00 00 69 06 55 BE DA 4B 5F F2 C0 A8 .(....i.U..K_...
0x0020: 00 0C 17 70 0B 97 60 B4 00 00 00 00 00 00 50 02 ...p..`.......P.
0x0030: 40 00 F1 34 00 00 00 00 00 00 00 00 @..4........

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

05/13-12:59:50.507559 0:9:5B:0:F3:DA -> 0:60:97:30:6B:C4 type:0x800 len:0x3C
121.140.174.105:6000 -> 192.168.0.12:2967 TCP TTL:107 TOS:0x20 ID:256 IpLen:20 DgmLen:40
******S* Seq: 0x4260000 Ack: 0x0 Win: 0x4000 TcpLen: 20
0x0000: 00 60 97 30 6B C4 00 09 5B 00 F3 DA 08 00 45 20 .`.0k...[.....E
0x0010: 00 28 01 00 00 00 6B 06 66 06 79 8C AE 69 C0 A8 .(....k.f.y..i..
0x0020: 00 0C 17 70 0B 97 04 26 00 00 00 00 00 00 50 02 ...p...&......P.
0x0030: 40 00 60 0B 00 00 00 00 00 00 00 00 @.`.........

Tuesday, May 12, 2009

A Brief Anatomy of Malware detection and some notes on using traceroute and determining 'intent'

From the posts below we can begin to understand why signature identification is so important. We are looking for malware in the packet data itself since any port can be used to send malware and any IP can be spoofed or unwittingly part of a botnet or worm. The packets below are indicative of the "Win32:SQLSlammer" worm attack that has been around for a considerable time. The worm propagates itself by generating random IP addresses. Notice that the first SIP (Source IP) address is either spoofed or "router leakage" : e.g. it comes from RFC1918 "private" (non-internet IPs) subnet: 10.255.255.255. Remember that any of these IP addresses can be either (a) spoofed or (b) botnet victims or (c) unpatched SQL servers so that their ultimate location may not neccessarily tells us anything about 'intent' or 'bad actors'. Note the common signature in these 376 byte packets. The "Win32:SQLSlammer" reeked an extraordinary amount of havoc upon the internet with a very small amount of assembly code. The current Snort rules for this worm look like this:

alert udp $EXTERNAL_NET any -> $HOME_NET 1434 (msg:"SQL Worm propagation attempt"; flow:to_server; content:"|04|"; depth:1; content:"|81 F1 03 01 04 9B 81 F1 01|"; content:"sock"; content:"send"; metadata:policy balanced-ips drop, policy security-ips drop; reference:bugtraq,5310; reference:bugtraq,5311; reference:cve,2002-0649; reference:nessus,11214; reference:url,vil.nai.com/vil/content/v_99992.htm; classtype:misc-attack; sid:2003; rev:12;)

alert udp $HOME_NET any -> $EXTERNAL_NET 1434 (msg:"SQL Worm propagation attempt OUTBOUND"; flow:to_server; content:"|04|"; depth:1; content:"|81 F1 03 01 04 9B 81 F1|"; content:"sock"; content:"send"; metadata:policy balanced-ips drop, policy security-ips drop; reference:bugtraq,5310; reference:bugtraq,5311; reference:cve,2002-0649; reference:nessus,11214; reference:url,vil.nai.com/vil/content/v_99992.htm; classtype:misc-attack; sid:2004; rev:11;)

The packets I captured are below. Note the common ASCII signature

05/11-14:33:07.744419 0:9:5B:0:F3:DA -> 0:60:97:30:6B:C4 type:0x800 len:0x1A2

10.13.3.61:1092 -> 192.168.0.12:1434 UDP TTL:113 TOS:0x20 ID:61068 IpLen:20 DgmLen:404

Len: 376

0x0000: 00 60 97 30 6B C4 00 09 5B 00 F3 DA 08 00 45 20 .`.0k...[.....E

0x0010: 01 94 EE 8C 00 00 71 11 8B AE 0A 0D 03 3D C0 A8 ......q......=..

0x0020: 00 0C 04 44 05 9A 01 80 63 09 04 01 01 01 01 01 ...D....c.......

0x0030: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................

0x0040: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................

0x0050: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................

0x0060: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................

0x0070: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................

0x0080: 01 01 01 01 01 01 01 01 01 01 01 DC C9 B0 42 EB ..............B.

0x0090: 0E 01 01 01 01 01 01 01 70 AE 42 01 70 AE 42 90 ........p.B.p.B.

0x00A0: 90 90 90 90 90 90 90 68 DC C9 B0 42 B8 01 01 01 .......h...B....

0x00B0: 01 31 C9 B1 18 50 E2 FD 35 01 01 01 05 50 89 E5 .1...P..5....P..

0x00C0: 51 68 2E 64 6C 6C 68 65 6C 33 32 68 6B 65 72 6E

0x00D0: 51 68 6F 75 6E 74 68 69 63 6B 43 68 47 65 74 54 QhounthickChGetT

0x00E0: 66 B9 6C 6C 51 68 33 32 2E 64 68 77 73 32 5F 66 f.llQh32.dhws2_f

0x00F0: B9 65 74 51 68 73 6F 63 6B 66 B9 74 6F 51 68 73 .etQhsockf.toQhs

0x0100: 65 6E 64 BE 18 10 AE 42 8D 45 D4 50 FF 16 50 8D end....B.E.P..P.

0x0110: 45 E0 50 8D 45 F0 50 FF 16 50 BE 10 10 AE 42 8B E.P.E.P..P....B.

0x0120: 1E 8B 03 3D 55 8B EC 51 74 05 BE 1C 10 AE 42 FF ...=U..Qt.....B.

0x0130: 16 FF D0 31 C9 51 51 50 81 F1 03 01 04 9B 81 F1 ...1.QQP........

0x0140: 01 01 01 01 51 8D 45 CC 50 8B 45 C0 50 FF 16 6A ....Q.E.P.E.P..j

0x0150: 11 6A 02 6A 02 FF D0 50 8D 45 C4 50 8B 45 C0 50 .j.j...P.E.P.E.P

0x0160: FF 16 89 C6 09 DB 81 F3 3C 61 D9 FF 8B 45 B4 8D ........

0x0170: 0C 40 8D 14 88 C1 E2 04 01 C2 C1 E2 08 29 C2 8D .@...........)..

0x0180: 04 90 01 D8 89 45 B4 6A 10 8D 45 B0 50 31 C9 51 .....E.j..E.P1.Q

0x0190: 66 81 F1 78 01 51 8D 45 03 50 8B 45 AC 50 FF D6 f..x.Q.E.P.E.P..

0x01A0: EB CA ..

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

05/11-14:53:48.630387 0:9:5B:0:F3:DA -> 0:60:97:30:6B:C4 type:0x800 len:0x1A2

202.99.11.99:1231 -> 192.168.0.12:1434 UDP TTL:110 TOS:0x80 ID:26925 IpLen:20 DgmLen:404

Len: 376

0x0000: 00 60 97 30 6B C4 00 09 5B 00 F3 DA 08 00 45 80 .`.0k...[.....E.

0x0010: 01 94 69 2D 00 00 6E 11 4B 31 CA 63 0B 63 C0 A8 ..i-..n.K1.c.c..

0x0020: 00 0C 04 CF 05 9A 01 80 9A 01 04 01 01 01 01 01 ................