Additional improvements to Metasploit, introduced in March, include a new mixin that simplifies hosting of files on SMB shares for exploit modules. This greatly simplifies writing exploits that require any form of SMB share to store files, and as you can see from the module changes, it makes it much more elegant.
Find the latest updated module on GitHub:
Windows Group Policy can be used to configure startup scripts that will execute each time the operating system starts up. These scripts execute with a high-level of privilege, the NT AUTHORITY\SYSTEM account, per the TechNet documentation:
“Startup scripts are run under the Local System account, and they have the full rights that are associated with being able to run under the Local System account.”
The scenario for this post includes a startup script running from a remote server using an SMB share. Typically it is not possible for an attacker to control the SMB share—if that were the case this post wouldn’t exist! But if an attacker is able to perform any form of man-in-the-middle attack or traffic redirection, such as DNS spoofing, it is possible to host a SMB server that will serve up malicious files in order to gain remote command execution as NT AUTHORITY\SYSTEM.
FINDING LOCAL STARTUP SCRIPTS
As part of any post-exploitation process or host review, all startup scripts should be reviewed to determine the possibility for an elevation of privilege. One technique is to use the autoruns utility, part of the Sysinternals suite. This will also display Group Policy startup scripts which is our focus here.
In the lab setup, we have a Windows 7 (SP1, x86) machine that has a startup script,startup.vbs that is run each time the system boots. As part of this demonstration no DNS spoofing will be performed (for simplicity) so the script will point directly to a remote SMB share located at 10.20.0.103, a Kali Linux machine.
In the image below, we can see that the startup script is configured to run from a remote network share. Note that even though it indicates “File not found”, the system will still attempt to run the script when Windows starts.
After seeing a similar scenario wherein a script was being run from a remote SMB share, this got me thinking… Would it be possible to spoof the SMB server? If the client asks for startup.vbs could I then send it evil.vbs of my choosing? Could I then further accept any form of authentication in order to trick the Windows system?
From this idea the concept of BadSamba was born, a simple malicious proof-of-concept SMB server that is built to exploit this very scenario in order to gain remote command execution as SYSTEM.
BadSamba has the following two requirements:
Accept any form of authentication – anonymous, domain, blank password, non-existent accounts. It will allow any user to connect to the SMB server and access any share.
File spoofing – serve the same file regardless of what file was originally requested, and regardless of which SMB share the client is connected to. If the user requests foo.vbs we will send them evil.vbs instead.
With these requirements, I have created an auxiliary Metasploit module to demonstrate this proof-of-concept that allows for any authentication, connection to arbitrary SMB shares, and reading files from the SMB server.
Within the Windows 7 system (10.20.0.101), we have already identified that the startup.vbs script will execute from the remote SMB share when the operating system starts up.
Start Metasploit on Kali (10.20.0.103) and load the BadSamba server, setting the FILE to notepad.vbs. This file simply executes notepad.exe in order to demonstrate that the commands being executed are in fact being run in the context of NT AUTHORITY\SYSTEM.
Set oShell = WScript.CreateObject (“WScript.Shell”)
After running the module and once the Windows 7 machine is restarted it successfully authenticates and connects to the malicious SMB share. A request forstartup.vbs is then made, and we serve up our notepad.vbs. This is downloaded and executed by the target machine under the NT AUTHORITY\SYSTEM account as can be seen by inspecting the running tasks within the operating system.
Now that we have verified the module works, and that we can execute privileged commands, let’s create another VBScript file that will add a user account, also added to the Administrators group.
Set oShell = WScript.CreateObject (“WScript.Shell”)
oShell.run “cmd.exe /c net user hacker Password123 /ADD && net localgroup Administrators hacker /ADD”
Again we set the FILE setting to our malicious script, run the exploit server and restart the Windows 7 system.
As we can see the file was successfully downloaded by the target machine. Now to verify it executed successfully:
The hacker account has been created and added to the Administrators group!
BadSamba has been tested using .bat and .vbs remote script includes. The file extension does seem to matter, so if it’s requesting a .bat, serve up a .bat.
In the lab environment, testing has been against Windows 7 SP1 (English) for the proof-of-concept. Different versions of Windows may react differently, but the principal concepts should remain the same.
It’s not currently possible to “Browse” the files within the SMB share. This is due to the complexity of the SMB protocol, and adding this functionality would greatly increase the complexity of the module.
The protocol is quite noisy, and so it can be difficult to determine if the file was successfully downloaded or if it was download and executed.
Currently there is no exclusive lock on files being requested, and this allows for the file to be downloaded multiple times. In my experience, it only gets executed once, but it does make for noisy output within the module.
LESSONS LEARNED & TIPS
The SMB protocol is one of the noisiest protocols I’ve ever looked at. The number of requests required just to establish a connection to a share and download a file is much higher than I would have ever anticipated! This module requires 9 distinct request/responses, granted some of those are very simple such as an SMB ping.
When running multiple commands in VBScript, the most consistent way I have found is to execute cmd.exe and use the && operator instead of multiple .run commands.
When setting up an SMB server, pay special attention to the “capabilities” bits that are sent during the negotiation phase. For similar modules, I recommend:
0x0080000d # UNIX extensions; large files; unicode; raw mode
When working with SMB, use the Wireshark dissector to determine what is being parsed accurately. I’ve included resources for the protocol below, but Wireshark was essential to building this module.
Every version of Windows, and different tools or commands, use the SMB protocol differently. When testing with Windows XP, and Windows 7, even the “type” command of a remote share was different than using the Windows Run dialog, and even the Windows Explorer Address bar. Keep this in mind when playing with Windows SMB, as you have to target specific environments and functionality.
This almost goes without saying, but do try your scripts out on the local test environment before attempting to execute them remotely. VBScript and Batch don’t necessarily have the most intuitive syntax.
REFERENCES & RESOURCES
[MS-CIFS]: Common Internet File System (CIFS) Protocol –http://msdn.microsoft.com/en-us/library/ee442092.aspx
Assign Computer Startup Scripts – http://technet.microsoft.com/en-gb/library/cc770556.aspx
Authentication Capture: SMB – https://github.com/rapid7/metasploit-framework/blob/master/modules/auxiliary/server/capture/smb.r