If a website allows the user to upload files, it’s usually considered a vulnerability and the server has to do a bunch of checks.
Does it depend on what the server does with the file? If the user uploads a hacking script, but the server is configured to do absolutely nothing with what’s uploaded, how can that script ever run?
And how can a user know what the server is doing with the file? Yeah trial and error, but trial what, and aren’t there countless things to trial?
In: Technology
Your body doesn’t know what to do with a virus, yet it still infects you. Iffy analogy, but the idea works. Malicious files don’t always need to be run by the host to cause problems. They can exploit vulnerabilities that allow them to operate “on their own”, gathering data, infecting connected systems, etc.
>And how can a user know what the server is doing with the file?
If you know what systems/software the server is running, and you know that there is a vulnerability in one of those systems, you can target that vulnerability with your malware to get some sort of access or do some sort of damage.
A lot of servers have simple configuration settings vulnerable to abuse.
The simplest, and perhaps oldest, example is a PHP service. Some web servers default to just running any PHP script a user requests as long as it can reach it. And if it has the ability to receive an upload and save it, then it has the ability to read the script back later.
So I can just write a virus in PHP, upload it, and then try downloading it again. Except the web server will run the script on its own CPU, and run the virus. Tada, vulnerability! And all you had do to prevent it was to make sure only files in certain directories were considered legal scripts in the settings.
As another simple example, if I can upload a file to you and you keep it, then I’m in a position to fill your hard drive with garbage by just uploading lots and lots of stuff. Now you can’t save logs, or send alerts, or run some programs, etc. Things start to break down on the inside with no disk space to work. Maybe the anti-virus doesn’t get updated because there’s no room to save the download.
And finally.. if other users can download the files I upload, then I can just upload a virus… and use your server to give it to future victims and I can remain anonymous and unknown. It’s your site that falls victim to “this site might try to infect your computer!” alerts from the web browser once the internet catches on. And I just move on to find someone else to host my stuff and the cycle continues.
Well, for starters, the size of the file alone is a vector of attack, Even if you do absolutely nothing with it, if a user uploads a file that’s too big you may run out of storage space, memory and/or bandwith if you don’t protect yourself.
Then it’s all guess work. But you can make educated guesses. For example, let’s say your website is facebook. You allow users to upload a profile picture. You notice that if you upload and then download your profile picture, the picture is not the same. Immediately you know that the picture MUST have some kind of processing so if there’s some well-known image processing software/library you can either check for vulnerabilities on that software/library or you can check of common mistakes that people do when using such software/library.
One big thing regardless of file contents is that you can potentially fill the servers disk, or if they’re using cloud storage, explode the storage bill. Both are very undesirable for the person running the server. Filling the disk can crash the server, and a huge cloud storage bill ruins profitability.
Beyond that, it also gives an attacker a potential avenue to load some tools in for them to use to advance an exploit. Many attacks are not just a full remote code execution, and layering multiple vulnerabilities in a row can be a way to gain access. Uploading files to use in those layers can be significant.
Transferring files in one direction opens up your device for files to be moved in the other direction, which combined with the length of time you are connected for the upload can be an issue.
Parsing any file for validity is an opportunity for flaws in its coding to be exposed. This is even more risky if the data given to it is from an unknown third-party who could have maliciously crafted the data to exploit exactly those flaws.
Something as innocent as a spreadsheet, PNG, PDF, MP3 etc. can easily be crafted to take account of known flaws in certain pieces of software that are used to process or render them.
It’s just not a case of the server storing a file and regurgitating it later, that much is too simple. But if you upload a PNG or JPEG or MP4 or MP3 to Facebook, you want to see / hear it, don’t you? And you want others to do so, too. Hence that file is processed and delivered to end-users and maybe delivered to their browser or their local plugin/extension/software in order to see it. That’s a prime opportunity to use Facebook, for example, to compromise everyone who tries to open that file.
And, yes, innocent files that even play correctly on most computers can have flaws deliberately inserted into them that will cause servers to crash, hang, spew memory, execute code, etc. if the software that’s processing them is vulnerable.
Also: All software is vulnerable. It doesn’t matter how well coded or popular it is, it will have these kinds of flaws and people will find more every day. Almost all websites use FFMPEG when processing video, for example. And FFMPEG has had just such flaws. The same for things like libpng (for PNG files), libvorbis (for OGG audio files), Adobe Acrobat (for PDF files), etc.
It’s a rule in programming that you treat ALL data of unknown origin – and everything that you user sends you – as “unsanitised” data, and take the absolute greatest care when processing it. Because that file can have malicious things inside it that your software may process badly and you won’t even know until it’s already happened.
An example of such a thing – most files have to tell you to set aside an amount of memory. Because they’re compressed, and the file records what the uncompressed size will be, your program has to “trust it” and set aside that much memory in order to process the file. Bam. Now you have the opportunity as an attacker to craft a file that expands to fill all RAM, that gets the computer into an infinite loop when processing it, that tries to allocate too small a buffer deliberately and thus the contents “spill over” into RAM that the computer is using for other things, and you have a dozen ways to cause problems – everything from hanging the server, slowing it down, crashing it, to compromising it and stealing information from other users!
So you have to process it REALLY carefully, take no chances, trust NOTHING that’s inside the file, even imagine new attacks like the above and where they might sneak in, and make sure that your software is doing exactly what you think and keep it up to date, and patch against all the latest flaws immediately – but your users still want to just look at that JPG they got from a friend and uploaded and they want to do it NOW.
As an example, did you know that WMF files (an early vector format, not unlike SVG) were actually just Windows executables? They used to “draw” shapes by just running certain internal Windows functions as part of a normal executable program. Until one day someone changed that program to do malicious things just by you opening a particular WMF they had made… and only THEN did Microsoft and everyone else start locking down how they processed WMF files.
And it’s constant and ongoing – there are flaws in major software suites every day just parsing ordinary Word docs or image files or video files or audio files. And every day someone finds a hole, uses it to craft a malicious file, sends that file out by email or Whatsapp link or Facebook post or whatever, and all those companies have to detect that, patch all their software everywhere across the world, and make sure they haven’t missed anything and haven’t broken any legitimate files in the process.
Sooooo, just about anything can be a vulnerability.
ELI5 version: Imagine a spider builds a web. The spider carefully connects the web to a branch of a tree and weaves a bunch of circles around and around to make the web.
Then, a fly comes buzzing along and lands in the middle of the web. The web stops the fly, but in order to remove the fly, the spider has to tear a piece of the web out and patch it.
This, in turn may make that one part of the web better at catching flies in the future but it also leaves a part of the web heavier and more vulnerable to the wind.
Explanation:
The spider is the programmer. The branches are the original security measures. The web is the website/server. The fly is a vulnerability, and the wind is future vulnerabilities. The patch in the web is a change to the original coding.
At first, you have a base level of security, or should. As time goes on and vulnerabilities become known. The patches usually come in the form of an update, which could potentially cause more vulnerabilities that are not yet known. There are tons of exploits (viruses) that use vulnerable points to give the creator what they want. Yet there are also constant patches and updates to combat those vulnerabilities.
Let’s go from the most basic to more advanced.
In the simplest form the website accepts the file as-is and then saves it to /uploads/yourfilename.ext . If we can get the server to execute this file, you can run it and possibly extract login info to the server itself, extract all of the files on the server, or extract the entire database. If you can’t then what you could do is upload a javascript file which will run on their own domain. Using this you could make a script to send out website credentials and run commands on behalf of logged in users as long as it could be included in the page.
Now lets add some security features which also open us up to other attacks.
We now scan the file to verify it is what it says it is. That scanner could have security problems which allow for the same thing to happen as above but we’re guaranteed the server is running code against the file so we could potentially have an RCE (remote code execution) attack.
Even if we **correctly** determine the file is legit like say an image with the WebP format, the code that parses that file could **still** be vulnerable to exploits as was shown a few months ago: [https://blog.cloudflare.com/uncovering-the-hidden-webp-vulnerability-cve-2023-4863/](https://blog.cloudflare.com/uncovering-the-hidden-webp-vulnerability-cve-2023-4863/)
Uploading files is risky and scanning them is risky. A “secure” upload would save the file outside of where the user can just access it, rename the file, run it on a different server, run it under an account with read-only access, scan it with yet another server with as little access as possible, make it available on a domain that isn’t the same as the primary host.
Latest Answers