SMBLoris is a remote, unauthenticated application-level denial of service (DoS) attack against Microsoft Windows operating systems. It is caused by a very old memory-handling bug in the Server Message Block (SMB) network protocol implementation. The vulnerability lies in the way SMB packets are processed and memory is allocated. It was discovered by two RiskSense security researchers — Sean Dillon and Jenna Magius and takes its name from Slowloris attack on web servers discovered back in 2009. SMBLoris is the same thing as Slowloris but instead of HTTP, its done via SMB.
SMBLoris affects all modern versions of Windows from Windows 2000 through Windows 10, and all the three versions of SMB – SMBv1, SMBv2, and SMBv3 are affected. Samba which is an alternative to SMB for other operating systems is also vulnerable in a default install.
SMB runs on port 445. The NetBIOS service on port 139 is probably also exploitable. For any SMB session, the data initially transmitted is the NetBIOS Session Service (NBSS) header and is processed before any SMB authentication mechanism established. NBSS header occupies 4 bytes of memory.
First 8 bits of NetBIOS Session Service (NBSS) header represent message type, next 7 bits represent flags and last 17 bits represent the length of SMB message. When a computer running an SMB service receives an NBSS header, it immediately allocates in memory the number of bytes determined by the Length field of the NBSS header. By sending a 17-bit NBSS length field set to the max value which is 2 raise to power 17, a max of 131072 bits (128 KiB) is allocated by the SMB service. The kernel keeps the connection open for 30 seconds and then gives up. So for 30 seconds, 128KiB of memory is tied up for every connection attempted. This memory allocated is in the “non-paged pool” (physical RAM) which cannot be swapped out to disk.
If attacker fires off a connection request for every TCP port possible – up to 65535, potentially it can chew through up to 8GiB of non-paged RAM for half a minute. This will hamper the performance of the machine. Additionally, if an attacker launches this attack on IPv4 and IPv6, that memory consumption increases to 16GiB. If an attack comes from ten IPs, an attacker can fill 80GiB, and so on. Eventually, the target can’t allocate memory and needs a manual reboot if it becomes unresponsive.
In short, computationally, it is very inexpensive for anyone to cause large memory allocations and waste enormous amounts of CPU cycles making vulnerable machines completely unusable and even causing the entire operating system to crash.
The SMBLoris flaw is dangerous as it allows an attacker to open tens of thousands of connections to the same machine, exhausting its RAM and potentially crashing the target’s computer. This vulnerability does not cause remote code execution but an attacker can get critical services to crash and can completely freeze the system. A PoC is also available here.
No patch exists for this vulnerability at this time. According to Microsoft, this vulnerability is a moderate issue as SMB port is blocked at the network edge by firewall rules. Inside of a network, its usage would only announce and pinpoint the attacker as it requires sending a large number of unauthenticated SMB connections. Microsoft has announced not to fix this vulnerability immediately but likely later in order to prevent unmanaged consumer users with no firewalls configured from being affected.
Disabling the SMB protocol on Windows will not help. According to the two RiskSense researchers Dillon and Zach, the only way to prevent an SMBLoris attack is if a computer running an SMB service is placed behind a firewall that blocks incoming SMB connections or limits their incoming SMB connections request number to a smaller value. In case of samba on Linux, admins can set “max smbd processes = 1000” in the Samba smb.conf config file to prevent attackers from opening a large number of SMB connections to the Samba server.