Slashdot Mirror
QRLJacking Attack Can Bypass Any QR Login System (helpnetsecurity.com)
dinscott and an anonymous reader are reporting of a new type of attack that bypasses SQRLs or Secure, Quick, Reliable Logins: "[As detailed by Seekurity Labs researcher Mohamed A. Baset], QRLJacking (i.e. Quick Response Code Login Jacking) is a method for tricking users into effectively logging into an online account on behalf of the attacker by making them scan the wrong QR code," reports Help Net Security. An anonymous Slashdot reader adds from a report via Softpedia: "In a Facebook post, Baset says he tested his attack on sites such as WhatsApp, WeChat, Line, Weibo, QQ Instant Messaging, QQ Mail, Alibaba, and more," reports Softpedia. The QRLJacking attack is nothing more than a social engineering attack that works by requesting a QR code for the service the victim is trying to log in to and modifying the QR code to send the confirmation message to the attacker's computer. The crook can modify these login details, add the data belonging to his PC, relay the data from his phone to the default login server, and access the victim's account from his PC. This attack needs both the attacker and the victim to be online at the same time, and can be defeated by any user that pays attention to the URL [of the page they're logging into with an account]. Judging that it's 2016 and people are still falling victim to phishing attacks, there's a high chance the attack can work. Baset demonstrated the attack against a WhatsApp user in a video posted to YouTube.
His squirrel has lost all of his nuts! Or I guess in this case, has had his nuts switched out behind the scenes!
The QRLJacking attack is nothing more than a social engineering attack
So it's really not a flaw or bug of the system; just a lack of user education.
AC comments get piped to
They may be crap, but it does not appear that this attack would work with SQRL. The SQRL client hashes the URL of the website, signs the result, and then sends the result to the URL encoded in the QR code. In this attack, the client would see that there is a mismatch between the phishing website and the URL encoded in the QR code. If the attacker modifies the QR code to fix that discrepancy, the SQRL blob would have the wrong URL hashed and the server would reject the login attempt.
The researcher does not mention SQRL in his post or the github repo. That was added by the editor or the submitter.
It's 2016 and browsers are trying to get ride of the URL bar. Hovering over a link to see where it might go is meaningless (JavaScript URL rewriting and URL shorteners) and you can't even do that in some mobile browsers. Any attack that requires users to not look at a URL will succeed now and even more so in the future.
While I truly believe that one should not bet against stupid users (Mother Nature can always make a "more stupid user"), the attack vector would still have a challenge with SQRL.
The SQRL client is supposed to (modulo bad client implementations) request verification of a valid login from the user before proceeding. For this attack to work the user is looking at some website, sees a QR code on the page (advertisement, bogus login, etc), decides to scan the code in the SQRL client, sees the SQRL client popup a code for a different website, and then decides to proceed with the login. It does not appear that SQRL is any worse then a username/password system in protecting the user from doing stupid things.
There are different attacks, however, that makes the QR option in SQRL worse in a practical sense than a username/password. One example is a variant of the hidden-browser attack against a smartcard-based hardware token. The SQRL client in this case serves two purposes: First it reinforces the user's mental perception of what they think is going on and, second, it provides the authentication. An attack against the QR option in SQRL is more significant than a site-specific QR authentication scheme because a SQRL client has the ability to authenticate against multiple web sites.
At the very least, any site using SQRL that cares about security should disallow logins where the SQRL client and browser IP addresses are different. Web sites should also implement the "respond to the SQRL client with the authenticated session URL" option. With this option, users would be required to use a browser on the same machine as the SQRL client. Finally, users should use a client that integrates with the browser as this would enable detection of a web page URL mismatch.
I suppose the authors of nmap didn't think their tool through correctly because it allows joe-random-employee at $office to portscan the ever loving shit out of every device behind the firewall.
Feel free to block the scanner. That's the appropriate response if you don't like having a port scan done. While you are at it, you should probably sit there and watch your firewall logs and block all of Shodan's bots, and all the malware-infected pcs hanging out there on the internet doing port scans. If you consider a port scan a threat to your office's or your company's security, you are relying on security by obscurity and are doing it wrong.
Oh, and SpinRite does work. I used to work at a university back in the days when floppies were the most common way for students to carry homework around. Every semester at finals time, we would have a few dozen students come in to the student support area in tears because their final/thesis/whatever was on a bad floppy and it was their only copy. I had about a 50% success rate with SpinRite. Better than nothing. I have also used SpinRite to get a drive back in good enough shape to pull an image before throwing it out. I've probably done this a dozen times over the years. I won't say it fixes the drive (or floppy disk), because it doesn't, and GRC doesn't claim it does. Generally the act of reading all the data just triggers the drive's internal ECC and it fixes itself by recovering from a spare sector.
"Frequently wrong, never in doubt."
I suppose the authors of nmap didn't think their tool through correctly because it allows joe-random-employee at $office to portscan the ever loving shit out of every device behind the firewall.
I believe you need to be root or nmap must be suid in order for it to do a full port scan.
My eyes reflect the stars and a smile lights up my face.
A simple TCP port scan doesn't need root. You are just attempting to open a connection to a port on a given host or hosts. This is the same behavior every network-enabled application is using to establish a connection with a remote host. It's also exactly what ShieldsUp does.
Fancier nmap scans (SYN scan for example) do need root.
"Frequently wrong, never in doubt."
To be perfectly clear, this attack IS just an update on normal authentication session phishing, where the attacker gets the target to authenticate a copy of the login form while the attacker is the custodian of the associated session cookie. If the user is inattentive it will work with all normal authentication methods and sadly also SQRL et-al when used in remote authentication (QR-Code) mode**. Thus most of these authentication methods exclude it from their designs as being out of scope.
That said, SQRL was not designed to address this currently intractable issue (people are lazy observers), it was designed to address the other big problem (people are bad at picking passwords). It does this by only sharing public information (site specific public key) with the server which it proves with zero knowledge that it has secret information (site specific private key) by signing a random challenge from the server. Which just happens to also have a 1:1 hidden relationship to the login page session cookie.
**Remote mode
This is when you use the QR-Code and client on a device separate from the device the browser is running on. In SQRL it is more common and more secure to have your client running on the same device such that instead of scanning the code you click/tap it and launch the associated sqrl:// scheme link. In that case hard same IP protections are enforced which would then refuse to complete an authentication unless the attacker is also present on the same WAN IP as the victim (a very much less likely scenario).
In closing, all these early zero knowledge and token authentication schemes will be updated soon after release to include methods and means to thwart this normally intractable attack mode but that will have to wait for parts of the client to be migrated into the browser agent codebase, where they can either respond more precisely to errors forced upon the attacker or be able to bypass the attacker altogether (see SQRL-V2 CPS mode).
At the very least, any site using SQRL that cares about security should disallow logins where the SQRL client and browser IP addresses are different.
This actually breaks the original intended mode of operation for SQRL, using a smartphone to scan a QR code and log in on a PC in most cases (it would still work if the PC and the phone are both behind the same NAT device). While this may not necessarily be useful for all people, one of the uses cases for this mode was to allow a safer login on a potentially untrusted machine.
End of Line.