+44 (0)20 86848683

Perpetual IT

News

S3 Ep64: Log4Shell again, scammers keeping busy, and Apple Home bug [Podcast + Transcript]

by

LISTEN NOW

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

With Doug Aamoth and Paul Ducklin. Intro and outro music by Edith Mudge.

You can listen to us on Soundcloud, Apple Podcasts, Google Podcasts, Spotify, Stitcher and anywhere that good podcasts are found. Or just drop the URL of our RSS feed into your favourite podcatcher.

READ THE TRANSCRIPT

DOUG. Log4Shell: It ain’t over till it’s over.

Instagram Scams. And Apple bugs.

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

[MUSICAL MODEM]

Welcome to the podcast, everyone.

Let’s see if I still remember how to do this, as I’ve been off for two weeks.

Paul, I see you’ve been working away, and you’ve jumped on the Worst Incidents of the Year List bandwagon, but in a much more productive and random way.

DUCK. [LAUGHS] Thank you, Doug.

I thought you were going to be cruel and say, “Ohhhhh, you just gave us your Top N list”… then you were very nice about it!

I decided to call mine The Top N Cybersecurity Stories of 2021 for Small Positive Integer Values of N [LAUGHTER], thus hopefully appealing to people with a vaguely mathematical bent.

DOUG. Well, as a former journalist who occasionally had to deal in what we used to call the Year-end Trash for Cash that we would write, this would have been very handy to have.

DUCK. Douglas, are you admitting that you wrote listicles in your time?

DOUG. I was admitting that I had editors that would say, “We need, we absolutely need to have a Top Ten Something Something About Something.”

If only I had a generator like this…

DUCK. Yes, I wrote a little script, and I put 14 items in there.

The script figuratively shuffles the deck – using a correct implementation of the random shuffle algorithm as originally presented by the famous Donald Knuth – and then prints out the Top N for you.

And sometimes when you run this little program with the Top 3, “IoT” will be at the top, because you *should* be concerned about Internet of Things stuff: we still haven’t conquered that, all these years on.

But you’ll also want to see things in there like “Kaseya“, “Hafnium“, “PrintNightmare“, “Clearview” and all the controversy around that.

And the only critique I got, Doug, was someone said, “How can you not include Solarwinds“?

DOUG. That’s the same comment on every one of these listicles: “How could you not include ______?”

DUCK. Well, the answer to that is, technically, Solarwinds….

DOUG. Oh, yes! 2020!

DUCK. Decemeber 2020!

How time flies when you’re having fun, Doug.

DOUG. Ah, yes: fun.

Well, speaking of fun, we do have a Fun Fact, of course, for this week’s show.

And it is this: although both companies were founded in the 1930s, the Packards in “Hewlett-Packard” and “Packard Bell” are unrelated.

HP’s Packard is David Packard; Packard Bell’s Packard is Leon Packard.

HP started out with electronic test and measurement equipment in 1939, while Packard Bell began life in 1933 producing consumer radios.

DUCK. Oooh, Hewlett-Packard, eh? I loved those calculators back in the day.

DOUG. Well, maybe we’ll talk about those little later in the show. So sit tight for that.

But until then, we must speak of something that surely belongs on your End of the Year list.

Where do we stand with the Log4Shell vulnerability?

When I went to sleep the week before Christmas and woke up yesterday, I was hoping we had put this to bed as well.

But it seems like it still kind of bubbled up a little bit here and there.

DUCK. Well, Log4Shell did get what you might call a “fourth installment” between Christmas and New Year.

So let’s just revisit what happened in December 2021.

DOUG. OK, so people found out about this “feature” [LAUGHTER].

Basically, you can insert code into forms that could do many things, one of them being to attack.

And then we all realised that this was a widespread problem.

And then we started to feel it in the pit in our stomach, with a little bit of adrenaline, when it sunk in that this can be exploited from even deep inside a network.

And then Apache responded by publishing 2.15.0 of Log4j.

Then, as attacks started and continued to surge, more researchers would say, “Hey, look what I found! Let me just run this scan to see how many of these are exploitable.”

So, these researchers were trying to help, but not really helping.

DUCK. Yes, there’s a limit to how much help you need, sometimes.

Too many cooks spoil the broth, etc.

DOUG. And then, as happens sometimes when you open a Pandora’s box like this, Apache dug a little deeper and found another flaw and updated it again to 2.16.0.

And then they found a third flaw.

DUCK. They did. [LAUGHTER]. It was the “gift that keeps on taking”, Doug.

DOUG. So, 2.17.0.

And then the government stepped in and said, “Christmas Eve! Must-patch deadline!”.

And then what happened?

DUCK. Well, I don’t know whether everyone hit the deadline, but it all went reasonably quiet.

And most companies that I know had done a pretty good job by then.

Then, lo and behold, between Christmas and New Year, another flaw came out, and Apache had to produce another fix.

This was 2.17.1, or CVE-2021-44832 if you want to go searching for it.

So the bad news was, “Oh, no!”

Skeleton staff at a lot of organisations; threat response, SecOps, IT teams, all trimmed down for the Christmas break.

“Is it going to be as bad as it was before? Do we have to cancel vacations and have all hands on deck?”

Fortunately, it turned out that to exploit this one, loosely speaking, an attacker would already have to have some footprint in your network.

They already needed to have intruded so they could fiddle with configuration files, or they needed to be able to manipulate and intercept your network traffic.

So that was the fourth vulnerability.

As you say, we had 2.15.0; then quickly 2.16.0 and 2.17.0; and then after Christmas and Boxing Day, suddenly we had 2.17.1.

And I guess that’s an indication, because it didn’t become 2.18.0…

…maybe that was meant to be a hint that this is a somewhat more minor issue than the previous ones.

So although there was a call-to-arms, that call wasn’t that you had to have all hands on deck right now, rescanning the network, redoing everything.

You do need to patch, but you probably didn’t need to bring everyone back to do it on New Year’s Eve. [LAUGHTER]

But if you did, then remember that patching alone isn’t enough in this case.

If crooks were exploiting this in your network, it would probably be because they were already inside and were able to fiddle with things.

