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?