Perpetual IT

You’re almost certainly familiar with vishing, a phone-based scam in which cybercriminals leave messages on your voicemail in the hope that you’ll call them back later to find out what’s going on.

In fact, if you have a long-standing phone number, like we do, you may well get more of these scam calls (perhaps even many more of them) than genuine calls, so you’ll know the sort of angle they take, which often goes along these lines:

[Synthetic voice] Your Amazon Prime subscription will auto-renew. Your card will be billed for [several tens of dollars]. To cancel your subscription or to discuss this renewal, press 1 now.

Sometimes, they’ll read out the number to call them back on, to re-iterate not only that it matches the number that shows up in your call history, but also that it’s a local number, right there in your own town or country.

The crooks do this to “prove” that caller is local too, rather than sitting overseas in some scammy boiler-room call centre, far from the reach of law enforcement and the regulators in your part of the world.

Unfortunately, the number that shows up in your call history (known by various names around the world, including Caller ID and calling line identification) doesn’t tell you where the caller is actually located.

Firstly, Caller ID is easy to spoof, so crooks can disguise their real number, or make it look as though they’re calling from somewhere you trust, such as your bank.

Secondly, if it’s not spoofed, Caller ID doesn’t tell you where a returned call will ultimately end up, but merely reports the last known phone number that it passed through on the way to you.

If a call centre (or a cybercriminal) calls you from overseas using a voice-over-IP (VoIP) service, where the call is transmitted cheaply over the internet until it reaches your country and only then redirected into the phone network, you will see a local number in your call history, but it won’t actually be the caller’s ID. Always keep in mind that the name Caller ID is misleading because it doesn’t identify the person who called you at all. Even calling line identification is an inaccurate name, given that the number that shows up can be modified and therefore doesn’t reliably identify the calling line, either.

Call us back

So, Caller ID can’t be trusted, and unexpected phone calls, like unwanted emails, could by-and-large have come from anyone.

That’s why many of us dump all our calls to voicemail these days, and respond only to the likely ones.

With this in mind, you may be wondering why crooks still bother running phone-based scams, especially when these require human interaction each and every time someone returns a call, unlike web-based scams, which largely look after themselves.

The answer, of course, is that variety is the spice of life, or, sadly, that variation is one of the secrets of scamming.

Sometimes, simply being different from what everyone has been told to watch out for is enough to get victims to let their guard down.

The other advantage, for the crooks, of running what you might call human-led scams instead of pure online ones is that the scammers in the call centre only ever deal with people who are already concerned enough to call back of their own accord.

In other words, call-back scamming may be a more time-consuming way of interacting with each potential victim, but:

• Many people feel comfortable about carrying out risky computer behaviours such as installing unknown software if there is an “IT helpdesk” person talking to them at the same time.
• Human scammers can adapt and respond in real time to objections or fears that potential victims might raise, thus keeping those callers on the hook for much longer than if they were left to their own devices.

Call us first

As you probably know, there’s a fascinating world of hybrid scamming that mixes together email-based and phone-based treachery.

Technical support scammers – those lowlifes who find fake viruses on your computer and then charge you real money for pretending to remove them – have been doing this for years.

They know that potential victims have been taught “not to click through” and to “watch out for dodgy popup links”, so many scams these days invite you to call a local phone number instead of clicking a link or opening an attachment.

At first, this feels as though it should be safer, because you’re not immediately exposing your browser or your computer to a site or a file that you aren’t sure of.

There’s always a chance, you might think, to make your own judgment of the “helpdesk expert” at the other end…

…before typing in the link they just gave you, or installing the software they just recommended.

Don’t click, call us instead

Unfortunately, as we wrote earlier this year, it’s not just the technical support scammers using this “don’t click a dangerous link, call this handy phone number instead” trick.

In April 2021, we warned of a malware crew using a similar trick to talk you into infecting yourself with their malware, known as BazarLoader (also known as BazaLoader), thus giving them a foothold on your computer to mount pretty much any sort of cyberattack they want:

Rather than deciding in advance whether they’re going to hit you with a keylogger, a data stealer or a ransomware attack, the crooks who talk to you on the phone helpfully explain how to open a booby-trapped Office file that they deliver to you.

By tricking you into bypassing the security checks that would otherwise keep you safe, they implant a general-purpose bot or zombie program onto your computer that can:

