Exploits in The Attic - Visiting Forgotten Metasploit Modules

About The Project - Taking a look in the Attic

I was poking around at PRs and issues within the Metasploit project and stumbled across something pretty interesting. There’s a GitHub label that exists within the Metasploit project called “attic”.

The “attic” label from my observations appears to be for modules that maintainers or contributors need to finish up but don’t quite have the time. Much like that shoebox full of comic books, you carefully set it aside in the attic to return to it at a later date (if at all).

However, while others may not have time or there are more pressing issues to fix; you might find just the exploit you’re looking for! I was able to download and successfully use with little to no change multiple exploits that contain the “attic” label. At the time of this writing, there are 81 closed PRs with the “attic” tag. This label does not imply they work and some may be in worse shape than others. However, it does give a starting point to exploit experimentation.

Testing Environment - Docker & Targets

Removing barriers from within your environment to get as close to immediate feedback as soon as possible is important not only in normal software development but also in exploit development as well. Seeing your changes instantly allow quicker iterations and overall quicker PoCs.

Leveraging Docker on my host machine to drop in, modify and reload modules proves to be a bit faster from my experience than reloading and testing modules in a “traditional” Kali Virtual Machine. Perhaps it’s just not having to context switch between multiple virtual machines, or maybe it’s all a placebo effect and I’m trading one abstraction for another. Regardless of if it’s a placebo effect or not, staying focused on the exploit and not being distracted by tooling allows you to “stay in the zone” and iterate faster.

The Metasploit Wiki has a well-documented section on how to get an environment up and running for Metasploit framework development. However, if you’re just looking to do some module testing; you can get away with much less.

Nima Saed has an excellent blog post on bootstrapping a Docker-based Metasploit environment. By taking their example and adding an additional directive to share the local Linux machines’ /tmp/ within the container, you’re ready to build and share executables between the container and the host system for transportation to your target machine.

function msf-docker() 
{   

    if [ -z "$(docker network ls | grep -w msf)" ];   then       
	# start docker network
	docker network create --subnet=172.18.0.0/16 msf;
    fi   

    if [ -z "$(docker ps -a | grep -w postgres)" ];   then
	# start postgresql db
	docker run --ip 172.18.0.2 --network msf --rm --name postgres -v
"${HOME}/.msf4/database:/var/lib/postgresql/data" -e POSTGRES_PASSWORD=postgres
-e POSTGRES_USER=postgres -e POSTGRES_DB=msf -d postgres:11-alpine   
    fi   

    # start docker msf
    docker run --rm -it -u 0 --network msf --name msf --ip 172.18.0.3 -v
"${HOME}/.msf4:/home/msf/.msf4" -v "/tmp/:/tmp/" -p 8443-8500:8443-8500
metasploitframework/metasploit-framework 

}

A key component within the alias above is the sharing of the .msf4 directory from the host machine into the container. This is combined with modules with the attic tag, and you’ll have an environment that will make it easy to test new modules.

Attic Module for LXD Privilege Escalation - Ubuntu 20.04

StealthCopter originally developed a Metasploit module to take advantage of an lxd escape that later received the attic label. By leveraging the shelved module in the test environment described in the previous section, it was quite easy to gain a root shell on a fresh install of Ubuntu 20.04.

Below you’ll see I already have a user level shell (uid 1000) and am preparing the lxc privilege escalation post-exploitation module.

After specifying the session local lxc image is leveraged to complete the privilege escalation.

Now that I have a basic shell on the remote machine via the privilege escalation, I will upgrade to a meterpreter shell and visually display that I now have a root session on the remote machine.

Being able to plug-and-play with Docker & these modules opens up not only new room for experimentation but also a chance to give back and test and provide comments to these pull requests.

Beyond The Blog - Thoughts on Open Source Software & Development

Maintaining Open Source software is difficult. When you’re working in the public, it’s easy for many to be a critic. My hat is off to those contributing their time to development, support, and testing to open source software across the board. It’s those thankless hours that go into coding and documentation that helps someone else, somewhere, at some time across the internet in the early hours of the morning when they’re trying to get their shellcode runner to fire. Experimenting or tinkering with source code and reading internet blogs on how to do interesting things with your machine is an education in itself.

For all of you that have put content for free into the world, I thank you.