How 1-Time Passcodes Became a Corporate Liability (krebsonsecurity.com) 53
Brian Krebs, reporting at Krebs on Security: In mid-June 2022, a flood of SMS phishing messages began targeting employees at commercial staffing firms that provide customer support and outsourcing to thousands of companies. The missives asked users to click a link and log in at a phishing page that mimicked their employer's Okta authentication page. Those who submitted credentials were then prompted to provide the one-time password needed for multi-factor authentication. The phishers behind this scheme used newly-registered domains that often included the name of the target company, and sent text messages urging employees to click on links to these domains to view information about a pending change in their work schedule.
The phishing sites leveraged a Telegram instant message bot to forward any submitted credentials in real-time, allowing the attackers to use the phished username, password and one-time code to log in as that employee at the real employer website. But because of the way the bot was configured, it was possible for security researchers to capture the information being sent by victims to the public Telegram server. This data trove was first reported by security researchers at Singapore-based Group-IB, which dubbed the campaign "0ktapus" for the attackers targeting organizations using identity management tools from Okta.com. "This case is of interest because despite using low-skill methods it was able to compromise a large number of well-known organizations," Group-IB wrote. "Furthermore, once the attackers compromised an organization they were quickly able to pivot and launch subsequent supply chain attacks, indicating that the attack was planned carefully in advance." It's not clear how many of these phishing text messages were sent out, but the Telegram bot data reviewed by KrebsOnSecurity shows they generated nearly 10,000 replies over approximately two months of sporadic SMS phishing attacks targeting more than a hundred companies.
The phishing sites leveraged a Telegram instant message bot to forward any submitted credentials in real-time, allowing the attackers to use the phished username, password and one-time code to log in as that employee at the real employer website. But because of the way the bot was configured, it was possible for security researchers to capture the information being sent by victims to the public Telegram server. This data trove was first reported by security researchers at Singapore-based Group-IB, which dubbed the campaign "0ktapus" for the attackers targeting organizations using identity management tools from Okta.com. "This case is of interest because despite using low-skill methods it was able to compromise a large number of well-known organizations," Group-IB wrote. "Furthermore, once the attackers compromised an organization they were quickly able to pivot and launch subsequent supply chain attacks, indicating that the attack was planned carefully in advance." It's not clear how many of these phishing text messages were sent out, but the Telegram bot data reviewed by KrebsOnSecurity shows they generated nearly 10,000 replies over approximately two months of sporadic SMS phishing attacks targeting more than a hundred companies.
Not a Liability (Score:5, Insightful)
The headline is a lie. The one-time passwords are not a liability. They're just not perfect. This shows that they can be defeated with a man-in-the-middle attack, which everyone already knew. If this were a fundamental flaw where the one-time passwords reduced security, the, yes, it would be a liability, but this is in no way such a case.
Corporations have been subject to pretty much constant attacks with phishing and other techniques. If someone weren't combining phishing with man-in-the-middle for one-time passwords, it would be surprising.
Re: (Score:2)
Yes. The problem here is really stupidly simple.
DO NOT CLICK LINKS. (Idiots)
If you get a mail, SMS, Whatsapp, whateverthefuck from what's apparently your employer, log in to your employer's website, like you always do.
Don't click the link like some idiot.
Re:Not a Liability (Score:5, Insightful)
You know what would help with that?
If employers would stop sending out legitimate emails with links to click on. (Especially when they've farmed out yet another HR function to some random 3rd party cloud app.)
Re: (Score:2)
Yes. Some of the stuff being sent out is just mind boggling, to be honest.
Re:Not a Liability (Score:4, Informative)
It's slightly worse with Okta, which is why you may notice Okta is mentioned by name in the summary.
So, for example, you get a random link from HR for something that they're requiring you to do (e.g., mandatory training, filling out paper work, getting your W-2), and that website will then redirect you to yourcompany.okta.com or something like that. This phishing attack did something similar, except it redirected to yourcompany-okta.com and presented a copy of the Okta web page.
Because being redirected to a third party webpage to enter your password is now just a regular part of just about everything you do, you have to be paying quite a bit of attention to notice that the "." is now a "-" and therefore instead of a subdomain of a trusted domain (or at least a domain you're required to trust thanks to your company farming out authentication services), you're now at an imposter website.
But anyway, yes, most of the problem is the fact that modern business frequently farms out essential functions to weird domains so that you can't entirely be sure that the unsigned email claiming to be from HR sending you to corporatetraining4u.biz isn't valid. Because there's a good chance that it isn't a phishing campaign, it's a legitimate email that HR really did send out with no digital signature and you really do have to go to corporatetraining4u.biz and sign in with your corporate account with MFA via Okta to watch a video on not clicking random links from untrusted sources.
Re: (Score:3)
I was almost disappointed that the latest email about this year's anti-phishing training from my employer was not itself a anti-phishing test.
It's gotten to the point that every time they use an outside supplier there has to be a preceding email noting to expect an email from the outside provider, because they have trained us to flag everything as a phishing attempt.
Re: (Score:2)
The headline is a lie. The one-time passwords are not a liability. They're just not perfect. This shows that they can be defeated with a man-in-the-middle attack, which everyone already knew. If this were a fundamental flaw where the one-time passwords reduced security, the, yes, it would be a liability, but this is in no way such a case.
Phishing is the #1 security threat. If your authentication system is worthless against the top security threat then terms like "fundamentally flawed" and "insecure" seem well deserved to me.
Systems vulnerable to authenticator impersonation should be viewed as insecure and therefore rejected as unfit for purpose. It doesn't have to be this way, secure authentication technology exists -- all people have to do is use it.
Re: (Score:1)
The headline is a lie. The one-time passwords are not a liability. They're just not perfect. This shows that they can be defeated with a man-in-the-middle attack, which everyone already knew. If this were a fundamental flaw where the one-time passwords reduced security, the, yes, it would be a liability, but this is in no way such a case.
Phishing is the #1 security threat. If your authentication system is worthless against the top security threat then terms like "fundamentally flawed" and "insecure" seem well deserved to me.
Systems vulnerable to authenticator impersonation should be viewed as insecure and therefore rejected as unfit for purpose. It doesn't have to be this way, secure authentication technology exists -- all people have to do is use it.
All security systems are flawed against a sufficiently determined and resourced adversary.
These MITM OTP proxy attacks are becoming more common, but they are still vastly outnumbered by normal password based attacks using cred stuffing, password spraying, brute force, etc. You are still probably getting two orders of magnitude reduction in frequency through the use of even SMS OTP.
Any (sensible) MFA beats password only, with an MFA with a separate physical token and protocol that resists authenticator impe
Re: (Score:2)
All security systems are flawed against a sufficiently determined and resourced adversary.
This is what I tell people whenever they express surprise all of my passwords are 'password'.
These MITM OTP proxy attacks are becoming more common, but they are still vastly outnumbered by normal password based attacks using cred stuffing, password spraying, brute force, etc.
These items are not phishing attacks.
You are still probably getting two orders of magnitude reduction in frequency through the use of even SMS OTP.
There is no logical basis for these assumptions.
If I can get you to login to my impersonation site and enter your username and password nothing stops me from prompting you for a "one time" password as well. This is materially no different or any more difficult than what has already been achieved. All I am doing is repeating what I did before to get you to give me your password
Re: (Score:1)
All security systems are flawed against a sufficiently determined and resourced adversary.
This is what I tell people whenever they express surprise all of my passwords are 'password'.
I take your point, but I hope you are actually not doing that.
These MITM OTP proxy attacks are becoming more common, but they are still vastly outnumbered by normal password based attacks using cred stuffing, password spraying, brute force, etc.
These items are not phishing attacks.
You called OTP worthless, insecure and fundamentally flawed. My point was OTP does provide a benefit, even if it could be better.
You are still probably getting two orders of magnitude reduction in frequency through the use of even SMS OTP.
There is no logical basis for these assumptions.
I'm probably more familiar with incident data than most. Here's one source: https://www.microsoft.com/secu... [microsoft.com]
If I can get you to login to my impersonation site and enter your username and password nothing stops me from prompting you for a "one time" password as well. This is materially no different or any more difficult than what has already been achieved. All I am doing is repeating what I did before to get you to give me your password for a second time.
The difference is in the complexity of the attack and durability of the credentials obtained.
Most OTP are time based, which gives the attacker a limited time within which to use the OTP (this isn't exactly hard,
Re: (Score:2)
You called OTP worthless, insecure and fundamentally flawed. My point was OTP does provide a benefit, even if it could be better.
No I didn't. What I said was "Phishing is the #1 security threat. If your authentication system is worthless against the top security threat then terms like "fundamentally flawed" and "insecure" seem well deserved to me."
Phishing is a subset of the constellation of all possible threats.
The difference is in the complexity of the attack and durability of the credentials obtained.
What complexity difference? Asking for similar data a second time?
Most OTP are time based, which gives the attacker a limited time within which to use the OTP (this isn't exactly hard, but it is a step above a password, which can just be stored away for a rainy day). If they authenticate successfully the attacker will likely get some kind of session token from the system. If that session token has a lifetime, or the session token is invalidated by other conditions - inactivity, change of IP address, etc (many don't, but many do) the attacker needs to either be able to complete their task or put in place some sort of persistence in that session, before the session token is invalidated.
If they have the user's password and there is no MFA, they can just return when they like. They might not even bother with persistence because what they have works perfectly, and means they don't need to make any changes to the system that might be detected.
How many logins does it take to empty your bank account, exfiltrate all your data and phish all of your contacts? This one time access argument has merit fo
Re: (Score:2)
My own employer has been subject to constant phishing attacks and in one case, they even got paid by us. Data security has since been tightened up and now everything is 2FA. We have still had phishing attempts where people have accidentally put in their password in the fake website, even technical types, however, the credential the phisher pilfered was mostly useless they managed to use it within about 20 seconds. (Call me paranoid but I wait until the code is about to turn before I submit the 2FA code).
Re: (Score:1)
My own employer has been subject to constant phishing attacks and in one case, they even got paid by us. Data security has since been tightened up and now everything is 2FA. We have still had phishing attempts where people have accidentally put in their password in the fake website, even technical types, however, the credential the phisher pilfered was mostly useless they managed to use it within about 20 seconds. (Call me paranoid but I wait until the code is about to turn before I submit the 2FA code). Fortunately, most of the time they aren't that quick, but no doubt they soon will be.
.
I wish the MS Office LDAP offered Yubikey support. Its long overdue for mass adoption.
the code you are waiting to expire can be good for up to +/- 5 minutes, depending on the system, so you are just wasting time.
client certificates are the way to go here. if the server requires a client certificate, you won't even get to a login prompt unless you have a valid client certificate installed and select it for the connection. my company's password manager is set up this way. If you don't have one of our certificates, you can't establish a connection, and never see the login screen.
In other words (Score:2)
There's not a foolproof technical solution to social engineering attacks.
Train your users, and give them the access they need to do their jobs - but no more.
We need authentication both ways (Score:2)
Re: (Score:2)
The server that you're giving the codes should provide a one-time code to authenticate itself to your crypto device. At Sun we had devices that had keypads, but I don't think we ever used them for anything but entering a personal pin
This just enables bidirectional authenticator impersonation.
OTP is not the liability (Score:3)
Even now so many sites and brokerages use SMS as the 2FA. SMS is weak. Even if the entire cell phone infrastructure is secured, the security model in mobile phones are poor. It is easy for apps to register themselves as sms/call whitelising software, intercept the sms at the final device. People can be tricked into downloading such apps, such apps might be evil payload on ostensibly legitimate apps providing other services...
Issue is on the SMS side, not OTP idea.
Re: (Score:3)
It's not SMS, this works with any OTP that's entered as a second password.
The problem is pretty basic: if you implement OTP as just a second credential that's entered, there's nothing preventing someone from just phishing both credentials and then using them to access the final system.
The attack was pretty simple: show a copy of the login screen. Then, when the user enters their username, password, and OTP into the form, relay those to the actual login page, and now you have an attacker-controlled session.
Re: (Score:2)
FIDO2 solves that issue. Everyone should be switching to it, but uptake has been slow.
Re: (Score:2)
Using SMS as the 2FA was the liability.
Even now so many sites and brokerages use SMS as the 2FA. SMS is weak. Even if the entire cell phone infrastructure is secured, the security model in mobile phones are poor. It is easy for apps to register themselves as sms/call whitelising software, intercept the sms at the final device. People can be tricked into downloading such apps, such apps might be evil payload on ostensibly legitimate apps providing other services...
Issue is on the SMS side, not OTP idea.
It doesn't matter how you get a password if how you enter it is also insecure. The way OTP is deployed is almost always insecure relying on unbound channel encryption subject to trivial authenticator impersonation.
A secure system for manual password entry would have two critical requirements:
1. Credential entry ONLY via secure dialogue post SAS invocation
2. Use of secure authentication algorithms such as zero knowledge proofs
Re: (Score:2)
Re: (Score:2)
You don't need zero knowledge proofs or anything fancy. This is a solved problem: derive a secret key from a per-token secret and the hash of the domain that wants to be authenticated. If you want to login in to search-engine.com and your phishing attack gives you search-engine.evil instead, your token will use a different key and therefore fail the 2FA test.
If you have a foolproof means of discriminating the correct location ahead of time aren't you basically just defining the problem away?
The reason zero knowledge proofs are used instead of hash schemes is hashes reveal information that can be used to conduct offline brute force attacks.
Re: (Score:2)
Re: (Score:2)
The trust model normally assumes that the security token is not actively comprising, e.g. if the token knows you want to access google.com, it won't use a special weak key.
No clue what you are trying to say. Don't understand how some external thing would even know what site you are actually going to. Assuming you didn't change the subject entirely and this is no longer about anything resembling OTP some context is required to understand what you are saying.
If you got a OTP from some sort of google.com authenticator using an external OTP gadget and entered it into the prompt when visiting g00gle.com site what specifically renders the entered code invalid? The authenticator
Re: (Score:2)
Re: (Score:2)
Now to solve the problem of man-in-the-middle attacks with FIDO, the computation is actually changed to something like HASH(HASH(seed)||HASH(counter)||HASH(domain)) where domain is the website actually used. When using WebAuthN with a USB token or Microsoft Hello or any other authenticator program, it is never entered by the user ("Of course I'm using search-engine.com!") and as a result, the login mask on search-engine.evil will get a different stream of passwords and therefore the man-in-the-middle login attempts fail. In practice, FIDO2 doesn't use passwords, but public key cryptography, but that's more a detail of the implementation.
So you are talking about PKI not OTP... In that case I recommend using client certs rather than FIDO. Client certs are proven technology in continuous production use for nearly a generation. This technology cryptographically binds the communications channel, offers full protection against authenticator impersonation and is nearly universally supported.
Client certs provide flexibility of storing keys on device or external smart cards. There is no need to worry about domain specific authentication. Your a
Re: (Score:2)
Re: (Score:2)
Typical man-in-the-middle:
User is tricked into visiting FakeBank.com instead of RealBank.com. FakeBank gets the authentication page and serves it to the user. User types in username and password. Fakebank collects it and sends it to the real bank. The real bank sends out a 2FA token through some other channel. User types the 2FA to the same fakebank.com and it forwards that token and authenticates itself to do nefarious thi
Re: (Score:2)
Re: (Score:2)
So, in FIDO2, some website wants to authenticate you. The local FIDO2 application/hardware hashes the requesting site name/IP address and sends it over. If requesting site is genuine, the hash will be as expected. If it is man-in-the-middle, the hash is not useful in forwarding to the real site.
Security comes from registering your FIDO2 compliant device/application earlier with the genuine site and creating public/private key pair.
Thanks, I am getting some general idea.
Re: (Score:2)
Re: (Score:2)
Realbank.com does not send an OTP through secure channel to the user. Instead it closes the connection with the message, "Secure link has been sent to your registered device. Continue there".
Realbank sends an hashed link, good f
Re: (Score:2)
Re: (Score:2)
When user setups an account with RealBank.com, he/she typically sets up username, password, 2FA method. In addition the user will also specify a secure call back channel and a call-me-username.
Normal login process would be, to use any device/browser to visit the RealBank.com and enter the call-me-username. RealBank.com will send a one-time-use-link through the registered secure channel and close the connection. Thus even if the user is
The criminals (Score:2)
Re: (Score:2)
> The criminals will find a way to exploit anything if stupid people are available
And if the organization has more than 10 people, some of them are stupid.
Re: (Score:2)
Re: (Score:2)
> The think I can't figure out is shouldn't there be a way to restrict the database dumps and what processes have access to them
Absolutely. Just a few minutes ago I deleted 529,803 credit card numbers (some dupes).
Those will absolutely never be breached, now.
#1 best way to prevent data breaches - don't friggin store sensitive data that you don't have a clear need for in the future. Which means you shouldn't be storing any that you *used* to have a clear need for, but no longer do.
Re: (Score:1)
> The criminals will find a way to exploit anything if stupid people are available
And if the organization has more than 10 people, some of them are stupid.
I'll give you a different angle on this.
Any person is capable of making stupid mistakes, under the right circumstances. The problem is the hackers only need one person to be stupid once to get their hooks in.
This whole PEBKAC approach to phishing and social engineering belongs in the 2000s, or maybe even the 90s. As technical people it's our job to engineer solutions that protect people, and our businesses, when they make a mistake. Likewise if we are in charge or moving money/paying transactions etc.
Even p
Swiss cheese model (Score:2)
Even a guy I know whose JOB is educating people about scams got scammed himself. That's because the good scammers know how to manipulate our EMOTIONS, which largely takes out logical brains out of the equation. So absolutely people will mess up.
Systems designed to protect despite screw ups will ALSO fail. The hope is that they don't both fail at the same time.
You mentioned pilots. In aviation, the "Swiss cheese model" is commonly used. Imagine a stack of three slices of Swiss cheese. You'll have a hole thro
Re: (Score:2)
heh heh yep. I was just trying to buy a TV and the alleged seller said I had to give them my cell number so I could get a text with a six digit code... then give them the code to prove I was a human. lolwaffles. I bet it works at least some of the time though
Not OTP that's the liability here (Score:3)
It sounds like it wasn't OTP/MFA that was the liability here. The liability was the people who were gullible enough to click on links in a message sent by an unknown party. Reality check: if the message wasn't cryptographically signed and the signature verified against a public key you know belongs to the purported sender, you DO NOT KNOW who sent it. But it's simple to defang any attacks like this, simply avoid completely trusting the message. If you need to take action, you should already know where to go to take that action without having to be given a link in the message. So do that. Use your bookmarks to go to wherever you need to go and do whatever's needed there. By doing that you deprive the attacker of any opportunity to direct you to their site and intercept your interaction.
At this point, I think anyone in any company proposing putting direct links in any company communication to employees is proposing a major security vulnerability be introduced and they and their proposal dealt with the way you'd deal with someone proposing that all passwords be the employee's first initial and last name.
Re: (Score:2)
None of this was in a secure app, it was simply a message (SMS, email whatever) sent to the employee. All companies do that, and it's a perfectly valid way of communicating with employees. The only problem that exists on the company side is this stupid idea of encouraging employees to trust content from channels that aren't secured. And secured in this case doesn't mean encrypted, it means signed in a way that lets the employee verify both the identity of the sender and that the content hasn't been altered
Use TOTP instead of SMS codes (Score:2)
Use TOTP generated codes for real security
Re: (Score:2)
Per the article, the initial SMS was used to direct the user to the fake phishing web site. According to the article, 47% of Okta customers use SMS or voice-based MFA. The attack also worked on companies using TOTP MFA.
TOTP doesn't solve phishing attacks. The attacker just tricks the victim into give them the TOPT (by entering it into a fake website). SMS is less secure because it's vulnerable to hijacking attacks like sim swapping in addition to these phishing attacks.
Even push-notification based apps
Telegram again? (Score:2)
Shift from dumping to IRC to Telegram (Score:2)
misleading headline (Score:2)