Is SQRL susceptible to MitM proxy attacks?

[rogeragrimes]

I apologize if this has been covered here previously, but I could not find it on my own. I see that SQRL is promoted as "phishing-resistant", and I wonder if it prevents MitM proxy attacks? Specifically, suppose a user gets sent a phishing email containing a rogue link that purports to belong to a SQRL logon site, which the user clicks. The rogue link takes the user to a rogue MitM proxy site, that then connects to the legitimate site the user thought they were going to in the first place. Everything the client types and acts upon can be captured by the MitM proxy web site before being sent to the legitimate site/service; and vice-versa.

Here is an example of the attack abusing a one-time-password MFA solution and web site:

Does SQRL contain features that prevent that? If so, how?

 

[PHolder]

It depends on the use case. It was originally designed around QR codes, which implies mobile devices authorizing logging into a desktop PC (or kiosk PC like a library or Internet cafe (assuming these still exist).) In that use case, there is some potential risk. This was designed out, as much as possible, but as I'm sure you're aware, it is impossible to prevent every possible attack scenario because bad actors are usually incentivized by all the potential money they can access illegally.

The strongest "trick" that SQRL uses is an out of band connection. Your client will directly connect to the server in the SQRL challenge, so if an attacker copies someone else's login challenge, your client will go direct to the original source and not to the attacker. Additionally, the hostname of the authentication challenge originator will show in the SQRL client, so if you think you're attempting to log into foosite but it's actually secretly a bank, then, if you're paying attention to the login request, you'll clearly see it's not for the site you think it is for.

Since the authorization cookie comes via this out of band connection, and the local client directs the connection locally to the browser, the most likely result is that you end up logged into the site you thought you were logging into, and the phisher is completely cut out of the loop. The biggest potential risk would be if the attacker could somehow mess with the DNS, because then you could be attacked... but that attack results in all sorts of man in the middle possibilities for any site, even after you get logged in... and SQRL is only about authentication. (Not strictly true given it can to authorization using the ASK protocol, but irrelevant in this discussion.)

The other thing to remember about SQRL is that there is no "password" to try and capture. Playing man in the middle or breaking into a site to get its user database will not yield any authentication data that will be useful for an attacker. (Assuming the user disables non-SQRL logins or the site doesn't offer anything else.) This means, even if you are phished somehow, since an attacker can't "change your password" easily, they can't lock you out of your account easily, and thus you should always be able to get in to use a site's "kill all active sessions" feature and permanently kick out the bad guy.

There is a great deal of information on the operation of SQRL in the 4 docs Steve produced, available here: https://www.grc.com/sqrl/sqrl.htm

 

[rogeragrimes]

Thanks for the reply. I have studied the docs, but I still don't understand how SQRL prevents the MitM site from grabbing the access control token cookie of the legitimate web site...or now with your reply how the legitimate user could end up logged into the legitimate web site, but the MitM web site didn't get access. I'll have to study more and go through each transaction. But your reply helps.

 

[PHolder]

Let's see if this picture, along with an explanation, helps.

Step 1, the attacker grabs a SQRL authentication challenge from a site. It can't make up its own because there is a unique identifier embedded in it which the server MUST have in its own memory for an authentication to succeed. (The design actually includes an option to lock the challenge to the IP address of the requestor, but that won't work in a mobile phone authorizing for a desktop computer, so mobile phones need to request disablement of this feature.)

Step 2, the attacker some how, in real time, forwards this challenge to the user. The challenge is time sensitive, so email is probably not a good way to deliver it, but they may use email to lure in the victim before starting a real time attempt.

Step 3, the client decodes the challenge, and gets the site hostname that it originated from. Part of the SQRL protocol requires this, because the generation of the correct site key is based on the hostname. If the attacker messed with that, then they could potentially try and authenticate the user to a look-a-like site, say amazune but then a unique key would be generated for amazune.com and would not be valid at the correct site.

