Tag Archives: Abuse of Functionality

Security Pictures

Security pictures are being used in a multitude of web applications to apply an extra step in securing the login process. However, are these security pictures being used properly? Could the use of security pictures actually aid hackers? Such questions passed through my mind when testing an application’s login process that relied on security pictures to provide an extra layer of security.

I was performing a business logic assessment for an insurance application that used security pictures as part of its login process, but something seemed off. The first step was to enter your username; if the username was found in the database then you would be presented with your security picture e.g. a dog, cat, iguana. If the username was not in the database then a message saying that you haven’t setup your security picture yet was displayed. Besides the clear potential for a brute force attack on usernames, there was another vulnerability hiding – you could view other users’ security pictures just by guessing the usernames in the first step.

Before I started to dwell into how should I classify the possible vulnerability in my assessment, I had to do some quick research in a couple of topics: what are security pictures used for? And, how do other applications use them effectively?

I always wondered what extra security the picture added. How could a picture of an iguana I chose protect me from danger at all? Or add an extra layer of security when I log in? Security pictures are mainly used to protect users from phishing attacks. For example, if an attacker tries to reproduce a banking login screen, a target user who is accustomed to see an iguana picture before entering his or her password would pause for a moment, then notice that something is not right since Iggy isn’t there anymore. The absence of a security picture produces that mental pause causing the user in most cases to not enter their password.

After finding about the true purpose of security pictures, I had to see how other applications use them in a less broken way. So I visited my bank’s website, entered my username, but instead of having my security picture displayed right away I was asked to answer my security question. Once the secret answer was entered my security picture would be displayed on top of the password input field. This approach to use a security picture was secure.

What seemed off in the beginning was the fact that because attackers can get users security pictures with a brute force attack, they can go a step further into phishing and use the security pictures of target users to create an even stronger phishing attack. This enhanced phishing attack would reassure the victim that they are in the right website because their security picture is there as usual.

Now that is clear that the finding was indeed a vulnerability, I had to think about how to classify it and what score to award. I classified it as Abuse of Functionality since WhiteHat Security defines Abuse of Functionality as:

“Abuse of Functionality is an attack technique that uses a web site’s own features and functionality to attack itself or others. Abuse of Functionality can be described as the abuse of an application’s intended functionality to perform an undesirable outcome. These attacks have varied results such as consuming resources, circumventing access controls, or leaking information. The potential and level of abuse will vary from web site to web site and application to application. Abuse of functionality attacks are often a combination of other attack types and/or utilize other attack vectors.”

In this case an attacker could use the application’s own authentication functionality to attack other users by combining the results of a brute force attack and the security pictures to create a powerful phishing attack. For the scores I have chosen to use Impact and Likelihood, which are given low, medium, and high values. Impact determines the potential damage a vulnerability inflicts and Likelihood estimates how likely it is for the vulnerability to be exploited. In terms of Likelihood, I would rate this a medium because it is very time consuming to setup a phishing attack and you will have to perform a brute force attack first to obtain valid usernames, then pick from the usernames the specific victims to attack; As for Impact, I would categorize this as high because once the phishing attack is sent the victim would most likely lose his or her credentials.

Security pictures can indeed help you add an extra layer of security to your application’s login process. However, put on your black hat for a moment and think how could a hacker use your own security against the application? As presented here, sometimes the medicine can be worse than the disease.

Root of the Issue

Let’s say you’re performing some business logic testing…specifically, you’re testing the quantity of items on an e-commerce site. When you try to add a negative amount of items to your cart, the site responds with a negative number of items. However, the cart page reflects a regular price. Darn, they’ve thought of that issue and have eliminated it.

Should you stop your testing?

The persistent hacker would definitely say, “No way!”

I came across this exact issue on a major, unnamed e-commerce site. (This vulnerability has since been remediated.)

In the above example that I discovered, the all-too-common issue that many e-commerce sites once faced was fixed, but was it fixed for good, or was the fix just “a bandage placed over an open wound?” On the site that I assessed, the wound definitely had a bandage on it, but what it really needed was stitches!

I say that because I was still able, quite easily, to add negative items to my cart, although I would still have to pay the correct amount at checkout. So I started experimenting with the site’s cart and its checkout procedures. The result? I found an interesting loophole.

Here’s what I discovered: Let’s say you added one $50 grill to your cart, and then added gift wrapping. The total price would then be $54; thus, gift wrapping costs $4. Now add a “negative” 27 towels at $2 each, making your new total $108. Then add the gift-wrapping option for the towels, and your final total price becomes zero!

To add even more fuel to the fire, the checkout process was nice enough to require no billing information if the total was “zero” dollars. The site documented that this could occur if gift cards were used. We didn’t even have to enter any personal information whatsoever to receive products!

