With Doug Aamoth and Paul Ducklin.
DOUG. Data breach fines.
Macros.
And leisurely bug fixes… all that, and more, on the Naked Security Podcast.
[MUSICAL MODEM]
Welcome to the podcast, everybody.
I am Doug Aamoth, and he is Paul Ducklin.
Paul, how do you do?
DUCK. I’m very well, Douglas.
Not that you’re ever unchipper… but that was a super-upbeat introduction, Doug!
I’m guessing you’ve got a very excellent Fun Fact/Tech Tip coming up.
DOUG. It’s true… thank you for the segue! [LAUGHTER]
Let’s talk about This Week in Tech History.
This week, in 1963, Syncom 2, which is short for Synchronous Communications Satellite, was launched into geosynchronous orbit, facilitating the first satellite-based phone call and one of the first satellite TV transmissions.
Syncom 2 was also used by NASA for voice, teletype and fax testing.
Syncom 1 launched a few months earlier and made it into orbit as well, but an electronics failure rendered it inoperable.
Can you imagine sending Sycnom 1 up there and going, “Oh, someone forgot to seat the RAM properly?”
DUCK. I believe that the payload was just 25kg!
I saw a picture of Syncom 2, and it looks like a giant space object out of a 1950s scifi movie…
…but apparently it was just 71cm in diameter.
It’s really, really tiny… what’s 71cm? Just over 2 feet?
And it could support one phone call – very low power – so it was just an experiment.
DOUG. We talked about an Office macro security feature that people were asking for for the better part of 20 years.
Microsoft turned it on, and then people commented that they didn’t like it.
So Microsoft turned it off, but said, “It will be back sometime.”
And now it’s back – that was quick!
DUCK. It was.
When we spoke about this last on the podcast, Doug, I was very upbeat about, “Yes, it’s coming back, but it’ll be a while.”
I was imagining maybe it would be a sort of Easter Egg for 2023 – a literal Easter Egg, you know, sometime in the Northern Hemisphere spring.
I was imagining, “It won’t be weeks;it’s probably going to be months.”
And how long was it? A couple of weeks!
DOUG.
Yes.
DUCK. So 20 years to turn it on, 20 weeks to turn it off and then just a couple of weeks to turn it back on.
So, good for Microsoft!
But if only, Doug, they had done it in 1998… that’s more than the better part of 20 years, that’s better than 20 years.
If they’d done it, say, the day before the Melissa virus came out, that would have been really handy, so that macros arriving over the internet would not have triggered unless you really wanted them to.
Although I imagine, in those days, it wouldn’t have been fully off.
There would have probably been a button [Allow anyway].
And the big deal here is that there is no more [Allow anyway] button.
So, it’s not that it warns you, “This is a bad idea. Do you want to hoist yourself by our own petard [Yes/Yes]?”
It’s just, “Sorry, macro came over the Internet. You can’t do that.”
DOUG. Did Microsoft change anything meaningfully between now and 20 days ago when they had to turn it back off?
DUCK. My understanding, Doug, is that the main thing they did – just reading this into what they wrote – is that they fulfilled their promise that they would document more clearly: how this worked, why it worked, and most importantly what you could do about it if you really wanted to have non-local or non-LAN servers that you treated as though they were local.
Because people go, “Oh, well, I’m a small biz, I use SharePoint, One drive, some cloud service, so I’ve got some random domain name that was issued to me… but to me that’s a local server, and that’s my trusted corporate repository for stuff.”
And so Microsoft now has some quite decent documentation saying, “Here’s how you can tell your users that a certain external server is to be treated as a trusted one.”
Although that *is* essentially an exclusion, and exclusions in cybersecurity can be dangerous, like people with their antivirus going, “Hey, it’s much faster if I exclude the C: drive. [LAUGHTER] Who knew?”
So you do need to be cautious, but it does mean that you then have a definitive list saying, “These are the servers that I actually trust, and I treat these as a place where people can go to get official work content.”
And that is very different from just relying on people not clicking the [Oh, go on then, she'll be right] button every time they get a macro from anywhere on the internet.
What Microsoft did is they went out and produced a document that is fairly easy to read and gives a number of ways of telling your company: “This is what we trust, and this is what we don’t.”
So, it’s a slightly more formal way of doing it than just relying on people not clicking the right button at the wrong time.
DOUG. OK, we have links to those two documents in the article which you can find on Naked Security.
It’s called: Office macro security: on-again-off-again feature now BACK ON AGAIN.
Hooray!
And then, moving right along to something that’s not so fun: T-Mobile had a big data breach in 2021 and they are now being ordered to cough up $500 million, which, after lawyer fees, shakes out to about $25 per victim.
DUCK. Yes, and it seems that half-a-billion dollars (wow, that’s a large amount!) is loosely split into two parts.
There’s $350,000,000 that is part of a class action lawsuit, which you have in the US… we don’t have those in the UK.
My understanding is a class action is where anybody can join in and say, “Oh, yes, I’m a customer.”
And the idea is… if you were to sue and you would only get $40 or $50 or $100, then it would be too risky to sue on your own, so you band together, “Power to the People”.
And the lawyers go after the big company on behalf of potentially millions of people.
So, it’s a $350,000,000 settlement for that.
Unfortunately, there are so many claimants that’s only $25 per person, after you take out the (gulp!) 30% of that… 105 million of your US dollars go to the lawyers.
The rest goes to the actual people who were T-Mobile’s customers.
But it does show that there aren’t zero consequences to a data breach.
And whether you like class actions or not, there is this sense that people do get injured when their data is breached, even if there’s no obvious connection between the breach and then suffering identity theft.
And then there’s another $150,000,000.
I don’t fully understand how this works in the US legal system, but my understanding is this is essentially a commitment from T-Mobile USA that they will spend that money on cybersecurity, whereas they might not have done so otherwise.
And if only they had seen cybersecurity as a value, not as a cost, beforehand!
If they’d invested the $150,000,000 upfront, they could probably have saved the $350,000,000… because they’re spending both those sums of money now anyway.
DOUG. So that’s probably the better part of the outcome here: that they’re being forced to spend on upgrading their security.
The $25 per person is great, whatever, but the earmarked money to upgrade their security is probably a good thing to come out of a bad situation.
DUCK. I’d say so, because that’s always the problem when you get a big fine of this sort, isn’t it, for not doing cybersecurity properly?
That’s money that now cannot be spent on cybersecurity because it’s gone elsewhere.
I guess the flip side of that is that you can’t just say, “Well, wait till you have a data breach and then there’ll be a massive penalty, but you get to spend it on cybersecurity anyway”, because that’s almost inviting people to delay until they’re forced to do it.
So, I can see the point that there’s the carrot part and there’s the stick part.
Together, half-a-billion dollars!
And to all the people who like to say, “Oh, well, for a multi-billion dollar company, that’s chump change”…
Really?
Sounds like a lot of money to me!
I guess if you’re a shareholder, you probably have a different view of just how chump-changy $500 million is.
It’s a reminder that data breaches aren’t something that you suffer, and you report, and you get shouted at, and you get a nasty report sent to you, but doesn’t cost you anything.
And like I said – and I know that working for a cyber security company, I would say this, but I’m saying it because I think it’s true, not just because I’ve got something to sell you…
You really need to think of cybersecurity as a *value*, because customers are increasingly expecting to find that as part of what they consider the package.
My take on this is I probably wouldn’t have joined the class action suit, but I would very strongly consider taking my business elsewhere, as a different way of proving the point.
DOUG. Well, we’ll keep an eye on that.
That is: T-Mobile to cough up $500 million over 2021 data breach, on nakedsecurity.sophos.com.
And we move right along to Apple patching a zero-day browser bug that we talked about from the Pwn2Own contest.
So, a little bit laggy as far as the patch goes, but we don’t know how bad it actually was on Apple’s side of the fence.
DUCK. In fact, there were two browser related bugs fixed in the latest slew of Apple updates, which in Apple’s traditional way are kind of like Microsoft Patch Tuesday in that they cover all possible Apple devices: tvOS Watch, OS, iOS, iPadOS, Mac OS, etc.
But, unlike patch Tuesday, they come when they feel like it… snd I think this one was actually on a Thursday, if I remember, so it wasn’t even on a Tuesday, it just arrived.
Now, Safari is patched by Apple in the operating system update for all supported operating systems except the previous and pre-previous versions of macOS, where you actually need to get *two* updates, one for the OS and one for Safari.
So, Safari goes to version 15.6.
And what’s interesting is it’s not just that Pwn2Own zero-day, where Mozilla famously patched the equivalent bug in Firefox within two days of finding out about it at Pwn2Own…
If you remember, the same chap, Manfred Paul, a German hacker, poned Firefox in a sort of double pwnage for $100,000 and he pwned Safari for $50,000.
Mozilla patched their bug or bugs within two days, if you remember.
But Apple took a couple of months to get round to theirs!
It was disclosed responsibly, of course, so we don’t know how likely it was that anyone else would find it.
But the other bug that was fixed in Safari was apparently the same flaw that emerged as that zero-day in Chrome we talked about on the podcast not too long ago, I think it was a couple of weeks ago.
That bug that was found in the wild by a security company that was investigating some suspicious behaviour that a customer had reported to them.
As sometimes happens with Managed Threat Response… you’re looking around, and you can see all the symptoms and the side effects of what the crooks have been doing, and you think, “Where did it start?”
And sometimes it’s obvious, “Oh, they logged in because you had a silly password, or they logged in because you’d forgotten to patch this, that or the other server.”
And occasionally you can’t quite work it out, but you might get lucky and stumble across what looks like a weird web page,: “Oh my golly, I found a zero-day in the browser!”
And then it’s a good guess that either a very niche group of cybercrooks have got it, or one of those so-called lawful spyware companies – the people who do the government interception stuff have found, and they’re using it in a targeted way.
That was the zero-day in Chrome, and Chrome fixed it.
Turns out that the same bug, it seems, was in WebKit – Apple’s code – and they took another two weeks to fix it, and didn’t say they were working on it.
So, go figure.
But that makes this patch for Apple at least as important as any other we’ve spoken about.
And I know we always say, “Don’t delay/Do it today.”
But in this case, there’s one bug that we know somebody already found because they demonstrated it working 100% at Pwn2Own, two months ago; and there’s another bug that’s related to code that was fixed by Google in Chrome because somebody found it being used for surveillance purposes in the wild.
DOUG. It is interesting how you described the process by which Pwn2Own shows the actual contest, but they take steps to not actually show how the attacks work while the responsible disclosure process is going on.
DUCK. Yes, it’s quite amusing, if you watch the video of Manfred Paul pwning Firefox.
He obviously was very confident that whatever he’d put together was going to work.
So, the camera is pointing at his face, and the adjudicator’s face, and then you see the commentator kind of sticks his head and said, “Here we go, folks.”
And there’s a little timer – he’s got 30 minutes.
“Everyone ready?”
Yes, they’re ready… and all you can see is the back of two screens, one for the server and the client.
And then you see the adjudicator say, “OK, Go!”
The timer starts counting down, and Manfred Paul clicks a button – obviously, he’s got a little [Do it now] button in his browser window…
…and then you see everybody nodding as the timer clicks over to just 7 seconds!
So you know that it worked – you can just see on their faces.
To be fair, in this case of Apple taking their time, you have to come to Pwn2Own prepared.
You have to come with full details, so we don’t know how long it took Manfred Paul to put the attack together.
He could have been working on it for months, in which case saying, “Apple should have fixed it in two days”…
…well, maybe they could have, but maybe they felt they didn’t need to, given the complexity.
And perhaps they wanted to make sure, in testing, that the fix was going to work well.
Anyway, although Pwn2Own has a live video feed, that should not give enough hints for somebody to figure out anything about the actual vulnerability.
DOUG. We’ve got some instructions about how to update your iPhones, iPads and Macs over on the site.
And we round out the show with a two-pack of Firefox bugs.
DUCK. Yes, and the good news is that for the latest version of Firefox, there’s a total of eight CVE numbers, but two of those are CVE numbers that cover all the bugs of which you can say, “These could probably be exploited and we’re fixing them in bulk anyway, without actually going into the detail of finding out how you might exploit them.”
So,those are things that are found automatically, for example through fuzzing or the automated tools that probe for vulnerabilities that you might have to wait years and years to find by accident.
The other six bugs… none of those are rated even High.
They’re all Medium or lower, which is kind of good news.
Two of them I thought were worth calling out individually, and we’ve written these up on Naked Security because it’s a fascinating part of understanding what kind of bug-related security risks can exist in browsers.
It’s not just, “Oh, the cooks can run arbitrary code and implant malware.”
There are two bugs that relate to potentially allowing attackers to trick you into clicking something that looks safer than it is.
And one of them is, I guess, good old clickjacking, which is where you click on object X, but actually you activate object Y.
The mouse position on the screen and where the browser *thinks* it is can be tricked into diverging.
So, you move the mouse, and you click… but actually the click registers somewhere else on the screen.
You can see how that could be quite dangerous!
It doesn’t guarantee remote code execution, but you can imagine: an ad fraudster would love that, wouldn’t they?
They get you to click on, “No, I definitely want to decline,” and in fact, you’d be racking up clicks saying, “Yes, I really want to view this ad.”
And it also means that for things like phishing attacks and fake downloads, you can make a download look legit when in fact the person is clicking on something they don’t realize.
And the other bug relates to a good old LNK link files on Windows, so that’s a Windows only firefox bug – it doesn’t affect other products.
And the idea is that if you open a local link that appears to go to a Windows link file…
…remember, a link file is a Windows shortcut, so they’re a security problem in their own right.
Because a link file is a tiny little file that says, when the person clicks on it, “Actually, don’t open the link. Open a file or a network location that’s listed inside the link. Oh, by the way, what icon would you like the link to display as?”
So you can have a link file with an icon that, say, looks like a PDF.
But when you click, it actually launches a EXE.
And in this case, you can take that even further.
You can have a link file which you “know” is local, so it’s going to open a local file.
But when you click the link, it actually triggers a network connection.
Of course, whenever there’s a network connection from a browser – even if nothing truly dangerous happens with what comes back, such as remote code execution – every outbound connection gives away information, possibly even including cookies, about the current session; about your browser; about you; about your network location.
And so you can see, with both of those bugs, it’s a great reminder that it’s really important that your browser presents you the unvarnished truth of what happens when you click on any point on the screen.
It’s vital that it gives you an accurate and useful rendition of what will happen next, such as, “You will go off site. You will go to this link that you wouldn’t have clicked if we’d made it obvious.”
So it’s important that the browser gives you at least a way of figuring out where you’re going next.
Anyway, these have been patched, so if you get the update, you will not be at risk!
DOUG. Excellent.
All right, that is called: Mild monthly security update from Firefox, but update anyway.
I found that more than mildly interesting, especially the Mouse position spoofing with CSS transforms.
DUCK. Yes, lots of potential for mischief badness there!
DOUG. OK, in that vein, we have a reader who’s written in.
Naked Security Podcast listener Nobody writes the following… I love this one:
Hi.
I like the show a lot and have heard almost every episode since the beginning. I work in security, but right now, in my private life, I’m cat-sitting for a family with a house alarm.
DUCK. When I started reading that email, I thought, “Oh, I know what happens! Every time the cat walks around, the alarm goes off. And now he’s faced with this thing, ‘Do I turn the security off even though I was told not to?’ But it’s much worse than that!”
DOUG. It’s even *better* than that. [LAUGHTER]
He writes:
The numbers that match their code are wearing off, while all the wrong numbers are clearly untouched.
So it’s easy to guess which numbers are in the code.
I considered telling them that it’s time to change their code, but then I noticed that the alarm code is also written on a piece of paper taped right next to the alarm.
So the security hole I found is clearly not worth mentioning to them.
[LAUGHTER]
You shouldn’t laugh!
Don’t write your security code next to your security alarm panel!
Joshua, thank you for writing that in.
I would advise you to advise them to change the code, and throw away the paper with the code written on it.
DUCK. Yes.
And, in fact, if they do that, you could argue that then the keypad would be like a nice decoy.
DOUG. Yes, exactly!
DUCK. Because the cooks will keep trying all permutations of the wrong code.
And if there’s like a ten-trial lockout or something…
DOUG. Well, 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, and 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]
