A Man-in-the-Middle Attack against a Password Reset System

This is nice work: “The Password Reset MitM Attack,” by Nethanel Gelerntor, Senia Kalma, Bar Magnezi, and Hen Porcilan:

Abstract: We present the password reset MitM (PRMitM) attack and show how it can be used to take over user accounts. The PRMitM attack exploits the similarity of the registration and password reset processes to launch a man in the middle (MitM) attack at the application level. The attacker initiates a password reset process with a website and forwards every challenge to the victim who either wishes to register in the attacking site or to access a particular resource on it.

The attack has several variants, including exploitation of a password reset process that relies on the victim’s mobile phone, using either SMS or phone call. We evaluated the PRMitM attacks on Google and Facebook users in several experiments, and found that their password reset process is vulnerable to the PRMitM attack. Other websites and some popular mobile applications are vulnerable as well.

Although solutions seem trivial in some cases, our experiments show that the straightforward solutions are not as effective as expected. We designed and evaluated two secure password reset processes and evaluated them on users of Google and Facebook. Our results indicate a significant improvement in the security. Since millions of accounts are currently vulnerable to the PRMitM attack, we also present a list of recommendations for implementing and auditing the password reset process.

Password resets have long been a weak security link.

BoingBoing post.

EDITED TO ADD (7/13): A couple of related papers.

Tags: academic papers, man-in-the-middle attacks, passwords, security engineering

Posted on July 3, 2017 at 6:01 AM • 23 Comments

Comments

species5618 • July 3, 2017 7:14 AM

very interesting,
fortunatly (or sadly depending on you view) I use a different email address (well diff user at some domain) , password for EVERY online service i have.
it keep my keepass database busy , but it works

Presumably any unsigned 2FA process, is flwed in some way.
so the painfull twitter 2FA , the MS app (not code) , and new google app (not code) is a way forward,
but that assumes the Provider to App commincation is signed

me • July 3, 2017 7:59 AM

this looks innovative (way to phish credentials).
and another proof that sms is not secure and should not be used for logins in any way.

i never give websites my number for privacy & security reasons. but if i ignore this fact for a moment i think i could get hacked (if message was unclear like “here is your code”).

i also don’t like facebook logins (or more in general third party logins).

Hocus Pocus • July 3, 2017 9:36 AM

Any service that requires two factor authentication I immediately stop using. It is the single reason why I switched cell phones providers. 2FA authentication is a strategy by companies to collect even more of their customers juicy personal data under the guise of improving computer security. The best evidence that is true is the fact that companies like Google will not allow any type of 2FA that doesn’t reveal personal data. Well, ok, technically one can do it but it is very cumbersome and beyond the reach of most people. It is funny because online MMORPGS like World of Warcraft figured out a long time ago how to implement anonymous two factor identification yet Craigslist and Google can’t(won’t).

Hossein • July 3, 2017 12:34 PM

These sort of attacks are very concerning. We have published a paper disclosing this attack with the name of “Verification Code Forwarding attack,” and have measured the phishing rate. It is quite scary that in our experiments, 50% of the subjects were successfully phished (or as the authors of this paper formulate it, could be easily victim of a MitM attack). We interviewed we subject and analyzed why they fall for phishing of this type.

Here is the paper: http://engineering.nyu.edu/files/VCFA_PasswordsCon15.pdf

We also published a second paper (Mind your SMSes: Mitigating Social Engineering in Second Factor Authentication) looking for solutions to this type of attack. The approach we proposed is based on changing the messages used for delivery of verification codes to reduce the phishing rates, as the message currently used to communicate with users lack any security feature. We developed some principles and using a careful design, we were able to reduce the phishing ratio from 50% to 8%.

Here is the follow-up paper:
https://www.researchgate.net/publication/308788021_Mind_your_SMSes_Mitigating_Social_Engineering_in_Second_Factor_Authentication

Ninja • July 3, 2017 1:34 PM

I’ve always been wary of 2FA that uses plain SMS (ie: not encrypted) and we’ve seen that you can exploit such system. However in this case it seems there’s a mix of social engineering involved so it can be mitigated. For instance, you don’t use Googles auth codes (if that’s your 2FA flavor) if you haven’t initiated an attempt to authenticate yourself and you did it inside of Google itself. The most security conscious among us would have less of a problem with this specific type of attack.

Those password reset options are there because we, like good and fallible humans, tend to forget passwords every now and then but what if we ditch them? What if services simply tell people “TAKE NOTE OF YOUR PASSWORD OR USE PASSWORD MANAGERS BECAUSE IF YOU FORGET YOU WILL BE PERMANENTLY LOCKED OUT OF YOUR ACCOUNT”? All along with mandatory 2FA.

Of course you’d have to make it harder for an attacker to change the password to avoid account take over. I was thinking (with IPv6 and a fixed IP/geo location) that having a trusted machine or IP that is allowed to do such changes but you can spoof stuff but it could be something in those lines.

Ryan • July 3, 2017 8:18 PM

