Happy Friday.
Today’s vulnerable box was not particularly difficult to set up, but I like the exploit. I am also using this particular box on the final exam for my network security students over the next few weeks, so part of me wants to see if they stumble across the tutorial. Full disclosure: I’ve never encountered Rejetto’s HTTP File Server on a penetration test. I stumbled across it on Exploit-DB.com and thought the manual exploit and the available Metasploit module would make good teaching tools.
What is Rejetto HFS?
According to the Rejetto website, HFS (HTTP File Server) is meant to be a simple solution for the sending and receiving of files over the web. The original goals for the project were compatibility across platforms, out-of-box functionality, and easy remote access. Some of the features include Dynamic DNS support, account management, logging, and support for HTML templates. Admittedly, the software does seem pretty handy. Unfortunately, versions prior to 2.3.e (the latest version as of this writing) contain a pretty enormous security hole. Daniele Linguaglossa discovered an unauthenticated remote code execution vulnerability in November 2014 along with a slew of other issues.
The Setup
As I mentioned, this build is not tricky at all. In fact, HFS is a standalone application, so there’s not even an installation step. Just download and unrar the executable from the exploit’s page on Exploit-DB.com, and you are good to go. I have run HFS in a variety of Windows flavors, including XP, Vista, and 7, and I haven’t run into any compatibility issues. When you’re ready to go, simply double-click on the executable. As with all vulnerable builds, stick to a virtual environment so you don’t inadvertently get yourself pwnd. HFS uses port 80 by default, so make sure you’re not running IIS or any other web server when you spin it up; if you do, it will default over to 8080 anyway.
Once HFS opens, switch to Expert Mode. Simply click ‘You are in Easy Mode’ to make the change. That will open up some additional options and make the initial configuration a little simpler. I would recommend setting up a user account or two just to add some realism. That being said, user or no user, the exploits still works.
Once you’re in Expert mode, click on ‘Menu,’ hover over ‘Other Options,’ and select ‘User accounts..’ To add a new user, select ‘Add’ from the bottom left hand corner of the window. To save my students the trouble of running bruteforce attacks without any benefit, I set stereotypical admin/password credentials. If you’re hoping to lure victims down an unnecessary rabbit hole, feel free to set an overly complicated username/password combination; if you’re using this software legitimately, obviously set appropriate credentials (and it should go without saying, but you should probably avoid using the version hosted on Exploit-DB.com). Once your account(s) is created, click ‘Apply’ and then ‘OK.”
To make sure HFS is running as expected, simply open a browser on your host and surf to the vulnerable VM’s IP address. You should be greeted with a page similar to the one found in the screenshot below.
Ensure Vulnerability
Log in or don’t; it won’t matter. All the exploit requires is access to the search function which is conveniently available to unauthenticated users. According to Linguaglossa’s findings, the application doesn’t handle the NULL byte (%00) properly. This byte will stop regex from parsing a searched string allowing an attacker to slip in operating system commands.
Using the the standalone exploit (linked above) as a guide, simply paste the provided PoC into your browser’s URL bar, substituting the VM’s IP address for localhost.
http://localhost:80/?search=%00{.exec|cmd.}
In the screenshot above, Chrome is on the host and includes the PoC URI. You’ll see in the background a bunch of cmd.exe windows have popped open. In the exploit verbiage, Linguaglossa has noted that the payload runs multiple times, so definitely keep that in mind if you put together a full-on exploit. The PoC is more than enough to compromise the machine in most cases, fortunately. Simply add a local administrator (assuming HFS is running within the context of an administrative account’s session), and RDP or psexec to the machine. The exploit is blind, so, the attacker (or student) may need to use a little guess-and-check.
http://localhost:80/?search=%00{.exec|cmd /c net user testuser testpassword /add.}
http://localhost:80/?search=%00{.exec|cmd /c net localgroup administrators testuser /add.}
Simple enough.
User Account Control
Obviously, the technique described in the previous section won’t work with UAC enabled. The Metasploit module, fortunately, will drop you into shell with or without UAC running on the target machine. This presents a perfect opportunity to make use of Metasploit’s UAC bypass capabilities. As demonstrated in the screenshot below, ‘getsystem’ will not elevate an admin account to SYSTEM. It’s also worth noting that the backend OS has to support UAC (we will switch to Windows 7 for this part).
There are a couple different UAC modules available in Metasploit as referenced below. Either of the bypassuac options should work just fine.
The only requirement for either module is to set a session value. With the non-injection module, it is possible to set the delivery method to either an executable or Powershell (which is super convenient). Using an existing session obtained through the Metasploit Rejetto HFS module, run the UAC bypass exploit to drop into a new session with UAC effectively disabled. From within your newly obtained shell, ‘getsystem’ will then elevate you to SYSTEM.
Storage
As mentioned in my previous post, I definitely recommend using a VMWare ESXi server to house all of your vulnerable systems for easy access, snapshots, etc. It’s a free, simple-to-use tool that is worth the time to explore and set up.
Next time, we’ll take a look at setting up a vulnerable Domino server.
