SMBRelay: Another Good Reason to Protect Your Internal Network

Last week, I discussed 3COM's new Embedded Firewall and the need to protect your internal networks. Shortly after I wrote that column, I came across some interesting news: A new program—SMBRelay—is available that can hijack a user's session to perform a man-in-the-middle attack. SMBRelay represents another good reason to protect your internal networks.

SMBRelay's author is Sir Dystic, a member of Cult of the Dead Cow (cDc). You'll recall that cDc also published Back Orifice and BO2K, remote control tools for Windows systems. SMBRelay sits on a Windows system waiting for a user to connect. When the user connects, the relay passes authentication traffic to its destination in a proxy-like fashion. After the system authenticates the session, the relay then disconnects the user's system and assumes control of the session. An intruder can use the relay system to access network resources under the same authority as the user whose session was hijacked. You can learn more about the program at the URL below.

http://pr0n.newhackcity.net/~sd/smbrelay.html

SMBRelay relies on the fact that many networks use the older NT LAN Manager (NTLM) authentication instead of the newer NTLMv2. The release of the L0phtcrack "http://www.securitysoftwaretech.com/lc3" password-cracking software showed security vulnerabilities in NTLM, so Microsoft released NTLMv2 when it published Windows NT 4.0 Service Pack 4 (SP4). To learn about NTLMv2, see Randy Franklin Smith's article, "Inside SP4 NTLMv2 Security Enhancements."

In addition, Microsoft has several articles online that discuss NTLMv2, including "How to Disable LM Authentication on Windows NT," and "How to Enable NTLM 2 Authentication for Windows 95/98/2000 and NT." You can add NTLMv2 support to Windows 9x by installing the Directory Services Client from the Windows 2000 CD-ROM as discussed in the second article.

NTLMv2 strengthens NTLM-based authentication, but it doesn't eliminate all risk. For example, NTLMv2 stops SMBRelay from hijacking user sessions, but the program might not stop future Server Message Block (SMB) relays. To better protect against man-in-the-middle attacks, you might want to integrate firewalls at the desktop and server level to guard against rogue client connections. Also consider VPN technology to protect user sessions and session traffic. Implementing a VPN can be tedious—but probably far less tedious than cleaning up after an intruder.