st27_ExploitWeekIntro.md

Introduction to Exploit Week.

This week we are going to examine some common web based exploits. You will also get the opportunity to put the theory into practice in the lab and do some hacking.

This is a pretty hardcore week, we will be looking at (and performing) real exploits of vulnerable services. However, you won't need any specialist tools or knowledge, just a web browser and a bit of thought. Some of this may be challenging to digest as you navigate through the material; however, rest assured, we'll explore the practical side of this content in the lab session

Intro to the Exploits

The exploits we are going to be doing are in the most commonly found issues with websites. In the first week we looked at the OWASP top 10. These are based on a survey of the most common security issues found on web services.

The two web based exploits we are going to look at are featured in the OWASP Top 10:

• SQL Injection
• Cross Site Scripting

These are very common issues, that could affect you when you visit web sites. We will discuss why they happen, how you can test for them, and methods that web site developers can use to protect against them.

Why these Exploits Happen

As we have moved from static web pages to the 'wonders' of Web2.0, with its responsive content and use of dynamic technologes such as javascript, we have needed ways of getting users to interact with a website. While this has let us do many amazing things, it has also been the primary cause of insecurity in web apps (and just about any other type of application).

The main problem here is that allowing users a way of arbitrarily adding input, means that they will do unexpected things. Therefore we get to RULE #1: NEVER trust user input. This is the root cause of many web based (and non web based) security flaws, and occurs in topics such as:

• Form Validation: Checking the information that the users have submited to programs, to ensure that no malicious code can be executed
• Buffer overflows: A prgramming flaw where we are able to overwrite a programs memory, changing its behavour.
• Remote Command Execution: Where a system allows remote users to run commands on a server.
• Users Breaking our lovely program by being idiots (RULE #2: The second you make something "Idiot proof", they will release an upgraded version of Idiot)

When it comes to validating user input we could spend some time discussing the merits of Whitelisting versus Blacklisting

• Blacklisting (filtering bad content) means we attempt to get rid of malicious input before using the result
• Whitelisting (allowing only good input) means we only allow a set of pre-defined inputs to be used

Both cause headaches, as they need to be well-designed to catch all the shenanigans that the user is likely to input, and in general this is impossible.

Personally, I lean towards blacklists (stopping the worst inputs), as whitelists don't tend to deal with Rule #2 (all users are idiots) quite so well.

Unfortunately there are no foolproof methods where filtering is involved, as it can often be bypassed by a bit of thinking. All we can do is remember that trusting the user is a BadThing(TM) and try our best to consider all the possible scenarios in advance.

Forms are (one of) the ways HTML deals with user input.

While the mechanics of forms, their input types, and their attributes could be another course, there are several interesting attributes of forms we need to consider as penetration testers.

A typical HTML Form

LD comment: This could be another step?

Let's consider the following password change form:

<form action="processor.php" method="post">
    <input type="password" class="form-control" id="password" name="password" placeholder="Password">
    <input type="password"class="form-control" id="password2" name="password2" placeholder="Repeat Password">
    <input type="hidden" name="user" value="dang42">

    <button type="submit" class="btn btn-primary">Submit</button>
  </div>
</form>

Looks good, right? Let's pick it apart a bit.

• The form sends a POST request to the processor.php page

• We have a few inputs:

  • Two inputs of the type "Password". These by default will be obscured when data is entered. The name field is the part passed in the HTTP request.
  • A hidden field, containing a pre-set value
  • The Submit button

The hidden field will not be displayed to the user, and is used by the web application to store some form of state.

Remember that HTTP is a stateless protocol, so each request is treated as an independent transaction (more on this when we get to Cookies). We can assume that this application is not using other forms of session management, so the user that the password change is applied to is the user specified in the hidden user field.

What can possibly go wrong here?

Lots, but predominately credential hijacking. The developer is guilty of three key mistakes:

• Security Through Obscurity
• Trusting user input
• Performing all authentication on the client side

Security through obscurity is a very BadThing(TM); controlling whose password gets changed with a hidden field is a terrible idea.

As l337 HaX0R d00dZ we should know about the mechanics behind the protocols we are testing. "Use the Source" and this should stick out like a sore thumb.

We also trust the user input (partially from above). This is bad because its easy it is to modify HTTP requests, so it is trivial to change the user field to someone else and take control of their password.

Finally, there is no authentication performed. This is probably the worst offence, as just asking for the current password (and performing a check against it) would stop both of the above attacks working.

So to exploit this we:

1. Login as a user we know
2. Send a POST request with our target user and whatever password we require.

Client side form validation

Client side form validation is where the form input is checked in the browser before being sent to the server. This allows us to do things like checking if the input type is as expected (for example, is that really an e-mail address). In the general case client side form validation is a good thing, because we can parse the form using HTML5/JavaScript and stop bad requests from being sent to (and rejected by) the server.

However, relying on this to clean up the user input is also a BadThing(TM)

• We can turn JS off, and avoid client side validation
  • HTML5 is a bit trickier but.....
• We can send whatever we want anyway (via requests)

If client side validation is used it is important that it is repeated on the server side (remember Rule #1)

Summary

A lot of web based exploits come from trusting the user to do what we expect them to do. Allowing them to add arbitrary input to any interactive components of a website, can lead to a toehold that we can then expand into a fully fledged exploit.

For the rest of this week we will look at two common web based exploits in detail, and show how we can either steal data or authenticate as another user.