Perpetual IT

Popular collaboration product Zimbra has warned customers to apply a software patch urgently to close a security hole that it says “could potentially impact the confidentiality and integrity of your data.”

The vulnerability is what’s known as an XSS bug, short for cross-site scripting, whereby performing an innocent-looking operation via site X, such as clicking through to site Y, gives the operator of site X a sneaky chance to implant rogue JavaScript code into the web pages that your browser receives back from Y.

This, in turn, means that X may end up with access to your account on site Y, by reading out and perhaps even modifying data that would otherwise be private to Y, such as your account details, login cookies, authentication tokens, transaction history, and so on.

The abbreviation XSS is a self-descriptive name, because the roguery essentially involves pushing untrusted scripts across from one site into the otherwise-trusted content of another site…

…all without needing to break into the other site in advance to hack its HTML files or JavaScript code directly.

Patched but not published

Although the bug has now been patched in Zimbra’s code, and the company says that “it has applied this fix to the July release”, it hasn’t yet published that version.

But the patch turns out to be urgent enough to be needed right away, because it was spotted in a real-life cyberattack by a security researcher at Google.

That makes it a dreaded zero-day exploit, the jargon term used for security holes that the Bad Guys find first and keep to themselves.

Zimbra has therefore warned its customers to apply the fix themselves by hand, which requires a single-line edit to a single data file in the product’s installation directory.

Zimbra didn’t quite use Naked Security’s very own rhyming reminder of Do not delay/Do it today, but the copmany’s techies said something with the same level of urgency in their own official security bulletin:

Take Action. Apply Fix Manually.

We understand that you may want to take action sooner rather than later to protect your data.

To maintain the highest level of security, we kindly request your cooperation to apply the fix manually on all of your mailbox nodes.

XSS explained

Simply put, XSS attacks usually involve tricking a server into generating a web page that trustingly includes data submitted from outside, without checking that the data is safe to send directly to the user’s browser.

As curious (or as unlikely) as this might sound at first, remember that repeating or reflecting input back into your browser is perfectly normal, for example when a site wants to to confirm data you’ve just entered or to report the results of a search.

If you were browsing a shopping site, for instance, and you wanted to see if they had any Holy Grails for sale, you’d expect to type Holy Grail into a search box, which might end up being submitted to the site in a URL like this:

https://example.com/search/?product=Holy%20Grail

(URLs can’t contain spaces, so the space character between the words is converted by your browser into %20, where 20 is the ASCII code for space in hexadecimal.)

And you wouldn’t be surprised to see the very same words repeated in the page that came back, for example like this:

You searched for: Holy Grail Sorry. We don't have any in stock.

Now imagine that you tried searching for a bizarrely-named product called a Holy<br>Grail instead, just to see what happened.

If you got back a page something like this…

You searched for: Holy
Grail Sorry. We don't have any in stock.

…instead of what you’d expect, namely…

You searched for: Holy<br>Grail Sorry. We don't have any in stock.

…then you’d immediately know that the server at the other end was being careless with so-called “special” characters such as < (less-than sign) and > (greater-than sign), which are used to specify HTML commands, not merely HTML data.

The HTML sequence <br> doesn’t literally means “display the text less-than sign letter-b letter-r greater-than sign“, but is instead an HTML tag, or command, that means “insert a line break at this point”.

A server that wants to send your browser a less-than sign to print on the screen needs to use the special sequence < instead. (Greater-than signs, as you can imgaine, are encoded as >.)

