Posts
The NetBIOS Auditing Tool (NAT) is designed to explore the NetBIOS file-sharing services offered by the target system.
It implements a stepwise approach to gather information and attempt to obtain file system-level access as though it were a legitimate local client.
If a NETBIOS session can be established at all via TCP port 139, the target is declared "vulnerable".
Once the session is fully set up, transactions are performed to collect more information about the server including any file system "shares" it offers.
Once the session is fully set up, transactions are performed to collect more information about the server including any file system "shares" it offers.
Attempts are then made to connect to all listed file system shares and some potentially unlisted ones. If the server requires passwords for the shares, defaults are attempted as described above for session setup. Any successful connections are then explored for writeability and some known file-naming problems.
If a NETBIOS session can be established at all via TCP port 139, the target is declared "vulnerable" with the remaining question being to what extent.
Information is collected under the appropriate vulnerability at most of these steps, since any point along the way be blocked by the security configurations of the target. Most Microsoft-OS based servers and Unix SAMBA will yield computer names and share lists, but not allow actual file-sharing connections without a valid username and/or password. A remote connection to a share is therefore a possibly serious security problem, and a connection that allows writing to the share almost certainly so. Let's take a look at an output from NAT.exe
C:\nat>nat 192.168.2.176
[*]--- Checking host: 192.168.2.176
[*]--- Obtaining list of remote NetBIOS names
[*]-- Remote systems name tables:
JOHN
WORKGROUP
JOHN
JOHN
WORKGROUP
.................
[*]--- Attempting to connect with name: JOHN
[*]--- CONNECTED with name: JOHN
.................
[*]--- Attempting to establish session
[*]--- Obtained server information:
Server= [JOHN] User= [] Workgroup= [WORKGROUP] Domain= [WORKGROUP]
[*]--- Obtained listing of shares:
Sharename Type Comment
--------- ---- ------
D Disk:
IPC$ IPC: Remote Inter Process Communication
[*]--- Attempting to access share: \\JOHN\D
[*]--- WARNING: Able to access share: \\JOHN\D
[*]--- Checking write access in: \\JOHN\D
[*]--- WARNING: Directory is writeable: \\JOHN\D
[*]--- Attempting to exercise... bug on: \\JOHN\D
ALL NetBIOS Tools Available @ http://www.cotse.com/tools/netbios.htm
http://www.tux.org/pub/security/secnet/tools/nat10/
http://www.softpedia.com/get/Network-Tools/Network-Testing/Essential-NetTools.shtml
http://www.softpedia.com/get/Network-Tools/Network-Testing/
It implements a stepwise approach to gather information and attempt to obtain file system-level access as though it were a legitimate local client.
If a NETBIOS session can be established at all via TCP port 139, the target is declared "vulnerable".
Once the session is fully set up, transactions are performed to collect more information about the server including any file system "shares" it offers.
Once the session is fully set up, transactions are performed to collect more information about the server including any file system "shares" it offers.
Attempts are then made to connect to all listed file system shares and some potentially unlisted ones. If the server requires passwords for the shares, defaults are attempted as described above for session setup. Any successful connections are then explored for writeability and some known file-naming problems.
If a NETBIOS session can be established at all via TCP port 139, the target is declared "vulnerable" with the remaining question being to what extent.
Information is collected under the appropriate vulnerability at most of these steps, since any point along the way be blocked by the security configurations of the target. Most Microsoft-OS based servers and Unix SAMBA will yield computer names and share lists, but not allow actual file-sharing connections without a valid username and/or password. A remote connection to a share is therefore a possibly serious security problem, and a connection that allows writing to the share almost certainly so. Let's take a look at an output from NAT.exe
C:\nat>nat 192.168.2.176
[*]--- Checking host: 192.168.2.176
[*]--- Obtaining list of remote NetBIOS names
[*]-- Remote systems name tables:
JOHN
WORKGROUP
JOHN
JOHN
WORKGROUP
.................
[*]--- Attempting to connect with name: JOHN
[*]--- CONNECTED with name: JOHN
.................
[*]--- Attempting to establish session
[*]--- Obtained server information:
Server= [JOHN] User= [] Workgroup= [WORKGROUP] Domain= [WORKGROUP]
[*]--- Obtained listing of shares:
Sharename Type Comment
--------- ---- ------
D Disk:
IPC$ IPC: Remote Inter Process Communication
[*]--- Attempting to access share: \\JOHN\D
[*]--- WARNING: Able to access share: \\JOHN\D
[*]--- Checking write access in: \\JOHN\D
[*]--- WARNING: Directory is writeable: \\JOHN\D
[*]--- Attempting to exercise... bug on: \\JOHN\D
ALL NetBIOS Tools Available @ http://www.cotse.com/tools/netbios.htm
http://www.tux.org/pub/security/secnet/tools/nat10/
http://www.softpedia.com/get/Network-Tools/Network-Testing/Essential-NetTools.shtml
http://www.softpedia.com/get/Network-Tools/Network-Testing/
0 comments:
Post a Comment