How to Attack and Defend Your Website (2015)

Chapter 3. Finding Vulnerabilities

Abstract

At this point, readers have learned about exploitation. In this chapter we discuss how to actually find these vulnerabilities by offering a simple step-by-step process.

Keywords

pentesting process

content management systems (CMS)

filtering bypasses

Hopefully, you have learned a little bit about exploitation in this book. The examples we have given are some of the most basic types of exploits a hacker can execute against a website. Now we will discuss how we actually find these vulnerabilities in the first place.

Hacking is all about being very mechanical and following processes as well as understanding the technologies.

Even if you are attacking a large web application, remember to always check for obvious things such as searching the pages in Burp Suite for comments. You might find a password in the developer comments – this has happened to me in a pentest before!

Ask yourself other obvious questions, for example, is the application using a content management system (CMS) like a Drupal, Wordpress, or a lesser known one? If it is, Google it! Try to find publicly available vulnerabilities and exploits. If somebody has already done the work for you, there is no reason for you to do it again. Look it up, see if there are publicly available vulnerabilities and exploits.

Next, try to discover if there is a default password on the CMS you are trying to hack. The better known ones will typically not do this, but some of the lesser known ones often will. If so, try it out on their admin page and see if the default password will work.

Look for obviously suspicious pages, for example, sometimes you can reset a user’s password without actually being authenticated as that user since all you have to do is hit a page called something like “resetpassword.php.”

As I mentioned, hacking a web app is a game of patience and repetition. Take notes! I mentioned at the beginning of the book that I like to have a spreadsheet open where I can make notes about things that I see, things that I find, things that I have already checked, things I have not checked.

Understand the application, understand what it is doing, how it is passing data, why it is passing data, what technologies are being used and where. After you understand the application, you should have a good idea where to find the login function for the application.

Following from this we know that the username and password are usually stored in some kind of a database and this is a great place to check for SQL injections. Look for other things, for example, is it echoing back a string somewhere when you enter syntax?

Always go for the obvious vulnerabilities first before trying more complex exploits.

One thing you should never ever do is run an automated scanner at an entire site because, although there are many great scanners out there, they tend to miss a lot of vulnerabilities. You need to understand the application and understand what it is doing before you can actually break it.

3.1. The basic process – steps

First, map the entire application; discover hidden content with the Burp Suite Spider and apply some educated guessing in order to find pages to attack. Look at HTTP requests and responses when you navigate the application. Try to understand how requests and responses are being passed back and forth.

Try to understand the technologies behind the application. Is it using PHP, is there some kind of database, is it JavaScript heavy?

Following from checking the obvious, we should look towards exploiting client-side controls that attempt to stop a user from doing something through parameters in GET or POST requests. Look for attempts at stopping the user from typing certain characters into text boxes since these are often good injection points.

If somebody is stopping you from doing something on a web application there is probably a reason for it, and if you can bypass that and find the reason for them to try to stop you from doing that, it is usually a great way in.

A general note on injection attacks: always URL encode when putting characters into parameters since it never hurts but always helps.

Check for SQL injections within the applications by trying special/reserved SQL characters, for example the apostrophe symbol, pound sign, dash, plus, parentheses, and so forth.

There is a huge amount of information out there on how to find and exploit SQL injections and we have only scratched the surface.

Check for cross-site scripting by entering the string we used in generating an alert box. Look at what happens when you try this (make sure it is URL encoded), and observe the response in a browser. If you see an alert pop up you just found cross-site scripting. You could actually go out there on a lot of websites and find cross-site scripting by doing that, although you should of course never try to pentest a site without permission.

If you do not see an alert pop up, that does not necessarily mean that it is not vulnerable to cross-site scripting. You can check the responses either in Burp Suite or by simply right clicking in your browser and viewing the source. Something to check for: are your script tags being filtered or changed in some way? If they are being filtered or changed in some way, can you think of a way to bypass that filter?

There are a lot of sloppy filters out there: check out what it is doing and see if you can bypass it. Understand what the application is doing to your attempted payload and then try to shape it around that. Failing that, there are also some really good resources online for “filtering bypasses” that are very simple to use. You can pretty much copy and paste strings into parameters and often they will work, but try to understand what you are doing rather than just copying and pasting.

Be very patient and eventually you will begin to understand where vulnerabilities are most likely to occur and that will end up saving you a lot of time.

3.2. Exercise – finding vulnerabilities

The final stage is to Capture the Flag!

Go to course.hyperiongray.com/vuln1, follow the instructions, and use what you learned to guide you.

If you solve the challenges and capture the flag, send me an email (acaceres@hyperiongray.com) and I will give you a shoutout on my personal Twitter account and the Hyperion Gray Twitter account.

Happy hacking! I really hope that you have enjoyed this book as much as I enjoyed making it.