And if they can fiddle with your Log4j settings, then you have to ask yourself, “My gosh. I wonder what other configuration settings they can fiddle with? I wonder what other network traffic they can intercept?”

So, you need to do a little bit of a review if you think you’re genuinely at risk of this one.

Doug, can I promote my Log4Shell – The Movie video?

DOUG. Please!

I was just going to say, “There’s a movie at the bottom”… please do it.

DUCK. Basically, I got a little bit tired of watching yet another YouTube video of someone who downloaded some online exploit kit written in Java.

Ran it up, attacked some random server out there and said, “You see, look what happens,” without really being able to explain how it all worked and show all the individual components.

So I did want to show an actual exploit in which I popped a calculator.

(And I popped an HP calculator, Doug, just to be absolutely clear!)

DOUG. [LAUGHS] All right!

DUCK. I actually wanted to show Log4j in a way which was self contained, yet realistic.

I wanted to show the details in a way not that made it easy for you to go and download a kit and do an attack yourself…

…I wanted to do it in a way that helps you understand what kind of things you might be able to look for on your network.

And also, to be honest, it was a little bit of, “This is why you probably need to send a ‘Thank You’ card to your IT people.”

This is why they’ve been working when everyone else was standing down for vacation, because you can see that this really matters.

It was a bug that got exploited, but you didn’t need any trickery.

It was what you might call a “product management bug” [LAUGHTER], not a “programming bug”.

It was implemented correctly – it was just that it shouldn’t have been implemented in the first place.

DOUG. [LAUGHS] It passed QA testing with flying colours!

DUCK. Yes, and that’s the problem.

It meant that absolutely anybody could use the bug, probably without understanding it.

Whereas if you want to be a defender, actually understanding the details, like how the DNS part works; how the LDAP and other TCP parts of it work; how the Java class injection part works…

I hope the video, in about 18 minutes gives you some hints on what your IT team were doing and why they were doing it, why it could happen deep inside your network, not just on your servers at the network: edge, and also gives you a good idea of the kind of things that will work.

People say, “Oh, go and block TCP connections from your vulnerable servers”, but as the video shows, that might not be enough.

There are other ways that the crooks can steal data, too.

So there you have it. Log4Shell – The Movie, Doug.

DOUG. Perfect.

All right, check that out, along with the article – it’s inside the article, which is Log4Shell vulnerability Number Four – Much Ado about Something at nakedsecurity.sophos.com.

Now, I don’t want to use the B-word on this podcast – it’s a family friendly podcast.

But this next story about an Instagram scam is, oooh, I’m going to say it, aaah: this is the best I’ve seen in some time.

DUCK. Yes.

By rights, you shouldn’t fall for this one, but it’s surprisingly believable if you’re just in a hurry, particularly because this happened in the middle of the holiday season.

I don’t want to say it was brilliant… but, yes, like you said, there’s definitely a B-word in there waiting to get out.

DOUG. Yes – what a difference a little criminal copyediting can make.

So, as we step through this: you’re accused of infringing upon someone’s copyright, and they send you a nastygram via email… which says what?

DUCK. That’s the thing, Doug – it’s not too much of a nastygram.

They’re just the person in the middle, so they’re not overtly threatening you.

DOUG. Yes, I should walk that back.

For anyone that’s ever had to deal with actual claims like this, it’s just basically, “Someone claimed that you stole their copyright. Click through here. There’s this form you need to fill out to say where you got it from, did you pay for it, or can you prove that you didn’t use it illegally?”

DUCK. Yes, that’s quite normal, isn’t it?

It just says, “We recently received a complaint. Your account will be removed if you don’t object. If you think this is a mistake, then you can click this button.”

It doesn’t look too bad, does it, Doug?

It goes to a domain called fb-notify DOT com; it’s HTTPS; it’s not something utterly bizarre like some freebie domain name in a country you’ve never heard of; it’s not some random string of characters, because that’s all they could get.

It’s fb-notify DOT com.

It scrapes information from your actual Instagram account, so with the Naked Security link that I followed, it sucked out the number of posts we’ve made, and the number of followers we’ve got…

[LAUGHTER] How people love to know how many followers they’ve got. They tend to fixate on that number.

The data looks correct because it *is* correct – they just copy it from your real page.

I’ve seen our example, and a few others: they copy not the most recent post, but I think in every case it was the second-to-last image.

So it is actually an image from your account.

You click the button and, undramatically, it just says, “Login required.”

OK, it’s not actually what the login page would really look like, but even if you’re not in a hurry, it doesn’t look outrageous, does it?

DOUG. No.

Especially if you haven’t done one of these before.

You’re like, “OK, I guess I need to log in.”

DUCK. And then whatever you type in, it goes, “Wrong password. Check your password.”

So you  t-y-p-e   i-t   i-n  more carefully the second time.

Can you see how the crooks are thinking here?

DOUG. Yes.

DUCK. You put in your password more carefully the second time, and then it says, “Thanks, your appeal has been sent successfully.”

It will say you’ll receive a response within 24 hours.

It’s not *exactly* how the process works, but it’s kind of how it works: there isn’t an instant decision, so that’s not unreasonable either.

And the last thing it does: it redirects you to Facebook/Instagram’s genuine copyright advice page.

DOUG. Just nailed the dismount!

DUCK. That’s the page you should actually have started at.

DOUG. [LAUGHS] Ah, the irony!

DUCK. And of course, as you can imagine, our first advice is: learn where that page is yourself.

DOUG. OK, that leads us nicely into our tips.

So what can people do to avoid scams such as these?

DUCK. Well, obviously that first one is: find out where the Facebook, the Instagram, the Twitter, the LinkedIn copyright infringement page is.

Learn what the procedure is, just in case it happens to you.

That basically brings us from tip zero to tip one: don’t bother clicking the link in the email.

If it really is a copyright infringement, you can go to Facebook… or Instagram, or Twitter, or LinkedIn, via your browser or your app directly yourself,without needing to use a link that came in an email.

And in this case, of course, what they want is your social media password, because that has real value to the crooks.

It may not affect you directly, but you know that if crooks get your social media password, the next thing that’s going to happen is all your buddies, all your friends or family, all the people in your inner circle groups are going to start getting “messages from you”, saying things that you would never dream of saying.

