4

Drive-by-downloads are automatic downloads without user interaction.

We provide a free service for uploading large files and notifying users by email (this one, something like ge.tt or WeTransfer).

By default when a user clicks a link in the email he gets, the opened URL automatically downloads the file (via the http-equiv="refresh" meta tag).

To minify the risk for the user while still keeping the usability up, I planned the following:

Based on the file extension of the uploaded files, either do an automatic download or provide a manual download link only.

Currently, I can think of file extensions like:

exe, com, bat, cmd, msi, vbs, js, jscript

to be filter as "unsafe for automatic download", while file extensions like:

bmp, gif, jpg

are considered to be safe.

My question:

Do I get any benefits (even if only minimal) when omitting automatic downloads for certain file types?

Or is this merely some kind of naive "security theater"?

(I also have automatic virus scanning and removal on the servers)

To summarize:

People can upload any content to our servers and let our servers notify other users by email with a download link to the previously uploaded file.

I want to ensure that our service is not being misused to spread drive-by-download malware.

The download URL in the email is a potential drive-by-download source, since it is public available and thus could be distributed by malicious persons to spread malware.

2

Do I get any benefits (even if only minimal) when omitting automatic downloads for certain file types?

Attackers used trusted web sites to upload files and use links to these files then inside drive-by-download attacks or phishing mails. Since the site itself is trusted the download will be allowed. Thus prohibiting automatic downloads in some cases is a good way to protect users against malware. More important for you might be that it also helps to protect the reputation of your site since it will not be used to distribute malware.

But, blacklisting certain types is usually a not sufficient. Instead you should whitelist certain innocent types and prohibit automatic download of everything else. Safe types are usually only image, video or similar, while unsafe types which are used to distribute malware are javascript, html and css (which both can include javascript) and of course any kind of archives, executable files etc. Even PDF and office documents should be considered unsafe because they are used in drive-by-download attacks or phishing mails.

(I also have automatic virus scanning and removal on the servers)

Antivirus often needs to catch up first when new malware gets distributed. So it is not enough to hope that antivirus will catch any kind of malware on your server.

  • Thanks a lot, Steffen! The file type filtering would be my "first line of defense", while the virus scanning would be my "second line of defense". Far from perfect, but probably "better than nothing". – Uwe Keim Dec 20 '15 at 17:28
  • 2
    @UweKeim: Don't rely only on the extension of the file for filtering. By using <a href=good.gif download=bad.exe> the attacker can force download with arbitrary names on modern browsers. – Steffen Ullrich Dec 20 '15 at 17:33
  • 1
    adding to Steffen's comment, Reflected file download is popular case of spoofing file name and actual file which have been downloaded. – dossi Dec 20 '15 at 18:45
2

Drive-By Download, or a Basic Trojan Horse?

Do I get any benefits (even if only minimal) when omitting automatic downloads for certain file types?

If you mean you're trying to detect and prevent a drive-by-download when it happens to you, then you get minimal benefit if your attacker doesn't know another method, but it's essentially a security theatre.

However, what you're describing is not a drive-by-download.

There are lots of different ways to initiate a drive-by download. Take for example the ability to write any type of file with an extension to the user's local storage, and then rename it to an actual executable, then execute it.

Currently, you can, for example, use the HTML5 cache to write an executable with any extension to the user's computer, then rename and execute the file with Flash. Pretty ebil, huh?


What exactly is a Drive-By Download?

I've updated this post based on Uwe Keim's new comments:

"Sorry, probably I described this in my initial question too confusing. We provide a service where users can upload files and let our system send emails to other users with a download link that goes to our website. Basically to "send" files that are too large for email attachments."

This isn't really a drive-by-download issue, although it could potentially lead to it.

A drive-by-download is when you force a user to download and execute a program automatically without their input. They are unaware of the file's existence, there is no download dialog, and it happens behind the scenes. While yes, you can serve them a malicious file whose existence they're aware of - which they execute on their own - that is not a drive-by download. That's a run-of-the-mill basic trojan horse.


How Could Someone Cause A Drive-By Download On My Users?

I am adding this block just in case, since I want you to understand how a drive-by-download could work; I do not feel you understand what it is. You may ignore this section if you have viable XSS/SQL injection protection already.

This could be done with an XSS/SQL injection vulnerability. Make sure you check, not sanitize, your input. One way is to make sure you have a regex of the file name which allows all of the common file names (A-Z, a-z, 0-9, period, apostrophe, brackets, etc. This isn't really sanitizing your input: it's simply disallowing bad inputs.

Apostrophes should be allowed in file names as well. Use prepared statements and not string concatenation in any form. You'll want it to be ascii only. When outputting your file for download, you'll want to replace any special characters.

Assuming you are using ORM, or serialized data, you'll be fine when outputting non-breaking characters. It is highly recommended, though, that you sanitize the output to replace all potential page-breaking tags with their respective html entities because - dons tinfoil hat - you'll want extra protection just in case the attacker somehow got around your regex check due to a funny exploit.

You do NOT want these tags getting injected on your pages: <% %>, <?php ?> <script>, </script>, or anything with < or >

null/length check + Regex input check + prepared statements/parameterized queries + output sanitation = Neatness.


Are malicious drive-by-downloads detectable based on file type/mime type?

Anyone could give a file any extension or mime-time they want, and reassemble it later with an exploit, so no, it's not detectable with this method unless the malware author made a serious mistake.

Furthermore, you also need to worry that your anti-virus won't detect it right away. Most anti-viral programs can be defeated through obfuscation, sadly. If relied on alone, it's essentially a false sense of security these days, in many areas.

And the method you're describing is not a drive-by-download; it's just a trojan horse.


Serving Executables That Download Automatically

Most websites do not try to get you to automatically download a file. Malware websites do. Most websites legitimate will implement something that says something like, "If your download doesn't begin in X seconds, click here."

This is a better idea for usability reasons mainly, but it will not offer any extra security at all, although it may prevent people from leaving your website for various reasons.

I think you could get away with presenting a download page that tells the user exactly what they're downloading, rather than an automated link. That could be a very convenient thing to track down some , and if the user


Conclusion

It's a bit of both. A little security, and some security theatre.

It will not provide much benefit unless someone exploits your download system and injects a fake download into it, but they could do that whether you implement this change or not, though.

However, presenting a download page could be very convenient, as it could potentially prevent the user from downloading the wrong file.

  • Thanks, Mark. Do your last two paragraphs also apply for my own website, where I'm in charge of the code that provides the download? (I.e. I do not write anything to the HTML5 cache or user's local storage). – Uwe Keim Dec 20 '15 at 17:16
  • 1
    Are you trying to prevent drive-by downloads from being served on your web server? – Mark Buffalo Dec 20 '15 at 17:17
  • 1
    Yes, absolutely! – Uwe Keim Dec 20 '15 at 17:17
  • 1
    Why do you need to do this on your server? A drive-by-download is when you visit someone else's website, and they serve you a malicious download. Do you have a database where people can put things inside of? So you are afraid of your web server being used maliciously like this? – Mark Buffalo Dec 20 '15 at 17:18
  • 1
    @UweKeim I misunderstood you earlier. I was in a hurry and glanced over it. I've updated my post. I hope this helps. – Mark Buffalo Dec 21 '15 at 4:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.