S3 Ep122: Stop calling every breach “sophisticated”! [Audio + Text]

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

---

DOUG.  Patching bugs, hacking Reddit, and the early days of computing.

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

[MUSICAL MODEM]

Welcome to the podcast, everybody.

I am Doug Aamoth.

He is Paul Ducklin.

Paul, how do you do?

---

DUCK.  Very well, Douglas.

---

DOUG.  Alright, I have an exciting This Week in Tech History segment for you today.

If this were a place in the world, it would be Rome, from where all civilisation began.

Sort of.

It’s arguable.

Anyhow…

---

DUCK.  Yes, that is definitely arguable! [LAUGHS]

---

DOUG.  [LAUGHS] This week, on 14 February 1946, ENIAC, or Electronic Numerical Integrator and Computer, was unveiled.

One of the earliest electronic general purpose computers, ENIAC filled an entire room, weighed 30 tonnes and contained 18,000 vacuum tubes, 70,000 resistors, 10,000 capacitors, and around 5 million hand-soldered joints.

ENIAC was used for a variety of calculations, including artillery shell trajectories, weather predictions, and thermonuclear weapons research.

It paved the way for commercially viable electronic computers, Paul.

---

DUCK.  Yes, it did!

The huge irony, of course, is that we British got there first, with the Colossus during the Second World War, at Bletchley Park.

And then, in a fit of amazing governmental wisdom, we decided to: [A] smash them all into tiny pieces, [B] burn all the documentation ([QUIETLY] though some of it survived), and [C] keep the fact that we had used thermionic valves to build fast electronic digital computers secret.

[PAUSE] What a silly thing to do… [LAUGHS]

Colossus – the first electronic digital computer

---

DOUG.  [AMAZED] Why would they do that?

---

DUCK.  [TRAGIC] Aaaaargh, I don’t know.

In the US, I believe, at the time of ENIAC, it was still not clear whether electromechanical relays or thermionic valves (vacuum tubes) would win out, because vacuum tubes were zillions of times faster…

…but they were hot, they used vast amounts of power, and they tended to blow randomly, which stopped the computer working, et cetera, et cetera.

But I think it was ENIAC that finally sealed the fate of all the electromechanical computers.

---

DOUG.  Speaking of things that have been around for a while…

..Reddit says that it was hacked thanks to a sophisticated phishing attack that, it turns out, wasn’t all that sophisticated.

Which might be the reason it works so well, ironically.

Reddit admits it was hacked and data stolen, says “Don’t panic”

---

DUCK.  [LAUGHS] I’m glad you said that rather than me, Doug!

But, yes, I think you’re right.

Why is it that so many senior execs who write breach notifications feel obliged to sneak the word “sophisticated” in there? [LAUGHS]

The whole thing about phishing attacks is that they’re *not* sophisticated.

They *aren’t* something that automatically sets alarm bells ringing.

---

DOUG.  Reddit says:

As in most phishing campaigns, the attacker sent out plausible-sounding prompts pointing employees to a website that cloned the behavior of our intranet gateway in an attempt to steal credentials and second-factor tokens. After successfully obtaining a single employee’s credentials, the attacker gained access to internal docs, code…

So that’s where it gets simple: trick one person into clicking on a link, getting taken to a page that looks like one of your systems, and handing over a 2FA code.

---

DUCK.  And then they were able to jump in, grab the stuff and get out.

And so, like in the LastPass breach and the recent GitHub breach, source code got stolen, along with a bit of other stuff.

Although that’s a good sign, inasmuch as it’s Reddit’s stuff that got stolen and not its users’ stuff (so it’s their problem to wrestle with, if you know what I mean)… we do know that inamongst that stuff, even if you only get source code, let alone internal documentation, there may be hints, scripts, tokens, server names, RESTy API endpoints, et cetera, that an attacker could use later.

But it does look as though the Reddit service itself, in other words the infrastructure behind the service, was not directly affected by this.

So, the crooks got in and they got some stuff and they got out, but it wasn’t like they broke into the network and then were able to wander around all the other places.

---

DOUG.  Reddit does offer three pieces of advice, two-thirds of which we agree with.

We’ve said countless times on the show before: Protect against phishing by using a password manager, because it makes it harder to put the right password into the wrong site.

Turn on 2FA if you can, so you have a second factor of authentication.

This one, though, is up for debate: Change your passwords every two months.

That might be a bridge too far, Paul?

---

DUCK.  Yes, Chester Wisniewski and I did a podcast (when was it? 2012?) where we busted that myth.

And NIST, the US National Institute of Standards and Technology, agrees with us.

It *is* a bridge too far, because it’s change for change’s sake.

And I think there are several problems with just, “Every two months, I’ll change my password.”

Firstly, why change your password if you genuinely don’t think there’s any reason to?

You’re just wasting your time – you could spend that time doing something that directly and genuinely improves your cybersecurity.

