by Stuart Rorer

Never Satisfied

I was something of a devious child, always coming up with schemes. One that worked well was when my parents would go through the drive thru at the bank. At that time, they would hand out suckers to each child in the car. In my case, my sister and I were always in the back seat. Not satisfied with just one sucker, I thought of a scheme to get more.

My sister had a large Raggedy Ann doll, and I had an extra coat with me. I put the doll in the coat, propped her up against the window and pulled the hood over the doll’s head. I made sure to sit near the doll, with my sister at the other end of the seat. We would both pretend to be talking to it. The plan worked and the teller gave us three suckers.

After my sister and I argued over who got the sucker, we decided next time we would enhance our strategy with another large doll to receive two more suckers. This worked for quite some time, until one day we stretched ourselves too thin and the teller caught on. The doll fell forward into the floor and our trick was revealed.

I love to use that story to illustrate the concept of attacking applications through logic flaws. Simply taking a legitimate action and finding a way to bend it to your will.

The Logic Behind It

Logic attacks are one of those strange, unique, categories in testing. It isn’t really restricted to any specific field of testing, because it’s everywhere. In many ways it’s what hacking is about, understanding a system so well that you see beyond the original intentions of what was created and figure how to do things that weren’t expected to be done. This is especially true in pentesting, where it would apply to software, procedures, systems, and more!

How to Find Them

Finding them typically requires thinking outside the box, a phrase that is so often mentioned yet less often implemented. The first step is understanding the object being tested. Since we are focusing on web applications, the initial task would be to dwell on what the application actually does. Let’s look at some examples and see what we can find.

Imagine that we are pentesting a bank and we have been granted a basic consumer account for checking and savings. A definite must would be going through all the different functions that are visibly available to us. I often like to use a mind mapping tool or whiteboard to map out different areas and functions. There are many free mind mapping tools online.

This will help to identify potential vulnerable areas and think of areas we might be able to do things beyond that of what is expected. Also, don’t forget to think of functions that also might exist but aren’t visible. Often, they may be available, if you can figure out how to access them.

Indirect Object Reference

For our example application, there is a Transfer Funds function that lets the user transfer money from one account they have to another. Already, the warning flags should be going off, as there are many ways a feature like that could easily be abused. We will focus on a possible indirect object reference (IDOR) in which we attempt to access an object (account number) we shouldn’t have access to. In the example below, we see two parameters. Let’s take a look at an example HTTP request. First, we see accountNum which is our primary account, and then the destAcct which is the account the money is being transferred to.

Now what if we put the value of accountNum, in destAcct, and decremented the accountNum from 1234567 to 1234566?

An interesting response, so maybe that account doesn’t have the funds. Let’s try again and decrement the number once more.

Obviously, this is a very simplistic example, and one that I hope is no longer out there. However, if real, would have been the result of failure to realize that the parameters could be manipulated in the request. A proper transfer function should come with backend checks for proper authorization and logging for any potential tampering.

Command Injection

Another interesting example, and one that is actually still found from time to time, revolves around a form of command injection. This used to be common in home router interfaces. Many home routers contain diagnostic tools for troubleshooting like the one pictured below.

There are several fun things we could test for, but one of the most interesting would be for command injection. While the function is meant for legitimate troubleshooting, for our purposes, let’s see if we can make it do something that wasn’t expected. To start let’s see what happens in the request.

From an initial perspective it’s fairly simple, the application is taking in an IP and sending it to the backend to ping. This means that our input is part of a command. Let’s see if we can trick it by using a command separator such as “;” to fool it into running a command of our own.

Success! It looks like we were able to get a directory listing as shown below.

While this is another simplified example, command injection still exists. An attack such as this could lead to the compromise of underlying systems and associated networks. The key is to finding what inputs are being acting upon on the backend, and how to properly inject into them. If defenses are setup, this might require encoding our input to bypass any filters. Let’s move on to the final example.

Cross-Site Scripting

Now we are testing an application that has a common feature, a profile page. Image uploads can provide potential for many vulnerabilities, but we’ll focus on trying to execute a Cross-Site Scripting (XSS) attack.

First, we need to find what types of extensions it allows. This will determine how we implement our attack vector. Attempting to upload a bad known file type such as .exe, or .txt file for an image upload usually will give us the message we need. Sometimes the application will just tell you straight up which files are allowed. Bypassing the file extension restriction is another fun thing to explore, but for now we will look at executing the XSS.

We can see that only .png, .jpg, and .svg are allowed. This is perfect, .svg’s are notorious for trouble. SVG’s contain markup language which we can use to inject our XSS. Now we just need to construct a simple .svg with our payload. In the example below we inject a JavaScript script tag, which will prompt anyone who views the image with the message “Hello Out There”.

Now we just choose that file to upload and wait and see what happens.

Success! Now keep in mind that different browsers may have a different reaction. It’s important to test the exploit with multiple browsers to see if it will also execute under that context.

Conclusion

While these examples were simplified, the concept is still the same. Whether it is testing a web application, or something different entirely, the primary objective is to understand the function, how it works, and how it might be able to be exploited. Breaking things down into smaller concepts, using mind mapping tools, and reading up on the item tested are all things that can help in getting a better grasp of what’s going on. Having a firm grasp on pentesting concepts, such as the OWASP top ten, is also helpful as it will enable you to realize a vulnerability when you see it. I’m sure in no time you will be thinking of some creative scenarios of your own to test and try!

About Stuart Rorer, Security Consultant

Stuart has worked in the IT Industry for more than twenty years and has worked within Cyber Security for the past twelve. In the past he has held jobs in the education, government, and private sector, and for the last few years has specialized in web application penetration testing. Stuart has performed testing on clients in all sectors, many of which have been in the Fortune 500. He enjoys spending time in research and exploring new penetration testing tactics, and techniques.

Certifications:

CPT, ECPPT, ECSA, CEH, SEC+