• Download and run another programs, disguising them as unexceptionable apps such as Notepad or Explorer.
• Download and run DLLs, Windows software modules that many people think of as safer than EXE files because they aren’t standalone programs that you can launch as apps in their own right.
• Download and run a batch file or PowerShell script. PowerShell is widely used by system administrators these days because it makes it easy to create full-blown Windows programs in the form of plain text files.
• Get rid of itself from disk and exit. By cleaning up their malware tools after an attack, the crooks make it harder for you to figure out what happened and thus make it tricky to know what to look out for in future.

BazarLoader is back

We’re writing this article now as a followup to a reminder that came from Microsoft itself last week, with the self-explanatory title:

BazaCall: Phony call centers lead to exfiltration and ransomware

As you can imagine, Microsoft takes this sort of attack at least as personally as anyone else, not least because the primary malware infiltration vehicle that the BazarLoader/BazarCaller crooks use is to talk you into infecting yourself via some sort of Microsoft Office file.

Ironically, the crooks use the pretence that the file is “protected” and therefore needs to be handled in a special way – something that a crooked “helpdesk support team member” will glibly and happily tell you how to do.

Of course, the “special way” of handling the “protected” file, shown above as ENABLE EDITING and ENABLE CONTENT, involves turning off Microsoft’s default security settings, thus allowing malware embedded in the Office file to run, rather than blocking it.

In the latest round of attacks, you are urged via email by the BazarCaller scammers to phone them up if you want to “resolve” a “purchase” that was just debited to your account, such as:

• Converting a software trial into an auto-billed “premium” paid package. (Call for details, or to cancel if this is an error, etc.)
• Joining a fitness program you showed an interest in. (Call with included personal ID for help or details, etc.)
• Autorenewing a service membership you’re already part of. (Call if you want to cancel, etc.)

The crooks know that you’ll know that you didn’t intend to make or authorise the purchase they’re warning you about.

They’re also hoping that you’ll want to check how the “mistake” happened, and get the charge removed from your card.

Don’t do it!

What to do?

• Never assume that calling a phone number is safer than clicking on a web link. Either way could put you directly into contact with cybercrooks.
• Never rely on contact details given to you by an outsider. If you are concerned about unauthorised payments taken off your card, contact your bank or card provider directly for advice. Always use the phone number or website on the back of your physical card, or printed on documentation that’s already in your possession.
• Never change a security setting on your computer because someone you don’t know told you to. If you’re wondering whether a link is safe to download, or an Office file is safe to open, find someone you already know and trust (e.g. a member of your own IT team from work, or a trusted friend in your own circle) and ask them directly.
• Never feel compelled to call a number back, whether you are being threatened or flattered. If you have any vulnerable friends or family whom you think might easily be misled on the phone, make sure they know to call you first.
• Listen to our special podcast episode on social engineering. Phone scammers can be much more persuasive than messages received via email or the web. Phone scammers adapt their lies and treachery line by line as they go along, and typically have the “gift of the gab” to explain away any concerns you might have along the way.

Remember that gangs like the BazarCaller crew talk people into infecting themselves with malware, including ransomware, for a living.

Cybercrooks of this sort typically have a lot more practice in telling you what you want to hear, the way you want to hear it, than you have in picking out which bits of what they just said are a pack of lies.

If in doubt, don’t give it out!

---

[01’08”] Apple’s emergency 0-day fix.
[08’51”] A new sort of Windows nightmare, this one not involving printers.
[20’39”] Another new sort of Windows nightmare, also with no printers.
[27’37”] Twitter hacker busted.
[34’50”] Oh! No! Our very own Doug ruins a brand new TV.

With Doug Aamoth and Paul Ducklin.

Intro and outro music by Edith Mudge.

---

WHERE TO FIND THE PODCAST ONLINE

You can listen to us on Soundcloud, Apple Podcasts, Google Podcasts, Spotify, Stitcher, Overcast and anywhere that good podcasts are found.

Or just drop the URL of our RSS feed into your favourite podcatcher software.

If you have any questions that you’d like us to answer on the podcast, you can contact us at tips@sophos.com, or simply leave us a comment below.

---

Yesterday, we wrote about a vaguely mysterious zero-day patch pushed out by Apple.