The Password Reset Man-in-the-Middle (PRMitM) attack is really very simple, but that doesn’t mean it’s not dangerous. It involves persuading the user to sign-up for an account for some service under the attacker’s control (maybe there’s an enticing free download for example), and then manipulating the registration flow such that the attacker is actually able to reset the password for the user’s account on some other system.

Gerard van Vooren • July 3, 2017 8:41 PM

@ Ninja,

What if services simply tell people “TAKE NOTE OF YOUR PASSWORD OR USE PASSWORD MANAGERS BECAUSE IF YOU FORGET YOU WILL BE PERMANENTLY LOCKED OUT OF YOUR ACCOUNT”? All along with mandatory 2FA.

There are two problems with that approach.

First is that these days people are “trained” in the current WOW. If you aren’t serving them in the current way then it doesn’t “fit” in the people’s mindset and if you in a competitive business then they could just abandon you because of that.

The second problem is a bit bigger. Call me a tinfoil hat person but I don’t trust password managers anymore. The password file itself is a honey-pot and the programs (all the “easy to use” ones) are too big to carefully inspect which means you have to trust the developer(s) behind it. But what if, in figure of speech, a “bad guy” points a gun to the developers head? The code is too fat AND the password file itself is rather small so it can be phoned home rather easily (or whatever approach to steal the passwords is taken).

In short, I like the idea but IMO it needs more thinking. Security has to be simple to work at all. An additional password manager (which you need at hand btw all the time, on all your machines with the password file synced), isn’t the right solution. What is, that is the question that the authors of the paper are trying to figure out as well.

Will • July 4, 2017 12:58 AM

The phishers could ask for your email, and then say “authenticate with google” to make the whole experience – and the fact you get the 2FA from google, even in their authenticator app – that much easier. So making it clearer that the 2FA is coming from Google probably won’t make much difference if phishers just choose their phrasing and user experience carefully… 🙁

me • July 4, 2017 3:51 AM

@Gerard van Vooren
I don’t trust password managers… password file itself is rather small so it can be phoned home rather easily

i trust password manager and i use a firewall to prevent it phone home even if it wants to.
what is far less trusted is any other app that i use on pc; in fact on standard windows (or linux)any app can do what it want with your whole pc.
so any could send your passwords back, password manager or not.
and when i switched to whitelist mode firewall (=everything blocked except firefox and few other) i saw that many many apps phone home for no reason, also some pdf/word documents on open!

this is the reason i like Qubes OS it gives you isolated VM each for one purpose so you will have a whole pc without connectivity just to store passwords. and VM are designed to be isolated, not like windows processes that communicate each other and everything is shared.

nobody • July 4, 2017 3:57 AM

@Ryan The flow interception can be done in many cases by an SMS interception via SS7 (Telco core network protocol) and LTE/Diameter.
SMS is not a service to be used for sensitive things like password, even NIST now recognizes that (took them long enough)

That was how the mTAN attack worked (or the facebook/whatsapp/telegram etc)

References:
SS7: http://blog.ptsecurity.com/2016/08/attacking-ss7-mobile-operators-security.html
Diameter/LTE: http://icc2017.ieee-icc.org/program/symposia
“SMS and One-Time-Password Interception in LTE Networks”

Max • July 4, 2017 5:21 AM

The best secondary authentication method is physical mail, in the case where the company has your current address for other reasons (ISP, bank, etc).

So it’s not instant. But so much more secure than email or SMS!

Dirk Praet • July 4, 2017 8:17 AM

@ me , @ Gerard van Vooren

I may have mentioned this a couple of times before, but nowadays egress control is even more important than ingress. That means Windows Firewall Control (WFC) on Windows, Little Snitch on MacOS and OpenSnitch on Linux. SubgraphOS has something similar built in. If someone is interested porting OpenSnitch to BSD, I could probably give a hand.

There is undoubtedly plenty of ways to work around those, but at least you have again raised the bar for whomever is trying to phone home.

Gerard van Vooren • July 4, 2017 10:57 AM

@ me, Dirk Praet,

You are both right but you are also diverting (okay, I started it). If we stay on subject then a password manager is probably a bad idea for the reasons that you both mentioned. No ordinary guy installs Qubes or monitors outgoing traffic and that’s the issue.

Secure login for websites has got to be simple. How? There are different methods of course but I still like the idea of “logging into the browser” and then, like Qubes, use colored tabs so you can see which identity a tab (=session) has. Logging in could be done with key sets and when the authentication has succeeded that key is used all over the “colored tab session”, and websites use these keys for login as well. It’s comparable with OpenID but if you do that at the browser level then you have a more visual approach and you can use a variety of sessions simultaneously.

(just thinking out loud)

further_diversion • July 4, 2017 4:54 PM

If someone is interested porting OpenSnitch to BSD, I could probably give a hand.

Don’t know how subgraph does it, but if you can run each application with a specific uid, I think you might be able to make use of pf’s “user” directive.

Drone • July 5, 2017 12:31 AM

“Horcrux Is a Password Manager Designed for Security and Paranoid Users”

By Catalin Cimpanu, July 4, 2017

https://www.bleepingcomputer.com/news/security/horcrux-is-a-password-manager-designed-for-security-and-paranoid-users/

