Coders Conquer Security: Share & Learn Series - Unrestricted File Uploads

Published Jan 10, 2019
by Jaap Karan Singh
cASE sTUDY

Coders Conquer Security: Share & Learn Series - Unrestricted File Uploads

Published Jan 10, 2019
by Jaap Karan Singh
View Resource
View Resource

The Unrestricted File Uploads problem is not an attack itself, but instead a common situation or state that allows attackers easy access to applications and network resources. You can think of it sort of like walking around in wet clothing out in the cold. While doing that won't necessarily make you sick on its own, it lowers your resistance to the point where any opportunistic virus will easily overwhelm your body's defenses.

In cybersecurity, attackers can be quick to exploit any application or program that has been allowed to support unrestricted file uploads. And the results can be devastating. Clever attackers can use their unrestricted access to upload malicious files, set up scripts to steal credentials or launch deeper attacks into a network using an application's own permissions. Even a relatively unsophisticated attacker could use this kind of unfettered access to perform denial of service attacks, or to crash an application.

Thankfully, there are quite a few ways to conquer the Unrestricted File Uploads problem that will stop would-be attackers in their tracks. To that end, we'll discuss three key aspects of Unrestricted File Uploads:

  • How they work
  • Why they are so dangerous
  • How you can put defenses in place to stop them.

How Do Attacks Exploit Unrestricted File Uploads?

There are a lot of reasons why sites would want to allow the public to upload files. Perhaps a company is looking to hire people, and wants to allow them to upload their resumes as part of the application process. Banks may encourage customers to fill out important paperwork at home, such as when applying for a loan or a new account. Tourism or social media sites may invite users to upload their photographs for sharing with others.

There are lots of valid reasons to allow file uploads. And by default, most new applications are probably going to allow any type of file upload, without restrictions. The trouble begins when a potential attacker notices that there are no restrictions placed on those uploads.

Having no restrictions on uploads subjects sites to three types of attack. Starting with the least sophisticated, a malicious user can simply upload huge files such as zipped archives containing hundreds of gigabytes of information. Besides choking off bandwidth, this can overload the storage area assigned to the application.

Next up on the infamous ladder is a user who uploads a malicious file like a virus or even something more sinister like ransomware. This is sort of like that old superstition of having to specifically invite a vampire into your home. If you hang out a sign that says anyone can come in freely, it's just like having unrestricted file uploads. You no longer control what comes through your door, and you should probably expect that not every visitor, or file, is going to be benign. Some of them might be monsters.

Finally, a skilled attacker can use unrestricted uploads to gain a foothold into a network for deeper attacks. Because there are no restrictions on what someone can upload, an attacker can send their own web shell through that process. Thereafter, they can send commands into their shell, and those commands will be executed on the server with the same permission level as the application.

Why is Having Unrestricted File Access so Dangerous?

While deploying an application with unrestricted file access isn't immediately dangerous, it's basically like opening up a hole in your cybersecurity defenses and inviting someone to attack your organization. Sooner or later, someone will respond.

At the most basic level, attackers don't even need a lot of skill to wreak havoc. Simply zipping up extremely large files and uploading them might be enough to deny service to valid users. Over time, it can even crash the application or an entire site, depending on how the app is programmed and networked.

Having unrestricted file access also might open a hole through network firewalls and other protections. It won't matter if you have a scanner looking at your incoming e-mail or your employee web browsing activity if you have created a path for attackers to upload malware directly to your core network. The malware might crash the application or even the server it's running on, though that is probably the best possible outcome. In a worst-case scenario, a truly malicious program like ransomware can use the compromised server to spread out to the entire network.

More skilled attackers probably won't be so obvious when exploiting an application with unrestricted file access. Instead, they can use the vulnerability to compromise the application, and use that to penetrate deeper into the network, moving slowly and trying to avoid detection. This can be done by uploading a web shell or other .exe type file, and then sending commands directly to it once it lands. Anything that the user runs through their shell will normally be executed by the server, using whatever permission levels are set for the application hosting it. To the server, those commands are coming from the application, and are not likely to be further checked or examined.

All of that makes the unrestricted file access vulnerability one of the most dangerous to have on your network. It's probably not a question of if it will cause a problem, but when.

How Do I Eliminate the Unrestricted File Access vulnerability?

So, how do you solve the unrestricted file access problem? The easiest way is simply to add one or a number of restrictions on the types of files that can be uploaded. These can be communicated to the user if you want, for example, telling them that the site will only accept Word or text files, or in the event of a picture sharing site, only .jpgs or .gifs. On the backend, you will need to create a whitelist of acceptable file extensions and then deny everything else. Restrictions should also be placed on the maximum length of file names. If a file has special characters in the name, which might indicate an attempt to trigger an executable command, it should likewise also be rejected.

