What is main-in-the-middle attack?
Man-in-the-middle (MITM) attacks are Devastatomg, because they compromise the integrity of the channel between legitimate clients and servers, preventing the reliable exchange of any information.
In the tutorial, we will survey some implementations of MITM attacks against Windows protocols that have appeared over the years.
In May 2001, Sir Dystik of the Cult of the Dead Cow wrote and released a tool called SMBRelay that was essentially an SMB server that could harvest username and password hashes from incoming SMB traffic.
As the name itself suggests, SMBRelay can perform more than a rogue SMB endpoint - it can also perform MITM attacks, given certain circumstances.
Acting as a rogue server, SMBRelay is capable of capturing network password hashes that can be imported into a cracking tool.
It can also create reverse connections for any client via SMB using the privileges of the original connection.
In full MITM mode, SMBRelay inserts itself between the client and the server, relaying valid client authentication to the exchange, and gaining access to the server using the same privileges as the client.
SMBRelay can be erratic, but when implemented successfully, it is clearly a devastating attack: MITM has gained full access to the target server's resources without actually lifting Ginger.
Another tool called SMBProxy (http://www.cqure.net/wp/11/) implements the "pass the hash" attack. As we mentioned earlier, Windows passwords are equivalent to hash passwords, so instead of attempting to crack them offline, savvy attackers can replay them to gain unauthorized access (a technique previously popularized by Hernán Ochoa Had happened).
SMBProxy works on Windows NT 4 and Windows 2000, but we are not aware of the reported ability to compromise later versions of Windows, with SMBPelay.
In theory, these similar techniques are an application for later versions but have not been successfully applied to an instrument.
Massimiliano Montoro's CAN tool offers to support SMB MITM capabilities, which combine a built-in ARP Poison Routing (APR) feature with NTLM Challenge spoofing and downgrade attack functions.
Using just CAN, an attacker can redirect local network traffic to itself using ARP and allow clients to more easily attack Windows authentication bids.
CAN does not implement a full MITM SMB server like SMBRelay.
Terminal Server is also subject to a MITM attack in April 2003 using Cain's APR to implement the attack described by Eric Forsberg (see http://www.securityfocus.com/archieve/1/317244) and by Cain's author Updated in 2005, Massimiliano Montoro.
Because Microsoft reuses the same key to initiate the authentication, CAN use a known key to sign a known MITM key that the standard Terminal Server client only verifies because it is signed by a known Microsoft key The content is designed to be accepted visually.
The APR interrupts the original client-server communication so that neither is aware that it is actually talking to MITM.
The end result is that terminal server traffic can be recorded, unencrypted, and recorded by CAN, exposing administrative credentials that can be used to compromise the server.
Although it presents a low-risk MITM for the environment, which is still dependent on the NetBIOS naming protocol (NBNS, UDP port 137), name spoofing can be used to facilitate MITM attacks.
For example, the crew at Toolcrypt.org created a device that listens for broadcasting NetBIOS queries on UDP 137 and provides a positive answer with the name associated with the IP address of the attacker's choice.
MITM Countermeasures
MITM attacks usually require proximity to the victim system, such as to successfully enforce the presence of a local LAN segment.
If an attacker has already acquired such a foothold on your network, it is difficult to completely mitigate all possible MITM attack methods they could have employed.
Basic network communication security fundamentals can protect against MITM attacks.
The use of authenticated and encrypted communications can mitigate against rogue clients or servers by inserting themselves into a valid communication stream.
Windows firewall rules in Vista and later can provide authenticated and encrypted connections as long as both endpoints are members of the same Active Directory (AD) domain and an IPSec policy is to make a secure connection between the endpoints.
Since Windows NT, a feature called SMB signing is available to authenticate SMB connections.
However, we have never actually seen it extensively, and furthermore, are uncertain as to MITM's ability to prevent attacks in some scenarios.
For example tools like SMBRelay try to disable SMB signing. Windows Firewall with IPSec / connection security rules is probably a better bet.
Last but not least, to address NetBIOS name spoofing attacks, we recommend disabling NetBIOS name services only if possible.
The NBNS bus is so easily degraded (because it is based on UDP), and most recent versions of Windows can survive without a properly configured DNS infrastructure without it.
If you should implement NBNS, more NBNS spoofing (http://support.microsoft.com/kb/150737/ for more information) than configuring a primary and secondary Windows Internet Naming Service (WIN) server in your infrastructure. See) may help reduce against.
