Slashdot Mirror
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."
We just need 3FA. Adding yet another insecure element into the mix will surely lead to security!
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.
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.
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
“He’s not deformed, he’s just drunk!”
Performing a MITM attack allows you to be a
Man in the (Middle)! What will these Iranian A-rabs think of next!>!>
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 quite scary... combined with the amount of mail servers that actually verify the certificates correctly via DANE
you can test your domain https://www.internet.nl/
Thankfully the German and Netherlands Governments have made DANE a standard for secure email communications... the American gov also MUST have DNSSEC enabled...
so test and secure your corporate domain today !
regards
John Jones
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.
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.
Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
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.
Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
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.
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.
Chaos - everything, everywhere, everywhen
Nobody seems to care. It's more convenient and expedient to just play along.
“He’s not deformed, he’s just drunk!”
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.
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/...
(It does require browser support, not JavaScript that just promises not to send the password over.)
If you're working in security and using an email client that renders HTML then screw you - you deserve everything you get.
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
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.
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 too as they have an open standard based direct browser support/integration. So, like the ZTIC it effectively reduces the attack surface to having to compromise the browser or OS directly, rather than just a relatively simple phishing attack. Unfortunately, if the Browser is compromised (or a trojan browser downloaded) an attacker can proxy the Yubikey physical presence challenge/response to a remote attacker's site. But, that is much more difficult than a simple phishing site.
I like your idea of the cellular device. It doesn't matter if someone tries to steal the IMEI or redirect the cellular account, since the crypto in the product guarantees it always authenticates the bank (and vice versa). In fact, Apple or Google could include something like that as a standard feature in the trusted zone of their products along with a dedicated indicator on the product that only turns 'green' when the authentication tool is running in full display mode. Then you just set up for various secure sites/entities like is done for Google Authenticator, and either directly confirm with a button on the tool, or optionally use a confirmation code displayed on the secure display and entered into the browser. The confirmation code allows the system to use a simple transport like SMS to send the user an encrypted/authenticated data and confirmation code - meaning an SMS/IMEI redirect isn't going to help an attacker as they can't decrypt the SMS - so the user can enter it into an application on another to round-trip secure that application if necessary. For most things a direct 'confirm' button on the authentication tool would be a simple single button solution to secure access and transactions.