3 ms·
It's trivial for a MITM to patch all binaries he's intercepting, it's less trivial[0] to modify the corresponding hashes on web pages. I'm talking about automat
by morsch 12y ago
It's trivial for a MITM to patch all binaries he's intercepting, it's less trivial[0] to modify the corresponding hashes on web pages. I'm talking about automation here, not messing with a single web page, which a human can do in a couple of minutes.
[0] You've probably already sent out the unmodified hashes before you sent out the patched file. First idea: Keep a set of known binaries and a set of hash replacements. When you encounter a binary, first check if you've seen it before. If you haven't, deliver it unmodified, then compute hashes in a couple of known formats, and the hashes of the corresponding patched binary. When you deliver text content, check if any of the previously computed hashes match and replace them with your evil version. When you encounter the binary a second time, deliver the patched version, assuming that you either sent a modified hash or there was no hash in the first place.
- kaoD 12y agoTo further improve your idea: you could detect links to binaries and look for hash-like strings next to them. Then you can pre-download, detect hash algorithm, patch, hash the patched binary and then serve the page with the modified hash (and cache everything for later use). It might make the first visit slower, but for small binaries (or large bandwith) it's probably not that noticeable (especially in Tor, where slowness is expected). Lots of times the hash is in a separate file, which makes the attack even less noticeable since you can patch and hash the binary as you detect it but before the hash file is downloaded by the user (and you can even delay the hash download as much as you need). As I see it, downloading hashes through unsafe channels delivers a false sense of security, which is even worse than no security at all.