using perl to grab IP addresses of multiple hostnames

Recently while conducting a vulnerability assessment for a rather large customer I was given a list of hostnames from around 20 domains culminating in a list of over 5000 targets that needed to go through the motions. Due to scale of the testing I needed to run the scans from several cloud nodes simultaneously to speed up the scanning. The other thing I needed to do was to extract all the IP addresses from the hostnames so as not to scan boxes multiple times when performing Port Scans for instance.

I had been playing with Perl for literally a couple of hours and decided to give writing my first Perl script a go in order to grab all the IP addresses from the list of hosts which I could then Unique and Sort to get the final list of target IP’s. I initially played with the idea of running ping commands or nslookups and then regex’ing the IP’s from there but I discovered a fantastic method called “gethostbyname” in Perl.
read more

decrypting base64 encrypted binary hashes

I came across a database while testing the other day which happily contained a table called users with the good old id, username and password fields. What made this a somewhat interesting find was the fact that the passwords appeared to be encrypted as base64.

After I stopped giggling I dumped the database and grabbed the first few hashes in an attempt to quickly script the decryption. The script ran fine although I ended up with a lot of garbled text and no plain text passwords. I decided to try decrypt these passwords using several online websites when I discovered that they were actually binary files that had be encoded with base64. I began to doubt my sanity and asked myself why anyone would have passwords stored as binary files. I mean, the log in page didn’t have a field for username and an upload box for password so what was going on?


read more

apache log poisoning with local file inclusion

So we have our Local File Inclusion vulnerability and we can read the “/etc/passwd” file, now it’s time to start escalating the attack so that we are able to execute our own commands on the target system.

lf1

In the previous post, we found the Apache log files and particularly the Apache “error.log” file using Burp Suite’s Intruder module. We are now going to use this log file to inject our own PHP code into this page.

If we tried to access “http://www.example.com/askjdhaksghfkgf” we should get an Error 404 telling us the the page was not found. Additionally, this should also echo our invalid request into the “error.log” file and we can now clearly see that by requesting anything that generates and error we have the ability to influence the contents of the “error.log” file.

lf2
read more

finding the apache log files using burp intruder

Often when conducting security assessments it is necessary to go beyond just identifying the vulnerability, reporting it and heading out for a beer. Sometimes, like when conducting a penetration test or when asked by a client to demonstrate business risk, it is necessary to gain command line line access to the machine to show the risks associated with having a web user being able to execute commands on their machine. Often this involves getting a shell by some means but in the case of Local File Inclusion (LFI) simply finding the Apache Log location folder can be enough to start running commands on the system as the Apache service account.

Often I’ve wasted hours trying all sorts of combinations trying to find the correct location of the log files by looking up version numbers and identifying operating systems but being the true to the Pentesters code, sometimes it’s better to be lazy and just automate the damn thing. So what a buddy of mine and me did was to compile a list of common Apache log file locations and files that may indicate Apache log locations across different operating systems. This list is by no means comprehensive and if the developer or engineer has bothered to spend 5 minutes moving the log file locations then chances are that this list may not help you.
read more

fault lines: controlling the web

In January 2012, two controversial pieces of legislation were making their way through the US Congress. SOPA, the Stop Online Piracy Act, and PIPA, the Protect Intellectual Property Act, were meant to crack down on the illegal sharing of digital media. The bills were drafted on request of the content industry, Hollywood studios and major record labels.

read more