Exploiting Unrestricted File Uploads

It started with a boxing contest…

Back in November 2016, Andre Ward was set to fight Sergey Kovalev. Boxing contests are difficult to watch outside of pay-per-view, which are difficult to purchase without a cable subscription with online viewing options being practically non-existent. As I suspect many others also did, I took to Google to find some way to watch the contest.

In my research, I found search results to documents on trusted websites, including .gov’s, that advertised “livestreams” of the events, but were really ad-loaded sites where the author wants to make a few bucks:

screenshot-from-2016-11-19-18-04-59

screenshot-from-2016-11-20-15-52-11screenshot-from-2016-11-20-15-50-26

The 3 sites shown above are colorado.gov, georgia.gov and yale.edu, though there were uploads across many more sites.

How for is happened has?

The mechanism here is fairly simple. The document author wants search engine exposure and clicks, so they find websites with unrestricted file uploading to drive traffic. In this case, the document author used websites with improperly implemented Drupal webform module to upload the file and selected high-profile websites for maximum exposure, all of which can be found here. For a more widespread implementation of this, a person could, for example, use the Shodan API to identify Drupal sites with the webform module and attempt the file upload.

Risk, risk, risk

These livestream advertisement documents aren’t inherently dangerous to anybody, though these files having made it onto government websites for over 24 hours speak volumes to how open any system can be, and how prevention and monitoring often leave much to be desired. For the purposes of this post, it validates the assumptions that malicious files can easily be uploaded and distributed for >24 hours before detection and removal.

OWASP describes the various direct risks to the application and servers to which the files are being uploaded and provides examples here.

You’re not always the target, even when being used

Security is often exclusively thought of and discussed as prevention, response and damage mitigation to an exploit or attack on your applications, servers, or networks. However, the novelty, in my opinion, of unrestricted file uploads to websites such as colorado.gov, georgia.gov and yale.edu – big, recognizable, trusted names – is the ability to gain a user’s trust and confidence in the file, its inputs and all of its links.

It’s always important to take a step back and recognize that most folks aren’t technology professionals who closely examine every URL. Most will see “yale.edu” and their trust will be earned. Even more so with a .gov website. Those with some, though not much, technical knowledge might even look at the SSL certificate to verify the website is authentic, which in these examples it is. Other than that, not much due diligence will be had.

So where’s the danger?

There is a massive online hacking community dedicated to generating profit or ruining a person’s day for the sake of ruining their day, or both. Not all hacking is focused on large corporations and dumping massive user credential collections.  Many just have fun with it, make money and troll people.

Unrestricted file uploads provide attackers with credibility and trust. It allows them to upload documents that request data or direct them to innocent-looking sites that deliver malicious payloads. And it’s real easy to do.

If spoof an email address from Company, and I then send emails to employees of Company with an @company.com email address linking to a document on http://www.company.com which asks for credentials, chances are by the end of the day I’ll have some credentials. If it links them to a website and provides instructions on how to download a software we’re testing here at Company, chances are by the end of the day I’ll have many hosts across plenty of VLANs infected with my payload of choice. Chances the security of Company assumes nobody will attempt anything from within, because they have ASAs and iptables set up, and that’s “good enough”. If it’s a Windows environment, chances are I’ll have access to a domain admin by the end of the day. See where I’m going with this?

If I’m sending phishing emails and I direct folks to a file on Colorado.gov, and it directs you to a survey site or asks for credentials, chances are by the end of the day I have a sizeable botnet and/or boatloads of credentials. It works with incredibly obvious, poorly thought out phishing emails with broken English, so chances are it would work even better when the effort is done with the authenticity, trust and perceived security of Colorado.gov or Yale.edu.. See where I’m going with this?

Why you should care

As I wrote earlier, unrestricted file uploads are a massive security risk to your application and infrastructure, but you can also be used as a platform to attack others using your own reputation. Both of these are stellar reasons to be able to, at any time, describe where in your application or service file uploads are both handled and accessed. You should also have a way to monitor and alter for suspicious uploads and upload attempts. For example, if I sent a POST request to your Drupal webforms module to upload a file and there’s no cookie information associated with that request… chances are it’s worth a look because that’s not regular user behavior. Your HTTP requests should be logged at all times and there should be a system in place to monitor and analyze them.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s