One of the topics I teach in Coalfire’s Adaptive Penetration Testing course, given most recently at Black Hat 2017, is manual privilege escalation on Linux- and Unix-based systems. I also talk about how common it is to gain an initial foothold in an environment by leveraging default or easily guessable login credentials. During a recent red team engagement, I leveraged both of these techniques – not only to fully compromise the organization’s Active Directory environment, but also to discover and exploit a previously unknown vulnerability in the Replibit Linux distribution installed on a server on their network.

After delivering the report to our client, I contacted Replibit to responsibly disclose the issue and give them the opportunity to release a fix. They responded immediately and published a fix within a week of my initial contact. I was impressed with how quickly they responded, and it was a real pleasure working with their team. Since then, I’ve publicly disclosed the vulnerability, which has been assigned the CVE number 2017-13707.

What follows is a brief walkthrough explaining how just a few of the exact same techniques I cover in our Adaptive Penetration Testing class were used to discover and exploit this vulnerability.

Getting a foothold with default credentials

We gained access to the client’s internal network through social engineering. The target office was located in a multi-tenant building, so a member of our team dressed up as an electrician and talked his way inside. He told the receptionist there had been a leak on the floor above, and now that it was fixed he needed to test the electrical outlets in the office to make sure there was no danger of anyone getting electrocuted. He walked around the office “testing” the electrical outlets, and during a brief moment when no one was looking, he plugged in a Raspberry Pi dropbox behind a printer in the office. After being plugged into the internal network, the dropbox made an encrypted connection over the Internet back to our command-and-control server. This provided us with the exact same level of access we would have if we were sitting inside the office, but with the convenience of 24/7 remote access from anywhere in the world. We could now come and go on the target network as we pleased.

In order to be as stealthy as possible, we didn’t use vulnerability scanners or other tools that would use lots of bandwidth or generate suspicious traffic. Instead, we slowly identified hosts on the internal network and probed them for common services like HTTP. This led us to a server running the Replibit Backup Manager web interface. After browsing the login page, we did a simple web search to find Replibit’s documentation, which contained the default username and password, both of which were “replibit”. However, when we tried logging in through the web interface, the login failed.

Fortunately for us, the Replibit server was also running SSH, and the default credentials let us login to that service on the first try.

Escaping the restricted shell

After logging in, I was presented with a restricted shell environment, which only allowed me to execute a limited subset of commands. Among the commands I had available were sudo and lsudo. Because sudo is a command that allows users to run other commands with elevated privileges (often root), these commands immediately caught my attention.

It turned out that the lsudo command was a built-in command within the restricted shell that listed other commands I was allowed to execute with sudo. This was useful since the usual “sudo -l” was not a command I was allowed to execute.

The screenshot below shows the output of the lsudo command. Among the commands listed were “more” and “vi”. These immediately stood out to me since both commands have often-overlooked features that can be used to escalate privileges when the commands are run via sudo.

I tried some of the immediately obvious tricks like reading password hashes from /etc/shadow, modifying user accounts in /etc/passwd, and using internal commands (such as more’s “!/bin/bash” and vi’s “:!/bin/bash” and “:shell”) to execute privileged shells. However, it appeared that the Replibit team was aware of all of these techniques since none of them worked.

Although I couldn’t open /etc/shadow or /etc/passwd directly from vi, I could open other files in the replibit user’s home directory. This made me wonder if I could open an allowed path from the command line and then change to one of the forbidden files from within vi. To try this, I executed “vi ~“, which told vi to display the contents of the current user’s home directory within its file browser interface.

From here I could use the arrow keys to move up and down the list of files and directories and the “Enter” key to select which one I wanted. I selected the first entry in the list, “../”, to move up to the parent directory.

Sure enough, this worked, and I was now presented with the contents of the “/home” directory.

I selected “../” to move into the parent directory again and then “etc/” to move into “/etc/”. Then I selected the shadow file and was immediately presented with the password hash of the root user account!

Becoming root

At this point I could have saved the hash locally and attempted to crack it with hashcat or a similar tool, but that’s a potentially time-consuming process that may or may not have been successful. Instead, I took the much faster route of temporarily changing the root user’s password to something else.

First, I backed up the root user’s password hash so I could set it back to its original value after getting a shell. Then since I already knew the password of the replibit user, I just copied replibit’s password hash and inserted it in place of root’s password hash. After saving changes to the shadow file, I made a second ssh connection to the server and logged in with the username, “root”, and the password, “replibit”.

After logging in, I changed the root user’s password hash back to its original value – both to cover my tracks and to keep from causing any problems for users or software that might use the root account to login to this machine.

Conclusion

Exploiting the Replibit server turned out to be a huge success since, not only was I able to escalate privileges and fully compromise this machine, but gaining root access allowed me to access full backups of several different Windows servers in use on the internal network. By using sshfs to access the Replibit server’s filesystem, I was able to mount the backup files remotely from the dropbox and extract the local password hashes from each. Then it was as easy as passing the hashes to gain administrative access to each Windows server and doing the Mimikatz shuffle to domain admin to fully compromise the whole domain.