Web App Mutual Authentication Fail
Thurs 8th June 17
Over the past two months I've tested two internet banking applications which used a mutual authentication process where they show the user a secret phrase or image they entered:
In both of these situations I've annoyed developers by showing that this method of authenticating the site to the user is pretty much useless as a security addition so thought I'd blog about it to see if others agree with my findings and see if anyone can suggest ways to improve it.
The problem I see with it is that it can easily be proxied, the attacker creates a clone of the site and lures the victim to it. The victim enters their username and is taken to the page which shows this "secret" information. At this point, the fake site passes the username on to the real site and starts the login process. When they are given the phrase or image, the site collects it, fills in in its template and serves it to the user. This flow chart shows the process from the initial phish to the stealing of the credentials.
At this point, the user sees their secret information and so feels they can trust the site and enters their password to complete the login process. The attacker now has the username and password and so can either redirect the user back to the real site so they think they entered a bad password and retry the login or they can keep them on their site and continue the attack.
When I've discussed this with others, one of the things that has been suggested as an alternative to showing the phrase/image is to take it out of band and to either send an SMS or make a phone call. This initially sounded like a good alternative but after a minute of thought it is obvious that this suffers from exactly the same problem, the fake site can start the login process and run it through till the real site sends the SMS or makes the call which completes the mutual authentication. The user still receives what they expect from the real site and so assume what they are accessing is trusted.
Another suggestion is to require the full login before showing the secret details, this fails as it gives the attacker the full credentials without the need of doing the proxying. The attacker can show any image they want or can redirect the user back to the real site where the user will assume they got something wrong and will try again.
What makes this method worse is that the more the site highlights this mutual authentication, the more serious the vulnerability becomes. If they really stress that only they know the secret information and so if you see it then you must be looking at the real site, then a proxy attack such as this can be much more effective. The cloning of the site does not need to be as accurate and the URL used doesn't need to be as close to the real one as, once they show the secret information, the victim will immediately trust the site and will overlook any problems.
I can't come up with a system that is this easy to use that actually works as anything that comes from the server can be proxied in some way. If the real site is strict on checking source IP and blocks multiple requests from the same source, the attacker can use open proxies to make their requests, if the server checks for HTTP headers, the attacker simply forwards the exact request made to it by the victim.
I'd love to have an alternative solution to give to clients so if you can suggest one, please get in touch.
Thanks to Michah and Anne for proof reading and diagram assistance.