Like almost all Apple security fixes, the update arrived without any sort of warning, but unlike most Apple updates, only a single bug was listed on the “fix list,” and even by Apple’s brisk and efficient bug-listing standards, the information published was thin.

The update was issued only for the very latest supported incarnations of iOS, iPadOS and macOS (major release numbers iOS/iPadOS 14 and macOS 11).

Older but still-supported versions of iOS and macOS (iOS 12, as well as macOS 10.15 Catalina and 10.14 Mojave), along with watchOS and tvOS, didn’t get a mention at all.

Whether those not-yet-patched versions are vulnerable but are proving harder to fix, are vulnerable but simply aren’t going to be fixed, or don’t actually contain the buggy code at all, we aren’t yet sure.

This lone bug is known only by the impersonal, database-issued name of CVE-2021-30807, and is attributed to “an anonymous researcher”.

What was the bug?

Was the new bug the secret heart of a new jailbreak that got leaked to Apple ahead of time? Was it an exploit built for a cybercrime attack that never took place? Was it part of a law enforcement phone cracking toolkit that wasn’t supposed to become known but did?

We don’t know.

All we know is that Apple says that it “is aware of a report that this issue may have been actively exploited”.

That statement has a fair amount of distance in it: not that it was exploited, but that it may have been; and not first-hand experience but merely awareness of a report about it.

Of course, none of that really matters given that Apple made it clear that this was a dangerous vulnerability (a likely code execution hole with kernel privileges), and pushed out patch to fix it.

Many, if not most, eligible iPhone users will already have received the update automatically, and the rest can get easily it on demand via Settings > General > Software Update.

A splash of intrigue

Well, no sooner was Apple’s pach out than security researcher Saar Amar added a whole new of splash of intrigue into the existing puddle of of mystery.

Saar Amar, who describes himself as working at MSRC (Microsoft Security Response Center) and being into “reversing, exploits, Windows internals, virtualization, [and] mitigations”, tweeted that he’d discovered this very vulnerability back in March 2021, but hadn’t had time to exploit it properly and therefore hadn’t bothered to report it to Apple.

Of course, when the unannounced patch arrived, Saar Amar realised that someone else must have reproduced his research work work independently in the meantime.

Technically, he had tweeted that he’d discovered the vulnerability back in March 2021, but he didn’t disclose it at the time.

Back in March, he tweeted a SHA-512 hash of a file he’d created called description_and_poc.txt:

This one is not accessible from the app sandbox, but still pretty cool 🙂 sha512(description_and_poc.txt)=d36248d389e069acf611f8f69f93c0ec8b96da1ac9c84e3323355db7e4892fc26394bcef3cf1ef17a1a591f3a0443141534960e011da6371f03c70c7967b484b

— Saar Amar (@AmarSaar) March 29, 2021

Hashed disclosure

Tweeting a cryptographic hash is a simple way of proving that you know something at time X without revealing it until later on.

It would be impossible (or at least be computationally infeasbile, in the jargon) for someone else to come up with a file of their own that just happens to have the same hash as yours, even if they were to spend decades on the problem.

In other words, if you can later produce a file with the same hash that you declared at time X, you can convince everyone that you must indeed have had that file in your possession since at least X.

You couldn’t have constructed the file from scratch after you published the hash, therefore the file must have preceded the hash.

A similar technique for establishing “primacy of discovery” has been used for centuries. Oxford physicist Robert Hooke, for example, gave advance notice of his discovery of what is now Hooke’s Law by writing a teaser, in 1660, that said: The true theory of elasticity or springiness […]: ceiiinosssttuu“. When unscrambled, the letters at the end can be arranged to read: ut tensio, sic uis, which is Latin for the extension is proportional to the force, the result that he finally published in 1678. (If you hang a 2kg mass on the end of a spring, it will stretch twice as much as if you hang 1kg on it. That’s the essence of Hooke’s Law, which you may have been required to learn at school, and possibly to validate experimentally with rubber bands and steel weights.)

Ut tensio, sic uis

On the same day that Apple announced the fix for CVE-2021-30807, Saar Amar published a document on Github that had that very SHA-512 hash, as you can check for yourself.

The document includes proof-of-concept code for a local privilege escalation in the very same kernel function noted by Apple in its latest bulletin.

So, the secret’s now out about the nature of the mystery bug!

But why hold back?

