Mandiant's brute-forced X account exposes perils of skimping on 2FA

Google-owned security house Mandiant's investigation into how its X account was taken over to push cryptocurrency scams concludes the "likely" cause was a successful brute-force password attack. The natural reaction to this would be to ask why two/multi-factor authentication didn't prevent this from taking place. Well, …

[Jellied Eel]

Gimme your phone number

Google's data from 2019 indicated that SMS-based 2FA can block up to 100 percent of automated attempts to hijack accounts, 99 percent of bulk phishing attacks, and 66 percent of targeted attacks.

Well, Google would say that, wouldn't they? How else would they grab the phone numbers and link that to the personal data of iPhone users? It already has that for Androids, so if you have one of those, may as well use 2FA. But I had a fun conversation with my bank requesting a new dongle. Why not use the app on my 'smart phone'. What's the most stolen device, I wonder..

Bit of a Hobson's Choice though, minimise the risk of targeted attacks, if you accept the massively increased risk of targeted spam.

[Anonymous Coward]

This is why I ignore the 2FA naysayers.

Even pisspoor 2FA is better than none.

[Doctor Syntax]

Re: This is why I ignore the 2FA naysayers.

Not quite, if you're a scammer, but nearly. You can talk the mark's provider into a SIM-swap or you just go ahead and steal the phone.

Remember folks, if you rely on mobile-based 2FA whoever holds your phone[number] is you, even if it's not you.

[Throatwarbler Mangrove]

Re: This is why I ignore the 2FA naysayers.

How common are SIM-swap attacks for regular people? Doesn't someone basically have to socially engineer an attack on the cell provider? In most cases, that should be difficult enough that only high-value targets would be worth going after. In terms of stealing the phone, my phone is locked, and the moment I realized it was gone, I would find my device and, if it was not in a location I recognized, I would remote-wipe it. My phone (as with most people's) is locked most of the time, anyway, so I'm mostly unconcerned with the possibility of a random thief breaking into it.

Pointing out that there are flaws with the SMS approach don't negate the reality that it's still better protection than a password alone.

[Michael Wojcik]

Re: This is why I ignore the 2FA naysayers.

Doesn't someone basically have to socially engineer an attack on the cell provider?

I think in a majority of the analyses I've seen, they co-opted an employee, typically at a phone store, rather than trying to social-engineer a carrier.

[DS999]

Re: This is why I ignore the 2FA naysayers.

Not sure that's true where SMS based 2FA is concerned, given how easy it is to overcome.

[Michael Wojcik]

Re: This is why I ignore the 2FA naysayers.

Even pisspoor 2FA is better than none.

Until it fails, and the user either doesn't have a backup method, or the backup method also fails (possibly because it's never been tested, or the user doesn't remember what it was, and so on).

Multi-factor authentication has its own failure modes. MFA using smartphones — fragile, valuable, small physical objects that many people play with more or less constantly, set down on any convenient surface, lose in their own home, etc — is a remarkably stupid idea.

TOTP, as a second factor, is pretty easy for the technically knowledgeable to back up; I have all my TOTP secrets backed up to multiple devices. But it's a black box for most users, and the widespread use of (horrible) QR codes to set TOTP secrets very much does not help.

MFA is also an obstacle to account-sharing, and there are very good use cases for sharing accounts. My wife and I have a joint "house" email account, for example, in addition to our personal accounts; that's where things like bills and other official communications go. Access to accounts after someone dies or is incapacitated is another one.

The fact of the matter is that however much security experts crow over the wonders of, say, FIDO2, the industry is far from producing an authentication solution that meets even a decent subset of reasonable requirements. We continue to fail miserably in this area.

[sitta_europea]

National Savings wrote to me to ask me to fill in a form to sign up for Internet access to my account.

I wrote on the form:

NEVER

NEVER

NEVER

and sent it back to them.

Haven't heard back.

[Throatwarbler Mangrove]

That's nice, granddad. Go back to listening to your phonograph.

[Strong as Taishan Mountains]

Just because you don't sign up for access doesn't mean every single byte of your details aren't sprayed across every data auction site in existence

Security esspensive.

Saving space and money shoving a business into a server is cheap .

[Kurgan]

Brute forced?

