S3 Ep123: Crypto company compromise kerfuffle [Audio + Text]

Click-and-drag on the soundwaves below to skip to any point. You can also listen directly on Soundcloud.

DOUG. Crypto company code captured, Twitter’s pay-for-2FA play, and GoDaddy breached.

All that, and more, on the Naked Security podcast.

[MUSICAL MODEM]

Welcome to the podcast, everybody.

I am Doug Aamoth; he is Paul Ducklin

And it is episode 123, Paul.

We made it!

DUCK. We did!

Super, Doug!

I liked your alliteration at the beginning…

DOUG. Thank you for that.

And you’ve got a poem coming up later – we’ll wait with bated breath for that.

DUCK. I love it when you call them poems, Doug, even though they really are just doggerel.

But let’s call it a poem…

DOUG. Yes, let’s call it a poem.

DUCK. All two lines of it… [LAUGHS]

DOUG. Exactly, that’s all you need.

As long as it rhymes.

Let’s start with our Tech History segment.

This week, on 19 February 1971, what is believed to be the first warrant in the US to search a computer storage device was issued.

Evidence of theft of trade secrets led to the search of computer punch cards, computer printout sheets, and computer memory bank and other data storage devices magnetically imprinted with the proprietary computer program.

The program in question, a remote plotting program, was valued at $15,000, and it was ultimately determined that a former employee who still had access to the system had dialled in and usurped the code, Paul.

DUCK. I was amazed when I saw that, Doug, given that we’ve spoken recently on the podcast about intrusions and code thefts in many cases.

What was it… LastPass? GoDaddy? Reddit? GitHub?

It really is a case of plus ça change, plus c’est la même chose, isn’t it?

They even recognised, way back then, that it would be prudent to do the search (at least of the office space) at night, when they knew that the systems would be running but the suspect probably wouldn’t be there.

And the warrant actually states that “experts have made us aware that computer storage can be wiped within minutes”.

DOUG. Yes, it’s a fascinating case.

This guy that went and worked for a different company, still had access to the previous company, and dialled into the system, and then accidentally, it seems, printed out punch cards at his old company while he was printing out paper of the code at his new company.

And the folks at the old company were like, “What’s going on around here?”

And then that’s what led to the warrant and ultimately the arrest.

DUCK. And the other thing I noticed, reading through the warrant, that the cop was able to put in there…

…is that he had found a witness at the old company who confirmed that this chap who’d moved to the new company had let slip, or bragged about, how he could still get in.

So it has all the hallmarks of a contemporary hack, Doug!

[A] the intruder made a blunder which led to the attack being spotted, [B] didn’t cover his tracks well enough, and [C] he’d been bragging about his haxxor skills beforehand. [LAUGHS]

As you say, that ultimately led to a conviction, didn’t it, for theft of trade secrets?

Oh, and the other thing of course, that the victim company didn’t do is…

…they forgot to close off access to former staff the day they left.

Which is still a mistake that companies make today, sadly.

DOUG. Yes.

Aside from the punch cards, this could be a modern day story.

DUCK. Yes!

DOUG. Well, let’s bring things into the modern, and talk about GoDaddy.

It has been hit with malware, and some of the customer sites have been poisoned.

This happened back in December 2022.

They didn’t come out and say in December, “Hey, this is happening.”

GoDaddy admits: Crooks hit us with malware, poisoned customer websites

DUCK. Yes, it did seem a bit late, although you could say, “Better late than never.”

And not so much to go into bat for GoDaddy, but at least to explain some of the complexity of looking into this…

… it seems that the malware that was implanted three months ago was designed to trigger intermittent changes to the behaviour of customers’ hosted web servers.

So it wasn’t as though the crooks came in, changed all the websites, made a whole load of changes that would show up in audit logs, got out, and then tried to profit.

It’s a little bit more like what we see in the case of malvertising, which is where you poison one of the ad networks that a website relies on, for some of the content that it sometimes produces.

That means every now and then someone gets hit up with malware when they visit the site.

But when researchers go back to have a look, it’s really hard for them to reproduce the behaviour.

