Softpanorama (slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-) Softpanorama Search

Samba

The SMB protocol over TCP/IP uses three ports:

• UDP/137 is used for name resolution and registration (Name service)

   UDP/137 carries name registrations and name queries. When the queries are unicast this protocol if often referred to as WINS (or Windows Internet Name Server).

  In order to start Sessions or distribute Datagrams, an application must register its NetBIOS name using the Name service. NetBIOS names are 16 bytes in length and vary based on the particular implementation. Frequently, the 16th byte is used to designate a "type" similar to the use of ports in TCP/IP. In NBT, the name service operates on UDP port 137 (TCP port 137 can also be used, but it is rarely if ever used).

  The name service primitives offered by NetBIOS are:

  • Add Name — registers a NetBIOS name.
  • Add Group Name — registers a NetBIOS "group" name.
  • Delete Name — un-registers a NetBIOS name or group name.
  • Find Name — looks up a NetBIOS name on the network.
   
• UDP/138 is used for Datagram distribution service. Datagram mode is "connectionless". Since each message is sent independently, they must be smal; the application becomes responsible for error detection and recovery. In NBT, the datagram service runs on UDP port 138.

  The datagram service primitives offered by NetBIOS are:

  • Send Datagram — send a datagram to a remote NetBIOS name.
  • Send Broadcast Datagram — send a datagram to all NetBIOS names on the network.
  • Receive Datagram — wait for a packet to arrive from a Send Datagram operation.
  • Receive Broadcast Datagram — wait for a packet to arrive from a Send Broadcast Datagram operation.

   

• TCP/139 is used for Session service. TCP/139 is where the main action happens with the SMB protocol. Session mode lets two computers establish a connection for a "conversation", allows larger messages to be handled, and provides error detection and recovery. In NBT, the session service runs on TCP port 139.

  The session service primitives offered by NetBIOS are:

  • Call — opens a session to a remote NetBIOS name.
  • Listen — listen for attempts to open a session to a NetBIOS name.
  • Hang Up — close a session.
  • Send — sends a packet to the computer on the other end of a session.
  • Send No Ack — like Send, but doesn't require an acknowledgment.
  • Receive — wait for a packet to arrive from a Send on the other end of a session.

  In the original protocol used to implement NetBIOS services on PC-Network, to establish a session, the computer establishing the session sends an Open request which is responded to by an Open acknowledgment. The computer that started the session will then send a Session Request packet which will prompt either a Session Accept or Session Reject packet. Data is transmitted during an established session by data packets which are responded to with either acknowledgment packets (ACK) or negative acknowledgment packets (NACK). Since NetBIOS is handling the error recovery, NACK packets will prompt retransmission of the data packet. Sessions are closed by the non-initiating computer by sending a close request. The computer that started the session will reply with a close response which prompts the final session closed packet.

There are two main authentication models available.

The SMB model defines two levels of security:

• Share level. Protection is applied at the share level on a server. Each share can have a password, and a client only needs that password to access all files under that share. This was the first security model that SMB had and is the only security model available in the Core and CorePlus protocols.
   
• User Level. Protection is applied to individual files in each share and is based on user access rights. Each user (client) must log in to the server and be authenticated by the server. When it is authenticated, the client is given a UID which it must present on all subsequent accesses to the server.

Old News

[Mar 29, 2007] CIRT @ CIS @ Brown NetBIOS NULL Sessions: The Good, The Bad, and The Ugly by Paul Asadoorian

(Updated August 17, 2005)

I. The NULL Session Concept: The Good?

II. The Bad and The Ugly.

III. Using the Information.

IV. How to disable NetBIOS NULL Sessions.

V. Further Defenses.

VI. References and Further reading.

Note: Follow the link below to download a script to disable NULL sessions: Download Disable NULL Sessions Script

---

I. The NULL Session Concept: The Good?

NULL sessions take advantage of “features” in the SMB (Server Message Block) protocol that exist primarily for trust relationships. You can establish a NULL session with a Windows host by logging on with a NULL user name and password. Using these NULL connections allows you to gather the following information from the host:

