Is SQRL susceptible to MitM proxy attacks?


rogeragrimes

New member
Jul 21, 2022
3
0
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

Well-known member
May 19, 2018
207
45
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
 
  • Like
Reactions: fcgreg

rogeragrimes

New member
Jul 21, 2022
3
0
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

Well-known member
May 19, 2018
207
45
Let's see if this picture, along with an explanation, helps.
1658441909604.png
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.
 
  • Like
Reactions: fcgreg