Tag Archives: git

Sokar: VulnHub anniversary competition

VulnHub just turned two, and to celebrate, they held a three week competition. The subject is Rasta Mouse‘s challenging VM, Sokar, which features multiple interesting and very recent vulnerabilities.

The challenge took me quite a few hours; much longer than the three hours that someone reportedly finished under. However, I did some interesting things, so please read on if you are interested Python scripting, time-delay based exfiltration, file injection through unusual channels, memory forensics, password cracking, and how a client application (Git) can badly bite you in the butt.

Initial scanning

It’s usually pretty safe to get heavy handed with a new VM; no administrators are watching and it’s usually the quickest way to find the attack vectors…

OK, so we’ve got one lonely port, and this is what it’s showing…Selection_010

There’s nothing particularly exploitable looking about the page. It takes no user input, and it appears to be presenting pretty static information. When refreshing, the contents (a list of connections output from netstat) do not update automatically; instead they are updated periodically, probably by some cron job on the server.

The page contains an iframe which executes /cgi-bin/cat on the server but, as the name suggests, this is probably just outputting a specific file on the server that we have no control over.

My first thought at this stage was, if this is exploitable, and it takes no user input, and it’s a CGI, then it’s probably a Shellshock vulnerability (Bashbug’s a far better name though).

I sent a test the server’s way to see if I could get execution.

Well, that’s a bit of a bummer. Am I getting commands to be executed or not? I need a time based test:

A delay;  great! I’m definitely executing commands on the server (note that the absolute path needs to be used), but I can’t figure out how to get data returned.

This is where I might have previously given up, but after writing an ICMP exfiltration script for Persistence last year, I decided to write a program to exfiltrate data from the server using time delays.

The conspicuous machine gun timing script

Later on I found out that I didn’t really need to do all of this, so this might make me look a bit stupid, but I definitely think I get some points for style here.

Here’s the script – exfil.py – which will exfiltrate the response of an arbitrary command on Sokar using repeated queries and delays to slowly drip out the data at about 10 bits per second. =) (Note that you may need to tweak the parameter exfil_delay to suit your network latency and VM performance. Higher is more accurate and reliable, but obviously slower.)

And here’s the output:

Not very fast and also contains some errors. 2 minutes to get a short directory listing. Pretty fun though. Of course, a network with an IPS or an observant administrator would probably shutdown the server before I could get any further.

So I went on my merry way, getting directory listings at a very slow rate as the apache web server process, until I found my next clue.

(It’s worth also stating here that this exfiltration script will only for for information that remains static. Getting a directory listing of a directory that was rapidly changing, or a file that was changing, would require script modifications.)

The scarequote to end all wars

There are two users on the server: bynarr and apophis. The former’s home directory is open to other users…

lime is script that I have execute access to. I decided to run this to see what it is, and I was surprised to find that without my exfiltration script it will output data over Bashbug:

I exfiltrated the contents of the script to find out what was special about it. Turns out that it echoes a single double-quote at the start.

Is this a quirk of Bashbug that everyone knows except me? Perhaps; this is the first time I’ve exploited it. Anyway, it means I can throw away the script and just use curl again which is far quicker; all I need to do is output a double-quote before all commands I need output from.

The unbearable lightness of Bynarr

I proceeded with further information gathering at faster speed, until I found that bynarr‘s email is readable and provides some clues…

This is actually really great news, as I had already been attempting to gain a reverse shell from the server under the apache user, but all network communications appear to be blocked. This is evidence that a network connection can be made by bynarr over TCP port 51242. Though, did they mean source or destination port? (Answer to come later.)

Uploading arbitrary files

Before trying to mess around with reverse TCP connections, I decided to make a script that would allow me to inject files onto the server. Here’s inject.py for your pleasure:

This script will take any file as an argument and place it in the /tmp/ directory of Sokar, using multiple 50-Base64-byte chunks.

Getting an interactive shell

Things we need:

  • A reverse shell:
  • The ability to run commands as bynarr. For this we will use pexpect, which we will inject onto the server
  • A script to interact with pexpect, allowing us to su to bynarr and execute the reverse shell:

(By the way, this answers the earlier question about whether TCP 51242 is the source or destination port. I discovered through trial and error that from Sokar’s perspective TCP 51242 must be the destination. I think, therefore, root was being a bit disingenuous when using the word ephemeral which would usually imply what the source port should be. =))

All three of the above files are uploaded to the server and run (once we make sure that we have a waiting socket on the attacking machine to accept connections!).

