Iranian Phishers Bypass 2fa Protections Offered By Yahoo Mail, Gmail (arstechnica.com)
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."
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 back to a mail program for mail means that the images in the HTML file will not be displayed by default, even in Outlook.
Couple this with the lack of security in SMS, which telcos -could- remedy, but seem not to be interested, and it is no wonder why this happens.
Best protection? Read mail in a mail program.
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.
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.
What we need is education. It’s really simple - stop clicking on every single link that comes along. Take a moment to see where the link takes you. Just about every one of these stories has the same thing in common... stupid users.
Performing a MITM attack allows you to be a
Man in the (Middle)! What will these Iranian A-rabs think of next!>!>
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.
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 phone, and the attackers will be let through.
Basically 2FA is not effective against phishing attacks that use a man-in-the-middle approach. It is only effective against your credentials being stolen and used without your involvement.
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 browser) would have a separate non-variable authentication dialog that is used to secure a channel. That dialog would use properly secure password exchange protocols like SRP. For second factor an API that allowed the browser security and authentication dialog to be proxied through the locally held USB 'second factor' would pretty much lock down the display so it only showed what could be locally encrypted and decrypted by the physically held factor, and as a bonus, the physical factor should have a mini LCD and 'confirm' button to allow the remote system to make sure certain risky actions are authenticated out-of-band of a potentially compromised browser and/or operation system.
The above doesn't stop a local targeted trojan from faking the whole screen and using your password and hardware token for a completely remote session. But, it does stop any rogue site or middle man from impersonating the secure server that you are talking to. And an 'in the loop' hardware token with LCD and confirmation button would even prevent a compromised computer from faking the critical data in the session (such as account numbers, values, and confirming transfers).
SMS based systems that send the full details per transaction with a 'confirm transfer to EntityX for $Y by entering the provided 6 digit code into the web portal' are an improvement, but are still susceptible to phone number hijacking.
A better option is to use a specialised Banking App on the phone itself to perform the transaction. At least you know the App (unless the phone is compromised, or you downloaded the App from a 'bad' place) is going to authenticate the server and path and can use secure protocols for password exchange and transaction authorisation. This is closer to 2FA, because the bank could authenticate the App on initial setup, and from then on, you must use that phone and that App with that password. The Phone/App become 'something you have' and the password is the 'something you know'. Someone steals or you lose your phone, you have to set up the banking App again and generate a new password.