Tag Archives: Abuse of Functionality

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!


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?