Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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.

share|improve this question
    
I advise you to visit : github.com/secretsquirrel/the-backdoor-factory This project aims to patch binary in MITM position . leviathansecurity.com/blog/the-case-of-the-modified-binaries –  CheatRam Oct 28 at 13:32

4 Answers 4

Yes. It can be done. I've done it personally with python, using a script that I wrote called the-backdoor-factory and implementing a proxy in python. Once you have the the patching system in place almost any proxy will work. You will just need to look for the application/octet-stream in the html, retrieve the binary, patch it, and forward to the client. I'll post a full write up online once I have stable program for community testing.

So here a video of the POC that I'm working on: http://www.youtube.com/watch?v=qPCy2IDaEOI

What you are seeing in the video is my POC on the left written in python and the 'victim' on the right browsing through the proxy. The proxy looks for binaries and only intercepts PE/COFF at the moment. After the binary is patched, it forwards the binary to the user, as you can tell, it's really fast.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
    
Instead of injecting malicious code, you could just wrap the original binary. And if the proxy also tampers with the preceding communication then changing the file size would be tranparent to the user. –  Perseids Sep 10 '12 at 19:40
    
Absolutely true, although it would be difficult to write software that would be able to interpret a web page and determine where to tamper with file sizes. –  GdD Sep 11 '12 at 8:51
    
I'm considering building a proof of concept, do you know if this has been done? –  Keith Loughnane Sep 11 '12 at 12:31
    
If you are referring to a proxy that replaces files with malicious ones then not as far as I know. I'm sure someone has done something like that for research or financial gain, but I doubt if they'd share any code. –  GdD Sep 11 '12 at 12:43
    
There are easy mechanisms to alter an exe on the wire to do malicious things. (Such as hyjacking a return operation and injecting additional code at the end of the file with a jump in the code.) A PDF would be trickier as it is something normally read rather than executed. –  AJ Henderson Sep 11 '12 at 17:41

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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