In addition to file types and naming rules, you are also going to want to restrict the maximum size of each file. The maximum size should be something reasonable and appropriate for the type of file the application is expected to collect. That might mean a cap of 10 megabytes or so for Word files and something a bit larger, perhaps around 50 megabytes, for graphical files. It's also possible to set minimum file size rules, but only if the size range of the expected files are well-known, which might be the case if users are filling out and uploading a specific form.

Attackers may still find a clever way to sneak a shell or other potentially malicious program past file type and size restrictions. To compensate, collected files should always be stored in a private directory with no execution privileges. For added security, files can be renamed by the system to a series of random characters. This would prevent unauthorized users from outside the network from searching for the location of their uploaded file, which might give them some recon into your network. If you do that, however, you will probably need to set up and maintain a table linking the random file names to their original designations.

Finally, anything that arrives in the network via an upload should be scanned for malware and viruses by whatever defensive programs the organization uses for those tasks. This might not catch everything, but is an important layer of security that could be used to detect up to 90 percent or more of the most common malicious files trying to enter via file upload.

Restricting the Unrestricted File Upload Problem

Once several layers of security are put in place on the backend, the Unrestricted File Upload problem ceases to become an issue. You are basically eliminating the issue by placing restrictions on your file uploads, hence they are no longer unrestricted. Only good files are allowed inside, while all the vampires and malware are left out in the cold.

For further reading, you can take a look at the OWASP Unrestricted File Upload Prevention Cheat Sheet, which outlines some of the most common problems when this kind of situation is allowed on a network. You can also put your newfound defensive knowledge to the test with the free showcase of the Secure Code Warrior platform, which trains cybersecurity teams to become the ultimate cyber warriors. To learn more about defeating this vulnerability, and a rogues'gallery of other threats, visit the Secure Code Warrior blog.

Think youre ready to tackle this vulnerability right now? Head to the battlefield and test your skills:

View Resource
View Resource

Author

Jaap Karan Singh

Want more?

Dive into onto our latest secure coding insights on the blog.

Our extensive resource library aims to empower the human approach to secure coding upskilling.

View Blog
Want more?

Get the latest research on developer-driven security

Our extensive resource library is full of helpful resources from whitepapers to webinars to get you started with developer-driven secure coding. Explore it now.

Resource Hub

Coders Conquer Security: Share & Learn Series - Unrestricted File Uploads

Published Jan 10, 2019
By Jaap Karan Singh

The Unrestricted File Uploads problem is not an attack itself, but instead a common situation or state that allows attackers easy access to applications and network resources. You can think of it sort of like walking around in wet clothing out in the cold. While doing that won't necessarily make you sick on its own, it lowers your resistance to the point where any opportunistic virus will easily overwhelm your body's defenses.

In cybersecurity, attackers can be quick to exploit any application or program that has been allowed to support unrestricted file uploads. And the results can be devastating. Clever attackers can use their unrestricted access to upload malicious files, set up scripts to steal credentials or launch deeper attacks into a network using an application's own permissions. Even a relatively unsophisticated attacker could use this kind of unfettered access to perform denial of service attacks, or to crash an application.

Thankfully, there are quite a few ways to conquer the Unrestricted File Uploads problem that will stop would-be attackers in their tracks. To that end, we'll discuss three key aspects of Unrestricted File Uploads:

  • How they work
  • Why they are so dangerous
  • How you can put defenses in place to stop them.

How Do Attacks Exploit Unrestricted File Uploads?

There are a lot of reasons why sites would want to allow the public to upload files. Perhaps a company is looking to hire people, and wants to allow them to upload their resumes as part of the application process. Banks may encourage customers to fill out important paperwork at home, such as when applying for a loan or a new account. Tourism or social media sites may invite users to upload their photographs for sharing with others.

There are lots of valid reasons to allow file uploads. And by default, most new applications are probably going to allow any type of file upload, without restrictions. The trouble begins when a potential attacker notices that there are no restrictions placed on those uploads.

Having no restrictions on uploads subjects sites to three types of attack. Starting with the least sophisticated, a malicious user can simply upload huge files such as zipped archives containing hundreds of gigabytes of information. Besides choking off bandwidth, this can overload the storage area assigned to the application.

Next up on the infamous ladder is a user who uploads a malicious file like a virus or even something more sinister like ransomware. This is sort of like that old superstition of having to specifically invite a vampire into your home. If you hang out a sign that says anyone can come in freely, it's just like having unrestricted file uploads. You no longer control what comes through your door, and you should probably expect that not every visitor, or file, is going to be benign. Some of them might be monsters.