Saar Amar says he put the basic vulnerability to one side in March because he intended to come back to it in August and to groom his code into a full-blown exploit (essentially, a proof of concept capable of delivering an actual jailbreak, not merely the promise of one) before disclosing it to Apple as a “high-quality submission”.

Holding onto bugs in this way in not unusual, for several reasons, including:

• If you’re an independent researcher living off bug bounties, a more complete (and, to be frank, a more dramatic and dangerous) exploit will generally earn you more money, possibly a lot more money. Of course, there is pressure not to wait too long because the bug will be worth nothing if someone else finds it too and reports it first.
• A more complete exploit typically involves a much more detailed chain of programmatic trickery, and therefore often gives the vendor much more more to work with, and may result in a much more comprehensive set of patches. This can improve security more significantly than just patching the initial hole that was spotted.

In this case, Saar Amar reported in his hashed document that this was a “very straightforward vulnerability”, and has subsequently written that “the vulnerability is as trivial and straightforward as it can get”.

With this in mind, of course, you could argue that putting the bug on ice for an expected five months (March to August) created a realistic risk that someone else would find it in the meantime, and that the bug-hunter who rediscovered it might decide to use it as a zero-day, and not for the purposes of responsible research.

(Indeed, that seems to be what happened.)

What to do?

Would you have disclosed the PoC directly to Apple back in March, as unpolished as you thought your work to be, in the hope that it would then be patched?

Or would you merely have staked your claim to it, in the tradition of Robert Hooke and many other enlightenment scientists, in the hope of writing up a bigger, better and more complete research article later in the year, and unquestionably getting it patched?

Have your say in the comments below! (You may remain anonymous.)

---

You might be forgiven for thinking that July 2021 was Microsoft’s month for cybersecurity vulnerabilities.

First there was PrintNightmare in several guises, followed by HiveNightmare (an entirely unrelated bug that nevertheless attracted the “Nightmare” moniker), followed by PetitPotam (which went down the cute aquatic mammal naming path).

Now, however, it’s Apple’s turn to be in the patch-right-now spotlight, with a somewhat under-announced emergency zero-day fix, just a few days after the company’s last, and much broader, security update.

This one doesn’t have a fancy name, but instead goes simply by CVE-2021-30807, and was reported, according to Apple “by an anonymous researcher”.

Indeed, all we know about it, and all Apple has said so far, is that:

An application may be able to execute arbitrary code with kernel privileges. Apple is aware of a report that this issue may have been actively exploited.

If the crooks knew about it first, that makes it a zero-day bug, the jargon term used when the patch came out after the Bad Guys had a head start, rather than before the Bad Guys figured it out for themselves.

(The name zero-day or 0-day denotes that there were zero days during which even the keenest and earliest adopters of official updates could have patched in advance.)

The vulnerability was apparently found in the IOMobileFrameBuffer kernel code, a component that helps userland applications (in other words, unprivileged software) to configure and use your device’s or computer’s display.

The functions supported by IOMobileFrameBuffer help with the management of settings such as video power saving, as well as colour and brightness correction.

We’re guessing that there’s a function in there that could be called in an unexpected and erroneous way that caused some sort of buffer overflow or buffer misdirection, where the kernel failed to check the parameters it was passed and therefore allowed an unprivileged program to shovel data into privileged memory where it wasn’t supposed to be.

That sort of bug frequently leads to DoS, or denial of service attacks, where a malicious program can deliberately crash the device at will.

Memory corruption bugs sometimes lead to information leakage holes, where a malicious program can read out other people’s data that is supposed to secret.

In the worst cases, however, the ability to make controlled but unauthorised modifications to kernel memory may cause even more serious kernel bugs.

These include elevation of privilege (EoP), where an otherwise uninteresting app suddenly gets the same sort of power as the operating system itself, or even remote code execution (RCE), where an otherwise innocent operation, such as viewing a web page or opening up an image, could trick the kernel into running completely untrusted code that didn’t come from Apple itself.

In particular, when Apple notes that “an application may be able to execute arbitrary code with kernel privileges”, you should assume that an attacker could not only steal your personal data without any visible warnings, but also effectively “jailbreak” your device, thereby bypassing Apple’s protective security boundaries entirely, without so much as a by-your-leave.

What to do?

Patch early, patch often!