Awesome.

The problem described here occurred because the site developers failed to confirm that the other functionality and/or code used in the ordering process used the corrected values. The raw input the user provided should have been scrapped/corrected immediately on the first request, before permeating any functionality, instead of just trying to manipulate the very end result if it didn’t match certain criteria.

Although I thoroughly tested all the way up to the final checkout confirmation, I did not confirm that the order was accepted, because WhiteHat provides only production-safe solutions.

The most important lesson here is that it is always essential to fix the root of every vulnerability, rather than simply applying a quick fix. Because as this example shows, the results can otherwise be disastrous.

Follow the Bouncing File Upload

I’m a big fan of Tom Liston and gang, so I decided to write a homage to Tom and his “Follow the Bouncing Malware” series (which I miss reading, Tom, so if you see this, I want more!) while adding my own little flavor.

Waiting on the staging lights … Ready? Go! Heh. Staging. Get it? Staging lights? Race track? Staging environment? Yeah … more bad jokes are sure to follow.

One day, while working in the TRC, Micheal got an email about a competition that was soon taking place. Fame, Fortune, and Fun were on the line. The triple threat. Except Micheal can’t sing, dance, or act. So maybe only a triple threat in the offsec world? Either way, he was going to put the pedal to the metal and show everybody up.

This wasn’t just any old contest. The application was to be ripped apart, like what a kid does at Christmas to the wrapping paper. The application had a few Cross-Site Scripting vulnerabilities, some Cross-Site Request Forgery, and a few other vulnerabilities, but initially, nothing too exciting.

But then, Micheal saw it. The one vuln that would rule them all, or so he hoped. It was what would later prove to be the “Golden Goose” that just kept giving: File Upload.

File upload functionality is sometimes necessary in a web application. It allows users to upload images on image-sharing websites; configurations in embedded devices, such as firewalls; and contact lists in social networking websites. This particular functionality was for uploading an image.

When Micheal uploaded the image, he noticed that the image uploading process required two steps. First, the image was uploaded to a temporary directory within the application. Then it was copied from that temporary directory − with the location of the temporary directory in the second POST request − and renamed.

Fortunately for Micheal, this two-step process was more than just the similarly named “2-Step” dance: It also gave Micheal the chance to practice his evil laughter. First, he uploaded a backdoor in the form of a server-side script. Though the application would not accept the backdoor script in the second step, it immediately accepted it in the first step. And because the file was never renamed or made inaccessible, all Micheal had to do was access the file directly. But would accessing the file yield the fruits of his labor? Would he be able to reap what he sown? Stay tuned to find out! Are you on the edge of your seat yet with anticipation?

It did! It did work! Now, laughing evilly, there’s no stopping Micheal. Taking control of the server just once isn’t enough for Micheal, though. With adrenaline coursing through his veins giving him enough horsepower to outpace a pace car that’s pacing a living room floor … giving enough horsepower to outpace a Mustang GT – Micheal was on a delicious, buttery yeast roll. With fresh strawberry jam. Mmmmmmm.

But there was still one catch: An administrator needed to upload that file. Micheal wasn’t satisfied with that. He wanted to be one to control what got uploaded. That was an easy enough problem to solve though. With the help of a couple of other TRC members, Micheal was able to craft an exploit whereby he could CSRF an administrator into uploading the file for him. Mwahahahahahahaha!

Even then, though, Micheal wanted more. More power … After all, he has his world domination plans to consider.

And because the second step had renamed the file from, for instance, a .jpg file to a .png file without actually converting it, it was still possible to get XSS. Internet Explorer 7 and below has a feature called MIME-sniffing. Back yet? Good. This MIME-sniffing feature, because of the way it was implemented, allows for XSS in files. And although IE8 offers some protection against this possibility in the form of an extra header that Web administrators can add, that protection may not be enough. More on that problem later, perhaps.

Another member of the TRC also found XSS, but that was still not enough to satisfy Micheal –  plus, someone other than him had found it. Harrumph! Have no fear, the “Golden Goose” is here! That second step I mentioned? Micheal made use of it: By changing the location of the temporary file, he found that arbitrary system files could be read. Ooooooh! So this meant that the application’s config file could be read, /etc/passwd, as well as many other files that system administrators probably do not want prying eyes to see. And all nicely tucked away in an image. Even better,  once the logo had been created, a guest user could simply download that logo to view the contents of the file that was read into the image.

Oh, pro-tip: Don’t read in /dev/zero. Hehe.

Micheal won the contest, of course. Such wonderful things, these file uploads. They provide so much laughter, which, as we all know, is a great stress reliever.

Are your file uploads safe from Micheal?