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."
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.