I have been asked to revoke access to some of my blog posts relating to some technical challenges which were being used inappropriately, diminishing their educational potential for some individuals. [Retracted, nothing to see here] I’ll leave you with a summary of the challenges I had provided technical details for, without revealing the answers. [Retracted] The following posts have been made inaccessible on this website, any references to these posts made on any other site are not under my control and cannot be retracted by me:
- Bacterial Vaginosis – Windows Domain Pwning
- AIDS – Windows 2000 challenge
- HIV – File upload
- Genital Warts – X11
- Syphilis – Third party software challenge
- Crabs – SNMP challenge
- Chlamydia – PostgreSQL challenge
- Gonorrhea – chroot challenge #2
- Hepatitis – chroot challenge
- Scabies – Network challenge
- Hackme challenge #2 – Weak encryption
The majority of the challenges, and indeed real life engagements, can be broken down into roughly three distinct phases (excluding scoping); recon, attack, and report. The recon phase is important, if not the most important phase, because any mishaps here could lead to pain down the line when you don’t find any vector in the stuff you’ve discovered. The recon phase involves establishing what is accessible, usually through port scans. You have a selection of tools you can use here, including:
My approach typically involves firing masscan to get some quick hits and then running nmap while looking at the results of the masscan. masscan is quick, which is why I use it first, but it can also be inaccurate insofar as nmap reporting open ports masscan didn’t. That’s fine for a quick pass, as long as it is backed up by an nmap scan.
Once I’ve established TCP connectivity, I’ll move onto udp-proto-scanner, which covers some of the UDP ports. For full coverage, I’d use nmap -sU, but for the standard services udp-proto-scanner is sufficient (maybe even better), because it sends the expected datagram for the service on that port.
Recon doesn’t end at port discovery though – depending on the service listening, I’d consider version reconnaissance, directory bruting, user enumeration, and unauthenticated web spidering, just be wary you don’t breach the scope.
The line between recon and attack is murky. If an attacker pulls the MySQL version via unsanitised user input is that recon or attack, or both? The recon and attack phases cannot be represented as two distinct junks on a timeline, they compliment and feed into one another, and happen constantly over the course of an engagement.
The reporting phase is designated for creating a document which encapsulates the work you’ve done for the client in a form which is digestable by non-technical people, while also providing technical details of any findings which merit mention.
The report should include an ‘executive’ summary, which provides a 10 000 foot view of the issues raised in the target test, as well as more technical details, to prove and demonstrate vulnerable vectors.
Okay, enough fluffy bullshit, let’s get technical. One of the problems with the challenges I wrote about is rooted in the fact that discrepancies between them stick out. That is, if one challenge box has a port open that isn’t open on any other challenge boxes, you can be relatively sure that this will be your vector. In real life, this won’t necessarily be the case. Another issue with challenges in general is that as an attacker, you know that the target is vulnerable *somehow*, this acts as a sort of motivator, which you wouldn’t inhibit on a real engagement, because some targets won’t necessarily be vulnerable, no matter how hard you try.
That isn’t to say the challenges aren’t useful – on the contrary, I believe them to be instrumental in standardising my recon process, as well as refining my knowledge in rooting Linux boxes, which is why I consider it a shame that I cannot share the technical details with you, the reader … [retracted, I shouldn't keep this bit]. I would like to [retracted] apologise on behalf of my employer for this. Sorry.
Once you’ve got a standard user account on a Linux box, typically through a network service, the things you should be looking out for are:
- File permissions
- SSH keys
- Local ports
- Binaries which interact with files on the filesystem with suspect permissions
- Third party tools
- Log files
- Sudo capabilites (sudo -l)
- Shell histories (.bash_history / .zsh_history)