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."
I love face 2 ass!
We just need 3FA. Adding yet another insecure element into the mix will surely lead to security!
Don't load images by default.
Don't click links in emails. Instead type the website into the browser.
Don't enter a 2 factor authentication code into a website without checking the URL.
Why are we still trusting unsecured, unsigned emails for anything other than a likely-spam folder?
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.
So you're saying if I was dumb as a brick and couldn't notice I wasn't actually on the right website, someone could get access to my stuff!? No way!
It is delicious!
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.
The endpoint being the "decent mail program."
The title is BS, they didn't bypass 2fa, they captured the response in a fake page, and replayed elsewhere. Details are actually important for those in security. People falling for fake sites is a problem, but this is NOT a big hole in 2fa.
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.
While you are correct that the 2FA is not a culprit, you miss what the real culprit is: The stupid users.
At this point, no one should fall for basic phishing schemes like this. When you get an email or text that asks you to click here to log in to something, DON'T. Don't click on the link, instead use your own bookmarks/shortcuts/apps. Or at least, look at the fricking URL before typing in your password.
No technical security measure will ever work, until users stop doing stupid things.
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.
Scared of those pesky Russian trolls, Chinese spies, and Iranian cyber-terrorists! Don't fear, CISA is here! The DHS Cybersecurity and Infrastructure Security Agency stands ready to take tax payer money and spend it on bureaucrats to go on junkets for to Europe...er, we mean, on releasing advisories that are at least a week old and are rehashes of what's been published by private sector companies..., err, I mean...can we get back to everyone on that?
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.
2FA that ask you to enter a code on the same page you sign in are silly for this reason. They offer zero protection if you're dumb enough to fall for a fake page or someone get haxored well enough for a MITM to happen.
When I sign into gmail my phone prompts me and I unlock it then it signs in automatically no further intervention I only enter username/password in the browser. You would need to hit my phone and browser to have a chance of doing anything.
Performing a MITM attack allows you to be a
Man in the (Middle)! What will these Iranian A-rabs think of next!>!>
Virtually impossible to phish
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
Who the fuck are they? A quick search shows nothing, spook front?
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.
Not entirely true. Yes, phishing schemes should be detectable and avoided. However, nothing stops a browser based exploit (possibly zero day, possibly just something that hasn't been patched for all users yet for whatever reason) having the same effect. You can be as diligent as you want and as 'intelligent' as you think you are, but you have no way to know this is happening in the background.
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.
2FA better authenticates the user. It doesn't authenticate the service. That's still up to the user to do adequately, and if they fail the entire system breaks down.
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"
This is why you need to authenticate the server first, to make sure nobody took control of the dns etc.
The certificates scammers buy can present same name as original using earlier tricks in text representation. "Oreo Bank INC" vs "0reo Bank INC" is the simplest...
If this is not done the rest is meaningless.
HTTPS: yep
Certificate "0reo Bank INC": Umm, yes???
TFA: Wasted time
it's pointless to secure sms since whole protocol that global phone network operate on is vulnerable....
What I'd really like is to see mutt integrated with a hardware-based solution such as Yubikey. Why does all the actual secure stuff have to be web-based javashit?
So, weirdly, this is also an issue with steam. Steam uses 2FA in the form of an app (mobile authenticator). This is used to secure your account. This matters because some people have accounts worth thousands of dollars (yes, in non-physical digital items). A few people have accounts worth more, multiple thousands of dollars (in an unrelated incident, check /r/vac_porn where two unrelated users with accounts worth multiple hundred(!) thousand dollars were vac banned earlier this week, rendering those items untradable and worthless).
That's just a preface to point out there is money to be made by scamming people out of account items. And recently, there has been a rising number of sophisticated scam websites. These sites basically operate the same as outlined in the article summary, but it's all automated. You visit a fake site that looks exactly like the official steam login page and enter your credentials; the fake website server uses this to actually authenticate you with steam. Then there's the standard popup asking for your steam 2FA code. Once again, the website just presents a front and passes that along. To the end user, it looks like a regular login, but now the fake website has (limited) access to your account. There are still some protections against what new ip address logins can do, but this is the critical first step in a new sophisticated scam. There's a detailed write up by a mod stickied at the top of /r/globaloffensivetrade if you want more info
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.