So their password was quite simple or very short, because you cannot brute force a 20 chars random password in a decent time, at least in my opinion.

[JimmyPage]

Re: Brute forced?

Why wasn't the account locked after the 3rd failure ?

[Andrew Hodgkinson]

Re: Brute forced?

Yep, exactly what I just said! https://forums.theregister.com/forum/all/2024/01/11/mandiant_x_account_brute_forced/#c_4790018

[ComputerSays_noAbsolutelyNo]

Re: Brute forced?

Swiss-cheese model: https://en.wikipedia.org/wiki/Swiss_cheese_model

The layers of security

* Password: it can't be anybody, at least easily

* Rate-limiting failed log-ins: rule out automated brute-force attacks

* 2FA of any description: reduce the population of possible attackers who might pull off a successful attack

Rate-limiting failed log-ins is such an easy measure, this should be mandatory for every service.

* There's no additional infrastructure required, as opposed to 2FA.

* There's no inconvenience to the user, they generally remember their passwords.

* There's nothing speaking against rate-limiting failed log-ins, is there?

[doublelayer]

Re: Brute forced?

I generally try to be generous with the number of incorrect attempts before it locks, but always have that feature enabled. I may give the user ten tries to guess, because it lets them try a password, try it again because maybe they mistyped it, try it with a simple character swap, try a different password because they might have been mistaken, etc. Three attempts can make things annoying for users. There is no excuse for leaving this out, though.

[Michael Wojcik]

Re: Brute forced?

RESTful scale-out architectures complicate rate-limiting, because it means you have to keep additional state across the server farm for failed logins. It can be done, but for a widely scaled-out, eventually-consistent system, granularity is going to be very large indeed.

Even on a single-machine system with multiple worker processes it can be cumbersome to implement rate limiting without introducing significant overhead due to serialization.

[TheFifth]

Re: Brute forced?

This is the first thing I thought about. I spend a lot of time developing web apps for businesses and one of the first things I implement is rate limiting against brute force attacks. It seems mad that Twitter doesn't have some form of automated system to detect them.

I understand that with a service the size of Twitter, it must be constantly receiving incorrect login attempts and password 'guesses' for high profile accounts, but surely a brute force attack that successfully cracked a password must have been battering the server for it to be possible in any sort of reasonable time?

[doublelayer]

Re: Brute forced?

It depends how many options you go through and how many nodes you test from. A truly random 20-character password would be hard, but a predictable 20-character password is less difficult. This is why they usually block people from doing brute force attacks, but that either wasn't in place or didn't work in this case.

[LybsterRoy]

Re: Brute forced?

-- A truly random 20-character password would be hard, --

Nope it will be pretty easy - who the hell can remember a random 20-character password - it would be written down - just search the obvious places - start with post it note

[MiguelC]

Re: Brute forced?

If only someone could invent some kind of password vault.... (hint, not online ones)

[I am David Jones]

Deary me

Is there any less useful claim than “up to 100%”? Terrible that they may not block attacks that do not exist ;)

Not to mention, signing a transaction for free crypto??? Was it offered by a Nigerian??

[Michael Wojcik]

Re: Deary me

signing a transaction for free crypto

"Airdrops" are, apparently, a Thing; it's a way to get a new token into play. At least that's what I understand from reading Molly White's site. I won't waste my time on cryptocurrency.

[Norfolk N Chance]

Re: Deary me

"These phishing pages lure users into connecting their wallets to receive what they believe is free crypto, only to have it drained after signing a transaction.”

I've read that 3 times now, but it still sounds like "Hey stranger, pass me your wallet and I'll put some free money in it".

Have I just woken up in some alternative universe?

[Andrew Hodgkinson]

No, that's not the natural reaction!

The natural reaction to this would be to ask why two/multi-factor authentication didn't prevent this from taking place.

Utterly wrong.

The natural reaction to this would be to ask why the account wasn't locked after a small number of wrong password entries along with an intentional few seconds of sleep time for every wrong password entry, to make brute force attempts impractical even without auto-lock.

THAT is the first line of defence against hijacking. 2FA is a secondary line but both must always be present.

[LybsterRoy]

Re: No, that's not the natural reaction!

Actually my natural reaction was to think "this is X - who cares"