Of course, this means that the ampersand character (&) has a special meaning, too, so ampersands-to-be-printed-out have to be encoded as &, along with double-quote marks (") and single-quotes or apostrophe marks (').

In real life, the problem with cross-site-scriptable output trickery is not “mostly harmless” HTML commands such as <br>, which disrupts the page layout, but dangerous HTML tags such as <script>, which allow you to embed JavaScript code right there, directly in the web page itself.

Once you’ve spotted that a site doesn’t handle searching for <br> properly, your next attempt might be to search for something like Holy<script>alert('Ooops')</script>Grail instead.

If that search term is returned precisely as you sent it over in the first place, the effect will be to run the JavaScript function alert() and to pop up a message in your browser saying Ooops.

As you can imagine, crooks who discover how to poison websites with trial alert() popups quickly switch to using their new-found XSS hole to perform much more devious operations.

These may include retrieving or modifying data relevant to your account, sending messages or authorising actions in your name, and perhaps grabbing hold of authentication cookies that will let the criminals themselves log directly back into your account later on.

Incidentally, the one-line patch you’re urged to apply in the Zimbra product directory involves changing an item in a built-in web form from this…

<input name="st" type="hidden" value="${param.st}"/>

…into a safer format, so that the value field (which will be sent to your browser as text but never shown, so you won’t even know it’s there while accessing the site) is constructed as follows:

<input name="st" type="hidden" value="${fn:escapeXml(param.st)}"/>

This new-look line tells the server (which is written in Java) to apply the security-conscious Java function escapeXml() to the value of the stfield first.

As you’ve probably guessed, escapeXml() ensures that any lefover <, >, &, " and ' characters in a text string are rewritten in their correct and XSS-resistant formats, using <, >, &, " and ' instead.

Safety first!

What to do?

Follow the hand-patching instructions on Zimbra’s website.

We’re assuming that companies that run their own Zimbra instances (or pay someone else to run them on their behalf) won’t find the patch technically complex to perform, and will quickly create a custom script or program to do it for them.

Just don’t forget that you need to repeat the patching process, as Zimbra reminds you, on all your mailbox nodes.

SING A SONG OF SUPERCOOKIES

Remembering the slide rule. What you need to know about Patch Tuesday. Supercookie surveillance shenanigans. When bugs arrive in pairs. Apple’s rapid patch that needed a rapid patch. User-Agent considered harmful.

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 and anywhere that good podcasts are found. Or just drop the URL of our RSS feed into your favourite podcatcher.

READ THE TRANSCRIPT

This Tuesday, 2023-07-11, was Microsoft’s Patch Tuesday for July 2023, so here’s a brief reminder to do two things:

• Patch early, patch often.

More than 100 vulnerabilities were patched this month, including four zero-day security holes for which working exploit code already exists.

Even though everyone was at risk until Tuesday, it’s important not to be one of those people who remains at risk longer than necessary.

When defenders close off holes that cybercriminals are already abusing, you should assume one thing: those crooks are going to focus their attention on the stragglers against whom those now-patched attacks are still effective, in order to extract the last “value” out of their former zero-day holes.

• Head to our sister site Sophos News for official details about on the patches.

We’ve published an unavoidably lengthy list, based on Microsoft’s official data, to help you navigate through the many CVE numbers and bug explanations relevant to the numerous products and services affected.

We think you’ll find the information easier to work with, as a starting point, than Redmond’s own tables and charts.

We’ve also published an in-depth article about an ongoing security issue that was serious enough to be addressed in a Microsoft Advisory (ADV230001).

We’ve given you important, interesting and informative detail about the ongoing saga of malicious kernel drivers, many of them signed and approved by Microsoft itself, that have finally been blocked by Windows.

Two quick takeaways

As we’ve mentioned above, you can read up about this month’s Microsoft security fixes on Sophos News, but there are two parts of this month’s patch set that we thought we’d cover here.

The first important item is the matter of those four zero-days that we already referred to.

CVE-2023-32049 and CVE-2023-35311 are security bypass exploits, meaning that criminals can abuse these bugs to sidestep security protections that would otherwise jump in to help you avoid malware infection or a possible attack.

Between them, these bugs allow criminals to present you with booby-trapped web URLs in your browser, or malicious email content in Outlook, that would usually pop up a warning to remind you of the risks, and to give you a chance to bail out and protect yourself…

…without those warnings appearing at all.

Although this isn’t as dangerous as a true remote code execution (RCE) hole, where an outsider could trick you into running a rogue program just by viewing a web page or by starting a particular network service, you can see why security bugs of this sort are gold dust to cybercriminals.

Bypasses for security warnings that users have come to expect, and perhaps to rely upon, provide a simple and effective way of luring even well-informed and careful users into making costly mistakes.

There are also patches for two zero-day elevation of privilege (EoP) exploits.

EoP exploits mean tha crooks who are already in your network, but without the ability to do much damage or to steal much data, can promote themselves to sysadmin level and thus essentially issue themselves “access all areas” security badges.

Dodgy driver problems

The second important item is the matter of ADV230001, Microsoft’s advisory entitled Guidance on Microsoft signed drivers being used maliciously.

This saga started back at the end of 2022, when Sophos researchers came across something that you don’t see anywhere near as often as you used to, namely rogue Windows kernel drivers:

The great thing about kernel drivers is that they provide a way for third-party software to get usefully involved at the very lowest levels of the operating system, such as supporting esoteric computer hardware, providing additional cybersecurity protection, monitoring and managing otherwise invisible details including memory allocation and resource utilisation, and more.

A kernel-level anti-virus program, for example, can jump in before every program runs, and not merely report but also actively block rogue software from loading at all.

The not-so-great thing about kernel drivers is that they offer the very same super-low-level, mega-dangerous and potentially subversive capabilities to malware creators and cybercriminals, too.

Indeed, kernel-level malware tools, often known as a rootkits, can work the same sort of low-level magic in reverse, for example by watching out for known-bad programs and preventing them from being blocked in the first place, and even making them apparently invisible to scanning tools, directory listing software and inventory-taking applications.

The name rootkit comes from early Unix malware, and references the idea of a kit of software tools that helps you not only to get administrator-level access in the first place (known as root on Unix and Unix-like systems), but also to go unnoticed for as long as possible.

Driver clampdown

As a result of the proliferation and abuse of rootkits on Windows XP, Microsoft started clamping down on kernel drivers, starting back in Windows Vista.

Indeed, in current versions of Windows where Secure Boot is enabled, you can only load kernel drivers that have been officially reviewed and digitally signed by Microsoft itself. (There are exceptions to this rule, but you can’t easily create and load a kernel driver today without sending it to Microsoft for scrutiny first.)

Although you may, albeit reluctantly, accept that code validation services such as Apple’s App Store and Google’s Play Store will inevitably be permeable to malware, given that their goal is to examine and approve huge numbers of third-party apps quickly, automatically and objectively…

…you might reasonably expect that kernel drivers, given their dangerous powers and their comparative rarity compared to regular applications, would be as good as impossible to sneak past the Windows vetting process.

Last December’s rogue driver discoveries by SophosLabs, however, ultimately turned up a significant list of kernel-level malware, including 100 drivers signed “personally” by Microsoft itself.

68 of the Microsoft-approved rogue drivers were anti-anti-virus tools, aimed at killing off security software “from underneath” by abusing the power and authority of the operating system.

The rest were more general rootkits aimed at spying on and manipulating data inside the operating system, where information as intimate as individual network packets to and from every running program can be snooped, surveilled and sneakily altered.

To learn more about the fascinating backstory of these wrongly-signed crimeware drivers, please read our article entitled Microsoft revokes malicious drivers in Patch Tuesday Culling:

What to do?

We said it at the top, albeit in slightly different words: Don’t delay; do it today.

If you’re responsible for your own computer, just go to Settings > Windows Update > Check for updates to see if you’re up-to-date or not.

Don’t forget that the updates won’t be completed until you reboot your computer, so aim to do that sooner rather than later.

Betteridge’s Law of Headlines insists that any headline posed as a question can instantly be answered with a simple “No.”

Apparently, the theory behind this witticism (it’s not actually a Law, nor yet a rule, nor even in fact anything more than a suggestion) is that if the author knew what they were talking about, and had real evidence to support their case, they’d have written the headline as an undiluted fact.

Well, we’re not journalists here on Naked Security, so fortunately we’re not bound by this law.

The ruthless answer to our own question in the headline above is, “No one knows except Apple, and Apple isn’t saying.”

A better but admittedly middle-of-the-road answer is, “Wait and see.”

Rapid responses

This story started late yesterday, at the tail end of 2023-06-10 UK time, when we excitedly [do you mean ‘excitably?’ – Ed.] wrote an advisory about Apple’s second-ever Rapid Security Response (RSR):

These RSRs are, as we explained previously, Apple’s effort to deliver single-issue emergency fixes as promptly as well-managed open source project generally do, where zero-day patches often come out within a day or two of a problem being found, with updates-to-the-updates following promptly if further investigations reveal further issues needing to be fixed.

One reason open source projects can take this sort of approach is that they usually provide a download page with the full source code of every officially-released version ever, so that if you rush to adopt the latest fixes in hours, rather than in days or weeks, and they don’t work out, there’s no barrier to rolling back to the previous version until the fix-for-the-fix is ready.

Apple’s offical upgrade pathway, however, at least for its mobile devices, has always been to supply full, system-level patches that can never be rolled back, because Apple doesn’t like the idea of users deliberately downgrading their own systems in order to exploit old bugs for the purpose of jailbreaking their own devices or installing alternative operating systems.

As a result, even when Apple produced emergency one-bug or two-bug fixes for zero-day holes that were already being actively exploited, the company needed to come up with (and you needed to put your faith in) what was essentially a one-way upgrade, even though all you really needed was a minmalistic update to one component of the system to patch a clear and present danger.

Enter the RSR process, allowing rapid patches that you can install in a hurry, that don’t require you to take your phone offline for 15 to 45 minutes of repeated reboots, and that you can later remove (and reinstall, and remove, and so on) if you decide that the cure was worse than the disease.

Bugs patched temporarily via an RSR will be patched permanently in the next full version upgrade…

…so that RSRs don’t need or get a whole new version number of their own.

Instead, they get a sequence letter appended, so that the first Rapid Security Response for iOS 16.5.1 (which came out yesterday) is displayed in Settings > General > About as 16.5.1 (a).

(We don’t know what happens if the sequence ever goes past (z), but we’d be willing to take a small wager on the answer being (aa), or perhaps (za) if alphabetic sortability is considered important.)

Here today, gone tomorrow

Anyway, just a few short hours after advising everyone to get iOS and iPadOS 16.5.1 (a), because it fixes a zero-day exploit in Apple’s WebKit code and could therefore almost certainly be abused for malware nastinesses such as implanting spyware or grabbing private data from your phone…

…commenters (special thanks to John Michael Leslie, who posted on our Facebook page) started reporting that the update was no longer showing up when they used Settings > General > Software Update to try to update their devices.

Apple’s own security portal still lists [2023-07-11T15:00:00Z] the most recent udpates as macOS 13.4.1 (a) and iOS/iPadOS 16.5.1 (a), dated 2023-07-10, with no notes about whether they’ve officially been suspended or not.

But reports via the MacRumors site suggest that the updates have been withdrawn for the time being.

One suggested reason is that Apple’s Safari browser now identifies itself in web requests with a User-Agent string that includes the appendage (a) in its veraion number.

Here’s what we saw when we pointed our updated Safari browser on iOS at a listening TCP socket (formatted with line breaks to improve legibility):

$ ncat -vv -l 9999
Ncat: Version 7.94 ( https://nmap.org/ncat )
Ncat: Listening on :::9999
Ncat: Listening on 0.0.0.0:9999
Ncat: Connection from 10.42.42.1.
Ncat: Connection from 10.42.42.1:13337.
GET / HTTP/1.1
Host: 10.42.42.42:9999
Upgrade-Insecure-Requests: 1
Accept: text/html,application/xhtml+xml, application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 16_5_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.5.2 (a) Mobile/15E148 Safari/604.1
Accept-Language: en-GB,en;q=0.9
Accept-Encoding: gzip, deflate
Connection: keep-alive NCAT DEBUG: Closing fd 5.

According to some MacRumors commentators, that Version/ string, consisting as it does of the usual numbers and dots along with some weird and unexpected text in round brackets, is confusing some websites.

(Ironically, the sites we’ve seen blamed in this apparently version-string-misparsing-blame-game all seem to be services that are much more commonly accessed by dedicated apps than via a browser, but the theory seems to be that they apparently choke on that 16.5.2 (a) version identifier if you decide to visit them with an updated version of Safari.)

What to do?

Strictly speaking, only Apple knows what’s going on here, and it’s not saying. (At least, not officially via its security portal (HT201222) or its About Rapid Security Responses page (HT201224.)

We suggest, if you already have the update, that you don’t remove it unless it genuinely interferes with your ability to use your phone with the websites or apps you need for work, or unless your own IT department explicitly tells you to roll back to the “non-(a)” flavour of macOS, iOS or iPadOS.

After all, this update was deemed suitable for a rapid response because the exploit it fixes is an in-the-wild, browser-based remote code execution (RCE) hole.

If you do need or wish to remove the RSR, you can do this:

• If you have an iPhone or iPad. Go to Settings > General > About > iOS/iPadOS Version and choose Remove Security Response.
• If you have a Mac. Go to System Settings > General > About and click the (i) icon at the end of item entitled macOS Ventura.

Note that we installed the RSR right away on macOS Ventura 13.4.1 and iOS 16.5.1, and haven’t had any problems browsing to our usual web haunts via Safari or Edge. (Remember that all browsers use WebKit on Apple mobile devices!)

Therefore we don’t intend to remove the update, and we’re not willing to do so experimentally, because we have no idea whether we’ll be able to reinstall it again afterwards.

Commenters have suggested that the patch simply doesn’t get reported when they try from an unpatched device, but we haven’t tried re-patching a previously-patched device to see if that gives you a magic ticket to fetch the update again.

Simply put:

• If you’ve already downloaded macOS 13.4.1 (a) or iOS/iPadOS 16.5.1 (a), keep the update unless you absolutely have to get rid of it, given that it’s securing you against a zero-day hole.
• If you installed it and really need or want to remove it, see our instructions above, but assume that you won’t be able to reinstall it later, and will therefore put yourself into the third category below.
• If you haven’t got it yet, watch this space. We’re guessing that the (a) patch will rapidly be replaced by a (b) patch, because the whole idea of these “lettered updates” is that they’re meant to be rapid responses. But only Apple knows for sure.

We’ll patch our usual advice from yesterday by saying: Do not delay; do it as soon as Apple and your device will let you.

The second-ever Apple Rapid Security Response just came out.

That’s where the very latest versions of macOS, iOS and iPadOS get emergency patches that:

• Don’t take as long for Apple to build, test and publish as a full version update would.
• Don’t take as long to download when you decide to fetch them.
• Don’t take as long to install and activate when you actually apply them.
• Don’t make irreversible changes that can’t be reversed if something goes wrong.

Speed is of the essence

The last point above is surprisingly important, given that Apple absolutely will not allow you to uninstall full-on system updates to your iPhones or iPads, even if you find that they cause genuine trouble and you wish you hadn’t applied them in the first place.

That’s because Apple doesn’t want users to be able to downgrade on purpose to reintroduce old bugs that they now know can be used for jailbreaking devices or installing an alternative operating system, even on devices that Apple itself it no longer supports.

Even if you completely wipe and reinstall your iDevice from scratch via a USB cable, using the built-in DFU (direct firmware update) utility, Apple’s servers know what version you were using before the reinstall, and won’t let you activate an old firmware image onto a device that’s already been upgraded past that point.

In other words, the cost of Apple’s commercial decision to keep you on a one-way path of iPhone and iPad upgrades is that the company can’t easily afford to rush out emergency upgrades as quickly as it might otherwise like to (or as quickly as you might want).

That’s because the only way to correct any critical problems that an upgrade might cause is to produce another complete upgrade to supersede it, because there is no quick fix process for an existing full upgrade that itself was released too quickly.

The Rapid Security Response system is meant to sidestep that problem, at least for a subset of software on your device, notably for Safari and other web browsing components, which are commonly exploited by criminals for launching attacks such as silently implanting spyware or injecting surveillance-related malware.

As mentioned above, Rapid Security Response patches are meant to be quick to install, and easy to remove afterwards if you run into trouble.

In Apple’s own words, Rapid Security Responses are designed so that:

[t]hey deliver important security improvements between software updates – for example, improvements to the Safari web browser, the WebKit framework stack or other critical system libraries. They may also be used to mitigate some security issues more quickly, such as issues that may have been exploited or reported to exist.

The importance of browser patches

Browsing on its own is meant to be comparatively low risk, given that the browser itself is supposed to programmed to shield you from immediate harm.

Indeed, browser-based content isn’t supposed to be able to cause any software-based cybersecurity trouble at all if all you do is look at at a website.

Sure, you could be lied to by fake content, but that won’t directly affect the security of the code running on the device itself.

Or you could be cajoled into approving some risky action such as installing a rogue app or filling in a fake logon form, but you typically get at least a fighting chance to detect that you’re being scammed.

Simply put, as long as you’re “Just Visiting”, as the Monopoly board puts it when you land on the Jail square naturally, instead of being sent there from somewhere else, you ought to be at little or no risk from browsing activity.

Of course, the ability of your browser to shield you from entirely automated attacks, and to ensure that the content of a web page by itself is never enough by itself to infect you with malware or steal data from your device…

…depends on the browser not having any security bugs through which booby-trapped content could circumvent the browser’s own security shields and subject you to what’s jocularly known as a drive-by install or a look-and-get-pwned attack.

What to do?

These latest patches should be considered critical.

We’re assuming that they’re associated with a live spyware or malware attack that’s happening right now, given the bug that’s fixed:

Impact: Processing web content may lead to arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited. Description: The issue was addressed with improved checks. CVE-2023-37450: an anonymous researcher

In jargon-free language, “actively exploited” means “this is a zero-day”, or more bluntly, “the crooks found this one first”, which in turn means: Do not delay, simply do it today.

There are Rapid Security Responses for the latest versions of macOS Ventura 13.4.1, iOS 16.5.1 and iPadOS 16.5.1.

Those versions will report themselves as 13.4.1 (a) and 16.5.1 (a) respectively once the rapid patch is installed. (That trailing (a) will vanish if you later uninstall the patch).

For the older supported versions macOS Big Sur and macOS Monterey, there’s an old-style system update that just patches Safari, which will show up as Safari 16.5.2 after the update.

So far, however [2023-07-10T23:00:00Z], there are no updates for any other Apple platforms, even though it’s possible that that iOS 15, still officially supported on older iPhones and iPads, is affected too, along with Apple Watches and TVs.

Keep your eye on Apple’s general Security Portal and the new Rapid Security Response page for further information about updates for other Apple systems.

Head to Settings > General > Software Update to check whether you’ve correctly received and installed this emergency patch yet, and to jump to the front of the queue if you haven’t.

Remember that on iPhones and iPads, all browsers and apps that can display web-based content (whether they’re from Apple, Mozilla, Microsoft, Google or any other vendor), are forced to use WebKit under the covers.

So, just installing an alternative browser and avoiding Safari for a while when you see news like this is not enough on its own!

(Note. On older Macs, check for the Safari 16.5.2 update using About This Mac > Software Update….)