Tag: metasploit

Categories
Uncategorized

Maintaining Presence and Installing Backdoors

By completing this exercise I learned that the best backdoor is one that you don’t need to install yourself! There are two backdoors that I opened up within the Metasploitable 2 operating system (msf2).

The most powerful and easiest backdoor was to login using the root shell, create a new superuser, and then add this user into the SSH list so that I could make use of the existing SSH server configuration. Easy-peasy.

I also wanted to install a second backdoor in the event the SSH server was turned off, my new user was spotted and removed, or one of the other root shell access points was patched. Keep in mind, all the work I’ve done, to this point, I still do not know the root password.

In brief, I created and uploaded a bind_php shell payload. I connected with a root shell, logged into the Apache server, uploaded the compromised payload which looks just like a regular PHP file, installed a listener on my attacker machine and then wired together the PHP exploit and the listener. I consider this attack to be beyond basic and maybe moving into the intermediate category. Let’s break it down.

Payload

I used MSF Venom to create a compromised PHP file. I then uploaded and buried this file within the Apache directory.

Listener

After uploading the compromised PHP file, I configured Armitage to listen to port 4001 at the target machine.


Once Armitage was listening, all I had to do was navigate to the infected PHP file in any browser and it would connect to the listener automatically. I now have persistent access to the host in a much more stealthy way.

Advantages

The PHP backdoor is difficult to identify. Unless the user is monitoring their own traffic on port 4001, it is unlikely they will spot the file hidden within hundreds of PHP files.

Also, the backdoor only connects and runs when I fire it up remotely, so it is less likely to be spotted.

This technique uses the existing www-data daemon within Apache. It doesn’t require access to any of the users within the operating system. This is useful in the event that SSH access is closed or my new superuser is discovered and deleted. I can log in when I need to, browse around the file tree, upload additional compromised files if needed, and download the /etc/passwd file and use John the Ripper to try to gain access to one of the existing accounts.

Update: I subsequently did crack a few of the other operating system accounts using John. I have previously written about my experience with John so I tried to avoid using the same techniques in this lab.

Challenges and Learnings

This was a fun exercise and much more challenging for me. I feel very proud about this work and feel I’m beginning to move beyond basic techniques into more advanced approaches.

I learned several important lessons.

1.) Having root shell access is much more powerful than gaining shell access through one of the lower privileged daemons. The daemons are plenty useful, nonetheless.

2.) I struggled mightily in crafting the right payload, getting the permissions correct to run it, and then connecting up the listener. I was getting an Access Denied error on the payload until I changed ownership to the www-data service. I am sure someone more skilled than me would have found a way for Apache to run the payload as root maintaining superuser access in the shell. I guess I compromised for a little less here.

3.) It would be good for me to create a username/password scheme because the PHP backdoor would be discoverable and usable to other attackers that are scanning the web files.

4.) The PHP backdoor is really easy to remove if spotted. All the user needs to do is delete the file. So in a way, while it is well hidden, it is brittle and speaks to all the more reason to install redundant backdoors.

Conclusion

Over the past two months I compromised the host, exfiltrated data, and installed multiple backdoors to maintain presence. At this point, I’m now going to turn my attention higher in the stack and start working more diligently on web vulnerability scanning through OpenVAS, Vega, Burp Suite, and other man-in-the-middle proxies.

Categories
Uncategorized

Got Root? Two More Exploits.

I’ve continued my experimentation with the Metasploitable (msf2) operating system as well as the Metasploit framework. I’m now up to five, I think, total successful exploits. I will write about two more of them here. The first, most basic, exploit I wrote about previously took advantage of a misconfigured rsh-server.

My next two exploits followed the same pattern:

  1. Conduct an nmap scan to see what services are exposed.
  2. Find open ports and search Metasploit for a highly probable exploit or exploit + payload to open a reverse shell with root access

I was successful in exploiting the IRC server running on port 6667 and Java server running on port 5432.

I think the exploit of IRC server running on 6667 was added to msf2 just to give newbies like myself something to practice on. I see little point in running an IRC server in light of more modern collaborative technology and the exploit we used is very dated and specific:

unix/irc/unreal_ircd_3281_backdoor This module exploits a malicious backdoor that was added to the Unreal IRCD 3.2.8.1 download archive. This backdoor was present in the Unreal3.2.8.1.tar.gz archive between November 2009 and June 12th 2010.

This is a great first exploit for Metasploit because I got to learn the software and run it successfully. It was the simplest of configurations–set your remote host IP address and go. Nothing more.

The second exploit I discovered is also dated (from 2011) and runs on Java. It was a little more complex.

multi/misc/java_rmi_server This module takes advantage of the default configuration of the RMI Registry and RMI Activation services, which allow loading classes from any remote (HTTP) URL. As it invokes a method in the RMI Distributed Garbage Collector which is available via every RMI endpoint, it can be used against both rmiregistry and rmid, and against most other (custom) RMI endpoints as well. Note that it does not work against Java Management Extension (JMX) ports since those do not support remote class loading, unless another RMI endpoint is active in the same Java process. RMI method calls do not support or require any sort of authentication.

This module requires picking and also delivering a payload. My first payload failed, a generic shell. The next payload I chose, a java reverse tcp shell, worked and I gained root access for the second time today.

Learnings

I’m getting more familiar with Metasploit as well as starting to see more clearly the holes in msf2. Up until this point I have resisted using Armitage, a visual UI for Metasploit, because I really wanted to learn about Metasploit directly. I think I will pick up Armitage soon if for nothing else, I think it will be a lot faster. I’m resisting the urge to just let Metasploit do all the thinking for me. I am intentional on what exploits I use and then trying to really understand why they do or do not work.

Update: I’ve since gained access to Postgres through the server and used psql to create/alter users and browse the tables.  I want to be thoughtful to make sure I keep learning.  I will not just get locked into the pattern of nmap >> metasploit >> root shell.  I was disappointed to see there wasn’t any fun data inside the postgres tables in msf2 and so no real incentive to learn how to exfiltrate the data.

I suspect many Metasploit users hit the stage I’m at pretty early on. Which is a lot of enthusiasm for hitting pay dirt occasionally, and the draw to stay locked in the same exploit pattern.