Annoyingly, you won’t yet find mention of this update on Apple’s main security update portal, the well-known HT201222 web page.

Similarly, the company has not yet [2021-07-27T13:00Z] issued any of its customary email alerts about the issue.

You can read Apple’s very thin description of the update to iOS 14.7.1 and iPadOS 14.7.1 at HT212623, and of the macOS 11.5.1 update at HT 212622.

As far as we can tell, those are the only updates available at the moment, but we can’t tell you if iOS 12 and older-but-supported versions of macOS don’t have updates because they aren’t vulnerable, or simply because Apple hasn’t got around to patching them yet.

Watch this space for additional information!

As a reminder, you can check for updates and automatically jump to the head of the queue to fetch them (assuming you are not yet up-to-date) as follows:

• On an iPad or iPhone. Go to Settings > General > Software Update. If you are using iOS 14, you want 14.7.1.
• On a MacBook laptop or a desktop Mac. Go to Apple menu > System Preferences > Software Update. If you are using macOS Big Sur 11, you want 11.5.1.

---

French researcher Gilles Lionel, who goes by @topotam77, recently published proof-of-concept code that attackers could use to take over a Windows network.

The hack, which he has dubbed PetitPotam (which is a nod to the endangered Pygmy Hippopotamus, as far as we can tell), involves what’s known as an NTLM relay attack, which is a form of manipulator-in-the-middle (MitM) attack against Microsoft’s NTLM authentication system.

Microsoft has been advising everyone to avoid NTLM, short for NT LAN Manager, for more than a decade, because it doesn’t meet modern cryptographic security standards.

Way back in 2012, for example, pasword researcher Jeremi Gosney, who describes himself as “your friendly neighborhood password cracker”, described and built a standalone password cracking computer, using 25 graphics cards, that could brute-force all eight-character Windows passwords from their NTLM hashes in just six hours.

Unfortunately, NTLM authentication has proved hard to shake off altogether, with many network administrators keeping it alive because of legacy applications that can’t use the network without it.

Microsoft has added several NTLM mitigations over the years to try to close off various NTLM relay attack loopholes that remain.

This has steadily made it harder for attackers to trick Windows clients into talking to imposter authentication servers (the so-called “relays” in the attack) that could allow pasword hashes to be sniffed out, stolen and abused by attackers.

Ironically, one popular NTLM relay trick used in the past was to abuse the Microsoft Print System Remote Protocol (MS-RPRN) – what you could call a PrintNightmare of yesteryear.

As Lionel himself points out, however, “[using] MS-RPRN to coerce machine authentication is great but the service is often disabled nowadays by admins [in] most [organisations].”

His new proof-of-concept uses a similar attack (indeed, Lionel credits his code as “inspired by the previous work on MS-RPRN”), but abuses a different remote access protocol called MS-EFSRPC, short for Encrypting File System Remote Protocol.

Annoyingly, according to Lionel, turning off the underlying Encrypting Filing System service doesn’t seem to help, so the obvious mitigation that worked for old-school MS-RPRN attacks (namely, turning off the service that supported the at-risk protocol) won’t work here.

According to Microsoft, the PetitPotam code relies on abusing system functions that are enabled if all of these conditions apply:

• NTLM authentication is enabled in your domain.
• You are using Active Directory Certificate Services (AD CS).
• You are have either Certificate Authority Web Enrollment or Certificate Enrollment Web Service enabled.

What to do?

Obviously, the most robust defence is to stop using NTLM anywhere in your network.

If you genuinely don’t need it (and it’s been deprecated for more than a decade) you can turn it off on your domain controller to improve security for your whole network.

Retiring NTLM altogether means that you are no longer at risk of NTLM relay attacks of any sort, whether they’re caused by attackers try to abuse your printing services, the encrypting file system service, or any other remote access protocol.

If you can’t turn off NTLM authentication altogether, Microsoft has numerous other steps that you can take instead, but these deal specifically with the PetitPotam loophole rather than with getting rid of the outdated cryptography of NTLM itself.

The next-best mitigations involve turning off NTLM authentication on specific servers in your network, such as those running Active Directory Certificate Services.

The final mitigation involves turning on an IIS feature known as Extended Protection for Authentication (EPA), which is supposed to protect the abovementioned Certificate Authority Web Enrollment and Certificate Enrollment Web Service features from a relay attacks.

---