The Damn Vulnerable Web App – Part 4

Apologies for not posting so much recently, I have been away in Italy, attending the absolutely excellent AppSecEU 2016, which is the big OWASP convention. They do one in the US, and one in the EU each year. If you ever get the chance to visit one of these conferences, I would highly recommend it.

I had the chance to attend some python training too, which was equally excellent, and spurred me on to keep hacking away at the DVWA and some other scripts I have been working on for a while. The first of them is a re-worked version of the brute force intrusion script we first covered in the DVWA – Part 2.

In that first example, below, we just ran through every line in each file. If you don’t remember, then it looks like this.

The code is OK, but there was a problem with it, where it would work with hard-coded credentials, but not the larger rockyou.txt list that is included in Kali Linux.

After playing around with the code for an hour or two, and trying out some best practises (functions, closing files etc) I ended up with this.

This worked with the much longer rockyou.txt file straight away, I’m guessing due to the close() method used on the files. Also, I added the users we found in the SQL injection attack we used in Part 1. The users had no specific naming convention such as first name + first character of last name, so I just stuck them in the file and waited.

The names were admin, gordonb, 1337, pablo and smithy. We already had the password hashes, so could have used John the Ripper, but I wanted to try them in the brute force python tool.

I used only the top 100 most commonly used passwords, just to check if it was working, and it returned successes with admin, smithy and gordonb almost immediately. Pablo took a little longer, after I realised that my wordlist was actually the problem, rather than my script (I had been using a concatenated version of it, that I must have broken somehow). In the end I also got the password for 1337 too. You can see them all below.

Also I noticed that my tool kept on going, even after it had finished with all the users, mainly because I didn’t give it a finished condition other than it had to go through all the usernames and passwords. That is certainly an optimisation for the future, to break it out of that particular loop when it knows it has successfully found a password, and to stop trying that username.

I’m going to leave this post as it is for now, as there is another topic that I want to cover in greater detail, and like functions, I want to keep every post focused on one topic, and do that one thing well.

Next up is something I started working on after seeing Frans Rosen talk at Security Fest, information gathering and subdomain enumeration. There will be plenty more posts coming afterwards too, as I have a lot of hacking left to do after the very inspirational AppSecEU.

I hope you have an amazing week!

Leave a Reply

Your email address will not be published. Required fields are marked *