Server Message Block (SMB) is a protocol used primarily for sharing files, printer services, and communication between computers on a network. The history of SMB is long, so I’ll try to keep this short and to the point.
Back in the 1980s and 1990s IBM and Microsoft were working on implementations of SMB to improve and build upon the protocol. Microsoft actually pushed to rename SMB to Common Internet File System (CIFS) and added a bunch of features, such as support for larger files and direct connections over port 445. SMBv1 was deprecated in 2013 and is no longer installed by default on Windows Server 2016. There are a handful of vulnerabilities that exist within SMBv1, most of which allow for remote code execution on the target host. You can see and review these on the CVE Details website. Most of these vulnerabilities have a patch available, but more often than not, SMBv1 can be completely disabled. Unless you have legacy systems in your environment that require SMBv1 (Windows XP) or legacy applications that rely on it, you’ll most likely not affect anything by disabling it across your organization.
SMBv2 was introduced in Windows Vista, circa 2006 by Microsoft. With the new version of SMB, came performance improvements and new features, such as support for symbolic links. SMBv3 was introduced with Windows 8 and Windows Server 2012, with this new version, came more performance improvements and security enhancements, such as end-to-end encryption.
SMBv1 vulnerabilities were brought to light when a hacker group leaked them after stealing them from the NSA. Shortly thereafter, ransomware like WannaCry was seen exploiting these vulnerabilities. These exploits have all been named ‘Eternal’X. EternalBlue being the most notable one that people are familiar with. EternalBlue exists because SMBv1 is not able to handle specific packets crafted by a remote attacker, leading to remote code execution. WannaCry ransomware apparently infected over 230k computers in 2017 and similar ransomware caused over $1 billion in damages across the globe. Malwarebytes provides a great deep dive into all the various exploits due to the SMBv1 vulnerabilities here.
Now that I’ve given some background on how SMBv1 has been exploited, specifically with the EternalBlue exploit, I want to show you guys how simple it can be for an attacker to use a tool like Metasploit to get an elevated command prompt on the target system. Once an attacker has an elevated command prompt on the target system, they’re able to do a bunch of things, such as create persistence by adding themselves as a local admin or even move laterally or escalate privileges by scraping hashes out of memory.
If you’re not familiar with Metasploit, it can be a little bit overwhelming at first as there is a lot to configure and it has a lot of capabilities. Imagine the scenario where I have the credentials of a non-privileged account within a domain. Using reconnaissance in Active Directory, I found some Windows Server 2008 machines that I think might be vulnerable to EternalBlue. Using Metasploit, I’m able to confirm those thoughts. Within the Metasploit console, I can search for the EternalBlue modules:
As you can see, there is a scanner module that allows us to detect if the machine might vulnerable to EternalBlue, and there are a few exploitation modules that can be leveraged to exploit EternalBlue. We’ll start with the scanner and see if the machine we found is actually vulnerable. Once we identify the module we want to use, simply type ‘use [module name]’. In this case, we’re going to use the scanner mentioned before. Below, you can see where I use the module, as well as configure the mandatory options to get the module to run.
As you can see, the result is that the host is ‘likely vulnerable’. This is a good indication I can move on to the next step to actually try to exploit EternalBlue on this target. Next, we’ll want to switch back to the search for EternalBlue and use the exploit module to try and exploit the vulnerability on the target.
After switching to the exploit module, I configured the same options and ran against the same host. This time, you can see it is doing that same check as before, but then going a step further and executing a payload that can exploit EternalBlue, granting me a SYSTEM level command prompt on the target host.
As I previously mentioned, an attacker can do various different things to move laterally, escalate, or persist with a SYSTEM level command prompt on an endpoint within your network. Hopefully, this shows why you should disable SMBv1 (if you can confirm it is not used) and more importantly, patch your systems.
So, how can you prevent something like this from occurring? The obvious answer is to ensure that all security-related patches are being installed across your end points. The other option that you have is to force SMBv1 to be disabled throughout your organization. Microsoft has a nice How-To that can assist in identifying the current status of SMB on a machine, as well as how to disable or enable it.
Start a Free Stealthbits Trial!
No risk. No obligation.