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!
Well, somebody's envious of Steve.
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
Pick any two...
seems there's a bug in the Related Links, as these aren't at all related:
[Related Links]
10 Confirmed Dead In Shooting at Oregon's Umpqua Community College
VC, Entrepreneur Says Basic Income Would Work Even If 90% People 'Smoked Pot' and Didn't Work
Yelp Employee Posts Open Letter About Cost Of Living And Low Wages, Gets Fired
Universal Basic Income Programs Arrive
Explosions and Multiple Shootings In Paris, Possible Hostages
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.
The whole story is just
IF YOU DON'T READ THE URL
you might be on the wrong site.
news @ 11
Just another Troll!! Anyone can make a baseless statement like "Spinrite doesn't do jack". For example, I can make a statement like "Da W00t is a hopeless loser who is pretending to be a system administrator". He may or may not be a system administrator.
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.
hackers have been going old school for *years* slapping stickers with qr codes linked to malware right on ads, store displays, menus, and other print media with them on it. qr codes are the dumbest fucking idea in consumer tech since bob.
just wait til the first bogus qr code linked bsod is found containing one... https://tech.slashdot.org/stor...
You have misunderstood what this ‘attack’ is. It's a social engineering fishing attack and it's already obvious that you're not on a legit login page if you're paying attention. If you're already paying enough attention to only login using SQRL (otherwise you're still ‘vulnerable’) then you're attentive enough not to get caught by this either.
And as with all fishing attacks, you need to somehow get people to visit the fishing website. In the example as presented, they inject an advertisement in a MITM against Amazon. I just tested if this really works, and it turns out I cannot visit Amazon's pages over unencrypted http: as in the demonstration using any of my browsers. Which is possibly a more robust lesson to learn from all this: never log in from a non-https: site, not using username / password and not using QR-codes or whatever else comes around.
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.
Why would you block the scanner? Does it hurt your firewall or cause a DOS on your network?
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."
Since SQRL isn't actually released or in use in production anywhere, I think this is a case of typical shit slashdot editing.
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.
TFS sucks and there's only a link to github, fuck that.
Is this seriously just "hey btw you can have a user go to a fake login page with a QR code"? Isn't that, like, the thing that's happened since the first QRc was printed?
What am I missing?