|
I genuinely looked for an answer to this but my terminology is lacking. If an attacker was in a MiTM position running a proxy, wouldn't it be possible for them to detect a binary like an .exe or .pdf and either implant some malicious instructions or completely swap the file with something evil? To clarify: Do you know of any software, paper or talk regarding this. |
||||
|
|
|
Yes they would. I'd say injecting malicious code into a .exe or a .pdf would be difficult without damaging the file integrity to the point it breaks the file, more likely an outright replacement would be smarter, but it would need to have a similar file size or might arouse suspicion. As the target is expecting a file suspicions would be low. |
|||||||||||
|
|
Man in the middle can do pretty much anything with data that passes through. The only defense is use of key/signatures that didn't pass through attacker - for example was delivered before injection or by another medium. Of course you should remember that keys could be compromised at some point in future too. |
|||
|
|
|
In general, you can't trust anything on an unsecured connection on any network where a MITM could be present (ie, you don't have complete physical control and security of the routing and wiring). A Man in the Middle could monitor and alter any unsecured connection by pretending to be you to the host and pretending to be the host to you. Neither system would be aware of the presence. The file could be entirely replaced or executable could be altered or replaced to do malicious things quite easily. There are, however, a number of ways to prevent this. Authenticated connections such as HTTPS guarantee that only two end points (at least one of which is trusted) can communicate. In brief, HTTPS works by the server having a special piece of information that the browser can validate is the server you think it is. That information can then be used to send a key generated by your client to the trusted server in a way that only the server can understand. Because the MitM doesn't know the newly shared key, the server can then respond using that key to encrypt the connection and the MitM can no longer observe or alter the meaningful contents of that communication and any alterations would cause it to appear as gibberish (or possibly be detected based on the protocol in use). Another technique is called checksums. A checksum is a small piece of information that can be independently provided to validate a much larger file. It generally consists of a hash of the file that is being sent which can then be rehashed after receipt in order to ensure the file didn't have any errors in transmission. If the checksum and the file are obtained from different connections, it is a little more difficult for the MitM to alter both, however it could still be possible for both to be altered. The checksum could also be cryptographically signed by the file distributor to ensure the checksum can not be altered by the MitM. The best method is to combine the two approaches and include a cryptographically signed checksum that validates that the file came from the sender while also communicating the file over a secure connection. This ensures that the data isn't corrupted during transmission and also ensures that it comes from the expected host. |
|||
|
|