Or, even worse, using your good name to try and talk people into making dodgy investments where they are much more likely to believe them because they’re coming from someone they know.

So your reputation, at the very least, stands to get burned.

DOUG. And then my favorite, as someone who is inherently lazy, is: just use a password manager and 2FA whenever you can, because that will do all the heavy lifting for you.

We do have a great video at the bottom of this post that will give you some additional advice.

And if you’re already an influencer; if you already gone viral several times: talk to someone else that’s done the same thing.

They can kind of walk you through what a copyright infringement actually entails, so you know what to look for if you’re ever accused in the future.

All right, that is Instagram copyright infringement scams – don’t get sucked in on nakedsecurity.sophos.com.

And it’s that time of the show: This Week in Tech History.

We talked a bit about…

DUCK. It’s calculators, isn’t it? RPN calculators? It’s *real* calculators?

DOUG. We’re getting to the calculators!

We talked a bit about HP earlier in the show, and this week, on 04 January 1972, the HP-35 portable scientific calculator, a world first, was born.

It was named the HP-35 simply because it had 35 buttons.

The calculator was a challenge by HP’s Bill Hewlett to shrink down the company’s desktop-sized 9100A scientific calculator so it could fit in his shirt pocket.

The HP-35 stood out for being able to perform trigonometric and exponential functions on the go – things that until then had required the use of slide rules.

At launch, it sold for $395, which is almost $2500 in today’s money.

And, Paul, have you ever used an HP calculator?

I’m going to guess the answer [LAUGHTER] is, “Yes”.

DUCK. Right now. Doug, I am looking at the HP-35…

(50 years ago to the day – amazing! Well, the day we’re recording anyway.)

…it’s not just an emulator of that series of HP calculators: it basically simulates the CPU that was used in HP calculators all through the 1970s and the 1980s, including models like the venerable HP-12C, the HP-16C, the HP-21, the HP-32, all of those.

They all use the same CPU, so [the author of this software] wrote something that can pretend to be the actual calculator.

And then he provides a copy of all the non-copyrighted HP ROMs of the day, some of which were got from listings and some of which…

…I believe that for the HP-35, someone actually ground the top off the ROM chips, took microscopic photographs of them, and then wrote a Perl script that basically digitized them out.

DOUG. Oh, my God!

DUCK. Amazing.

When these calculators were made, the US has still not signed the Berne Convention on Copyright – I believe the US only signed in something like the mid-1980s.

So, some of the ROMs aren’t copyrighted, so it’s genuinely legal to have them and use them.

When you run this simulation – I’m looking at the HP-35 now, what a thing it was! – when you run this program, not only does it look right because they’ve taken photographs of a real calculator, you’re actually running the original ROM.

So any bugs in the calculator will be faithfully repeated in the simulator.

DOUG. What a time to be alive. Unreal.

DUCK. 3kHz, I believe was the CPU rate. You can do 3000 instructions per second.

DOUG. Amazing.

Well, we’ve got a very modern… how do I segue to this one? [LAUGHTER]

From the distant past to the not-so-distant present, we’ve got an Apple bug that is affecting its “Home” products.

And this is a bit obscure – is that a diplomatic way to put it? – but still bad. Kind of…

DUCK. Yes, it’s a reminder that sometimes Denial of Service bugs, where putting in dodgy data that doesn’t let the crooks take over your network or put spyware on your…

…I nearly said “on your calculator” [LAUGHTER] – I have an HP-42 calculator program on my phone, so it is a calculator as well as a phone.

You can have a bug that only really provides Denial of Service opportunity, but if it happens at the wrong time and in the wrong place, and if the program that crashes goes, “You know, that shouldn’t have happened; that must be a one off; I’ll start myself up again and try and carry on where I left off. Oh, dear. Guess what’s happened again. Let me start myself up again”…

…you get into this infinite loop of a program that really should give up gracefully going on to take up so much computational power that you can’t get to the menu screen that lets you stop it happening.

And if you reboot your phone, then it’s running before you can get in and go, “No, I don’t want you to run!”

That seems to be the nature of this bug.

The chap who found it is called Trevor Spiniolas – I hope I’ve pronounced that correctly – and he’s given it a cute little logo and a name with a funky font.

He’s called it “doorLock”.

And, basically, it relates to the Home app.

That’s the app with a little icon of a house that, if you’re an Apple user, you typically use to manage your home automation, your IoT stuff.

Amazon has got their way of doing it; Google’s got their way of doing it; and Apple has a thing called “HomeKit”.

You just buy a device that’s HomeKit compatible, and then you can basically bring it into your home automation network and you control it very nicely with this Apple Home app.

You can give all your devices meaningful names, like fishtank, webcam, babymon, doorbell, whatever.

But it turns out – you can guess where this is going – Trevor decided that doorbell wasn’t a long enough name.

If he had a name that was 500,000 characters long… well, I wonder what will happen?

So the bug he was reporting is that you could make this change with the Home app, if you tried hard enough.

And then, when the Home app later tried to display the name of one of these devices, it would get its knickers in a knot, to put not too fine a point upon it.

And you wouldn’t be able to use the Home app.

So that’s bad enough, because now you’re cut off from your HomeKit network.

But worse, what he claims is that if you had set what’s called the Control Center – depending on your iPhone, you either swipe up from the bottom or down from the top, and it brings up a menu of what you might call special apps that can come up over the top of any other app.

I have it on my phone – I use it basically for the Torch app, or the Flashlight as you call it.

So you swipe up, and you get these special buttons: you can turn on WiFi; turn on Bluetooth; turn on the torch; see where you’re going.

But you can also have apps that pop up there ,if they’re apps that you want to get at any time.

And Home is obviously one of the apps that popularly people put into this Control Center, and it means that when you reboot your phone, the Control Center goes, “Hey, you want all this control? I’ll fire up all these apps in the background, so they’re just one swipe and one tap away, even if you’re in the middle of another app.”

Very convenient.

So, you can see where this is going: you’ve got this bug that can freeze up the Home app, but it’s now starting automatically in the background whenever your phone reboots.

Therefore it bogs down your phone, and you can get to the point that there isn’t time, according to Trevor, to get into Settings > Control Center > Remove the Home app before your phone’s bogged down when it’s rebooting.