[A] it doesn’t happen all the time, and [B] it can vary, depending on who you are, where you’re coming from, what browser you’re using…

…or even, of course, if the crooks recognise that you’re probably a malware researcher.

So I accept that it was tricky for GoDaddy, but as you say, it might have been nice if they had let people know back in December that there had been this “intermittent redirection” of their websites.

DOUG. Yes, they say the “malware intermittently redirected random customer websites to malicious sites”, which is hard to track down if it’s random.

But this wasn’t some sort of really advanced attack.

They were redirecting customer sites to other sites where the crooks were making money off of it…

DUCK. [CYNICAL] I don’t want to disagree with you, Doug, but according to GoDaddy, this may be part of a multi-year campaign by a “sophisticated threat actor”.

DOUG. [MOCK ASTONISHED] Sophisticated?

DUCK. So the S-word got dropped in there all over again.

All I’m hoping is that, given that there’s not much we can advise people about now because we have no indicators of compromise, and we don’t even know whether, at this remove, GoDaddy has been able to come up with what people could go and look for to see if this happened to them…

…let’s hope that when their investigation, that they’ve told the SEC (Securities and Exchange Commission) they’re still conducting); let’s hope that when that finishes, that there’ll be a bit more information and that it won’t take another three months.

Given not only that the redirects happened three months ago, but also that it looks as though this may be down to essentially one cybergang that’s been messing around inside their network for as much as three years.

DOUG. I believe I say this every week, but, “We will keep an eye on that.”

All right, more changes afoot at Twitter.

If you want to use two-factor authentication, you can use text messaging, you can use an authenticator app on your phone, or you can use a hardware token like a Yubikey.

Twitter has decided to charge for text-messaging 2FA, saying that it’s not secure.

But as we also know, it costs a lot to send text messages to phones all over the world in order to authenticate users logging in, Paul.

Twitter tells users: Pay up if you want to keep using insecure 2FA

DUCK. Yes, I was a little mixed up by this.

The report, reasonably enough, says, “We’ve decided, essentially, that text-message based, SMS-based 2FA just isn’t secure enough”…

…because of what we’ve spoken about before: SIM swapping.

That’s where crooks go into a mobile phone shop and persuade an employee at the shop to give them a new SIM, but with your number on it.

So SIM swapping is a real problem, and it’s what caused the US government, via NIST (the National Institute of Standards and Technology), to say, “We’re not going to support this for government-based logins anymore, simply because we don’t feel we’ve got enough control over the issuing of SIM cards.”

Twitter, bless their hearts (Reddit did it five years ago), said it’s not secure enough.

But if you buy a Twitter Blue badge, which you’d imagine implies that you’re a more serious user, or that you want to be recognised as a major player…

…you can keep on using the insecure way of doing it.

Which sounds a little bit weird.

So I summarised it in the aforementioned poem, or doggerel, as follows:

    Using texts is insecure       for doing 2FA.     So if you want to keep it up,       you're going to have to pay.  

DOUG. Bravo!

DUCK. I don’t quite follow that.

Surely if it’s so insecure that it’s dangerous for the majority of us, even lesser users whose accounts are perhaps not so valuable to crooks…

…surely the very people who should at least be discouraged from carrying on using SMS-based 2FA would be the Blue badge holders?

But apparently not…

DOUG. OK, we have some advice here, and it basically boils down to: Whether or not you pay for Twitter Blue, you should consider moving away from text-based 2FA.

Use a 2FA app instead.

DUCK. I’m not as vociferously against SMS-based 2FA as most cybersecurity people seem to be.

I quite like its simplicity.

I like the fact that it does not require a shared secret that could be leaked by the other end.

But I am aware of the SIM-swapping risk.

And my opinion is, if Twitter genuinely thinks that its ecosystem is better off without SMS-based 2FA for the vast majority of people, then it should really be working to get *everybody* off 2FA…

…especially including Twitter Blue subscribers, not treating them as an exception.

That’s my opinion.

So whether you’re going to pay for Twitter Blue or not, whether you already pay for it or not, I suggest moving anyway, if indeed the risk is as big as Twitter makes out to be.

