Years ago, I wrote a series of posts covering the basics of building and exploiting vulnerable machines for learning purposes. With my two most recent posts covering virtual labs, it seems like an appropriate time to revisit the topic.
I’ve used the misconfiguration I’m going to cover in this article on several Capture the Flag events and mock pentests over the years. It makes use of the Sophos UTM 9’s HTML5 VPN and closely resembles enterprise level remote access options like XenDesktop from Citrix (albeit missing a lot of features and customization). The actual flaw has to do with adding extra functionality to the Windows login screen. Under Windows 7, it was surprisingly common for organizations to use third-party plugins to add features like password reset to the Windows logon screen. This option has officially gone away with Windows 10 given the enormous risk such functionality presented. However, by co-opting the Ease of Access button, we can simulate the same kinds of situations.
Windows Setup
The first step is to get this vulnerability in place is to decide how you’ll be using it. Normally, I use this as part of a faux corporate environment in a mock pentest. As mentioned, the premise I typically use is a (fake) password reset function on the login screen.
We start with an instance of Windows 10 (though it will still work the same way in Windows 7 as the attack portion of this post will demonstrate):
- Make sure that Remote Desktop is enabled and permitted at the local firewall.
- Create a Visual Basic script to create a simple, ‘restricted’ Internet Explorer window. We’ll need to change the registry to have the Ease of Access button on the logon screen to call this script. I normally set up a web server (sometimes right on the Windows desktop itself) to host a page that says something to the effect of ‘Password reset is broken. Check back later.” The X.X.X.X address below needs to point at the IP address of that server.
Set objExplorer = CreateObject("InternetExplorer.Application") objExplorer.Navigate "http://X.X.X.X/" objExplorer.Visible = true objExplorer.Toolbar = false objExplorer.MenuBar = false objExplorer.StatusBar = false objExplorer.AddressBar = false objExplorer.Width = 640 objExplorer.Heigh = 480 objExplorer.Left = 0 objExplorer.Top = 0 - To change the Ease of Access button’s functionality, we need to edit the registry, and go to the following key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options
- Right-click on the “Image File Execution Options” folder and create a new key named ‘utilman.exe’.
- Within the new utilman.exe subkey, add a new String called Debugger.
- Set its Value data to the full path of our new Visual Basic script.
I recommend setting a logon message through Local Security Settings that will key-in users to the Ease of Access button’s custom usage.
- Open secpol.msc
- Navigate to Security Settings -> Local Policies -> Security Options
- Find the Interactive Logon: Message title for users attempting to log on and Interactive logon: message text for users attempting to log on
- Use these to set a title (ie: “Password Reset”) and body (ie: “To reset your password, please click the button in the lower left hand side of the screen”) for the logon message
To verify that everything has worked, logout. From the logon screen, check the message, and click the Ease of Access button. An Internet Explorer window should appear pointing to your chosen web server.
HTML5 VPN Setup
From your Sophos UTM 9 (ideally, Exercise Firewall, per my previous post), browse to the ‘Remote Access’ tab on the left hand side of the Web Admin page. And then go to ‘HTML5 VPN Portal.’
Click the grey button (it will switch to green) to enable this functionality. Then, select ‘New HTML5 VPN Portal Connector…’ (See Figure 1).
We have a couple different connection options ranging from Remote Desktop (the default) to HTTP/S web apps or even SSH (see Figure 2). Don’t select Automatic login. The ‘Allowed users (Userportal)’ box will include any Sophos UTM 9 users you want to have access to it. You could also follow this guide to add Active Directory users if you are including this as part of a full mock pentest. Name the Connector something memorable (opportune place for a flag) and save it.
Your newly created session will be accessible using your chosen accounts from the Sophos User Portal. The settings for the User Portal can be found under the Management tab on the left hand side of the screen in the Web Admin page. Set the network segments from which you want the User Portal (and HTML5 VPN) to be accessible under ‘Global’ (see Figure 3). The ‘Allow All Users’ check box can stay selected if this is your dedicated Exercise firewall (making the assumption that there aren’t any ‘legitimate’ users’).
Under ‘Advanced,’ I normally check everything except Remote Access under the ‘Disable Portal Items’ box in order to keep the scope and intended pathway for my participants as tight as possible (see Figure 4).
Once the Sophos UTM 9 settings have been applied, the setup should be ready to go.
Exploitation
The first step in the attack is to guess or obtain credentials for the Sophos User Portal. Normally, I either leak credentials for the portal elsewhere in the scope of the mock pentest (such as in a Wiki page) or have them be shared with another site (or Active Directory) and guessable. The login page for the User Portal is very similar to its equivalent in Web Admin (Figures 5 & 6).
Having locked down the User Portal settings in the UTM, all that the user should see is the Remote Access tab. Clicking on that will show us the session we previously created (see Figure 7).
Selecting this connector will bring up a remote desktop session. The welcome messages we set earlier should be displayed (see Figure 8).
Note: As mentioned earlier, though the instructions I gave above were for Windows 10, the back-end demonstrated in these screenshots is Windows 7 to demonstrate that the same registry settings can be applied in either version to make a vulnerable machine.
Clicking the Ease of Access button in the lower left hand corner (see Figure 9) will open the Internet Explorer window as expected.
From here, there are a couple of options to get to shell. We could use the Ctrl-O keyboard shortcut to bring up the ‘Open’ dialogue. Browsing to C:\Windows\System32, locating cmd.exe, right-clicking it, and selecting Open will pop open a shell (see Figures 10 & 11).
Another option is to use Ctrl-P (or right-click, Print) to bring up the Print dialogue. Checking the ‘Print to File’ box and then selecting ‘Print’ will open a file browser. The same process can be repeated to locate and open cmd.exe (see Figure 12).
Both techniques will drop you in as the NT_AUTHORITY\SYSTEM user, giving you complete local access to the machine without ever having to login (see Figure 13).
Conclusion
The technique used in the attack is extremely transferable. It’s a great way to demonstrate how finding a file explorer can lead to shell (which is particularly useful in Citrix XenApps, for example). It’s also a great teaching tool for getting students or relatively green testers to start thinking about how to abuse intended functionality in software and ‘out-think’ developers.