• List of users and groups
• List of machines
• List of shares
• Users and host SID' (Security Identifiers)

NULL sessions exist in windows networking to allow:

• Trusted domains to enumerate resources
• Computers outside the domain to authenticate and enumerate users
• The SYSTEM account to authenticate and enumerate resources

NetBIOS NULL sessions are enabled by default in Windows NT and 2000. Windows XP and 2003 will allow anonymous enumeration of shares, but not SAM accounts.

II. The Bad and the Ugly

The NULL session vulnerability is fairly widespread, however the introduction of Windows XP and Windows 2003 has made it far less useful. For the most part if the appropriate ports are accessible a NULL session is possible.

Port	Protocol	Description
135	TCP	Location Service (RPC endpoint mapping)
135	UDP	Location Service (RPC endpoint mapping)
137	TCP	NETBIOS Name Service
137	UDP	NETBIOS Name Service
138	TCP	NETBIOS Datagram Service
138	UDP	NETBIOS Datagram Service
139	TCP	NETBIOS Session Service
139	UDP	NETBIOS Session Service
445	TCP	SMB/CIFS

Figure 1

Port 139 or 445 TCP is required to be open in order for a NULL session to be successful (it needs to connect to IPC$ first). The other ports may be required, depending on the configuration, for services such as name resolution. There are many tools available to exploit NULL sessions, here are some examples:

Enum ( http://www.bindview.com/Services/RAZOR/Utilities/Windows/enum_readme.cfm )

enum is truly one of the best tools for exploiting the NULL session vulnerability. It is the "Swiss army knife" of NULL session hacking, allowing you to exploits every aspect of this flaw. Its true power lies in the ability to enumerate users, and then try to brute force the password using a supplied password list. Sample output is below (I usually run with the –S and –U flags as shown below):

C:\tools>enum -SU <IP Address> server: <IP Address> setting up session... success. getting user list (pass 1, index 0)... success, got 5. Administrator Guest IUSR_CHANNEL IWAM_CHANNEL victim_user enumerating shares (pass 1)... got 4 shares, 0 left: IPC$ c ADMIN$ C$ cleaning up... success.

Figure 2

From the above output we can see that the machine has one additional user aside from the default accounts, called “victim_user”, and that none of the default accounts have been renamed. This is another great usage of NULL sessions, if the user has been conscientious and renamed the administrator account, we can see what it has been changed to. The guest account exists as well, which comes by default in most windows, and should be left disabled. It appears as though this machine is also running Microsoft IIS web server, from the IUSR_<machine name> account that exists. Moving on to the shares we see all of the default hidden administrative shares (denoted by the “$” character), as well as an unhidden share called “c”. The ability to view hidden shares on the host is yet another great feature of NULL sessions.

Hunt ( http://www.foundstone.com/resources/freetools/hunt.zip )

Part of the NT Forensic Toolkit from Foundstone, this tool makes it very easy to enumerate users and shares from a vulnerable windows host, and is the most accurate in my experience. Some sample output is below:

 

C:\tools>hunt \\<IP Address> share = IPC$ - Remote IPC share = c - share = ADMIN$ - Remote Admin share = C$ - Default share User = Administrator, , , Built-in account for administering the computer/domain Admin is <NetBIOS Name>\Administrator User = Guest, , , Built-in account for guest access to the computer/domain User = IUSR_<NetBIOS Name>, Internet Guest Account, Built-in account for anonymous access to Internet Information Services, Built-in account for anonymous access to Internet Information Services User = IWAM_<NetBIOS Name>, Internet Guest Account, Built-in account for anonymous access to Internet Information Services out of process applications, Built-in account for anonymous access to Internet Information Services out of process applications User = victim_user Victim Name, ,

Figure 3

Above we see the same information as enum presents represented in a slightly different format.

winfo ( http://ntsecurity.nu/toolbox/winfo/ )

This command line tool queries the host for most of the information made available by a NULL session (Including any trust relationships) and displays it to the screen. Sample output is below:

C:\>winfo 128.148.151.7 –n winfo 1.5 - copyright (c) 1999-2001, Arne Vidstrom - http://www.ntsecurity.nu/toolbox/winfo/ Trying to establish null session... Null session established. USER ACCOUNTS: * Administrator (This account is the built-in administrator account) * Guest (This account is the built-in guest account) * victim_user WORKSTATION TRUST ACCOUNTS: INTERDOMAIN TRUST ACCOUNTS: SERVER TRUST ACCOUNTS: SHARES: * IPC$ * drivec$

Figure 4

The output above shows the listing of users, similar to the other tools. winfo is unique in that it will also show the trust relationships this machine may have with other machines. Finally, it will list the shares it has made available.

Dumpsec ( http://www.systemtools.com/cgi-bin/download.pl?DumpAcl )

Formerly Dumpacl, This tool is similar to winfo, but has a GUI interface.

Built-in tools

You can use built-in tools to enumerate NULL sessions by executing the following command using the "net" utility that comes with Windows. Without NULL sessions when we attempt to list the shares on a remote windows computer we get the following error:

 

C:\tools>net view \\MY.SUB.NET.IP System error 5 has occurred. Access is denied.

Figure 5

By default we would not have permissions to list the shares. If we map the IPC$ share (Inter Process Communications) using our NULL username and password combinations we are successful:

C:\tools>net use \\MY.SUB.NET.IP\IPC$ "" /u:"" The command completed successfully.

Figure 6

Now we try to list the shares again with greater success:

 

C:\tools>net view \\MY.SUB.NET.IP Shared resources at \\MY.SUB.NET.IP Share name Type Used as Comment ------------------------------------------------------- c Disk The command completed successfully.

Figure 7

 

III. Using the Information

An attacker will use the information gained from NULL sessions and try to logon to the system, using various tools that will try different username and password combinations. Common attacks against University computers have shown that attackers will typically gain access to the system, install FTP servers, IRC bots, and DDOS tools, then copy the illegal (copyrighted and pirated) software up for distribution. The FTP server Serv-U FTP Server and the IRC bot iroffer are very common as well. This task is made easier by users who when prompted for an administrator password when installing NT/2000/XP leave it blank. Please set a password on every account on your machine, if not for the security of your machine, then for the security of all our machines.

A worm called “Zotob” that takes advantage of the MS05-039 vulnerability relies on NULL sessions to propagate. Follow the instructions in the next section to protect yourself (and of course apply all operating system patches).

IV. How to Disable NetBIOS NULL Sessions

Follow the link below to download a script to disable NULL sessions: Download Disable NULL sessions Script (Authored by Brown University Software Services)

Below are instructions on how to manually disable NetBIOS NULL sessions:

Windows XP Home Edition

Note: This also works in Windows 2000 and XP Professional.

1. Set the Following Registry Key: HKLM/System/CurrentControlSet/Control/LSA/RestrictAnonymous=2

2. Reboot to make the changes take effect.

Windows XP Professional Edition and Windows Server 2003

1. Go to Administrative Tools --> Local Security Policy --> Local Policies --> Security Options. Make sure the following two policies are enabled:
Network Access: Do not allow anonymous enumeration of SAM accounts: Enabled (Default)
Network Access: Do not allow anonymous enumeration of SAM accounts and shares: Enabled

This can also be accomplished using the following registry keys:
HKLM\System\CurrentControlSet\Control\Lsa\RestrictAnonymous=1 (This disallows enumeration of shares)
HKLM\System\CurrentControlSet\Control\Lsa\RestrictAnonymousSAM=1 (Default, not allowing enumeration of user accounts)

2. Reboot to make the changes take effect.

Windows 2000

1. Go to --> Administrative Tools --> Local Security Settings --> Local Policies --> Security Options

2. Select "Additional restrictions of anonymous connections" in the Policy pane on the right

3. From the pull down menu labeled "Local policy setting", select: "No access without explicit anonymous permissions"

4. Click OK

5. The registry setting equivalent is: HKLM\System\CurrentControlSet\Control\Lsa\RestrictAnonymous=2

6. Reboot to make the changes take effect.

Windows NT 4.0 (Service Pack 3 or later)

Set the Following Registry Key: HKLM/System/CurrentControlSet/Control/LSA/RestrictAnonymous=1

Samba

I am not certain how this works in the latest releases of Samba. Please email me with any feedback or experiences you could provide.

V. Further Defenses

While the above describes how to disable this vulnerability on the host, there are some things you can do on the network to help defend against NULL sessions:

• Blocking NetBIOS ports on your firewall or border router
• Blocking the Windows networking ports in Figure 1 will prevent against NULL sessions (And other attacks that use NetBIOS)
• Remove the IPC$ share (net share IPC$ /delete)

Intrusion Detection

Most Intrusion Detection systems come with signatures to detect NULL session activity, although when run on the “inside” of your network will generate false positives if not configured correctly. Configuring the Snort ( www.snort.org ) NULL session detection rule ( http://www.snort.org/pub-bin/sigs.cgi?sid=530 ) to look at certain traffic proves to be very effective. For example, you may only want to look at NULL session attempts from the Internet to your internal network, and IDS rules should be configured accordingly.

Account Policy

All versions of Windows that are vulnerable to this attack provide some mechanism to set account policies. The Center for Internet Security has released benchmark standards for all Windows platforms that include recommended account policies (See http://www.cisecurity.org for more details and to download the benchmarks). They cover password expiration, password length, and account lockout policies, which should all be applied to your domain (or workstation if you are not part of a domain). These documents also outline some recommendations for audit policies, or logging of certain activity on your computer. You should enable logging of security events on your windows servers and workstations for accounting purposes. Account and auditing policies should be tailored to individual organizations needs. Having these in place will significantly decrease the risk of someone using NULL sessions to gain access to your machine.

 

VI. References and Further Reading

Web Sites:

rr.sans.org/win/null.php - “NULL sessions In NT/2000” - Perhaps the best description of why NULL sessions exist, and general NULL session facts includes a complete description of how NetBIOS NULL sessions are used in a Windows networking environment. By Joe Finamore.

www.giac.org/certified_professionals/practicals/gcih/0345.php - “Weak Passwords + NULL Session = Windows 2000 Exploit” -This paper outlines the dangers of NULL sessions and gives an example of incident that uses this vulnerability. By Michael S. Kriss.

www.hsc.fr/ressources/presentations/null_sessions/msrpc_null_sessions.pdf - “MSRPC NULL sessions - exploitation and protection” – A new way to exploit NULL sessions using MSRPC and named pipes. Lets you do more than just view users and shares.

www.softheap.com/security/session-access.html - "How is information enumerated through NULL session access, Remote Procedure Calls and IPC$?"

www.sygate.com/alerts/Netbios_Null_Attack.htm - “NetBIOS NULL Session Attack in XP”

www.microsoft.com/technet/treeview/default.asp?url=/TechNet/prodtechnol/winxppro/proddocs/windows_security_differences.asp - Important differences between Windows NT 4.0 and Windows XP Professional

secinf.net/info/nt/wardoc.txt - “The Windows NT WARDOC: A Study in Remote NT Penetration”

www.sans.org/top20/#w3 - SANS/FBI Top 20 List, Windows Remote Access Services

Books:

"Hacking Exposed" or "Hacking Windows 2000 Exposed", Scambray & McClure, Chapter 4: Enumeration

Other Universities Descriptions of NetBIOS NULL Sessions:

www.cit.cornell.edu/computer/security/scanning/windows/nullsessions.html

rusecure.rutgers.edu/add_sec_meas/nullssn.php

security.uchicago.edu/windows/netbios/index.shtml

mit.edu/ist/topics/windows/server/winmitedu/security.html

---

Copyright 2002-2005

Authored by Paul Asadoorian, Brown University, June 17, 2002

Please send any questions/comments to Paul_Asadoorian@brown.edu

Revision 1.0: November 14, 2002 – Added a significant amount of content.

Revision 1.1 January 3, 2003 – Updated for Windows XP Home Edition

Revision 1.3 August 16, 2005 – Updated for Windows 2003, MS05-039 worm, general clean-up and fixed all broken links.

 

[Feb 20, 2007] Possible way of fighting network worms that use exploits on ports 136-139

See: http://support.microsoft.com/support/kb/articles/Q204/2/79.ASP

NetBIOS-free SMB protocol on port 445 in Windows 2000-XP

Jay Ts jay at toltec.metran.cx
Wed Aug 29 21:52:52 GMT 2001

• Previous message: NetBIOS-free SMB protocol on port 445 in Windows 2000/XP
• Next message: NetBIOS-free SMB protocol on port 445 in Windows 2000/XP
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Chris Hertel wrote:
> Yes, we know.  Have known for over a year.
> I think it was Tridge who convinced Microsoft to use port 445. 

Cool.  So can I assume that it will be no problem to add support for it?
And are plans for such in process?

- Jay Ts

------------------------------------------
> > Hi,
> > 
> > Yesterday a friend forwarded to me this URL at Microsoft:
> > 
> > http://support.microsoft.com/support/kb/articles/Q204/2/79.ASP
> > 
> > It is about support in Windows 2000/XP for running SMB for
> > file and printer sharing over port 445, with no overhead of
> > NetBIOS.
> > 
> > The question of course is, are the Samba Team aware of this,
> > and can it be supported in future versions of Samba?
> > 
> > The webpage says it is possible to set up a Win 2000/XP network to
> > only use the new protocol, and shut out SMB/NetBIOS networking on
> > ports 137-139 entirely.
> > 
> > - Jay Ts

Basic Networking Windows to Linux Fedora  by Mark Rais, Senior Editor ReallyLinux.com and author of "Linux for the Rest of Us" 2nd Edition.

(ReallyLinux.com) This article is for all of those readers asking for a very basic overview of networking Windows and Linux PCs. You may also benefit from my article: From Windows to Linux.

Can a Windows system and a Linux system talk together harmoniously? After all, there is a lot of work and personal data left on Windows PCs that many want to keep! So this question of networking the two systems is both reasonable and vital.

... ...

Therefore, basic Windows file sharing can be done with relative ease if your Linux flavor includes the Samba tools. Of course, it also requires a little work on the Windows PC since any good communication comes from two sides!

The goal then, regardless which Linux flavor you're using, is to:

1. Ensure that Samba tools are included and available
2. Configure the PC network cards and settings
3. Configure the Windows PC to allow workgroup sharing
4. Configure Samba tools to recognize the Windows PC

I include details for each of these steps in the article. Implementing the steps above is somewhat unique across every major flavor I've used. Some flavors will require you to select Samba tools at the very beginning of the installation process. Other flavors include the full Samba suite of tools as part of the package, ready to go. It depends so much on your flavor that I can't provide specific guidance without writing another fifty pages on the subject. I plan to release an indepth SAMBA article here in the future.

However, what I can share with you now are steps needed to implement Samba using Fedora as a tutorial or guide. These steps are for making a basic WindowsXP Home Edition available to Linux.

My assumption is that before you begin, you've already familiarized yourself with the Post-Installation Configuration article, and that you have the two PCs connected properly with a network hub and cables.

 

OSFaq.com: How to install a Linux File/Print Server on your Windows Network [with Samba]

(Oct 15, 2000, 16:00 UTC) (558 reads) (0 talkbacks) (Posted by mhall)
"In this article, We will cover how to setup and configure a Linux File/Print Server on your Windows network."

 

Recommended Links

---

In case of broken links please try to use Google search. If you find the page please notify us about new location

---

NetBIOS - Wikipedia, the free encyclopedia

O'Reilly Samba Book, the second edition

SAMBA Developers Guide

Index of -samba-docs-man

Jelmer Vernooij - Publications

• The Official Samba-3 How-To and Reference Guide (2003)  
• Samba Developers Guide
• Supporting DCOM in Samba 4