DOUG. And just because you’re using app-based 2FA instead of SMS-based 2FA, that does not mean that you’re protected against phishing attacks.

DUCK. That’s correct.

It’s important to remember that the greatest defence you can get via 2FA against phishing attacks (where you go to a clone site and it says, “Now put in your username, your password, and your 2FA code”) is when you use a hardware token-based authenticator… like, as you said, a Yubikey, which you have to go and buy separately.

The idea there is that that authentication doesn’t just print out a code that you then dutifully type in on your laptop, where it might be sent to the crooks anyway.

So, if you’re not using the hardware key-based authentication, then whether you get that magic six-digit code via SMS, or whether you look it up on your phone screen from an app…

…if all you’re going to do is type it into your laptop and potentially put it into a phishing site, then neither app-based nor SMS-based 2FA has any particular advantage over the other.

DOUG. Alright, be safe out there, people.

And our last story of the day is Coinbase.

Another day, another cryptocurrency exchange breached.

This time, by some good old fashioned social engineering, Paul?

Coinbase breached by social engineers, employee data stolen

DUCK. Yes.

Guess what came into the report, Doug?

I’ll give you a clue: “I spy, with my little eye, something beginning with S.”

DOUG. [IRONIC] Oh my gosh!

Was this another sophisticated attack?

DUCK. Sure was… apparently, Douglas.

DOUG. [MOCK SHOCKED] Oh, my!

DUCK. As I think we’ve spoken about before on the podcast, and as you can see written up in Naked Security comments, “‘Sophisticated’ usually translates as ‘better than us’.”

Not better than everybody, just better than us.

Because, as we pointed out in the video for last week’s podcast, no one wants to be seen as the person who fell for an unsophisticated attack.

But as we also mentioned, and as you explained very clearly in last week’s podcast, sometimes the unsophisticated attacks work…

…because they just seem so humdrum and normal that they don’t set off the alarm bells that something more diabolical might.

The nice thing that Coinbase did is they did provide what you might call some indicators of compromise, or what are known as TTPs (tools, techniques and procedures) that the crooks followed in this attack.

Just so you can learn from the bad things that happened to them, where the crooks got in and apparently had a look around and got some source code, but hopefully nothing further than that.

So firstly: SMS based phishing.

You get a text message and it has a link in the text message and, of course, if you click it on your mobile phone, then it’s easier for the crooks to disguise that you’re on a fake site because the address bar is not so clear, et cetera, et cetera.

It seemed that that bit failed because they needed a two-factor authentication code that somehow the crooks weren’t able to get.

Now, we don’t know…

…did they forget to ask because they didn’t realise?

Did the employee who got phished ultimately realise, “This is suspicious. I’ll put in my password, but I’m not putting in the code.”

Or were they using hardware tokens, where the 2FA capture just didn’t work?

We don’t know… but that bit didn’t work.

Now, unfortunately, that employee didn’t, it seems, call it in and tell the security team, “Hey, I’ve just had this weird thing happen. I reckon someone was trying to get into my account.”

So, the crooks followed up with a phone call.

They called up this person (they had some contact details for them), and they got some information out of them that way.

The third telltale was they were desperately trying to get this person to install a remote access program on their say so.

DOUG. [GROAN]

DUCK. And, apparently, the programs suggested were AnyDesk and ISL Online.

It sounds as though the reason they tried both of those is that the person must have baulked, and in the end didn’t install either of them.

By the way, *don’t do that*… it’s a very, very bad idea.

A remote access tool basically bumps you out of your chair in front of your computer and screen, and plops the attacker right there, “from a distance.”

They move their mouse; it moves on your screen.

They type at their keyboard; it’s the same as if you were typing at your keyboard while logged in.

And then the last telltale that they had in all of this is presumably someone trying to be terribly helpful: “Oh, well, I need to investigate something in your browser. Could you please install this browser plugin?”

Whoa!

Alarm bells should go off there!

In this case, the plugin they wanted is a perfectly legitimate plug in for Chrome, I believe, called “Edit This Cookie”.

