•The problem is to convince a victim's client to authenticate to the MITM server •You can send a malicious e-mail message to the victim client with an embedded hyperlink to the SMBRelay server's IP address.
•Another solution is ARP poisoning attack against the entire segment causing all of the systems on the segment to authenticate through the fraudulent MITM server Countermeasures
•Configure Windows 2000 to use SMB signing.
•Client and server communication will cause it to cryptographically sign each block of SMB communications.
•These settings are found under Security Policies /Security Options
There are inherent weaknesses in executing a SMBRelay attack. The hindrances to this attack are pointers towards countermeasures to be adopted. Firstly SMBRelay must be able to bind to port 139 to receive the incoming NetBIOS connections. This requires administrative privileges as this is a port number less than 1024.
SMBRelay targets and runs best on Windows NT and 2000 machines. Connections from 9x and ME boxes will have unpredictable results. Moreover, it relies on the attacker's ability to convince the user to authenticate himself to the MITM server. Ways to overcome these weaknesses include sending a malicious email
Another solution is ARP poisoning attack against the entire segment causing all of the systems on the segment to authenticate through the fraudulent MITM server. ARP traffic can be easily spoofed to reroute traffic originating from the system to the attacker's system, even in a switched environment. Rerouted traffic can be viewed with a network packet analyzer and then forwarded to the real destination in a variant of the MITM attack.
The only real prevention against SMBRelay is to dismantle all SMB communications and to use Windows 2000 Kerberos authentication only in a native, single forest environment network (with no legacy clients) and with all applications supporting Kerberos.
Another countermeasure is as discussed earlier in the context of SMBRelay MITM - to force the requirement for digitally signed SMB communications under Security Policy / Local Policies / Security Options. Though this may result in connectivity issues with NT4 systems, it can ensure adequate protection
While considering countermeasures, disabling NetBIOS alone is not sufficient to prevent SMB communication. This is because in the absence of standard NetBIOS ports, SMB will use Transmission Control Protocol (TCP) port 445, which is referred to as SMB Direct Host or the Common Internet File System (CIFS) port. As a result, explicit steps must be taken to disable both NetBIOS and SMB separately.
NetBIOS uses the following ports: UDP/137 (NetBIOS name service), UDP/138 (NetBIOS datagram service) and TCP/139 (NetBIOS session service). SMB uses the following ports: TCP/139, TCP/445. On servers accessible from the Internet, SMB must be disabled by removing File and Printer Sharing for Microsoft Networks and Client for Microsoft Networks using the Transmission Control Protocol/Internet Protocol (TCP/IP) properties dialog box in the Local Area Connection properties dialog box.
•Another solution is ARP poisoning attack against the entire segment causing all of the systems on the segment to authenticate through the fraudulent MITM server Countermeasures
•Configure Windows 2000 to use SMB signing.
•Client and server communication will cause it to cryptographically sign each block of SMB communications.
•These settings are found under Security Policies /Security Options
There are inherent weaknesses in executing a SMBRelay attack. The hindrances to this attack are pointers towards countermeasures to be adopted. Firstly SMBRelay must be able to bind to port 139 to receive the incoming NetBIOS connections. This requires administrative privileges as this is a port number less than 1024.
SMBRelay targets and runs best on Windows NT and 2000 machines. Connections from 9x and ME boxes will have unpredictable results. Moreover, it relies on the attacker's ability to convince the user to authenticate himself to the MITM server. Ways to overcome these weaknesses include sending a malicious email
Another solution is ARP poisoning attack against the entire segment causing all of the systems on the segment to authenticate through the fraudulent MITM server. ARP traffic can be easily spoofed to reroute traffic originating from the system to the attacker's system, even in a switched environment. Rerouted traffic can be viewed with a network packet analyzer and then forwarded to the real destination in a variant of the MITM attack.
The only real prevention against SMBRelay is to dismantle all SMB communications and to use Windows 2000 Kerberos authentication only in a native, single forest environment network (with no legacy clients) and with all applications supporting Kerberos.
Another countermeasure is as discussed earlier in the context of SMBRelay MITM - to force the requirement for digitally signed SMB communications under Security Policy / Local Policies / Security Options. Though this may result in connectivity issues with NT4 systems, it can ensure adequate protection
While considering countermeasures, disabling NetBIOS alone is not sufficient to prevent SMB communication. This is because in the absence of standard NetBIOS ports, SMB will use Transmission Control Protocol (TCP) port 445, which is referred to as SMB Direct Host or the Common Internet File System (CIFS) port. As a result, explicit steps must be taken to disable both NetBIOS and SMB separately.
NetBIOS uses the following ports: UDP/137 (NetBIOS name service), UDP/138 (NetBIOS datagram service) and TCP/139 (NetBIOS session service). SMB uses the following ports: TCP/139, TCP/445. On servers accessible from the Internet, SMB must be disabled by removing File and Printer Sharing for Microsoft Networks and Client for Microsoft Networks using the Transmission Control Protocol/Internet Protocol (TCP/IP) properties dialog box in the Local Area Connection properties dialog box.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.