I have been seeing a rising volume of NetBIOS-related scan traffic against my honeypot over the past several months. Curious about what was producing it, I spent an evening doing some careful sampling — scanning a small range of public IPs to see how many were actually responding on NetBIOS ports.
The results are uncomfortable. Worth writing about.
What NetBIOS is, briefly
NetBIOS is the name-resolution and session protocol used by Windows for file sharing, printer sharing, and inter-machine communication on local networks. It runs on three TCP/UDP ports: 137 (name service), 138 (datagram), and 139 (session).
The protocol was designed for local networks — machines that trust each other on the same LAN segment. Many of its assumptions reflect this: the authentication is weak, the data is unencrypted, the access controls are limited.
None of this is a problem on a properly-configured local network. It is a substantial problem when the same protocols are exposed to the open internet.
What I observed
The sampling: I scanned a small block of UK residential cable-modem IPs (about 250 addresses) and a similar block of small-business DSL IPs. For each address, I checked whether ports 137, 138, or 139 responded.
Results from the residential range:
- 8% of addresses responded on port 139 (TCP, NetBIOS session).
- 12% of addresses responded on port 137 (UDP, NetBIOS name service).
- 4% of addresses answered name-service queries returning the real hostname and the workgroup the machine was in.
- 2% of addresses answered share-enumeration queries with a list of actual shared folders on the machine.
Results from the small-business range:
- 15% on port 139.
- 22% on port 137.
- 9% returning hostname/workgroup.
- 5% returning share lists.
The small-business numbers are worse than residential — these are organisations large enough to have multiple internal hosts but apparently without consistent perimeter filtering.
A non-trivial fraction — call it 5-10% of all internet-facing UK IPs — is exposing NetBIOS to the open internet. This is substantial. Across the global IPv4 space, this would be tens of millions of hosts.
Why this is a problem
A short list, in roughly increasing order of severity.
Information disclosure. The hostname, workgroup, and (sometimes) Windows version are visible to anyone who asks. This is reconnaissance information for further attacks.
Shared-folder enumeration. Many of the responding hosts list their shared folders. The list often includes folders with intuitive names — documents, pictures, family-photos. The folders themselves may or may not require authentication.
Authentication weakness. When folders do require authentication, the NetBIOS authentication is not secure against passive observation. The challenge-response is a known-weak hash; offline cracking of intercepted authentication exchanges can recover passwords for many users.
Direct file access for unprotected shares. A worrying fraction of shared folders are not password-protected. Anyone who can reach the host can read or write to them. I have seen users with their entire C:\ drive shared without authentication. The contents are accessible to the public internet.
Vulnerability for known exploits. SMB has a steady stream of vulnerabilities, several of which allow remote code execution. A host with port 139 reachable from the internet is a candidate for the next exploit, regardless of how the operator has configured authentication.
Worm propagation surface. When the next worm comes that targets SMB — and one will come, given the trajectory — these hosts are the substrate. They will be compromised at internet scale.
Why this happens
A few explanations, in roughly decreasing order of how much they matter.
Default Windows configuration. A Windows installation enables NetBIOS by default. The file-sharing service binds to all network interfaces by default. There is, in default Windows, no concept of "this is the internal interface" versus "this is the internet-facing interface"; the same services run on both.
Home-network architectures place the host directly on the public IP. A typical UK home with cable or DSL has the desktop computer connecting directly via PPPoE or PPP, with the public IP assigned to the desktop's network adapter. There is no separate firewall between the desktop and the internet.
Routers as firewalls are not yet ubiquitous. Cable-modem providers in 2000 are starting to ship combination router/firewall boxes; many home users still have direct cable-modem connections without any network-layer firewall.
Operating-system defaults are not safe-by-default. Windows ships with many services enabled. The user has to actively disable them. Most users do not know which services are running, let alone how to disable them.
What this implies
A few things, with practical actions.
Microsoft should ship Windows with file sharing disabled by default. This is the right answer and is, on the available evidence, going to take years to ship. The cultural change in the Windows team — from "enable everything by default" to "opt in to network exposure" — is significant and slow.
ISPs should filter ports 135-139 by default. A blanket inbound block on these ports at the carrier edge would prevent the worst exposure with no real cost to legitimate users. A small fraction of users — those who legitimately need NetBIOS over the internet — could opt out.
Home routers should ship with NetBIOS blocked at the perimeter. The combination router/firewall boxes coming on the market in 2000 should default to blocking inbound NetBIOS. Most do not yet; this is the kind of default that needs to change.
For individual operators, the obvious immediate action. A firewall rule on every internet-connected Windows host blocking inbound 135-139. Most users do not know how to set this up; the user-experience for doing it on Windows is poor. Better firewalls, better defaults, simpler configuration would substantially reduce the exposure.
What I am doing
For my own infrastructure: nothing new. I have no Windows hosts on internet-facing IPs, and the OpenBSD perimeter blocks inbound NetBIOS as a side-effect of its default-deny posture.
For friends running Windows: I am sending a short note with specific instructions for adding NetBIOS firewall rules. The instructions are simpler than they might be — most users have a third-party firewall product that can handle this with a few clicks — but the discipline of applying them is non-zero.
For the broader picture: I am noting the data and including it in the Honeynet Project materials I am preparing for next quarter. The aggregate exposure metric is worth quantifying and publishing in a more rigorous form than my one-evening sampling.
A small prediction
The NetBIOS exposure is the substrate for a very effective worm, when one is written. The worm would scan for port 139 listeners, exploit a known SMB vulnerability against vulnerable hosts, install itself, repeat. Given the size of the exposed population — tens of millions of hosts — propagation could be extremely fast. The worm-propagation arithmetic I did in May suggests minutes from outbreak to global saturation if the technique is right.
I would not be surprised to see this in the next 12-24 months. The pre-conditions are all in place: large vulnerable population, known exploit techniques, mature DDoS-tool infrastructure that can be repurposed.
For anyone running infrastructure that depends on Windows hosts: paying attention to this is overdue. The standard recommendations — patch promptly, firewall the perimeter, segment the network — apply with extra urgency.
More as the year develops.