And it’s meant to be a way that you can go in and look at website cookies, and website storage, and delete the ones that you don’t want.

So if you go, “Oh, I didn’t realise I was still logged into Facebook, Twitter, YouTube, whatever, I want to delete that cookie”, that will stop your browser automatically reconnecting.

So it’s a good way of keeping track of how websites are keeping track of you.

But of course it’s designed so that you, the legitimate user of the browser, can basically spy on what websites are doing to try and spy on you.

But if a *crook* can get you to install that, when you don’t quite know what it’s all about, and they can then get you to open up that plugin, they can get a peek at your screen (and take a screenshot if they’ve got a remote access tool) of things like access tokens for websites.

Those cookies that are set because you logged in this morning, and the cookie will let you stay logged in for the whole day, or the whole week, sometimes even a whole month, so you don’t have to log in over and over again.

If the crook gets hold of one of those, then any username, password and two-factor authentication you have kind-of goes by the board.

And it sounds like Coinbase were doing some kind of XDR (extended detection response).

At least, they claimed that someone in their security team noticed that there was a login for a legitimate user that came via a VPN (in other words, disguising your source) that they would not normally expect.

“That could be right, but it kind-of looks unusual. Let’s dig a bit further.”

And eventually they were actually able to get hold of the employee who’d fallen for the crooks *while they were being phished, while they were being socially engineered*.

The Coinbase team convinced the user, “Hey, look, *we’re* the good guys, they’re the bad guys. Break off all contact, and if they try and call you back, *don’t listen to them anymore*.”

And it seems that that actually worked.

So a little bit of intervention goes an awful long way!

DOUG. Alright, so some good news, a happy ending.

They made off with a little bit of employee data, but it could have been much, much worse, it sounds like?

DUCK. I think you’re right, Doug.

It could have been very much worse.

For example, if they got loads of access tokens, they could have stolen more source code; they could have got hold of things like code-signing keys; they could have got access to things that were beyond just the development network, maybe even customer account data.

They didn’t, and that’s good.

DOUG. Alright, well, let’s hear from one of our readers on this story.

Naked Security reader Richard writes:

Regularly and actively looking for hints that someone is up to no good in your network doesn’t convince senior management that your job is needed, necessary, or important.

Waiting for traditional cybersecurity detections is tangible, measurable and justifiable.

What say you, Paul?

DUCK. It’s that age-old problem that if you take precautions that are good enough (or better than good enough, and they do really, really well)…

…it kind-of starts undermining the arguments that you used for applying those precautions in the first place.

“Danger? What danger? Nobody’s fallen over this cliff for ten years. We never needed the fencing after all!”

I know it’s a big problem when people say, “Oh, X happened, then Y happened, so X must have caused Y.”

But it’s equally dangerous to say, “Hey, we did X because we thought it would prevent Y. Y stopped happening, so maybe we didn’t need X after all – maybe that’s all a red herring.”

DOUG. I mean, I think that XDR and MDR… those are becoming more popular.

The old “ounce of prevention is worth a pound of cure”… that might be catching on, and making its way upstairs to the higher levels of the corporation.

So we will hopefully keep fighting that good fight!

DUCK. I think you’re right, Doug.

And I think you could argue also that there may be regulatory pressures, as well, that make companies less willing to go, “You know what? Why don’t we just wait and see? And if we get a tiny little breach that we don’t have to tell anyone about, maybe we’ll get away with it.”

I think people are realising, “It’s much better to be ahead of the game, and not to get into trouble with the regulator if something goes wrong, than to take unnecessary risks for our own and our customers’ business.”

That’s what I hope, anyway!

DOUG. Indeed.

And thank you very much, Richard, for sending that in.

If you have an interesting story, comment or question you’d like to submit, we’d love to read it on the podcast.

You can email tips@sophos.com, you can comment on any one of our articles, or you can hit us up on social: @NakedSecurity.

That’s our show for today; thanks very much for listening.

For Paul Ducklin, I’m Doug Aamoth, reminding you until next time to…

BOTH. Stay secure!

[MUSICAL MODEM]