COMMAND: nmap -v -sS -A -PN <IP>
I I initially investigated the web presence to see what was going on there. It seems to just poke some fun at the attacker, however I did find a LFI vuln in the main page but was only able to read a few files with it, nothing major though.
Now since I couldn't exploit the LFI vuln in any worthwhile meaning I continued on. I now turned my attention to the HTTP service running on port 10000. This of course turned out to be a running instance of Webmin, this is the default port for it as well. We dont get any real version info except from the banner which indicates it is likely an early release. We do a quick check and find CVE-2006-3392 which when combined with the approach used for the earlier released CVE-2006-3274 should allow local file disclosure on anything less than version 1.29 (both Usermin and Webmin affected). I reviewed an existing PHP script found in Exploit-DB but since I don't like PHP much I decided to write my own script in bash. You can find the source to my script here: https://pastee.org/ymv9m. You just point it at the target server, indicate the port webmin/usermin service is running on and let it know what file you want to get. Since Webmin typically runs as root or with root privileges we can read pretty much any file on the server. Using my script I was able to snatch the /etc/passwd, /etc/shadow, and a few /home/$user/.ssh/authorized_keys files with this vulnerability.
You could stop here and direct all attention to cracking the Unix password (DES) hashes from the shadow file but I decided to investigate further to see if there were any other ways we could get a shell first...
Nessus to the rescue:
We find the target server has a critical vulnerability identified, marked as Debian Weak Key Generation Vulnerability (CVE-2008-0166) which indicates a remote shell is possible. I looked it up and found out it was an interesting vulnerability indeed. If you want the full writeup and details you can check out original Debian security writeup here: http://digitaloffense.net/tools/debian-openssl/. Essentially there is a flaw in how the random generator works and due to the flaw the randomness is not so random. In fact it uses a base around the current process ID, problem is that PID number possibilities are limited to 32,758 possibles so we have a severely limited key set as a result. HD Moore figured out we could pre-generate these keys and bruteforce a weak generated key to find the matching pair and thus allow connection over SSH or decryption of SSL encrypted data. You can read the article to find out how to generate your own keys as well as a few links to sets available for download. There are several scripts in the exploit databases available in several languages which do the job of finding the right pair but I my favourite after testing several was the Warcat Team's python script as it had the best results without drastic compromise on timing. Essentially they all sort through the possible key files using threaded SSH connection attempts until one pops indicating a match has been found. You may need to alter the script to insert some delays and such if you have a sensitive target or lockout policy in place (could also tweak to rotate after x number of attempts to attack a different user account). You can then turnaround and use this found key to connect or to decrypt depending on if you are attacking SSH or SSL. This approach would be what I would call the ONLINE approach and is not light on the logs of the target server. Alternatively if you already have one key you can use the pre-generated keys in an OFFLINE manner to find the matching key wihtout any need to send anything to the target server. Once you find the match you can again turnaround and connect or decrypt based on your situation.
Quick run through of abusing this against SSH to pop shell:
Using the keys you made or downloaded (see link referenced above) and the Warcat script (exploit-db) we simply point script to our keys, the target server, the port SSH is running, and give it a valid user-name for SSH account on server.
It will then launch the bruteforce attack until it finds the matching key. You might need a little patience but in most cases it should be able to test the full key set in about 20 minutes or less. Once its found you should get some kind of indicator that the key was found, Warcat script even gives you SSH syntax for connecting after finding:
Once known we confirm its working by actualy connecting:
We finish things off with the sock_sendpage() or sendsock.c exploit which yields us root privileges for the final win against pwnOS 1.0.
I understand there are other ways this can be done but thought I would share my experience with you guys. In case anyone still having trouble grasping everything or for those who just need the visual walk through, here is a short video on everything: http://www.youtube.com/watch?v=YudNYxQw240
Until next time, Enjoy!