You don’t lose any data; you don’t get malware on your phone; it doesn’t sound like the end of the world.

But the only way Trevor could find out reliably to recover your phone was basically to use Recovery mode or a direct firmware update (DFU).

And the only way you can do that is if the data gets wiped first, and that’s the downside here.

It means that if someone entices you, “Hey, join my HomeKit network”, and then they have one of these absurdly-named devices, then your app will hang up while it’s looking at it.

And if you’re unlucky, you can end up having to wipe your phone to get back enough control to do anything useful with your phone.

Which is a long way of saying, “You should make backups.” [LAUGHTER]

Because then it doesn’t matter if you have to restore your phone to a bog-standard firmware with no data, because you canjust restore your backup.

DOUG. You could also just not name your devices more than, say, 20 characters, instead of 90,000.

DUCK. Ah. My understanding is that’s the reason why this bug finally got disclosed.

It seems that he reported it last year in August to Apple: “Have a look, I found this thing. You can set a device name to a value that the app will then choke on when it reads it back.”

So clearly the fixes are: don’t let the app set rogue names; and don’t let the app choke on rogue names.

And as far as Trevor could see, by December-time 2021, Apple had fixed the first problem.

They stopped you typing in 90,000 characters and setting your HomeKit device name to the weird value.

But they didn’t fix the other side of the bug, which is that if you already have one of those devices on your network, or some naughty person like your dodgy uncle who thinks he’s a hacker who’s got access to your HomeKit network… if he hasn’t updated his phone, he can use the old version to wreck the name, and your updated app will still choke on it.

DOUG. Aha!

DUCK. So, apparently, according to the researcher, he went to Apple early in early December 2021 and said, “Look, it’s been ages now, it’s been from August. I’m planning on disclosing this publicly in January, so I can give advice to people on a workaround. Just letting you know.”

And you know how Apple is: they don’t tell you what they’re doing until they’ve done it.

So, January came around and, rightly or wrongly, for good or for bad, he did the disclosure.

And his argument is that you might as well know, because Apple has had months to fix this.

They fixed the first part of the problem, but not the second part.

And so there are two ways that, without putting a super-long name into your own network, you could, in theory, get caught out.

I think they’re unlikely, so I don’t think it’s quite as big a risk as maybe the researcher is making out… but it is worth knowing about this.

The first one is if you’ve allowed somebody else access to your HomeKit network, which is the 21st century equivalent of giving your neighbor a spare key, isn’t it?

People do share access with others, and if any one of those people either turns rogue or *their* device gets hacked, they could, in theory, set up your HomeKit network so that when you come back from your vacation, your phone chokes.

And the other thing is that you could respond to what looks like an innocent HomeKit invitation.

That’s where you get invited to join someone else’s network.

And of course, as soon as your phone fetches the absurd HomeKit device names from the other network, your phone chokes, but theirs doesn’t.

So that’s the long version of the story.

DOUG. OK, so are there ways that people can mitigate the second part themselves?

Do people need to worry about this, or what?

DUCK. Well, the obvious fixes are things that I think you should be doing anyway, when it comes to anything to do with home automation.

Firstly, minimize the number of people that you’ve invited to join your HomeKit network.

It is basically like, in the old days, giving someone a key to your house: you have to trust the person a lot before you do that.

So if you’ve been in the habit of going, “Oh, well, I’m not giving them a real key. I can rescind this at any time. It’s not like I have to go and change a physical lock or anything like that”, cut down the list of people who are able to access your home kit network.

That’s good cybersecurity sense anyway.

And vice versa, accepting invitations to look after somebody else’s HomeKit network: treat that with the responsibility that it deserves.

Don’t just do it casually.

Maybe that’s actually an invitation you only want to accept if you know and trust the person a lot.

So, minimize the list of home networks that you allow yourself to connect to.

And the other thing you can do immediately, assuming you haven’t been hit by this, and until Apple produces a fix, is this.

If you remove the Home app from the Control Center, then the app will only launch explicitly when you want it to.

So you always have a chance to get back into your phone if something goes wrong.

And then lastly, as we said right at the top of this item, make a backup of your iPhone data.

Don’t just back it up into iCloud – that pretty much means you need to log into your Apple account to be able to recover it.

You can also make local backups, say onto encrypted removable drives, and then you can easily keep your own offline, off-site backup, just in case something super-bad happens, like you lose your phone, or it gets smashed in an accident, or you just simply can’t get at your data.

Having your own local copy is a great idea.

You can do it with iTunes, on Mac or Windows, and if you’ve got Linux, it’s even easier: there’s an app called idevicebackup2.

If you ever need to recover your data in emergency, you won’t need an Apple device, and you won’t need to log into an online account.

So, that’s my advice.

DOUG. OK, that is Apple Home software bug could lock you out of your iPhone on nakedsecurity.sophos.com.

And it is that time of the show for the Oh! No! of the week.

Reddit user Xanthian writes…

I got a call from a user who needed MFA – multifactor authentication – set up on their email.

After setting up their Authenticator app, I had to explain how to use it.

So this code on your phone will refresh every 30 seconds, and you just enter that code and it asks you for it when signing into your email.

“Got it. Let me just write this down.”

You shouldn’t need to write it down – the code will just be on your phone. You can enter it when you need it.

“OK, it looks like there’s a new code. Let me just write this one down.”

Yeah, the code is going to refresh every 30 seconds – you just enter whatever it’s showing you when you try to sign in.

“OK, there’s another one. I’m going to write this one down real quick.”

Yes, it’s going to change every time you use it – you won’t be able to write it down the correct code.

“How am I supposed to remember my code if it changes every time? you people never think these things through!”

He eventually figured it out.

The joys of the first-time MFA user with the ever-changing codes, trying to get those plugged in, or in this case written down, before it changes.

DUCK. It shows that the message about not writing down passwords on PostIt notes had not sunk in! [LAUGHTER]

The very thing that 2FA, with ever-changing codes, was supposed to help us fix.

But I see the idea: he wants to make sure that he won’t get caught out if he doesn’t have his phone.

Which is, I guess, the resistance many people haveto that kind of 2FA, isn’t it?

People go, “What if I leave my phone behind? What if I join the wrong HomeKit network? [LAUGHTER]

Well, the answer is that for most programs that work like this, you can print off ten special one-time codes that you lock away just in case.

But you do need to lock them away, because they are the keys to the castle.

DOUG. Well, we’ll all be much safer once everyone figures it out!

If you have an Oh! No! that you’d like to submit, we’d love to read it on the podcast.

You can email tips@sophos.com; uou can comment on any one of our articles; or 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]

News

FTC threatens “legal action” over unpatched Log4j and other vulns

by

The Federal Trade Commission (FTC) is the US consumer rights body, and it has sailed into 2022 with a bang, not a whimper.

Using the infamous Log4Shell vulnerability as what you might call its Exhibit A, the FTC has fired a shot across the bows of companies in US jurisdictions, telling them to get their patching in order, or face the consequences:

It is critical that companies and their vendors relying on Log4j act now, in order to reduce the likelihood of harm to consumers, and to avoid FTC legal action.

It’s not just Log4j, of course, that creates a legal obligation to do the right thing to protect consumers, with the FTC reminding us all that:

When vulnerabilities are discovered and exploited, it risks a loss or breach of personal information, financial loss, and other irreversible harms. The duty to take reasonable steps to mitigate known software vulnerabilities implicates laws including, among others, the Federal Trade Commission Act and the Gramm Leach Bliley Act.

In other words, even though your company may itself be the victim of a crime, that doesn’t let you off the hook for civil or criminal liability of your own.

Simply put: if there were precautions against a data breach that you could reasonably have taken, and that people would reasonably expect you to have taken, but you did not…

…then you could end up being both a victim and a perpetrator at the same time.

FTC has done this before

The FTC’s brief but blunt warning makes an example of the infamous Equifax breach of 2017, where the US credit reporting behemoth was compromised via an unpatched Apache Struts vulnerability with the unassuming bug identifier CVE-2017-5638.

The personal information of nearly 150,000,000 people was exposed as a result.

The FTC keenly reminds us that Equifax ended up paying $700 million to settle the ensuing legal actions from the FTC itself, from the US Consumer Financial Protection Bureau, and from all fifty US states.

The FTC also makes it clear that it will be perfectly happy to lead the charge against future offenders, too:

The FTC intends to use its full legal authority to pursue companies that fail to take reasonable steps to protect consumer data from exposure as a result of Log4j, or similar known vulnerabilities in the future.

Déjà vu all over again

Interestingly, the Apache Struts vulnerability that caught out Equifax had many similarities with the Log4Shell security hole in Apache’s Log4j logging code.

The CVE-2017-5638 Struts vulnerability was exploitable because otherwise unimportant text data in an untrusted web request could contain “magic character sequences” that were treated as miniature programs at the other end.

Instead of saying “the data I just sent you is in this format: text/plain“, you could say something like “the data I just sent you is: (hey, run this totally untrusted short text string as a program fragment in order to find out what type it is)”.

Like Log4j’s Log4Shell hole, this bug was originally intended as a feature, giving your back-end business logic programmers funky flexibility in their code, while inadvertently giving cybercriminal attackers an exploitable backdoor hole for remote code execution at the same time.

The Log4j bug officially known as CVE-2021-44228, but commony referred to as Log4Shell, is even worse.

The logging toolkit erroneously allowed crooks not only to say “the data I want you to log is: this text here“, but also to embed logging instructions such as: “the data I want to you log is: (hey, here’s a web URL where you’ll find a program that may or may not tell you, so kindly download it yourself and run it for me)”.

[embedded content]

If you can’t read the text in the video clearly here, try using Full Screen mode, or watch directly on YouTube. Click on the cog in the video player to speed up playback or to turn on subtitles.

What to do?

If you’re still stuck with 1999-style patching policies that rely on letting companies with better cybersecurity readiness go first, watching cautiously from the sidelines, and then waiting a few more {days, weeks, months} while your Change Control Committee weighs up the pros and cons…

…you may need to get your Change Control Committee to put through a change in the Change Control Committee itself.

The FTC is essentially warning companies and vendors that some vulnerabilities and patches are important enough that there’s no longer room for lead, follow, or get out of the way; there’s room only for lead.

In Naked Security’s own regularly repeated words: patch early, patch often…

…your customers (and your country’s regulators) will respect you for it!

News

Apple Home software bug could lock you out of your iPhone

by

A security research called Trevor Spiniolas has just published information about a bug he claims has existed in Apple’s iOS operating system since at least version 14.7.

The bug affects the Home app, Apple’s home automation software that lets you control home devices – webcams, doorbells, thermostats, light bulbs, and so on – that support Apple’s HomeKit ecosystem.

Spiniolas has dubbed the bug doorLock, giving it both a logo and a dedicated web page, claiming that although he disclosed it to Apple back in August 2021, the company’s attempts to patch it so far have been incomplete, and his specified deadline of 01 January 2022 for “going live” with details of the flaw has now passed:

I believe this bug is being handled inappropriately as it poses a serious risk to users and many months have passed without a comprehensive fix. The public should be aware of this vulnerability and how to prevent it from being exploited, rather than being kept in the dark.

You’ll have to make your own mind up about whether this bug truly “poses a serious risk”, but in this article we’ll tell you how to deal with the issue anyway.

The good news is that the bug doesn’t let attackers spy on your phone (or your HomeKit devices), steal data such as passwords or personal messages, install malware, rack up fraudulent online charges, or mess with your network.

Also, there are some easy ways to avoid getting bitten by this bug in the first place while you wait for Apple to come up with a complete fix.

The bad news is that if an attacker does trick you into triggering the bug, you could end up with a phone that’s so unresponsive that you have to do a firmware reset to get back into the device.

And, as you probably already knew – or, if you didn’t, you know now! – using Device Recovery or DFU (a direct firmware update, where you completely reinitialise the firmware of a recalcitrant iDevice over a USB cable) automatically wipes out all your personal data first.

Wiping your data when reinitialising the device is a feature, not a bug: it stops thieves simply grabbing your phone, doing a hard reset and a DFU of their own, and then reading off the old data from the device they’ve just ‘recovered’. Wiping your data is quick and reliable because Apple mobile devices always encrypt your data, even if you don’t set a lock code of your own, using a randomly chosen passphrase kept in secure storage. Wiping just this passphrase from the device is therefore enough to render all your data useless in one go, without having to wait for a overwrite of all the flash storage in the device, and without the uncertainty of whether any unencrypted data got left behind.

Which devices are affected?

Spiniolas doesn’t say, but we’re assuming that this same bug is present in iPadOS, which has shipped separately from iOS since version 13, though always with a matching version number.

We also don’t know how far back this bug goes: as mentioned above, Spiniolas says “from iOS 14.7”, which we’re guessing is the earliest version he’s been able to test.

Apple doesn’t allow iPhones and iPads to be downgraded, as a way of preventing would-be jailbreakers from reverting to known-buggy iOS versions in order to reintroduce exploitable security holes on purpose.

What causes the bug?

According to the description given by Spiniolas, the bug is triggered if Apple’s Home app encounters a HomeKit device under its purview with an enormously long name, for example 90,000 characters or more.

That makes this bug sound like an old-fashioned buffer overflow, where more data is saved into memory than was originally allocated as the “worst-case” scenario, at best causing the offending program to crash, and at worst tricking it into misbehaving in a controllable fashion.

The former outcome – an outright crash – typically leads to a denial of service (DoS) bug, where attackers could deliberately crash an app, possibly over and over again, to cause inconvenience or outright trouble.

The latter outcome, where attackers maintain enough control over the crash to take over the buggy program completely and to replace the running program with untrusted software of their own choice, is known as remote code execution (RCE).

RCE is typically used to implant spyware or malware, and is clearly a much more serious danger than DoS.

At the moment, there’s no suggestion that Spiniolas’s crash could reliably be used for a full RCE exploit, or even that it could lead to an RCE at all.

But the fact that cybercriminals now know where to start looking makes this bug doubly worth avoiding.

How does the bug get triggered?

If you deliberately rename one of the home devices in your HomeKit network so it has a name of about 100,000 characters or more (Spiniolas variously used 500,000 and 90,000 characters in his experiments), the Home app will apparently lock up when it subsequently tries to deal with the weirdly-named device, and ultimately crash.

According to Spiniolas, Apple recently patched the Home app to prevent you renaming devices to have absurdly long names.

Bu the patch apparently doesn’t stop the latest version of the app from reacting badly to devices that already have overly-long names, and obviously doesn’t stop miscreants from using devices that haven’t been patched to catch out apps that have.

Spiniolas isn’t clear on this issue, but we’ve inferred from his report that although unpatched versions of the Home app sometimes crash whilst trying to set an extra-long HomeKit device name, they sometimes don’t crash, or crash only after the extra-long name has been applied. Spiniolas has also shown how to create a one-off iOS app that you can install locally on your own device, using an Apple developer account, to rename HomeKit devices in an unregulated way, whether your device is patched or not. So even if you aren’t able to set ultra-long HomeKit device names yourself, you should assume that attackers can.

Trouble with Control Center

Unfortunately, says Spinioloas, if you’ve enabled the Home app in the Apple Control Center (the always-available menu system that you can bring up at any time by swiping from the top or bottom of the screen, depending on your iPhone version), then the app will automatically load in the background whenever you start your phone.

This means your device may get into a permanent “lockup-crash-try-again-lockup-crash-ad-infinitum” loop that leaves it unusably unresponsive before you have time to get into the Settings menu and remove Home from the Control Center.

Catch-22!

You can regain control of the Control Center by accessing the Settings app; but you first need to regain control of the Control Center in order to access the Settings app.

That’s why Spiniolas claims that the only way out of the dilemma is to do a Recover or a DFU on the unresponsive device.

Because this removes all your personal data, the Home app will no longer have any HomeKit device names to display until after you sign into your iCloud account for the first time and your HomeKit details get re-downloaded to your phone.

This gives you a chance, before your phone gets presented with any crash-inducing HomeKit device names, to access the Settings app and to remove the Home app from the Control Center screen.

As for renaming any offending devices so you can take control of them safely once more, Spiniolas suggests that you will need to install a custom app (he offers sample code you can use “at your own risk” on his GitHub page) using an Apple Developer account, and use that app to do the renaming.

What to do?

We consider it vanishingly unlikely that you will ever trigger this bug inadvertently on your own HomeKit network, given that you’re unlikely to copy-and-paste an absurd device name into the Home app by mistake and then also deliberately tap [Save] to commit the weird name to your HomeKit configuration.

So the most likely way you’d come unstuck is either:

  • Someone you’ve already authorised to access your HomeKit network decides to trigger the bug for you. If you’ve chosen your trusted neighbours or family members wisely (and you trust them to keep their phones secure against cybercriminals and pickpockets), this risk should be very low.
  • You accept a HomeKit network invitation from someone whose own network will trigger the bug. Assuming that you treat access to someone else’s home automation network as a significant personal responsibility (which it is!), this risk should also be very low.

In other words, mitigating this issue is easy:

  • Minimise the number of people who have access to your HomeKit network. We recommend this strongly anyway.
  • Minimise the number of HomeKit networks to which you yourself accept inviations. We recommend this strongly anyway.
  • Remove the Home app from the Apple Control Center. Go to Settings > Control Center > Customize Controls. If Home appears in the INCLUDE list, tap the red minus sign next to it and then tap the red [Remove] button that appears on the right hand side. (See image below.)
  • Make a regular local backup of your iPhone data. You can do this onto a Mac or Windows computer using iTunes. On Linux, it’s even easier: you can use the idevicebackup2 utility to make a full backup whenever you like. You don’t need an Apple account to keep regular local copies of your photos, videos, messages, audio files and so forth. If you save the data onto an encrypted removable drive, you can store it both offline and offsite, and in an emergency you’ll have access to your iPhone data without needing a working Apple login or an Apple device.
Removing the Home app via the Settings > Control Center screen
Left. Click on ‘no entry’ sign    Centre. Click on ‘Remove’    Right. Gone!

Next steps

As we’re not home automation fans ourselves, we don’t have an iCloud account or a HomeKit network to practise with.

As a result, we can’t advise you whether there’s a way to manage HomeKit devices from your browser, or from a non-Apple device, which would neatly sidestep the buggy Home app…

…so if you are a HomeKit user and have any suggestions for other readers, please let us all know in the comments below!

News, Phishing

Instagram copyright infringment scams – don’t get sucked in!

by

If you create any sort of online content at all – even if you’re just a once-in-a-while blogger or an occasional social media user – you almost certainly know how easy it is for other people to rip off your material and present it as their own.

We’re not talking about links, shares, retweets, and so on, which are legitimate ways for people to re-promote your work.

We’re referring to outright scraping, copying or republishing of your original content by someone else, as though they created the material themselves…

…without ever bothering to ask for permission.

At the same time, you’ll also know how easy it is to end up accused of copyright wrongdoing yourself, even if you’re always careful only to use third-party material in accordance with the original creator’s licensing guidelines.

So, given the frequent argy-bargy that surrounds online copyright issues, many social networks have established formal procedures for making complaints and appealing against takedowns.

Instagram’s procedures, for example, are listed in some detail on its official help page, which explains both how to complain if you think you’ve been ripped off, and how to respond if you’ve been falsely accused.

Enter cybercrime

As you can imagine, cybercriminals have learned how to use copyright infringement notices as bait in phishing scams.

By pretending to be a social network such as Instagram, they try to scare you into thinking that there’s an official copyright complaint against you..

…whilst at the same time giving you a quick and easy way of replying with a counter-claim of your own.

The criminals know that the complaint is totally bogus, and they know that you know it’s bogus.

But instead of leaving you to figure out that it’s bogus because there was no complaint in the first place, they trick you into thinking that the complaint was real, but that the bogus part was the accusation made by the complainer.

To do this, they don’t accuse you themselves, and they don’t threaten to sue; instead, they offer you an easy way to “prove” your “innocence” by providing a link to object to the “complaint”.

While we hope that you’d spot an email scam of this sort right away, we have to admit that some of the copyright phishes we’ve received in recent weeks are much more believable – and better spelled, and more grammatical – than many of the examples we’ve written about before.

Like this one:

Hello, @nakedsecurity

We recently received a complaint about a post on your Instagram. Your post has been reported as infringing copyright.

Your account will be removed if no objection is made to the copyrighted work. If you think this determination is incorrect, please fill out the objection form from the link below.

The [Appeal] button in this example uses a shortened link (this one comes from from bit.ly), but whether you check the destination of link in advance or click through anyway, the resulting website doesn’t look as bogus as you might expect.

To check a bit.ly link before visiting it, paste the link into your browser’s address bar and add a plus sign (+) at the end, which tells bit.ly to show you the original link without redirecting to it.

Here, the crooks have registered the fake-but-not-too-far-off domain name fb-notify DOT com, and the link you’re given takes you to a personalised scam page that explicitly references your account:

In the screenshot above, the account statistics are correct, or they were at the time we received the email, and the image shown does indeed come from our Instagram page. (Amusingly, and ironically, that means the email itself infringes copyright.)

In other pages linked to by these scammers, the image ripped off by the crooks always seemed to be scraped from the second-to-last post on the victim’s Instagram page. That might have been a coincidence, or it could be a deliberate ploy by the crooks to pick an image recent enough that you’ll remember posting it, but not so recent that the copyright complaint might seem unrealistically quick.

The sting

Anyone who gets this far is almost certainly starting to believe the scam, which would make the next page seem unexceptionable enough, especially given the HTTPS padlock and the sort-of-OK-looking fb-notify domain name:

The website then pretends you made an error typing in your password and tells you to try again, presumably as a simple way for the crooks to discard login attempts where a user clearly just bashed out any old garbage on the keyboard to see what happened next:

Then there’s a believable enough message to tell you that your appeal was submitted successfully:

Finally, the criminals sneakily redirect you to the real Instagram copyright page that we listed above, presumably to add an air of legitimacy that leaves you on a genuine website:

What to do?

  • Don’t click “helpful” links in emails. Learn in advance how to handle Instagram copyright complaints, so you know the procedure before you need to follow it. Do the same for the other social networks and content delivery sites you use. Don’t wait until after a complaint arrives to find out the right way to respond. If you already know the right URL to use, you never need to rely on any link in any email, whether that email is real or fake.
  • Think before you click. Although the website name in this scam is somewhat believable, it’s clearly not instagram.com or facebook.com, which is almost certainly what you would expect. We hope you wouldn’t click through in the first place (see point 1), but if you do visit the site by mistake, don’t be in a hurry to go further. A few seconds to stop and double-check the site details would be time well spent.
  • Use a password manager and 2FA whenever you can. Password managers help to prevent you putting the right password into the wrong site, because they can’t suggest a password for a site they’ve never seen before. And 2FA (those one-time codes you use together with a password) make things harder for the crooks, because your password alone is no longer enough to give them access to your account.
  • Talk to a friend you know face-to-face who’s done it before. If you are active on social media or in the blogosphere, you might as well prepare in case you ever get a copyright infringement notice for real. (We’re assuming the accuation will be false, but the complaint itself will actually exist.) If you know someone who who has already gone through the genuine process once, see if they’ll tell you how it went in real life. This will make it much easier to spot fake complaints in future.
  • Watch our video below for additional advice. Early in 2021, we presented a Facebook Live talk looking at the history and evolution of this type of scam. If you have any friends who rely on social media to generate income, and who might be worried about getting cut off from their accounts, show them the video to protect them from tricks like this one.

Watch directly on YouTube if the video won’t play here.
Click the on-screen Settings cog to speed up playback or show subtitles.

[embedded content]

News

Log4Shell vulnerability Number Four: “Much ado about something”

by

Are you a sysadmin who managed to get your Log4Shell mitigations done in time for the US Government’s cybersecurity deadline of 24 December 2021?

If so, you may have enjoyed a Christmas mini-vacation along with much of the rest of the world…

…only to return to the fray this week and find that the Apache Log2j team just put out the fourth patch in what you might call the Log4Shell Vulnerability Saga.

The newly discovered bug is CVE-2021-44832, patched in Log4j 2.17.1, announced on 2021-12-28 (yesterday at the time of writing).