Excerpting: Two researchers from the University of Virginia have developed a new password manager prototype that works quite differently from existing password manager clients. There are two main differences between Horcrux and currently available password manager clients. [1] Horcrux inserts dummy credentials into your forms. [2] Horcrux spreads credentials across multiple servers. More details about the Horcrux design and implementation are available in the research team’s paper, entitled “Horcrux: A Password Manager for Paranoids.”

https://arxiv.org/pdf/1706.05085.pdf

P.S., The Researchers should prepare for the inevitable call from the Evil Lawyers at the $25 billion USD Harry Potter franchise.

Dirk Praet • July 5, 2017 4:52 AM

@ Gerard van Vooren, @ me

There are different methods of course but I still like the idea of “logging into the browser” and then, like Qubes, use colored tabs so you can see which identity a tab (=session) has.

The first part already exists. Most browsers allow you to store passwords in a local database and to protect those with some master password. Alternatively, you can use a kwallet or keepass backend with Firefox. None of these however allow for granular control in the sense that you can restrict an unlocked login/password to one particular browser tab. Another venue could be creating different browser profiles (and/or multiple wallets) for each login, but that would be a rather cumbersome approach.

@ Drone

Horcrux Is a Password Manager Designed for Security and Paranoid Users

They should rename it. Not just to avoid troubles with J.K. Rowling & co., but because Horcrux is also the name of a quite handy duplicity-based utility for encrypted backups.

ab praeceptis • July 5, 2017 5:09 AM

Dirk Praet

Nothing in any way linked to a browser is even remotely secure.

I strongly advise against any thing related to security (such as password stores) whatsoever to get in anyway close to a browser, let alone being part of one.

Dirk Praet • July 5, 2017 6:16 AM

@ ab praeceptis

Nothing in any way linked to a browser is even remotely secure.

Of course it isn’t. You keep forgetting that I am in the mitigation business. The way I see it, there are only a limited number of actions you can take when it comes to web userid.’s and passwords:

Turn off form and password storage and try to memorize everything. That doesn’t work for most of us, especially when there are dozens of passwords to remember.
Use the same password or a variation on it for everything. Not particularly recommended.
Use a password manager with browser extensions to store userid.’s and passwords in a (theoretically) more secure backend than the one that comes with the browser itself (kwallet, keepass, 1Password)
Store passwords in a password manager without the browser extensions, using copy/paste instead. Kinda cumbersome.

ab praeceptis • July 5, 2017 3:00 PM

Dirk Praet

Store passwords in a password manager without the browser extensions, using copy/paste instead. Kinda cumbersome.

I personally wouldn’t care much about “cumbersome”. If that’s the price to pay for security, well, then be it.

The much larger problem that I see is that the data go via the clipboard which every application can read. It’s in a way as if one had his passwords stored in cleartext in a file.

There would, of course be better ways, e.g. via unix socket (not 100% secure either but much much better than the clipboard) but browsers being what they are…

So I stick with my statement that anything in the context of browsers is condemned to be utterly insecure.

Dirk Praet • July 5, 2017 4:17 PM

@ ab praeceptis

So I stick with my statement that anything in the context of browsers is condemned to be utterly insecure.

And which I didn’t deny.

EvilKiru • July 5, 2017 9:15 PM

I like how the password manager I use gives me choices: I can either copy-past the individual usernames and/or passwords one at a time for pasting (and then clears the clipboard within 10 or 15 seconds, but it’s still passing through the clipboard), or by hitting Ctrl+V, which switched focus back to the previous app that had focus and mimics typing the username, hitting tab, typing the password, and pressing enter, all without touching the clipboard. It also lets me customize the keystrokes that are sent, such as for sites that stupidly add tab-to fields between the username and password, like AT&T, which keeps changing how many fields you have to tab through (I think they’re up to 5 or 6 by now). It doesn’t matter which particular one I’m using, because it seems like the best ones all offer variations of the customizable type-a-matic feature.

anon • July 6, 2017 1:55 AM

@Gerard van Vooren

Color coding tabs for different identities is actually doable today, though probably not for Joe Ordinary. Check out the containers experiment for Firefox.

It lets you create your own identities and automatically open an URL in a certain identity. It also tries to do minimal sandboxing between identities so that your Google identity will not be aware of or able to access your Facebook one. It’s still very much a work in progress but definitely a step in the right direction.

Dixie • July 17, 2017 4:13 PM

Reading the MiTM paper, I was trying to see where this would fail to trap me.

The first place is I wouldn’t usually give my real email address for a free service. Instead, I usually use a random receive-only email generator, the kind where anyone on the web can read incoming mail in a browser window. This will probably fail right off the bat, when the MiTM has no means to start the forgot my password process.

If things got past that hurdle, the second place is when the MiTM asks for a security question. I treat security answers in the same veign as passwords. Never use the same one at multiple sites. Never use the real answer. This means I will have to store the answer somewhere. A password manager or more likely a postit note.

Yes, it’s SbyO and I leave myself vulnerable to someone discovering my credentials for that free service. It’s hard to see how I lose anything if that happens.

Schneier on Security

A Man-in-the-Middle Attack against a Password Reset System

Comments

Leave a comment Cancel reply