Nmap Development mailing list archives

port 138 revisited


From: mike <dmciscobgp () hotmail com>
Date: Sun, 7 Sep 2008 20:41:03 +0000


Ron
 
i am gonna copy something i read on Secureteam. it proves that there is a possible way to communicate with the port 138 
datagram service (albeit, a possible DoS is evident!)
 
 
From Secureteam:
 
Vulnerability Information:The Microsoft designed CIFS Browser Protocol defines a number of Browse Frames encapsulated 
within a NetBIOS datagram which is defined in RFC 1002 (4.4). The NetBIOS datagram header contains a source and 
destination NetBIOS name, as well as a second source IP address, in addition to the IP headers.When a Browse frame 
Request is received on UDP port 138, Microsoft's implementation extracts information from the NetBIOS datagram header 
and stores the information in the NetBIOS cache. The source NetBIOS Name and source IP address from the NetBIOS 
datagram header are blindly extracted from the UDP datagram and inserted into the NetBIOS cache.As an interesting side 
note, when a Browse frame Response is generated the NetBIOS cache is examined to resolve the source NetBIOS name of the 
previous request and delivered to that IP address. Because the NetBIOS cache entry for the source NetBIOS name is under 
control of the attacker, the response can be delivered to an arbitrary host.It is important to note that dynamic 
NetBIOS cache entries can be inserted in addition to overwriting static entries imported from the LMHOSTS file. 
Furthermore, the NetBIOS cache is corrupted with an unsolicited UDP datagram, removing the requirement for attackers to 
predict Transaction IDs. With the NetBIOS cache under the control of a remote attacker many opportunities are 
available, one of the most obvious is to subvert outbound SMB connections to an arbitrary address. A rogue SMB server 
would then be able to capture NT username and password hashes as presented.In addition to inserting entries into the 
NetBIOS cache it is also possible to flush dynamic entries. RFC 1001 (15.1.8) states that "a node ought to flush any 
cache information associated with an IP address if the node receives any information indicating that there may be any 
possibility of trouble with the node at that IP address". One possible way to flush dynamic NetBIOS cache entries is to 
deliver an unsolicited Positive Name Query response that provides a different IP address to NetBIOS name mapping to the 
entry in the NetBIOS cache.In a manner similar to DNS, the NetBIOS name resolution process utilizes a 16-bit 
Transaction ID to associate requests and responses. The Microsoft implementation of NetBIOS contains an easily 
predictable Transaction ID, although the previously discussed vulnerability is a much more effective method of 
inserting entries into the NetBIOS cache.
 
i hope you look into that set of tools i mentioned before (the ones related to the Microsoft Resource Kit |*Browsemon*)
 
alright, thank you for the work you have done so far with NETBIOS protocols!
 
m|ke
 
 
_________________________________________________________________
See how Windows connects the people, information, and fun that are part of your life.
http://clk.atdmt.com/MRT/go/msnnkwxp1020093175mrt/direct/01/

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org


Current thread: