Perpetual IT

[00’21”] Norbert (huzzah for Norbert!) does tech support.
[02’38”] Europol digs into the ransomware scene.
[09’21”] Microsoft finds a wacky bug in Apple’s shell.
[18’09”] The Morris worm turns 33.
[21’57”] Edge on Linux phans the phlames.
[26’18”] Ola! Gibberish peculiarity textual solvage.

With Paul Ducklin and Doug Aamoth. 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 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.

---

No more facial recognition on Facebook!

Is it a publicity stunt?

Is it an admission that it simply doesn’t work very well?

Or is it a genuine attempt to disavow the sort of technology that gives both privacy advocates and cybersecurity experts the heebie-jeebies?

As Facebook, or more precisely the new holding comany Meta, puts it:

We will shut down the Face Recognition system on Facebook as part of a company-wide move to limit the use of facial recognition in our products.

To be fair to Facebook, the system has always been opt-in, meaning that the company’s servers never tried to guess which photos looked like you unless you turned the feature on yourself.

Once enabled, the company used images in which it already knew you appeared (or at least in which it assumed you appeared) in order to train its recognition software to identify you elsewhere online.

It referred to this process of learning to pick users out of crowds as constructing “individual facial recognition templates.”

At the top of the list of official reasons why you might want to opt in was to “[f]ind photos and videos you’re in so we can help you review or share content, suggest tags and provide more relevant content and feature recommendations”.

That was a sort-of two way street, helping people who actively wanted to promote themselves on Facebook to help Facebook itself target them with ads.

Very loosely speaking, Facebook would actively help you keep track of your appearances on Facebook for free, if you allowed Facebook to promote its paying customers to you in return, based on recognising your face.

Of course, Facebook also offered other reasons to turn this option on, notably that:

• By finding you in other people’s profile pictures, the company could help to warn you about accounts where someone was impersonating you.
• By identifying you by name in more photos, the company would benefit partially-sighted or visually impaired users who might otherwise not be able to recognise you.

But those positives were, it must be said, at the bottom of the list – it really was a trade off of ads-for-visibility, as much as for anything else.

Calling time on faces

Well, it looks as though Meta has finally decided that the benefits are outweighed by the risks, and so it’s calling time, for now, on building, storing and using facial recognition data.

Facebook, ah, Meta, does admit that only one-third of its users ever opted in, though it doesn’t say whether that was down to a sizeable majority of users actively deciding, “No”, or merely due to a significant proportion not realising they could say “Yes”.

If you have this feature turned on, then it’s going to stop working: all existing facial recognition templates will be gradually deleted from Facebook’s servers; automatic photo-tagging will, as a consequence, no longer be possible; and the Face recognition option in Facebook’s menus will disappear.

What to do?

• If you haven’t opted in to this feature, there’s nothing you can do, because you don’t have a “template” to delete. Sit back and enjoy the sensation that Facebook has come round to your point of view.
• If you have opted in, you can opt out manually right away if you like, now you know that even Facebook thinks it’s not a great idea. But you don’t need to do anything because your stored facial recognition data will be deleted anyway in due course.
• If you have strong opinions on using or not using technology of this sort, don’t be afraid to make your voice heard. Meta admits that it is “civil society groups and regulators who are leading [the] discussion [on facial recognition]”, and that it intends to “continue engaging in that conversation”.
• Be aware before you share. If you willingly identify yourself via images you post on Facebook, it’s not just Meta who “knows” what you look like. In other words, Meta’s own U-turn on facial recognition doesn’t stop other people (or other people’s computers, or other people’s business ventures) using online images where you explicitly identify yourself as tools to track you online automatically.

---

In an intriguingly worded news statement issued today, Europol has announced police action in both Switzerland and Ukraine against 12 cybercrime suspects.

The document doesn’t actually use words such as a “arrested” or “charged with criminal offences”, saying merely that:

A total of 12 individuals wreaking havoc across the world with ransomware attacks against critical infrastructure have been targeted as the result of a law enforcement and judicial operation involving eight countries. […]

As the result of the action [on 26 October 2021], over USD 52,000 in cash was seized, alongside 5 luxury vehicles. A number of electronic devices are currently being forensically examined to secure evidence and identify new investigative leads.

What we don’t know is whether the cars were seized because they are valuable and suspected to be the proceeds of crime, or because cars, like mobile phones, are an important source of forensic evidence in today’s investigative world. (Or both, of course.)

In previous reports we’ve written of recent ransomare busts, cars were seized, along with cash, phones, computers and more – there wasn’t a beater amongst the towed-away vehicles that we could see – but in one of the bust videos, cybercops can be seen checking out computer gear inside the car itself before allowing it to be loaded onto the towtruck.

Job roles in a ransomware gang

The alleged crooks in this operation don’t seem to be the core criminals who produced the ransomware code, dealt with the encryption/decryption process, and handled the blackmail payments from the victims.

Instead, they seem to be from various other arms of the operation.

As you probably know, a lot of ransomware gangs these days consist of what you might call a cybercrime “ecosystem” or “subculture”, with the core coders surrounded by numerous affiliates or associates who take the malware out into the world and use it actively in attacks.

Europol lists the following “job titles” for the suspects targeted in this operation, and described the work duties that the many human cogs in the ransomware machine are alleged to have performed:

• Job role: Network penetration. Work duties: Use multiple mechanisms to compromise IT networks, including brute force attacks, SQL injections, stolen credentials and phishing emails with malicious attachments.
• Job role: Lateral movement. Work duties: Spread through network. Deploy malware along the way, such as Trickbot or post-exploitation frameworks such as Cobalt Strike or PowerShell Empire, to stay undetected while gaining further access.
• Job role: Network exploration. Work duties: Probe for IT weaknesses, sometimes for months.
• Job role: Ransomware detonation. Work duties: Unleash a final ransomware payload, scrambling as many files as possible on the network, using malware including LockerGoga, MegaCortex and Dharma. Present a blackmail note demanding a ransom payment.
• Job role: Money laundering. Work duties: A number of the individuals interrogated are suspected of being in charge of laundering the ransom payments: they would funnel the Bitcoin ransom payments through mixing services, before cashing out the ill-gotten gains.

How the crooks make things worse

The dispassionate list given above by Europol, breaking down the modern-day “commercialised” ransomware process into well-defined tasks, is scary enough.

But we’d also like you to read an astonishing and fascinating report from Sophos Managed Threat Respose expert Peter Mackenzie that we published yesterday.

Entitled The top 10 ways ransomware operators ramp up the pressure to pay, it gives you an even more startling and uncompromising insight into just how aggressive and uncompromsing these crooks can be.

Amongst other things, ransomware crooks will email employees individually (and sometimes even phone up IT staff directly) to show off the personal data they’ve stolen, presumably in the hope of getting staff to turn on their employers to urge that the ransom be paid.

We’ve personally sat wide-eyed at work while Peter showed us (with consent, of course) a video recording of an IT manager, in the thick of a ransomware crisis, receiving a personal call from the criminals in which they calmly but chillingly read back to him his social security number and other personal data that they’d extracted from the company network.

That’s the sort of thing that gets your attention!

As Peter writes in his jaw-dropping article:

Attackers generally dig out information such as corporate and personal bank details, invoices, payroll information, details of disciplinary cases, passports, drivers’ licenses, social security numbers, and more, belonging to employees and customers.

For instance, in a recent Conti ransomware attack on a transport logistics provider that Sophos Rapid Response investigated, the attackers had exfiltrated details of active accident investigations, featuring the names of the drivers involved, fatalities and other related information. The fact that such information was about to fall into the public domain added significant stress to an already difficult situation.

Peter has also included a chilling audio voicemail sent by affiliates of the SunCrypt gang, with the permission of the organisation targeted in that attack.

It’s three minutes long, and calmly serious, in a laconic tone that makes it even more unnerving:

[embedded content]

If you don’t pay, the crooks point out, they’ll do numerous bad things to you, such as dumping your data, alerting your competitors, selling off backdoor access to other crooks, and informing the media.

After reeling off the list, they say, with dismissive self-assurance, “Anyway, this will be the last day of your business,” before warning you: “Think about your future and your families.”

Peter also describes how some ransomware crooks have publicised their extortion demands to affected staff by dumping a ransom note on every printer on the network, including those visible to the public, such as point of sale terminals…

…definitely not the sort of verbiage that customers expect to see mixed in with their list of purchases!

What next?

With no mention yet of arrests or criminal charges, but an obvious focus on operational intelligence and forensic analysis (including those five fancy cars), we’ll be interested to see what Europol announces next.

Just last week, we reported on a legally authorised “hack back” operation against the REvil ransomware crew by the FBI and intelligence groups described as hailing from “multiple countries”:

Perhaps the worm is at last beginning to turn on the ransomware scene?

Learn more about Sophos Managed Threat Response here:
Sophos MTR – Expert Led Response  ▶
24/7 threat hunting, detection, and response  ▶

When we wrote about Apple’s latest security patches earlier this week, we noted that:

There are 37 listed fixes covering everything from AppKit to zsh. 15 of these were of the “malicious application may be able to execute arbitrary code” sort, with 9 of those bugs dealing with code execution bugs in the kernel itself.

We mentioned zsh, Apple’s default command shell program, mainly because it starts with the letter Z, and thus gave us an opportunity to use the A-to-Z metaphor.

Apple’s own description of the bug, dubbed CVE-2021-30892, said simply:

 Impact: A malicious application may be able to modify protected parts of the file system Description: An inherited permissions issue was addressed with additional restrictions CVE-2021-30892: Jonathan Bar Or of Microsoft

Linux users (and, increasingly, Windows users with the Subsystem for Linux installed) are probably more familiar with bash, which used to be Apple’s command shell of choice, but Apple adopted the similar-and-mostly compatible zsh variant almost exactly two years ago for licensing reasons.

A bit more to it

As we now know, following an article published by Microsoft researchers after Apple’s patches came out, there was a bit more to it that just “modifying protected parts” of the file system.

Simply put, the bug was gloriously simple (or ingloriously so, if you prefer).

Like many command shells, zsh consults a range of different configuration files when it starts up, so that sysadmins can tweak its behaviour to suit corporate needs, and individual users can add their own customisation on top of that.

Unix and Unix-like system commands are full of these “magic files”, as a glance at the /etc directory will remind you.

Some system utilities have individual files that adapt their behaviour, such as /etc/resolv.conf to control how the operating system’s low-level DNS software looks up server names online.

Others services have subdirectories to tell them how to behave on startup, such as /etc/ssh/ to configure vital options used by the SSH remote access software.

And some software has both, such as bash and various other Unix shells, which consult both the file /etc/profile and the contents of the directory /etc/profile.d/ to look for shell scripts to run before launching the user’s chosen script or opening a terminal window.

Well, zsh has a comprehensive set of pre-execution configuration files of its own, including:

 /etc/zshenv /etc/zprofile /etc/zshrc /etc/zlogin /etc/zlogout $ZDOTDIR/.zshenv $ZDOTDIR/.zprofile $ZDOTDIR/.zshrc $ZDOTDIR/.zlogin $ZDOTDIR/.zlogout

(In the list above, taken from the zsh manual page, the text string $ZDOTDIR/ is usually, but not necessarily, replaced with the name of your home directory, e.g. /home/yourusername/.)

That’s a lot of places where a maliciously minded person could implant their own script code to subvert the behaviour of almost every launch of the shell…

…and shell scripts are widely used not only by users wanting to automate repetitive tasks (in the same way that Windows users deploy BAT or PS1 files), but also by system configuration and installation utilities.

Of course, anyone who already has sysdmin powers via the root account (user ID zero) on a traditional Unix-like system, and who could therefore modify files such as /etc/zshenv, would already have the sort of power needed to do almost anything they wanted anyway.

Going rootless

Apple’s attempt to rein in the traditionally unimpeded and absolute power of the Unix root user is known formally as SIP, short for System Integrity Protection, or informally by the cooler name rootless.

The idea is to define system operations that even the root user can’t perform, such as loading unsigned kernel drivers, accessing key files on the disk, altering the boot-time configuration, or peeking into the kernel with a debugger.

SIP therefore creates a sort of “ueberoot” user whose blessing is required even for root itself to do certain dangerous functions, such as tweaking the kernel.

There’s a Catch-22, though, namely that SIP has to have a special, seamless way of allowing certain programs or processes to run with at least partial ueberoot powers, for example during a system security update, wher critical operating system files may need to be removed, modified or added.

As Microsoft researcher Jonathan Bar Or explains, Apple’s approach to the need for occasional exceptions to the strict SIP lockdown rules involves a secure installation process called system_­installd.

The suffix -d on a Unix process name typically denotes a daemon (properly pronounced “die-moan” in English), the Unix equivalent of a Windows service. Daemons execute in the background and keep on running even after the user who started them logs out.

Exceptions for signed packages

The system_installd daemon regulates the execution of privileged Apple .pkg files (short for software package installer), ensuring, amongst other checks, that they are digitally signed by Apple itself.

And, like many Unix/Linux package file formats, .pkg bundles can contain various shell scripts that run as part of the package installation or upgrade process, including a special post-install script for finalising the operation.

You can guess where this is going.

Bar Or noticed that even though system_installd was essentially “blessing” any package scripts it ran with ueberroot powers, it nevertheless executed those post-install scripts by running zsh in the regular way.

So, even those trusted invocations of zsh-with-ueberoot-powers consulted the regular /etc/zshenv file first, and executed any commands in that file with system_installd privileges.

In other words, a writable-by-root file could be used to inject runnable-by-ueberroot commands into Apple’s trusted system configuration and update process.

Bar Or named this vulnerability shrootless, because it’s a way of getting a rootless shell without having rootless superpowers already, a classic EoP, or elevation of privilege attack.

(We’d have gone down the satirical path and called this one shrootmore, but we didn’t figure out the bug so we don’t get a say.)

What to do?

• Make sure you have Apple’s latest updates. This bug was present in all currently supported versions of macOS, namely Catalina (macOS 10), Big Sur (macOS 11) and Monterey (macOS 12). A convenient summary of the update names and numbers for all versions can be found in our Monterey security update advisory from earlier this week.
• Learn your configuration files. On any Unix/Linux system, take the trouble to find out which system files can influence the behaviour of what system features. As shown above, zsh alone has 10 different configuration files that can alter its behaviour completely. If you’re new to Unix/Linux, be prepared to put as much effort into learning your way around system configuration files as you did to plumbing the depths of the Windows registry. Unexpected changes to these files can be good IoCs (indicators of compromise) in an otherwise low-key attack.
• Code for simplicity. If you’re a programmer, and you’re building software tools that could be used in a high-security environment, make sure you include a simple way of launching your software with all its implicit configuration dependencies turned off. Implicit configuration files are convenient for day-to-day work, but they can easily turn into cybersecurity backdoors when they are inadvertently consulted during secure operations.

Forcing secure programmers to “say explicitly what they mean” when they want use your code securely is a convenience and a strength, not an inconvenience or a weakness.

---

We’ve been using Edge on Linux for quite some time, first in Dev Build form, then in its Beta flavour…

…but when we went to check Microsoft’s repository tonight, we were surprised to see a build package that had arrived just an hour earlier with the name microsoft-edge-stable-95.0.1020.38-1.x86_64.rpm.

So, the Eagle, or whatever you want to call it, has finally landed!

As you probably know, Edge no longer has Microsoft’s in-house HTML and JavaScript engines at its core, but is based, like many other contemporary browsers, on the Google-derived open source Chromium project.

Chromium also also powers browsers such as Brave, Opera, Vivaldi and, of course, Google’s own Chrome, which, ironically, perhaps, isn’t itself open source.

That leaves just three other mainstream browser engines these days, one of which we’d all love to put behind us forever, but it just keeps hanging around semi-invisibly in the background.

Alongside all the Chromium browsers out there, we’ve also got: Apple’s Safari, based on a core known as WebKit; Mozilla’s Firefox; and Microsoft’s Internet Explorer core, often referred to as MSHTML after the program file mshtml.dll that is the heart of its executable code (and still the source of the sort of vulnerabilities we all hoped we’d left behind).

When choice isn’t really

By the way, even if you’re using a non-Safari browser such as Firefox or Chrome on your iPhone or iPad, you’re nevertheless running the WebKit engine, with the browser itself essentially being a “skin” on top of Apple’s core code.

That’s one of Apple’s rules: any app that handles web content must use WebKit, or else it will be excluded from the App Store – and (unless you use a trick involving Enterprise Provisioning, normally reserved for companies to install proprietary corporate apps), that’s the only way to distribute your software.

Does it matter?

We’re happy to see Edge for Linux finally make Stable and Official status, because we find it handy to have two distinct browsers on any operating system platform we use.

If nothing else, running two different browsers that share no code or configuration data means that you can use one for logged-in sessions and the other to see what the same websites look like when you aren’t logged in.

That’s especially handy if you’re a content creator, because it makes it easy to check exactly what your readers are seeing out there in the real world – which often looks completely different to the “idealised” view of things you get while you’re logged in.

Many Linux users probably already use Chrome (or Chromium if they prefer to stay away from closed-source browsers), but those products aren’t available for all distros…

…and if you don’t have any Google accounts, or you’re not a Google fan, then the Google-centricity of Chrome might be something you neither need nor really want.

We use the rolling-release version of Slackware Linux, or Slackware GNU/Linux if you absolutely insist, a distro that Chrome doesn’t support at all.

However, simply extracting the /opt/microsoft/edge directory tree from the the Yum repository shown above works a treat. (Yum and RPM files are usually associated with RedHat’s commercially oriented Linux distros, but the distro contents worked agnostically on our laptop.)

What to do?

Things to like about Edge for Linux. It’s fast; it looks good; it may work for you where Chrome builds won’t; and it’s really easy to configure it to delete all its cookies, web data, authentication tokens and other historical baggage automatically every time you exit the browser.

(We can’t figure out how to clear browsing data automatically on Chrome, and therefore prefer Firefox and Edge, where it’s easy to do this without plugins or scripted hacks.)

What’s not to like. You need to take care to review all the default settings before first use, because there are some privacy settings that security conscious users will want to change.

In fact, taking a trip round Edge’s privacy options on Linux – there are lots of them – is worth doing, so that you can learn to do it on Windows as well.

In particular, we recommend visiting the following sub-options under Settings:

• Profiles. Be sure to visit all suboptions to ensure you are happy with the defaults. Most people will be, but we always turn off features that autofill data , remember passwords by default or keep payment card data for later.
• Privacy, search and services. We always go straight for Strict tracking protection in both Edge and Firefox, and we haven’t found any sites (at least ones we want to keep using) that don’t work. This page also has the Choose what to clear every time you close the browser option, and lets you turn off data collection relating to diagnostics and advertising.
• Privacy, search and services > Address bar and search. Don’t forget to go here. It’s easily missed, and by default Edge (like many other browsers) enables its Search and suggest as you type options. We strongly recommend turning these off, so that you don’t hand over your search terms until you’re really ready to do so.
• Cookies and site permissions. All the contentious options, such as getting your location and using your camera, are set to Ask first by default, but there are some you may want to turn off altogether so you can’t enable them by mistake. (Our Never allow choices include location, payment handlers, USB devices and motion sensors.)
• System and performance. This is where you can turn off Continue running background extensions and apps when Microsoft Edge is closed, which is enabled by default. We prefer our browser to shut down completely when we shut it down.

Five years ago, we’d have laughed if you’d suggested that by 2021 our Top Two “workflow” apps on Linux would not only be from Microsoft but also be open source…

…but they are.

We wrote this article in the Visual Studio Code editor for Linux, and uploaded it into WordPress using the landed-two-hours-ago-in-Stable-form Microsoft Edge for Linux.

Didn’t see that coming.

---

---