From The Art of Network Penetration Testing by Royce Davis
This article delves into how attackers discover and exploit patching vulnerabilities.
Discovering patching vulnerabilities
Discovering patching vulnerabilities is as straightforward as identifying which version of a software your target is running and then comparing that version to the latest stable release available. If you find that your target is on an older release you can check public exploit databases to see if there are any remote code execution bugs that were patched in the newest release, which an older version may be vulnerable to.
For example, using your service discovery data from the previous phase you can see that one of our target systems is running Apache Tomcat/7.0.92. If you go to the Apache Tomcat 7 page located at https://tomcat.apache.org/download-70.cgi, you see that during the time of this publication the latest available version of Apache Tomcat was 7.0.94. As an attacker you could make the assumption that the developers have fixed a lot of bugs between 7.0.92 and 7.0.94 and its possible that one of those bugs resulted in an exploitable weakness. Head over to the public exploit database (https://www.exploit-db.com) and search for “Apache Tomcat 7” and you get a list of all the current known exploitable attack vectors and determine which ones your target might be vulnerable to.
Figure 1. Searching the public exploit database for “Apache Tomcat 7”
In the case of MS17-010 it’s even easier because Metasploit has already created a simple module to tell us if a host is vulnerable. First, let’s use CrackMapExec (CME) to enumerate our list of Windows targets to get a feel for what versions are active on this network. MS17-010 was patched in 2017 and doesn’t typically affect Windows Server 2012 or greater. If our target network is running mostly up-to-date Windows boxes, then Eternal Blue is unlikely to be present. Run the following command from your pentest VM
cme smb /path/to/your/windows.txt. Remember that the windows.txt file contains all of the IP addresses which were running port 445 during service-discovery.
Output from that command indicates we’re in luck; one older version of Windows runs on this network which is potentially vulnerable to Eternal Blue. Windows 6.1 is either a Windows 7 workstation or Windows Server 2008 R2 system. We know this from checking the Microsoft page here.
Listing 1. Use CrackMapExec to identify Windows version
~$ cme smb discovery/hosts/windows.txt CME 10.0.10.206:445 YAMCHA [*] Windows 10.0 Build 17763 (name:YAMCHA) (domain:CAPSULECORP) CME 10.0.10.201:445 GOHAN [*] Windows 10.0 Build 14393 (name:GOHAN) (domain:CAPSULECORP) CME 10.0.10.207:445 RADITZ [*] Windows 10.0 Build 14393 (name:RADITZ) (domain:CAPSULECORP) CME 10.0.10.200:445 GOKU [*] Windows 10.0 Build 17763 (name:GOKU) (domain:CAPSULECORP) CME 10.0.10.202:445 VEGETA [*] Windows 6.3 Build 9600 (name:VEGETA) (domain:CAPSULECORP) CME 10.0.10.203:445 TRUNKS [*] Windows 6.3 Build 9600 (name:TRUNKS) (domain:CAPSULECORP) CME 10.0.10.208:445 TIEN [*] Windows 6.1 Build 7601#A (name:TIEN) (domain:CAPSULECORP) CME 10.0.10.205:445 KRILLIN [*] Windows 10.0 Build 17763 (name:KRILLIN) (domain:CAPSULECORP)
#A The host at 10.0.10.208 is running Windows 6.1 which may be vulnerable to MS17-010
It’s possible that this system could be missing the MS17-010 security update from Microsoft. All we need to do now is run the Metasploit auxiliary scan module to find out.
Scanning for MS17-010 Eternal Blue
To use the Metasploit module you must fire up the msfconsole from inside your pentest VM. Type
use auxiliary/scanner/smb/smb_ms17_010 in the console prompt to select the module. Set the rhosts variable to point to your windows.txt like this
set rhosts file:/path/to/your/windows.txt. Now run the module by issuing the
run command at the prompt. The following listing shows what it looks like to run this module.
Listing 2. Use Metasploit to scan windows hosts for ms17-010
msf5 > use auxiliary/scanner/smb/smb_ms17_010 msf5 auxiliary(scanner/smb/smb_ms17_010) > set rhosts file:/home/royce/capsulecorp/discovery/hosts/windows.txt rhosts => file:/home/royce/capsulecorp/discovery/hosts/windows.txt msf5 auxiliary(scanner/smb/smb_ms17_010) > run [-] 10.0.10.200:445 - An SMB Login Error occurred while connecting to the IPC$ tree. [*] Scanned 1 of 8 hosts (12% complete) [-] 10.0.10.201:445 - An SMB Login Error occurred while connecting to the IPC$ tree. [*] Scanned 2 of 8 hosts (25% complete) [-] 10.0.10.202:445 - An SMB Login Error occurred while connecting to the IPC$ tree. [*] Scanned 3 of 8 hosts (37% complete) [-] 10.0.10.203:445 - An SMB Login Error occurred while connecting to the IPC$ tree. [*] Scanned 4 of 8 hosts (50% complete) [-] 10.0.10.205:445 - An SMB Login Error occurred while connecting to the IPC$ tree. [*] Scanned 5 of 8 hosts (62% complete) [-] 10.0.10.206:445 - An SMB Login Error occurred while connecting to the IPC$ tree. [*] Scanned 6 of 8 hosts (75% complete) [-] 10.0.10.207:445 - An SMB Login Error occurred while connecting to the IPC$ tree. [*] Scanned 7 of 8 hosts (87% complete) [+] 10.0.10.208:445 - Host is likely VULNERABLE to MS17-010! - Windows 7 Professional 7601 Service Pack 1 x64 (64-bit)#A [*] Scanned 8 of 8 hosts (100% complete) [*] Auxiliary module execution completed msf5 auxiliary(scanner/smb/smb_ms17_010) >
#A Running the MS17-010 scanner module shows the host is Windows 7 and it’s likely vulnerable to the attack
From this output it’s clear that a single host running Windows 7 Professional build 7601 is potentially vulnerable to Eternal Blue. If you read the source code to the scanner module you can see that it checks for the presence of a string during the SMB handshake which isn’t present on patched systems. This means that there’s a relatively low likelihood of the results being a false positive. During focused penetration, the next phase in our INPT we can try the ms17-010 exploit module which, if successful, provides us with a reverse shell command prompt on this system.