When starting step 3 the client opens a DIRECT TLS connection to the hostname from the challenge. If it's a stolen challenge from a valid site, and the user proceeds with it, then they will, using the same back channel, get the response back (step 4) from the valid site with an authorization cookie. The attacker can't see this because they're not in the path. (There are possible scenarios where an attacker might try and get in the middle of the conversation, but that would be much harder, involving either DNS poisoning or maybe malware on the users PC. SQRL does not claim to be secure if the user has malware, as nothing really can legitimately make this claim.)

Step 5, the client has the cookie it needs, it now launches directly to the correct site, again using the correct hostname it received along with the cookie, again totally bypassing any attacker in the middle.

 

[rogeragrimes]

Perfect. Thank you.

 

[aikidd]

Let's see if this picture, along with an explanation, helps.
View attachment 739
Step 1, the attacker grabs a SQRL authentication challenge from a site. It can't make up its own because there is a unique identifier embedded in it which the server MUST have in its own memory for an authentication to succeed. (The design actually includes an option to lock the challenge to the IP address of the requestor, but that won't work in a mobile phone authorizing for a desktop computer, so mobile phones need to request disablement of this feature.)

Step 2, the attacker some how, in real time, forwards this challenge to the user. The challenge is time sensitive, so email is probably not a good way to deliver it, but they may use email to lure in the victim before starting a real time attempt.

Step 3, the client decodes the challenge, and gets the site hostname that it originated from. Part of the SQRL protocol requires this, because the generation of the correct site key is based on the hostname. If the attacker messed with that, then they could potentially try and authenticate the user to a look-a-like site, say amazune but then a unique key would be generated for amazune.com and would not be valid at the correct site.

When starting step 3 the client opens a DIRECT TLS connection to the hostname from the challenge. If it's a stolen challenge from a valid site, and the user proceeds with it, then they will, using the same back channel, get the response back (step 4) from the valid site with an authorization cookie. The attacker can't see this because they're not in the path. (There are possible scenarios where an attacker might try and get in the middle of the conversation, but that would be much harder, involving either DNS poisoning or maybe malware on the users PC. SQRL does not claim to be secure if the user has malware, as nothing really can legitimately make this claim.)

Step 5, the client has the cookie it needs, it now launches directly to the correct site, again using the correct hostname it received along with the cookie, again totally bypassing any attacker in the middle.

Thank you for this description of how SQRL attempts to mitigate attacks. I came here looking for a response to this comment "a phisher can take a valid QR code from the real site and show it to a victim using an invalid phishing page" at https://security.meta.stackexchange.com/a/1877/284278
I do not have enough reputation there to comment or reply but perhaps someone here does. While it is an old post I feel it should be rebutted.

 

[rogeragrimes]

Thank you for this description of how SQRL attempts to mitigate attacks. I came here looking for a response to this comment "a phisher can take a valid QR code from the real site and show it to a victim using an invalid phishing page" at https://security.meta.stackexchange.com/a/1877/284278
I do not have enough reputation there to comment or reply but perhaps someone here does. While it is an old post I feel it should be rebutted.

SQRL cannot be MitM'd the way most phishable MFA/passwords is MitM'd. Let's suppose a SQRL user/client gets tricked into first connecting to a MitM web site and then to the intended participating SQRL relying party (RP) (i.e., a website) (this is the most common real world scenario). The SQRL RP sends back a challenge to the SQRL client. That challenge from the RP includes the URL of the RP. Nothing in the RP's challenge can be changed by the MitM attacker. So, the client gets the challenge with the RP's URL. Then the client connects directly to the URL that is in the RP's challenge. So, if the client was originally connected to the MitM attacker, they would not be opening up a brand new connection to the RP. There's no easy way for the MiTM web site to insert itself into the response connection. This is not to say that SQRL can't be MitM'd...just not easily and not using the most popular MitM attack type used against authentication. And if SQRL is MitM'd...a whole bunch of other solutions, like the very popular FIDO, are going to fall the same way.