Finally, a skilled attacker can use unrestricted uploads to gain a foothold into a network for deeper attacks. Because there are no restrictions on what someone can upload, an attacker can send their own web shell through that process. Thereafter, they can send commands into their shell, and those commands will be executed on the server with the same permission level as the application.

Why is Having Unrestricted File Access so Dangerous?

While deploying an application with unrestricted file access isn't immediately dangerous, it's basically like opening up a hole in your cybersecurity defenses and inviting someone to attack your organization. Sooner or later, someone will respond.

At the most basic level, attackers don't even need a lot of skill to wreak havoc. Simply zipping up extremely large files and uploading them might be enough to deny service to valid users. Over time, it can even crash the application or an entire site, depending on how the app is programmed and networked.

Having unrestricted file access also might open a hole through network firewalls and other protections. It won't matter if you have a scanner looking at your incoming e-mail or your employee web browsing activity if you have created a path for attackers to upload malware directly to your core network. The malware might crash the application or even the server it's running on, though that is probably the best possible outcome. In a worst-case scenario, a truly malicious program like ransomware can use the compromised server to spread out to the entire network.

More skilled attackers probably won't be so obvious when exploiting an application with unrestricted file access. Instead, they can use the vulnerability to compromise the application, and use that to penetrate deeper into the network, moving slowly and trying to avoid detection. This can be done by uploading a web shell or other .exe type file, and then sending commands directly to it once it lands. Anything that the user runs through their shell will normally be executed by the server, using whatever permission levels are set for the application hosting it. To the server, those commands are coming from the application, and are not likely to be further checked or examined.

All of that makes the unrestricted file access vulnerability one of the most dangerous to have on your network. It's probably not a question of if it will cause a problem, but when.

How Do I Eliminate the Unrestricted File Access vulnerability?

So, how do you solve the unrestricted file access problem? The easiest way is simply to add one or a number of restrictions on the types of files that can be uploaded. These can be communicated to the user if you want, for example, telling them that the site will only accept Word or text files, or in the event of a picture sharing site, only .jpgs or .gifs. On the backend, you will need to create a whitelist of acceptable file extensions and then deny everything else. Restrictions should also be placed on the maximum length of file names. If a file has special characters in the name, which might indicate an attempt to trigger an executable command, it should likewise also be rejected.

In addition to file types and naming rules, you are also going to want to restrict the maximum size of each file. The maximum size should be something reasonable and appropriate for the type of file the application is expected to collect. That might mean a cap of 10 megabytes or so for Word files and something a bit larger, perhaps around 50 megabytes, for graphical files. It's also possible to set minimum file size rules, but only if the size range of the expected files are well-known, which might be the case if users are filling out and uploading a specific form.

Attackers may still find a clever way to sneak a shell or other potentially malicious program past file type and size restrictions. To compensate, collected files should always be stored in a private directory with no execution privileges. For added security, files can be renamed by the system to a series of random characters. This would prevent unauthorized users from outside the network from searching for the location of their uploaded file, which might give them some recon into your network. If you do that, however, you will probably need to set up and maintain a table linking the random file names to their original designations.

Finally, anything that arrives in the network via an upload should be scanned for malware and viruses by whatever defensive programs the organization uses for those tasks. This might not catch everything, but is an important layer of security that could be used to detect up to 90 percent or more of the most common malicious files trying to enter via file upload.

Restricting the Unrestricted File Upload Problem

Once several layers of security are put in place on the backend, the Unrestricted File Upload problem ceases to become an issue. You are basically eliminating the issue by placing restrictions on your file uploads, hence they are no longer unrestricted. Only good files are allowed inside, while all the vampires and malware are left out in the cold.

For further reading, you can take a look at the OWASP Unrestricted File Upload Prevention Cheat Sheet, which outlines some of the most common problems when this kind of situation is allowed on a network. You can also put your newfound defensive knowledge to the test with the free showcase of the Secure Code Warrior platform, which trains cybersecurity teams to become the ultimate cyber warriors. To learn more about defeating this vulnerability, and a rogues'gallery of other threats, visit the Secure Code Warrior blog.

Think youre ready to tackle this vulnerability right now? Head to the battlefield and test your skills:

We would like your permission to send you information on our products and/or related secure coding topics. We’ll always treat your personal details with the utmost care and will never sell them to other companies for marketing purposes.

Submit
To submit the form, please enable 'Analytics' cookies. Feel free to disable them again once you're done.