Ta da! Got a connection. (I check the id and improve the shell I’ve given quickly:

The Limey

With the interactive shell, we revisit the lime script in /home/bynarr. The script allows the loading or unloading of a kernel module called lime.so:

Execution of insmod is usually restricted to root, but we can suspect that if it’s been placed there by root then bynarr’s been given sudo rights to run it.

Doing some research on LiME reveals that it’s a forensics kernel module that allows extraction of the entire contents of system memory. Fantastic. This creates a 256MB file at /tmp/ram which I need to get off the server for offline analysis.

We’re already using the only IPv4 port that can allegedly be used for connections, and 256MB is too much to dump to the terminal in Base64 encoding. I could kill my connection and upgrade to a Meterpreter shell, but I’d rather keep my tool use to a minimum.

The choice of a new generation

I noticed earlier that Sokar has IPv6 enabled:

What are the chances that the administrator didn’t take the same precautions about IPv6 connections that were taken for IPv4? I ping my attacking machine from the victim:

Looks promising. I’ll just upload ftp (it’s not on the server):

And then upload the file for analysis from Sokar:

Memory hunting

There’s a lot of information to trawl through in the RAM dump (have a look if you don’t believe me).

Having already wandered around the server quite a bit by this point – and having found that everything felt quite secure (i.e. no services to exploit, no misconfigurations, no vulnerable kernel) – I was convinced that it was actually just password hashes that were needed and that the next target was either the apophis user or root directly.

Opening up ram in hexedit and performing some searches (e.g. ‘shadow’, ‘passwd’, ‘password’) provided many many results, but a search for ‘apophis’ yielded the fastest return with a copy of the /etc/shadow file:

Selection_011

I added the hashes to a file and ran john against them using the RockYou password list. After not very long, I got the password for apophis:

BOOM! Let’s have a look what’s in apophis’s home:

Ok, we’ve got an ELF executable, which is run as root, and which appears to be trying to access another server called sokar-dev.

What’s he building in there?

Taking a copy of build off the server to disassemble reveals that the main purpose of the executable is encrypted. However, by debugging the program, we can discover quite easily what it’s doing:

This tells us that the script gets root to execute:

It’s not immediately clear how this could help, as cloning a repository is a safe routine. If it wasn’t, then there would be hundreds of nefarious projects tricking people into executing exploitative code, right?

But I had a niggling doubt, so I decided to check the CVE database for git vulnerabilities, bearing in mind that Sokar has git version 2.2.0.

Well it turns out that Git 2.2.0 has a vulnerability. The CVE appears to be undetailed as of writing, but it’s been publicised elsewhere since 18th December.

You git

Essentially, if a user checks out a nefarious repository with Git version 2.2.0 it is possible for an attacker to get arbitrary command execution. This only affects case insensitive file systems, so Linux should really be safe. However, the location where we’re going to be checking out to – /mnt/secret-project/ – is on a vfat volume, which is case insensitive:

The end is in sight. First we need to get Sokar to recognise our attacking machine as sokar-dev. As luck would have it, /etc/resolv.conf is world writeable!

We add a DNS zone file to BIND on the attacking machine, and of course we get sokar-dev to resolve to us. I’ll provide both IPv4 and IPv6 addresses just in case the administrator opened the IPv4 firewall just for this purpose. (Although, I’m pretty sure that IPv6 wouldn’t work anyway as the addresses we have are only local-link addresses and the interface/scopeId would need to be specified in the git command.)

An evil repository

The git clone command is vulnerable because we are able to take control of the user’s git configuration. The simplest way to abuse that is to create a post-checkout hook that the user never made that will execute an arbitrary command.

The command we will run is:

i.e. add full sudo privileges for user apophis.

To do so, we create an evil repository with a post-checkout hook in the .GIT/HOOKS directory.

To show the creation of a bad repository, I’ve made a quick video. The working location is root‘s home directory on the attacking machine; that is the location that the victim’s root user is going to connect to to retrieve the repository.

Privilege elevation

All that leaves is to clone the the repository, which will in turn checkout the HEAD revision, write a hook to .git/hooks/post-checkout, and execute it…

Iptables

Just for completeness, here’s the iptables configuration that prevented all connections except bynarr‘s outgoing connections to destination TCP port 51242, root‘s outbound SSH connections to sokar-dev, and the server’s outbound DNS queries.

Conclusion

This was a great challenge.  There were lots of steps covering many unrelated areas and it didn’t feel contrived. After my last big challenge which mainly concentrated on binary exploitation, it was nice to attack a machine that was mainly vulnerable through tools and configuration. It’s close in spirit to the machines in the Offensive Security‘s PWK course.

It would have been nice if there had been an additional step required to modify /etc/resolv.conf; that was the only bit that felt a little unlikely. However, despite that it still proved to be very time consuming and frustrating (in a good way) and I highly recommend others to try it even now that the competition has closed.

Thanks again to Rasta Mouse and g0tmi1k from VulnHub for the great work on this. Please feel free to leave any comments or questions.