“Once more,” dear friends, in the words famously given to King Henry V by the Bard of Avon.

Fortunately, for all the understandable publicity this fourth flaw has received, and for all that we urge you to patch it promptly anyway, this bug is currently only dubbed Moderate.

This one doesn’t seem to be directly and easily exploitable like the original CVE-2021-44228 hole that gave rise to the name Log4Shell in the first place.

The saga so far

To summarise the saga so far, starting on about 09 December 2021:

  • News breaks of an easy-to-abuse “feature” in the Apache Log4j logging code. What most programmers shrugged off as simple variable substitution in logging data (e.g. turning ${java:version} into a text string describing the Java version) turned out to allow attackers to hide dangerous commands in data from outside, such as injecting instructions for leaking secret data or downloading malicious code.
  • Organisations around the world realise the buggy code is very widespread. Even businesses that didn’t consider themselves Java shops found Java apps scattered all over their networks. Log4j unexpectedly turned out to be buried in many of these apps.
  • The message sinks in that this bug can be exploited even deep inside a network. Running non-Java servers at the network edge doesn’t remove the risk. Any internal server to which untrusted data (e.g. a telephone number or a postcode) gets sent for processing could be at risk if it logs that data. And many business-logic apps create copious logs, often with good reason, such as for audit or compliance purposes.
  • Apache rapidly publishes Log4j 2.15.0, fixing the primary security hole. For those servers where change control stood in the way of applying the patch (apparently without irony given that the same change control process presumably waved through the vulnerable code many years ago), Apache provided handy run-time mitigations to suppress the dangerous behaviour.
  • Attacks surge, including many from self-styled researchers “trying to help”. Because this bug was originally a feature, it could be exploited with ease, so anyone who wanted to get involved could give it a go. Thousands, perhaps even millions, did, often without overtly malicious intent. But amid the cybersecurity smoke of unhelpful “research” were numerous genuine fires started by cybercriminals stealing data or implanting malware such as cryptominers and ransomware.
  • Apache digs deeper into the code and finds a further flaw. Log4j quickly gets a second update to 2.16.0.
  • Apache finds a third flaw that brings us version 2.17.0. We advised sysadmins who were part-way through upgrading to 2.16.0 or 2.15.0 simply to carry on patching, but using 2.17.0 for their as-yet unpatched systems. Better to have all of your systems at 2.15.0 or greater as soon as you could, and then go back and “top up” the 2.15.0 and 2.16.0 servers later, than to risk leaving some servers completely unpatched for longer.
  • The US Government sets 24 December 2021 as a must-patch deadline. With Christmas Day and Boxing Day 2021 landing on Saturday and Sunday respectively, creating a weekend-plus-family-holiday double play in much of the world, CISA decides to set the proverbial Night Before Christmas as the deadline for the US public sector to roll out its patches.

Flaw the fourth

This new, fourth flaw was reported just after the Christmas 2021 weekend, on 2021-12-28.

Fortunately, in Apache’s words:

Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4) are vulnerable to a remote code execution (RCE) attack where an attacker with permission to modify the logging configuration file can construct a malicious configuration using a JDBC Appender with a data source referencing a JNDI URI which can execute remote code. This issue is fixed by limiting JNDI data source names to the java protocol in Log4j2 versions 2.17.1, 2.12.4, and 2.3.2.

RCE, of course, is about the worst sort of cybersecurity hole you’ll experience, because it typically means that an outsider can poke an unexpected program into your computer without so much as a by-your-leave.

An RCE attack might inject an untrusted app, poke a binary fragment of machine code into memory, or sneakily offer up an unwanted script file…

…and if the attacker succeeds, you’ll run their code unknowingly, without any official Are you sure (Y/N)? prompt or This could harm your computer dialog to tip you off.

But for all that this bug mentions RCE, it isn’t really what the jargon calls an unauthenticated remote execution, where anyone who can interact with your network without logging in first (e.g. by visiting a public-facing website) could trigger the bug.

As Apache mentions, to enable remote execution, an attacker would first need sufficient access to mess with the configuration settings of the vulnerable server or business-logic application.

We suspect that any attackers with enough access to alter server-side configuration settings will have any number of additional ways to compromise your internal apps, systems or network.

In other words, if you are directly at risk of CVE-2021-44832 right now, then updating Log4j 2.17.0 to 2.17.1 is probably neither a necessary nor a sufficient solution to your security problems.

Simply put, don’t just patch to 2.17.1 and think, “Great. Now I can relax until the New Year.”

What to do?

  • Patch to Log4j 2.17.1 when you can. There’s no point in skipping this update altogether simply because it’s only rated Moderate.
  • If you think that CVE-2021-44832 poses a clear and present danger to your network, patching on its own is not enough. A system that is genuinely vulnerable to malicious outsiders on account of this bug is almost certainly at risk of numerous other attacks, too.
  • Review your Log4j configuration settings. Look for unauthorised or unwanted settings that you might not have considered before.

In an earlier article, we proposed revisiting your own usage of Log4j in the near future, and working out whether you genuinely need it in your own software.

If you inherited Log4j without even realising it, as part of the Java “supply chain”, and could readily replace it with something much simpler and less feature-rich, we think that would be a wise choice.

Some commenters said we were being unrealistic or going over the top by saying this, claiming that we were underestimating the complex logging needs of the average business app.

But we’re going to suggest, once again, that if you have found Log4j in your ecosystem recently, especially on servers where you didn’t even know it was there, that you should ask yourself the question, “Do I genuinely need a multi-megabyte logging toolkit consisting of close to half a million lines of source code, or would something much more modest and easier to review do at least as well?”

That’s not a criticism of Apache; it’s merely a reminder that inherited security problems such as Log4Shell are often the unexpected side-effect of a cybersecurity decision made years ago by someone from outside your company whom you’ve never met, and never will.

For all that the original decision might not be your doing, it’s now your responsibility, so reviewing it can hardly be considered controversial or ill-considered!

LEARN HOW THE LOG4SHELL VULNERABILITY WORKS

[embedded content]

(If you can’t read the text clearly here, try using Full Screen mode, or watch directly on YouTube. Click on the cog in the video player to speed up playback or to turn on subtitles.)

Latest Blog

View All
go top