Secondly, as Chester put it in that old podcast (which we’ve put in the article, so you can go and listen to it), “It kind-of gets people into the habit of a bad habit,” because you’re trying to program their attitudes to passwords instead of embracing randomness and entropy.

And, thirdly, I think it leads people to thinking, “You know what, I should change my password, but I’m going to change them all in six weeks’ time anyway, so I’ll leave it until then.”

I would rather have an approach that says, “When you think you need to change your password, *do it in five minutes*.”

---

BUSTING PASSWORD MYTHS

Even though we recorded this podcast more than a decade ago, the advice it contains is still relevant and thoughtful today. We haven’t hit the passwordless future yet, so password-related cybersecurity advice will be valuable for a good while yet. Listen here, or click through for a full transcript.

---

DOUG.  There is a certain irony here with recommending the use of a password manager…

…when it’s pretty clear that this employee wouldn’t have been able to log into the fake site had he or she been using a password manager.

---

DUCK.  Yes, you’d think so, wouldn’t you?

Because it would just go, “Never heard of the site, can’t do it, don’t have a password.”

And you’d be going, “But it looks so right.”

Computer: “No, never heard of it.”

---

DOUG.  And then, once you’ve logged into a bogus site, 2FA does no good if you’re just going to enter the code into a form on the bogus site that gets sent to the crook!

---

DUCK.  If you’re planning to use 2FA as an excuse for being more casual about security, either [A] don’t do that, or [B] choose a two-factor authentication system that doesn’t rely simply on transcribing digits from your phone onto your laptop.

Use a token-based system like OAuth, or something like that, that is more sophisticated and somewhat harder for the crooks to subvert simply by getting you to tell them the magic digits.

---

DOUG.  Let’s stay on the irony theme.

GnuTLS had a timing flaw in the code that was supposed to log timing attack errors.

How do you like that?

Serious Security: GnuTLS follows OpenSSL, fixes timing attack bug

---

DUCK.  [LAUGHS] They checked to see whether something went wrong during the RSA session setup process by getting this variable called ok.

It’s TRUE if it’s OK, and it’s FALSE if it’s not.

And then they have this code that goes, “If it’s not OK, then report it, if the person’s got debugging turned on.”

You can see the programmer has thought about this (there’s even a comment)…

If there’s no error, then do a pretend logging exercise that isn’t really logging, but let’s try and use up exactly the same amount of time, completely redundantly.

Else if there was an error, go and actually do the logging.

But it turns out that either there wasn’t sufficient similarity between the execution of the two paths, or it could have been that the part where the actual logging was happening responded in a different amount of time depending on the type of error that you deliberately provoked.

It turns out that by doing a million or more deliberately booby-trapped, “Hey, I want to set up a session request,” you could basically dig into the session setup in order to retrieve a key that would be used later for future stuff.

And, in theory, that might let you decrypt sessions.

---

DOUG.  And that’s where we get the term “oracle bug” (lowercase oracle, not to be confused with the company Oracle).

You’re able to see things that you shouldn’t be able to see, right?

---

DUCK.  You essentially get the code to give you back an answer that doesn’t directly answer the question, but gives you some hints about what the answer might be.

You’re letting the encryption process give away a little bit about itself each time.

And although it sounds like, “Who could ever do a million extra session setup requests without being spotted?”…

…well, on modern networks, a million network packets is not actually that much, Doug.

And, at the end of it, you’ve actually learned something about the other end, because its behaviour has just not been quite consistent enough.

Every now and then, the oracle has given away something that it was supposed to keep secret.

---

DOUG.  Alright, we’ve got some advice about how to update if you’re a GnuTLS user, so you can head over to the article to check that out.

Let’s talk about “Happy Patch Tuesday”, everybody.

We’ve got a lot of bugs from Microsoft Patch Tuesday, including three zero-days.

Microsoft Patch Tuesday: 36 RCE bugs, 3 zero-days, 75 CVEs

---

DUCK.  Yes, indeed, Doug.

75 CVEs, and, as you say, three of them are zero-days.

But they’re only rated Important, not Critical.

In fact, the critical bugs, fortunately, were, it seems, fixed responsibly.

So it wasn’t that there’s an exploit already out there in the wild.

I think what’s more important about this list of 75 CVEs is that almost half of them are remote code execution bugs.

Those are generally considered the most serious sorts of bug to worry about ,because that’s how crooks get in in the first place.

Then comes EoP (elevation of privilege), of which there are several, including one of them being a zero-day… in the Windows Common Log File System driver

Of course, RCEs, remote code executions, are often paired up by cybercriminals with elevation of privilege bugs.

They use the first one to break in without needing a password or without having to authenticate.

They get to implant code that then triggers the elevation of privilege bug, so not only do they go *in*, they go *up*.

And typically they end up either as a sysadmin (very bad, because then they’re basically free to roam the network), or they end up with the same privilege as the local operating system… on Windows, what’s called the SYSTEM account (which pretty much means they can do anything on that computer).

---

DOUG.  There are so many bugs in this Patch Tuesday that it forced your hand to devote a section of this article called Security Bug Classes Explained…

