Comparing Man-in-the-Middle with Man-in-the-Browser

Question

According to OWASP the Man-in-the-Browser (Malware-in-the-Middle) attack uses the same approach as Man-in-the-middle attack, but the differences is that interception is done at the application layer by exploiting bugs in the browser.

So My question is that defenses like HTTPS,SSL which operates below the application layer are ineffective against Man-in-the-Browser attack since malware can modify and intercept application calls?

Secondly From Application developer perspective if the application developer knows that application is bound to run on untrustworthy OS then what are the defenses or access control measures he can take? i.e. banking applications in particular

Answer 1

Malware which got into the browser can grab and alter any data that the browser contains; if you see it or type it, then the malware sees it, and the malware can "type" other values. That's your doom.

SSL (HTTPS) only protect data in transit, between the browser and the server. It ensures that no outsider may peek at the data and/or alter it. But malware which is in the browser (or in the Operating System itself) is an insider and SSL is not relevant for it.

Best defence against malware, arguably the only defence, is not to let malware enter your machine. Don't install software which is not from a trustworthy source; keep your OS and browser fully up-to-date with regards to published security fixes; and pray. Oh yes, pray a lot.

Answer 2

If the attacker controls your computer, it isn't yours any more. You have no control and no security. The defense is nuking the system from orbit and rebuilding it without the vulnerability.

Answer 3

Basic preventative measures such as keep everything patched, keep your AV definitions updated and be careful of what applications you allow your machine to run. I also found that a company named Trusteer Has a product to help fight MITB attacks. I haven't used it personally so I can't vouch for it yet. In the end once you have malware on your machine the only way to make sure it get's out of there is to reimage it.

EDIT: (to answer about what developers could do) If the attacker controls the web browser there's nothing you can do about them scraping the data as they will see everything. You could try running you application on an infected browser to see if you can detect an MITB attack using JavaScript or whatever tools you have available then shut down all requests if it's detected.

For authentication purposes the developer could implement some sort of 2 factor authentication such as google authenticator, require a certificate to be installed on the client machine or require a smart card to be inserted into the machine.

Google Authenticator is probably the easiest thing to do but the user still has to type in their auth code, the attacker will have less than a minute to use it so they would have to be sitting there waiting, it could also be written into an application to find the auth code field and use it.

Installing a certificate on the users machine would help however if their machine is compromised the attacker can get the cert and abuse it. It would also make it a pain for the customer to use other computers to access your site since they would need to install a cert on every computer they use and I guarantee at least one of them will install it on a public computer in a library or internet cafe.

Requiring they insert a smart card is good but unless I get REAL value from your site I'm not buying a smart card just to access it and good luck trying to convince your business people to buy a smart card for every customer.

Answer 4

Better certificate management is topical considering the recent breaches where certificates were used to compromise systems. There are some tools out there for hashing and parsing the certificate and keeping one portion on a USB drive and one in a secure file container on your machine. Not really convenient and the only adopters are likely to be developers. There is one company that has aimed it's technology at certificate storage, wwpass . I ran into them at the RSA show and stopped to drink the kool-aid. Using smart card type behavior, the hardware token becomes your personal crypto device and allows you to import certs, encrypt them and then disperse them into the cloud. This way you never have to store your certs on a local machine or on a USB stick, the certs are hashed, chopped up and dispersed. Only the user with token can decrypt the fragments and present the certificates.