Iranian Phishers Bypass 2fa Protections Offered By Yahoo Mail, Gmail (arstechnica.com) 59
An anonymous reader quotes a report from Ars Technica: A recent phishing campaign targeting U.S. government officials, activists, and journalists is notable for using a technique that allowed the attackers to bypass two-factor authentication protections offered by services such as Gmail and Yahoo Mail, researchers said Thursday. The event underscores the risks of 2fa that relies on one-tap logins or one-time passwords, particularly if the latter are sent in SMS messages to phones.
Attackers working on behalf of the Iranian government collected detailed information on targets and used that knowledge to write spear-phishing emails that were tailored to the targets' level of operational security, researchers with security firm Certfa Lab said in a blog post. The emails contained a hidden image that alerted the attackers in real time when targets viewed the messages. When targets entered passwords into a fake Gmail or Yahoo security page, the attackers would almost simultaneously enter the credentials into a real login page. In the event targets' accounts were protected by 2fa, the attackers redirected targets to a new page that requested a one-time password. "In other words, they check victims' usernames and passwords in realtime on their own servers, and even if 2 factor authentication such as text message, authenticator app or one-tap login are enabled they can trick targets and steal that information too," Certfa Lab researchers wrote. "We've seen [it] tried to bypass 2fa for Google Authenticator, but we are not sure they've managed to do such a thing or not," the Certfa representative wrote. "For sure, we know hackers have bypassed 2fa via SMS."
Attackers working on behalf of the Iranian government collected detailed information on targets and used that knowledge to write spear-phishing emails that were tailored to the targets' level of operational security, researchers with security firm Certfa Lab said in a blog post. The emails contained a hidden image that alerted the attackers in real time when targets viewed the messages. When targets entered passwords into a fake Gmail or Yahoo security page, the attackers would almost simultaneously enter the credentials into a real login page. In the event targets' accounts were protected by 2fa, the attackers redirected targets to a new page that requested a one-time password. "In other words, they check victims' usernames and passwords in realtime on their own servers, and even if 2 factor authentication such as text message, authenticator app or one-tap login are enabled they can trick targets and steal that information too," Certfa Lab researchers wrote. "We've seen [it] tried to bypass 2fa for Google Authenticator, but we are not sure they've managed to do such a thing or not," the Certfa representative wrote. "For sure, we know hackers have bypassed 2fa via SMS."
Re: (Score:3, Insightful)
This doesn't mean that 2FA is the culprit. Instead, what is one major problem, is the fact that we use web browsers for everything. With a decent mail program, the only time you really need a password is during the initial setup. From there on, it hands the authentication, forcing attackers to either attack the mail server or the endpoint.
We are starting to come to a point where a single application that has to handle anything and everything just cannot be made secure against every eventuality. Going ba
Re: (Score:3)
Very true. However, after all the fallout, even Outlook is up to par. Thunderbird isn't perfect, but decent. There are others out there that one can try. Worst case, there is always Mutt, which laughs at bogus HTML attacks.
Re: (Score:3, Interesting)
Problem here is that all these OTP (including SMS, Authenticator, etc) systems are glorified version of the 1st factor 'something you know'. The something you have is only being used as the equivalent of a memory aid to boost the strength of the 'something you know' factor.
The web browser is effectively a remote display for a secure server with generic security and a variable security interface provided by the remote system to display on the user's display (browser). A properly secured system (secure browse
Re: (Score:2)
One of the best things I've seen was IBM's ZTIC. The implementation was flawed, as it had to piggyback via USB onto the network. Instead, a cellular modem could be used. With a device like this, whose only function is to confirm transactions posted on it, it would go a long way to stop fraud, mainly because the attacker would have to have that device and be using it, as well as 2FA access into the account.
Of course, there are always Yubikeys, which also confirm physical presence.
Re: (Score:2)
Yeah, that ZTIC looks promising, but still flawed. Sadly, it depends on the OS and local software to be completely trusted. In the end, it could be remotely proxied by a compromised browser. If that little USB dongle had an LCD and confirm button, it would complete the security and completely remove the benefit of trojaning the OS, banking software or browser on the computer. If an attacker tried to change the account or the amount, it would be visible on the Dongle's LCD.
The Yubikey looks very interesting
Re: (Score:2)
So they hacked a phone and snooped SMS. Cool
No, not at all, you didn't even read the summary.
In this attack they... ask for the 2FA authorization code on their fake login screen.
Re: (Score:2)
No.
They intercept the login, and then MITM it.
They pass on the username and password to Google, and then Google sends them a text.
They then enter the text on the fake screen (or do a one tap, or I assume they can even work with the authenticators).
This is why U2F is important, without getting a compromised registrar it can't be MITMed.
Re: (Score:3)
For Google, there are a number of 2FA options - it can send an OTP by SMS, or generate one on the phone. Both of these would be vulnerable. The third option prompts directly on the mobile phone to confirm it is really you trying to access the site. This will be vulnerable too, as if the user is not aware that the site they are logging into is a man-in-the-middle site, they are going to confirm on their p
The answer is simple. (Score:1, Funny)
We just need 3FA. Adding yet another insecure element into the mix will surely lead to security!
Re:The answer is simple. (Score:4, Insightful)
Re: (Score:2)
Go to the big US brand shop and have a worker see the person and their ID in front of them?
Send the person a letter in the mail?
Accounts and people using "digital" services want instant support.
Governments all over the world can study people and craft the exact messages needed to induce that one needed click from within the "dissidents"/interesting computer system.
Re: (Score:2)
And then InfiniteFA!
U2F FTW! (Score:4, Insightful)
The liFIDO / U2F systems (aka the little usb/wireless tokens) were not compromised by this attack! Yay technical security advance!
We really could use less all-over-the-map branding for U2F .. is called FIDO, FIDO2, Atlas? In fact many times it's called "Yubikey" which is pretty wrong.
What's great about U2F is that the user can be directed to the phishing, site and click the login button on the token and .. nothing bad happens. The system does not depend on the user for vigilance.
Re:U2F FTW! (Score:4, Informative)
Re: (Score:2)
Sure,
But if someone can get a fake cert, anything goes.
I agree that it'd be nice if there was key storage like ssh too, it would close the fake cert option for sites one visits, but the key itself is as safe as accurately typing the domain name as far as preventing MITM.
Re: (Score:2)
> But if someone can get a fake cert, anything goes.
Not if you use Secure Remote Password.
Re: (Score:2)
I was too glib and you are correct.
As you say, U2F is extremely secure, including against ordinary MITM attacks, but it is not air-tight.
The main case it does not protect against is if this is malware on the user's machine, tampering with their web pages after U2F has made the login. If you are worried about that case, maybe get a chromebook (which works with U2F).
Re: (Score:3)
Google actually had a feature that would have negated this attack, but disabled it a while back. Google would download external images to their own server, and then re-write the HTML in to use their cache. That way external images couldn't be used to track or detect when users read an email.
I seem to recall it caused some problems and eventually had to be disabled.
Re: (Score:2)
This looks like a classic man-in-the-middle attack. FIDO U2F makes MITM attacks much harder, but not impossible. https://security.stackexchange.com/questions/157756/mitm-attacks-on-fido-uaf-and-u2f [stackexchange.com]
Soemtimes the implementation is a bit off as well. I've had an Apple account where it tells me there is a new logon, asks me to allow it, sends the code and opens up a popup to enter the code. All very nice, except it happens on the machine I am using to login. I am not sure why it does that, a Handoff issue, but it seems a bit nonsensical the "extra protection" only requires me todo extra steps all on the same device.
loading images so 90's just use txt (Score:2)
the fact they watch for email being read wont work for plain txt, gmail even for HTML loads the images into the gmail cache on receipt so you cant tell when the person reads the email (you have to use the gmail apps though) you should use plain text if possible.
so basically this is a phishing scheme linked to SMS messages and wont work with the google authenticator or yahoo 2FA nor will it work with apple 2FA
your more at risk if you dont secure your domain... the number of domains that do not have DNSSEC is
Re: (Score:2)
Why won't this concept work with the authenticator?
A big flaw with authenticators, even separate ones is that they are vulnerable to dummy sites.
How does dnssec prevent this? The person is already at a false domain.
Passwords are more secure than U2F (Score:2)
Provided that you do not actually send them to the server and use them properly.
Secure Remote Passwords is totally secure from MIM attacks, as wall as being totally secure against bad CAs. It uses the password to generate the shared secret.
And due to some extreme cleverness in the algorithm, is even secure against weak passwords.
So why don't we use it! Because it would put most of the security industry out of business? Or pure ignorance.
https://en.wikipedia.org/wiki/... [wikipedia.org]
(It does require browser support, n
Re: (Score:2)
So, I admit it's a step above what I can quite clearly see the details of, but it seems to me that you need to store the salt client side to login?
If that's the case doesn't one effectively need a fob to use at more than one computer?
Re: (Score:2)
I did read the Wikipedia.
My understanding was that the shared salt is how the server knows it's speaking to the correct client.
First, to establish a password p with server Steve, client Carol picks a small random salt s, and computes x = H(s, p), v = gx. Steve stores v and s, indexed by I, as Carol's password verifier and salt.
Doesn't that mean any time I login as Carol I'll need access to that salt?
Re: Passwords are more secure than U2F (Score:2)
Nevermind, it looks like the salt is sent to the client as part of the login.
I swear I read it a few times, and missed that.
Re: (Score:1)
Yeah it's funny how all these "crimes" are done by "Russians", "Iranians", "North Koreans", the enemy du jour.
War mongering press hard at play
Re: (Score:2)
What they mean to say, is Iranian government registered IP addresses, which of course can be spoofed from just about anywhere, especially the CIA underwater cable links.
They want to make that claim, establish network criminal activity investigation treaties, and prove it. Just the bullshit waffle about IP addresses, is stupid, especially after both the CIA and NSA have been caught out at intending to fake those on purpose as part of their dominate the planet scams.
Re: (Score:1)
Nobody seems to care. It's more convenient and expedient to just play along.
Re: (Score:2)
Yeah, because when you think you're logging in, and then your phone asks if you're logging in, you'll never click that you're logging in, good call.
Or maybe actually it offers no extra protection for this type of attack.
Holy fucking shit, Batman! (Score:3)
Man in the (Middle)! What will these Iranian A-rabs think of next!>!>
What they call two factor is still one factor (Score:4, Informative)
The premise of multi factor security is that the authentication is performed in a way that guarantees each factor is an orthogonal channel. Ie. Something you know (ie. information), something you have (a physical device), and something you are (your physical body).
Sending something out of band to a user (or getting them run App that generates that something), that they then enter and send down the same authentication channel as the password is still single factor. Same applies to a photo of the user when a remote server is taking the picture with a remote 'camera' that is not under its secure control.
The issue is that anyone that hijacks the connection (either with a mistyped/phished link, or more a sophisticated interception/trojan attack), can run a simultaneous session so the user sees a facsimile of the real site and performs all security requests to enter data along the same channel. Since the channel is hijacked, the attacker just runs a parallel session where they enter all the same data as the user in the real session, while the user enters data into the fake channel (including SMS codes, google authenticator codes, whatever).
This reduces these techniques to a single factor 'something you know'. Even though some of that data is recreated at the last second (OTPs/codes) and then combined with longer term unchanging values such as password/userid/etc, it is still just a single use 'something you know', albeit something you only knew for a short time, and the knowledge is now longer useable.
Even though these banking style faux 2FA systems are still just a single factor, One Time Passwords (OTPs) are an improvement over a single long term password as they are a single use 'something you know'. So they prevent an attacker having repeated access. OTPs can be known through a device (FOB), an App (Authenticator), an SMS message, or even a series of passwords or an algorithm you've memorised that allows the OTP to never be repeated. These hardware/software based '2nd factor' systems are simply memory boosters so you don't have to memorise anything complicated, or multiple single use codes. Some people call this 'two factor', but the authentication path still reduces to 'something you know' since with 'you' as proxy, at the time of entry, it is still clearly only 'something you know', and no longer 'something you have'. It is something you know, that I could come to know remotely, even if just for a single use, without having access to your 'something you have'.
True 2FA 'something you have' would require the browser authenticate through your 'authenticator device' where the device is verifying the communications path and data that the user is entering into it. True 3FA would have you enter a secure environment with the first two factors, then use securely controlled scanner(s) to verify that your physical body or a perfect facsimile is being scanned.
Re: (Score:2)
U2F keys defeat this kind of attack. The browser passes the URL of the site requesting the code to the key, and the key checks if it is one that it has a time-based password for. Since any fake log-in page will almost certainly not be served from google.com that is a very effective protection.
Re: (Score:2)
U2F is a significant improvement on faux two factor schemes because it not only directly provides a cryptographic challenge/response auth, but it uses features in the browser that are not controlled or can be overridden by scripts running in the accessed page. And as such provides a complete round trip cryptographically secure verification of what URL the browser thinks it's accessing.
This lets the 'something you have' become the [browser + OS + PKI + UDF device]. Which means the attacker must now compromis
Images in Emails? (Score:2)
If you're working in security and using an email client that renders HTML then screw you - you deserve everything you get.