In the previous post, I covered the SMB protocol and how it has become one of the most widely used protocols in modern networks in one form or another regardless of operating system used.
This post covers the flip side of the love / hate relationship it has in the world of IT / Cyber.
Since its conception, SMB has been one of the primary methods of post network compromise and has facilitated some of the most devastating network breaches:
- In 2014, the Emotet trojan – a banking Trojan was released on the Internet. Soon after, the trojan was converted into self-propagating malware by exploiting the EternalBlue vulnerability.
- In 2016, the TrickBot trojan was released – This banking trojan is capable of stealing financial information and account credentials. It leverages the EternalChampion exploit developed by Shadow Brokers to facilitate lateral network propagation.
- In 2017, the WannaCry ransomware was released, causing devastation to thousands of Microsoft Windows systems worldwide. This ransomware also leveraged the EternalBlue exploit. By 2019, there were more than 12,000 variants of this ransomware in the wild.
- In 2020, the SolarWinds Orion platform was compromised in an elaborate supply chain attack resulting in one of the most widespread compromises of systems across the globe.
All four of the above malware variants used SMB to move laterally throughout a network after initial compromise.
A history of vulnerabilities
SMB has a long history of issues – a cursory search for “smb” on the CVE database (cve.mitre.org) returns 551 recorded vulnerabilities stretching as far back as 1999. A similar search for “samba” returns 266 results.
In many cases, the vulnerabilities surrounding SMB manifest during the implementation of the protocol within an application, or device, not the actual protocol itself, however the protocol does have many of its own issues.
SMB attacks
One of the most common attacks that uses an SMB vulnerability is the SMB relay attack. This attack initially involves a Man-In-The_Middle (MiTM) attack to gather the challenge-response transmitted during a remote connection session.
When a client device (or application) wants to access a specific remote service, the service sends a challenge – known as a nonce (number used once), which is a random string unique to each session to the client, and asks the client to encrypt it with the client’s password hash.
The client sends back the encrypted challenge to the service for validation.
In a Windows domain, once the service receives the encrypted challenge, it forwards it to the Domain Controller (DC) with the clear-text challenge. The DC knows the hashes of all the users and resources in the environment and as such can use the client’s hash to encrypt the challenge to see if it matches the one received from the service. If they match, then access to the resource is granted.
The relay attack
Once a threat actor has captured the transmitted hash, it can simply be relayed to another machine, and thus authenticate to it instead of a legitimate user. All this can be done without ever cracking the hash to recover the password.
This type of attack is commonly called a Pass-The-Hash attack and is made possible because in many cases SMB signing is not enabled that would see the received hash being validated against a digital signature. This is the default configuration for most Windows desktop operating systems whereas Windows servers will usually have SMB Signing enabled and enforced by default – but not always!
Why is SMB signing not widely used?
The simple answer is – legacy technologies.
SMB signing was introduced with Windows 2000 and Windows NT v4.0 as an update to SMB v1.0, so the capability has been around for many years now. But there are still systems that don’t support SMB signing, and when you have legacy systems like that, you will always have a weakness.
During the Wannacry attacks, a number of Seimens Healthineers systems used within the NHS were affected purely because they ran SMB v1.0 which rendered then completely vulnerable to the malware, even though other parts of the NHS were using systems running SMB v2.0 or higher.
SMB Encryption
With the release of SMB v3.0 with Windows 2012, Microsoft introduced SMB Encryption as a security enhancement which would see the replacement for SMB signing, however Microsoft themselves acknowledge that in some instances, a degradation in network performance can occur, and that neither option should be enabled in such cases.
SMB Signing and SMB Encryption have some trade-offs in performance. If network performance is important to your deployment scenarios (such as with Storage Spaces Direct), we recommend that you not deploy SMB Signing and SMB Encryption
Concluding words
It is plain to see that there is a huge reliance on SMB in modern networks to facilitate the sharing of resources, but its also plain to see that the primary protocol to allow this to happen is simply not robust enough to allow for secure communications to those resources – Hence the love / hate relationship SMB has.
Like many things though, SMB is so ingrained in many systems, replacing it with a more robust solution would be almost impossible, so we have to take other, preventative measures to ensure the security of the systems we have. This leads to ever more complex systems requiring more competent staff to configure and manage them, all the while bringing the real possibility of introducing a weakness somewhere else.
Its things like this that keep the cyber security industry on its toes at all times – truly a job forever!
