Sample attack scenarios on file downloads over HTTP

Question

The websites that serve files over https, can it be considered overkill? or is it a best practice everyone has to follow?

The downside to serving files over HTTPS is that you will lose the caching as far as I've read. But apart from that, the attack scenario I have in mind is either someone accessing the server and manipulating the file which HTTPS doesn't help much to prevent, or someone replacing the file with a malicious one over the air in a MITM scenario which HTTPS can mitigate.

How probable is it to have a MITM scenario where the client goes about downloading a specific executable?

Are there other attacks which HTTPS can prevent?

One other solution some websites use is that they put the checksum of the executable on the website, but most users won't bother to check that or won't even know how to do it.

So to sum it up, is there much gain in serving files over HTTPS (whether a checksum is put on the website along with the file or not) and can serving files over HTTP be considered a huge security flaw?

(The exact scenario in my mind is that a bank is letting the customers download its mobile banking app via its website over http)

Answer 1

It highly depends on the kind of data you offer for downloading and what kind of trust relationship there is between the user and your site. Just take a closer look at what HTTPS offers and what not:

• It offers some kind of privacy through encryption. If the data are already encrypted by other means then you don't need another layer of encryption. If the data are for public consumption anyway you also don't need to hide the data using encryption.
• It offers tamper resistance. If the data are signed somehow and the signature gets definitely checked then you don't need to add another layer for tamper resistance. Often firmware or software updates are already protected this way.
• It offers some kind of authentication of the site which protects against man in the middle attacks. But it offers no protection if the user takes the wrong URL, like a similar or trusted looking URL during a phishing attack.
• It offers some kind of privacy to hide which file gets downloaded. But it does not hide the access to the site itself, but hides only the specific URL visited on this site. And it is often possible to find out which file was loaded from the site because of meta data like the amount of transferred bytes.

Which means that depending on the use case HTTPS can help, but it does not offer more protection in all cases. And it offers less protection one might assume. Especially it is still possible to download malware using HTTPS because on either used the wrong URL (phishing) or the server itself was compromised and serves the malware.

Apart from that it usually does not harm to add HTTPS if you have the resources, no matter if your use case really profits from it. Most users don't really understand the complexities of what https offers and what not but they feel safer with https. Thus you might just give them some illusion of safety, i.e. security theater.

Answer 2

Here is a theoretical attack scenario that depends highly on the end-users security savvy.

If the user were to retrieve a file over HTTP (unencrypted) and the connection was MiTM, the user's browser would not be able to verify the server's identity and therefore the validity of the response from the server. The response could then be easily spoofed by the MiTM.

Now, say the user was downloading a PDF document. PDF's are usually relatively safe. At least generally safer than MS Word document files since Word document files can contain macros which can run code on the user's computer.

This means that the attacker could intercept the request for the .pdf document and reply with a 302 (or other 300 reply) that the document has moved to another URL. This would give the attacker the opportunity to provide resource location with a .doc file extension instead of the requested .pdf file extension. The browser would dutifully fulfill the redirection to the .doc file.

If the user did not notice that the request for a .pdf file resulted in the download of a .doc file, and again missed the notice from MS Word that the file contains macros, then they would be in trouble.

Macros can contain embedded code written in a programming language known as Visual Basic for Applications (VBA) which, if run, can create files, download files, and execute code, replace DLL files, etc.

Answer 3

The exact scenario in my mind is that a bank is letting the customers download its mobile banking app via its website over http

The most simplified answer is that "mobile banking app"s aren't downloaded over HTTP. If there is an answer that is more specific, we are probably missing critical details about the workings of your relatively unknown bank and mobile OS.

The most popular mobile phone OS's use central app stores, where apps are supposedly vetted. (The app store downloads are authenticated. They happen to use HTTPS, which provides privacy as well).

Android may technically support downloading apps from a HTTP website. However, doing so will show warnings so scary that a bank SHOULD NOT do this.

Downloading executables over HTTP is mostly an old Windows ("PC") thing.

---

How probable is it to have a MITM scenario ...

It might be less than you think, from how security people talk. Unfortunately, it is more than is comfortable. One problem has been vulnerabilities in consumer/small business routers. The attacker doesn't need to install sophisticated code, just configure the router to use their DNS server.

... where the client goes about downloading a specific executable?

I think it is relatively infrequent that you have to manually download an executable - compared with other things you can attack with the MITM.

It wouldn't be very profitable to attack a specific executable. Most likely all executables would be attacked. Example. Thanks to Nasrus' comment for the excellent link. The linked example suggests this is more likely in some countries than others.

Notice that one obstacle is code-signing. Windows will warn you on "first-run" / running downloaded software. Without a code signature, the warning is relatively scary. With a signature, the warning will show a company name. For example, the certificate authority might be slightly cautious about issuing certificates with a company name "Micro-soft" or "Barclays Banking". And the user might be suspicious, if any executable they download warns that it is from "Simon's Honest Software", and not anyone they expected.

Code signing helps against more common attacks than MITM. I think it helps explain why you used to see a lot of Windows software downloaded over HTTP, and you didn't hear a lot about this being exploited.

The websites that serve files over https, can it be considered overkill? or is it a best practice everyone has to follow?

The Web browsers tell you HTTPS is good, and are pushing for it to be the default. I generally agree. I don't know if they have any warning on HTTP downloads yet? E.g. it's possible they would start warning if a HTTPS page links to a HTTP download, so they can get a little extra leverage from the padlock in the address bar.