Metasploit Community CTF 2018 writeup
This weekend we participated in Metasploit Community CTF and got the 12th place out of 1000 registered teams (but according to organizers, 600 teams logged in). This time our team was small (chcx and me most of the time, deb_security last day) and we got the help from Miguel Mendez (@s1kr10s) from exploiting.cl for an important task.
Here’s a little review of some of the challenges. There were two machines: a Windows and an Ubuntu machine, both with a lot of services. Let’s start with some challenges related to Ubuntu machine and then continue with Windows one.
King of diamonds
There was a port 2222 open in Ubuntu machine:
2222/tcp open ssh (protocol 2.0)
Connecting to it using ssh client with verbose output enabled, showed us that it was using libssh . There was a public vulnerability some months ago that came up to our minds, then we used metasploit to exploit it.
auxiliary/scanner/ssh/libssh_auth_bypass
We got root privileges and started to dig up the filesystem. The only thing that we found were some files in /tmp that indicate that the running service sshd_fake_server was backdoored. Using strings on it, we could get the credentials myuser:mypassword to enter to the ssh service with a full shell.
After thinking it was a rabbit hole, werealized that there was a strange issue in the output of mount , it was mounting some files in /etc from /dev/xvda1 . We tried mounting that device and voila!
It was the hard disk of the docker host! Looking at syslog logs, we knew about the existence of this binary corey that could be speaking the flag. To know what it does, we transferred the file to our kali machine. We noticed it was quite heavy to be a binary, saw some PNG keywords in strings output and we thought that we could use the old foremost to try to extract the image.
It worked!
Looking at other docker containers, we realized that there were flags for other challenges! But unfortunately we’ve already solved them, the hard way.
Ace of hearts
In Windows box we found a file: ace_of_hearts.png.pgp . From a previous challenge that was exploited using SQL Injection, in the database there were two entries: a base64-encoded flag and a GPG key named ace_of_hearts.key . Using that key we decrypted this new file and got the valid image.
9 of hearts
As there were few challenges remaining and we still had this service on Ubuntu machine at port 8777, after days trying with several word lists we requested straight 9_of_hearts.png and bingo! But it wasn’t a valid PNG image.
The PNG header must be 89 50 4e 47 , then these bytes were swapped! A python script help us to reorganize the bytes:
Line 4 was important! The length of the original file was odd, then swapping every two bytes will lead to discard the last byte. It generated a valid image but an invalid checksum (and pngcheck told us it had a invalid CRC checksum too).
Entry to Windows machine
After trying to get access through exposed services in the Windows machine, there was a global hint provided by the organizers.
Try to enter Windows Machine fuzzing port 4444
It was hard to fuzz it using the network service because in presence of longs strings it will corrupt the memory and the service will be available one minute after.
It was a network service that accepted input and dropped a PE executable. This executable was the binary running on this port, then we have to analyze it. I have a Windows 10 machine to do binary analysis and running this executable didn’t work because it tried to register himself as a service before running. Eventually I patched the binary to avoid the service logic and go to directly run the listening socket.
Then I arrived to the following function, which I commented in the image:
It was processing our provided string (at most 1024 bytes) and then copying it on a stack buffer, adding also other string of 16 bytes, overflowing the expected buffer. After some tries, the length of our provided string that overwrites the instruction pointer was 1021 characters.
The final buffer in the program was [aclientSaysString + ourString].
Ok, we can place our shellcode in buffer and maybe jump there? Wedidn’t have any experience exploiting in Windows platforms and the memory mitigations that could exist in place. We asked guidance to Miguel Mendez @s1kr10s from exploiting.cl and he created a working exploit that provided us with a shell on the Windows server!
The key part is the variable return_addr . It has the value 0x10472CA7 that points to a memory address in the binary itself. This address contains the following assembly instructions: add esp, 0x14;ret .
ESP pointer is pointing to the start of the buffer [aclientSaysString + ourString] , then the instructions at 0x10472CA7 will move the ESP pointer ahead ( 0x14 positions) until our nop_sled and will execute our shellcode.
Ace of diamonds
In Windows machine we found this binary flag_finder_9000.exe and a file named obfuscated.png . The binary received as arguments a filename (in this case obfuscated.png and a magic number to decipher it. Analyzing it on IDA, we could see a comparison that if it’s true will lead to the deciphering logic.
Our magic number was processed and that result was compared in the first box of the graph view. We set a breakpoint at that place in the debugger, set eax=0x845FED to make the comparison evaluate to true and in front of the jnz instruction take the left path. As output, the binary created the file success.png .
We would like to express thanks to the organizers for the challenges, they were fun and we had a great time consolidating the team. Also it was a interesting infrastructure setup to keep in mind in case of organizing a competition!