…which I would deem to be required reading if you’re just getting into cybersecurity and want to know what types of bugs are out there.

So we talked about an RCE (remote code execution), and we talked about EoP (elevation of privilege).

You next explained what a Leak is…

---

DUCK.  Indeed.

Now, in particular, memory leaks can obviously be bad if what’s leaking is, say, a password or the entire contents of a super-secret document.

But the problem is that some leaks, to someone who’s not familiar with cybersecurity, sound really unimportant.

OK, so you leaked a memory address of where such-and-such a DLL or such-and-such a kernel driver just happened to be loaded in memory?

How bad is that?

But the problem is that remote code execution exploits are generally much easier if you know exactly where to poke your knitting needle in memory on that particular server or that particular laptop.

Because modern operating systems almost all use a thing called ASLR (address space layout randomisation), where they deliberately load programs, and DLLs, and shared libraries, and kernel drivers and stuff at randomly chosen memory addresses…

…so that your memory layout on your test computer, where your exploit worked perfectly, will not be the same as mine.

And it’s much harder to get an exploit to work generically when you have this randomness built into the system than when you don’t.

So there are some tiny little memory leaks, where you might just leak eight bytes of memory (or even just four bytes if it’s a 32-bit system) where you give away a memory address.

And that is all the crooks need to turn an exploit that might just work, if they’re really lucky, into one which they can abuse every single time, reliably.

So be careful of leaks!

---

DOUG.  Please tell us what a Bypass means.

---

DUCK.  It sort-of means exactly what it says.

You’ve got a security precaution that you expect the operating system or your software to kick in with.

For example, “Hey, are you really sure that you want to open this dastardly attachment that came in in an email from someone you don’t know?”

If the crooks can find a way to do that bad behaviour but to bypass the security check that’s supposed to kick in and give you a fighting chance to be a well-informed user doing the right thing…

…believe me, they will take it.

So, security bypasses can be quite problematic.

---

DOUG.  And then along those lines, we talked about Spoofing.

In the Reddit story, luring someone to a website that looks like a legit website but isn’t – it’s a spoof site.

And then, finally, we’ve got DoS, or denial of service.

---

DUCK.  Well, that’s exactly what it says.

It’s where you stop something that is supposed to work on the victim’s computer from doing its job.

You kind-of think, “Denial of service, it should be at the bottom of the list of concerns, because who really cares? We’ve got auto-restart.”

But if the crooks can pick the right time to do it (say, 30 seconds after your server that crashed two minutes ago has just come back up),then they may actually be able to use a denial of service bug surprisingly infrequently to cause what amounts to almost a continuous outage for you.

And you can imagine: [A] that could actually cost you business if you rely on your online services being up, and [B] it can make a fascinating smokescreen for the crooks, by creating this disruption that lets the crooks come steaming in somewhere else.

---

DOUG.  And not content to be left out of the fun, Apple has come along to fix a zero-day remote code execution bug.

Apple fixes zero-day spyware implant bug – patch now!

---

DUCK.  This bug, and I’ll read out the CVE just for reference: it is CVE-2023-23529…

…is a zero-day remote code execution hole in WebKit, which I for one, and I think many other people infer to mean, “Browser bug that can be triggered by code that’s supplied remotely.”

And of course, particularly in iPhones and iPads, as we’ve spoken about many times, WebKit is required code for every single browser, even ones that don’t use WebKit on other platforms.

So it kind-of smells like, “We found out about this because there’s some spyware going around,” or, “There’s a bug that can be used to jailbreak your phone and remove all the strictures that let the crooks in and let them wander around at will.”

Obviously, on a phone, that’s something you definitely don’t want.

---

DOUG.  Alright, and on this story, Naked Security reader Peter writes:

I try to update as soon as I’ve seen your update alerts in my inbox. While I know little to nothing about the technical issues involved, I do know it’s important to keep software updated, and it’s why I have the automatic software update option selected on all my devices. But it’s seldom, if ever, that I receive software alerts on my iPhone, iPad or MacBook before receiving them from Sophos.

So, thanks, guys!

That’s nice!

---

DUCK.  It is!

And I can only reply by saying, “Glad to be of assistance.”

I quite like writing those articles, because I think they provide a decent service.

Better to know and be prepared than to be caught unawares… that is my opinion.

---

DOUG.  And not to show how the sausage is made around here too much, but the reason Paul is able to jump on these Apple updates so quickly is because he has a big red siren in his living room that’s connected via USB cable to his computer, and checks the Apple security update page every six seconds.

So it starts blaring the second that page has been updated, and then he goes and writes it up for Naked Security.

---

DUCK.  [LAUGHS] I think the reason is probably just that I tend to go to bed quite late.

---

DOUG.  [LAUGHS] Exactly, you don’t sleep…

---

DUCK.  Now I’m big, I don’t have a fixed bedtime.

I can stay up as late as I want! [LAUGHTER]

---

DOUG.  Alright, thank you, Peter, 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]