QRLJacking Attack Can Bypass Any QR Login System (helpnetsecurity.com) 31
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.
Quick! Someone tell Steve Gibson of GRC! (Score:1)
His squirrel has lost all of his nuts! Or I guess in this case, has had his nuts switched out behind the scenes!
Re: (Score:2)
Re:From GRC who brought you ShieldsUp! and SpinRit (Score:4, Insightful)
They may be crap, but it does not appear that this attack would work with SQRL [grc.com]. 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.
Re: From GRC who brought you ShieldsUp! and SpinRi (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
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 un
Re:From GRC who brought you ShieldsUp! and SpinRit (Score:4, Informative)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Social engineering (Score:3)
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.
Re:Social engineering (Score:4, Insightful)
Misfeatures like that are (arguably) serious design flaws. Correct operation requires the user to pay attention to something that works properly almost all the time, but when it doesn't work, it drives the user underneath a truck at 80 miles per hour.
Something like that, anyway.
Re: (Score:1)
I don't see how this is different from clicking on a (possibly malicious) link. Do you think hyperlinks are a serious design flaw?
Re: Social engineering (Score:2)
The app performs a security function, and there are lots of good technical ways to defeat such primitive MITM attacks. Making the user pay attention to hyperlink text from a source that is almost always good is a recipe for failure. A security app is not inherently suspect like emails from Prince Iwanna Scamya or dodgy websites are inherently suspect.
It's 2016 (Score:3, Insightful)
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.
This is well known & outside the remit! (Score:2)
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 wa