Ball ache level, AI without memory is hard, so I cheated a bit.
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)
It may sound like an oxymoron, but it’s a legitimate concern among the good guys in the security industry. Under the circumstance that a company has authorised you to try and hack into their live system, you really don’t want to be pissing around with ‘dangerous’ SQL injections. Dangerous is defined here as an SQL injection which results in undesirable data modification in the database, which could have otherwise have been avoided if the SQLi was considered more carefully (or wasn’t present in the first place). Let’s have a quick demonstration.
Mr Developer decides that passing unsanitised user input is a good idea, and that prepared statements are not. He wants to use a SELECT query to determine if the username and password are correct, and he also wants to update a table containing login information using an UPDATE statement. The company Mr Developer works for have received a tip that the developer might be a bit of a tit, and decide to hire Mr Security Man to try and break into Mr Developer’s web application. Unfortunately, Mr Security Man is also a bit of a tit, and thinks that still using some variant of ‘ or 1=1 — is a good idea. Let’s see how it all unravels:
SELECT * FROM tbl_test WHERE username = 'test' AND password = 'pass';
Above we have an innocent enough looking SQL statement. The attacker finds the login form associated with this statement and injects the password field with ‘ or 1=1 –
SELECT * FROM tbl_test WHERE username = 'test' AND password = 'pass' or 1=1 -- '
Mr Security Man is excited, he’s bypassed the login form and is now sitting on the site with a message reaffirming his suspicion that his non-skiddy SQLi has landed him the test user. “Hello test!”. Excellent.
Unfortunately, Mr Security Man didn’t realise that Mr Developer runs an UPDATE statement on an audit table using his username and password. This is where brown hits blade.
mysql> select * from audit; +------+----------+----------+------------+ | id | username | password | last_login | +------+----------+----------+------------+ | 1 | test | pass | yesterday | | 2 | admin | password | yesterday | +------+----------+----------+------------+ 2 rows in set (0.00 sec) mysql> mysql> UPDATE audit SET last_login = 'today' WHERE username = 'test' AND password ='pass' or 1=1 -- ' -> ; Query OK, 2 rows affected (0.01 sec) Rows matched: 2 Changed: 2 Warnings: 0 mysql> select * from audit; +------+----------+----------+------------+ | id | username | password | last_login | +------+----------+----------+------------+ | 1 | test | pass | today | | 2 | admin | password | today | +------+----------+----------+------------+ 2 rows in set (0.00 sec) mysql>
Whoops? It’s okay though right because it’s only an audit table? Well, not really. It was only an audit table in this example, and a few things had to happen for this injection to be ‘dangerous’, but are they that inconceivable in real life?
Okay, so if ‘ or 1=1 — is bad, what should be used instead? Well, that’s a tough question, because any form of SQLi transforms the structure of the statement, which could potentially manipulate data in ways unintended or by second-order. I’m currently of the opinion that the safest way to test for SQLi is by forcing a syntax error. Doing this shouldn’t get you passed a login page, but it will at least indicate the presence of an SQL injection.
A slightly riskier stratedgy would be the utilisation of the ORDER BY or LIMIT clauses, or the BENCHMARK function. While the web app probably has to be of particularly bad quality for the aforementioned clauses or function to result in undesirable data modification, this is still a possibility you have to assume if you don’t want to be Mr Security Man.