Perpetual IT

Researchers at browser identification company FingerprintJS recently found and disclosed a fascinating data leakage bug in Apple’s web browser software.

Technically, the bug exists in Apple’s open source WebKit browser engine, which means it affects any browser that relies on WebKit.

As you might expect, this includes all versions of Apple’s own Safari browser, whether you’re running it on macOS, your iPhone or your iPad.

But on iOS and iPadOS, even non-Apple browsers that don’t usually use WebKit at all are required by Apple’s own App Store rules to ditch their regular underpinnings and use WebKit.

On Windows and Linux, for example, Firefox uses its own Gecko rendering engine; Microsoft Edge, Google Chrome and many other browsers are based on Google’s Blink renderer.

Although Blink was originally derived from WebKit, the forked-off project is now separate from, and very different to, Apple’s current WebKit codebase.

So Safari on macOS, and pretty much any browser you’re using on an iPhone or iPad, is affected by this bug.

A little leakage goes a long way

At first telling, the bug sounds both undramatic and unimportant: although it allows private data to leak between separate browser tabs that contain content from unrelated websites, the amount of data that leaks is minuscule.

So, let’s start at the beginning.

WebKit, like all other modern browser engines, lets websites set and store what’s called stateful data – information that’s carried from one visit to a site to the next, traditionally via web cookies.

Cookies are used for information such as remembering display settings (e.g. light mode versus dark mode), keeping track of repeat visits (e.g. by assigning you a unique visitor ID that can be matched up next time), and letting you log in with a password (e.g. by recording a secret temporary access code known as an authentication token).

Cookies, historically, are sent along in the headers of every web request to the site that originally set them, so they’re not a very efficient way of recording the status of a web session: whenever you visit site X, you’re supposed to send every cookie ever set by site X, even cookies that aren’t relevant to the page you’re currently visiting.

Modern browsers therefore also provide a client-side database known as Web Storage that can be accessed only when needed by JavaScript code in the pages of a website.

(You’ll often hear the term “cookie” used to encompass both cookies sent in every web request, and thus usable even when JavaScript is turned off, and web storage, used only as needed, but unavilable unless JavaScript is enabled.)

As you can imagine, the sort of data stored in cookies and web storage isn’t suitable for disclosing to anyone, given that it often identifies you loosely, and frequently identifies you exactly – for example, cookies may grant access to private data in an online account, such as your name, address, contact details, credit card data, as well as the password reset page for that account.

Therefore browsers are expected to enforce what’s called the Same Origin Policy (SOP), whereby web data that is created by website X can only every be read back by site X.

Actually, the SOP is stricter than that: the protocol used must match (this prevents an HTTPS cookie such as a password or your real name from being exposed via HTTP); the server name must match (so that services from two different customers that happen to be hosted at the same cloud IP number can’t match by mistake); and the TCP port used must match (this makes it harder for an imposter who has only partial access to your network to set up a parallel service on an existing server that differs only by using a different port).

More and more in the browser

Unfortunately, and ironically, today’s cloud-centric world means that we’re running more and more apps inside our browsers.

Even the web storage system that we mentioned above, specially concocted to get around the performance limitations of old-school HTTP cookies…

…turns out to be inadequate when browser-based apps such as document processing systems or image editors need to manage and process large amounts of locally-cached data.

So, we now have THREE types of local storage: cookies, which are great for simple settings such as pagestyle=dark; web storage, fine for larger-sized chunks of data such as configuration settings and modestly-sized documents; and a local database system known as IndexedDB, when you need to keep large amounts of data and to access it efficiently.

As Mozilla’s excellent reference pages put it:

IndexedDB is a low-level API for client-side storage of significant amounts of structured data, including files [and binary chunks]. This API uses indexes to enable high-performance searches of this data. While Web Storage is useful for storing smaller amounts of data, it is less useful for storing larger amounts of structured data. IndexedDB provides a solution.

IndexedDB isn’t quite a full-blown SQL database, but it’s capable of storing, indexing, searching and retrieving much larger local databases than you can manage efficiently using web storage.

Complexity, the enemy of security

You can guess where this is going, given that complexity is the enemy of security.

It turns out that Apple’s implementation of the IndexedDB feature includes a function called, simply, indexedDB.databases(), which returns a list of all IndexedDB databases currently known to the browser.

And although your website can only access databases that match the SOP (so you can’t open an IndexedDB that was created by a different website and read it willy-nilly)…

…you can access the full list of current database names, regardless of which web page originally created those databases.

Your first thought here is probably, “So what? A database name doesn’t give away much, if indeed it reveals anything at all.”

But now stop to think of the issue another way.

Imagine that you had a special directory on your hard disk called PersonalData, and inside that you had files that were really important to you, such as ReplyToTaxAudit2016.docs, SpeedingFineLegalAppeal.pdf, PasswordsForHostingCompany.txt, JobApplicationToNewCo.pdf and DNSCoRenewalInfo.xls.

You wouldn’t willingly publish those filenames, because the names themselves – although much less useful to a crook than the actual contents – nevertheless reveal personal information that could easily assist in future attacks against you.

Even in the artificial example above, the filenames alone give away something about your relationship with the Tax Office; hint that you have been in trouble with criminal charges related to driving; tell your current emplyer something they might not know, and expose information about some of the IT companies you use.

Database names considered leaky

In the case of IndexedDB database names, FingerprintJS noticed that some services – Google, for example – use an identifier unique to your account (your Google User ID) in the string that names the Google-specific IndexedDB.

Even if an attacker has no way of telling who you are from that Google User ID, the fact that it’s consistent whenver you’re logged into Google means that, at best, it serves as a kind of “supercookie” that identifies that you’re the same user visiting other websites.

Even when you’ve turned tracking protection on, in order to prevent websites automatically sharing cookie data with each other, you reveal yourself as “the same person every time” whenever you visit a web page that invokes the pesky indexedDB.databases() function via JavaScript.

And FingerprintJS reports that the “filenames” (for want of a better word) chosen as IndexedDB identifiers by other services often uniquely identify that service, even if they don’t uniquely identify a specific user.

That means the list of names exposed by the indexedDB.databases() function could act as a history list of your recent web browsing: by extracting the list of IndexedDB names in your browser, crooks can easily learn more than you would expect about the web apps and online services you’ve used recently.

That’s a bit like a situation in which anyone who is able to get a glimpse of just the cover of your passport – not even the picture page, just the outside of it! – immediately comes away with a complete list of all the countries you’ve visited lately.

It’s not a complete privacy disaster…

…but it’s definitely not supposed to work that way!

What to do?

• On macOS, you can simply use a different browser until Apple issues a fix. As explained above, browsers such as Firefox, Edge and Chrome don’t use the WebKit engine and don’t have this bug.
• On iDevices, you can probably reduce the risk slightly by clearing your website data regularly. Switching to a different browser doesn’t help because all App Store browsers use WebKit internally. Also, clearing web data (Settings > Safari > Clear History and Data) typically means you need to need to login and readjust preferences for every website you’ve used lately. Of course, as soon as you use any of those websites again, the IndexedDB list gets updated once again.
• Watch Apple’s security advisory page for updates. According to FingerprintJS, Apple recently acknowledged the problem and has started adding fixes to the WebKit open source code. Sadly, Apple refuses to announce dates for security fixes before they’re published, so we have no idea how long it will be before a patch comes out. The main security portal for Apple updates is HT201222.

THE INDEXEDDB LEAK IN PICTURES

We used this Ncat script as a simple webserver for opening and listing IndexedDB files.

We set the script listening on port 7777 of a server named naksec.test, and on port 8888 of server named other.example, using the command ncat -k -vv -l [nnnn] --lua-exec script.lua, where the file below was saved as script.lua.

The lines highlighted in blue denote the browser-based JavaScript calls ised to create and list IndexedDB databases:

We used the /list URL to show the databases visible via the naksec.test server:

And via the other.example server. At this point, neither site has a local IndexedDB database in the list:

Then we called the JavaScript function that creates a uniquue, new IndexedDB database for each of the sites. We did this by visiting the /open URL on each site:

And, finally, we re-visited the /list URL to see which database names each site could discover. You would not expect the naksec.test:7777 page to know about the existence of any other databases, let alone to be able to extract their names; likewise, other.example:8888 should only know about its own database (named 192.168.1.159_8888 below).

Due to this bug, however, each site can determine the existence and name of the other site’s database, despite the Same Origin Policy:

A UK-based scammer who preyed on nearly 700 women and conned nine of them out of £20,000 (about $27,000), has been sent to prison.

London resident Osagie Aigbonohan, 41, pleaded guilty to charges of fraud and money laundering, including scamming £9500 out of one victim in the course of a fake 10-month online relationship.

According to the UK National Crime Agency (NCA), Aigbonohan spun a hard-luck story about how he’d run short of money after paying for the funerals of a group of people who died in tragic industrial accident.

He needed the money for drilling equipment he was hiring for a business venture overseas…

…but it was all a pack of lies.

Fabricated stories

As Dominic Mugan, a manager at the NCA, explains:

Aigbonohan had no regard for these women. He went to great lengths to gain their trust, fabricating stories to exploit them out of thousands.

This is a typical pattern of romance fraudsters: they work to build rapport before making such requests. Romance fraud is a crime that affects victims emotionally and financially, and in some cases impacts their families.

We want to encourage all those who think they’ve been a victim of romance fraud to not feel embarrassed or ashamed but rather report it.

Remember that romance scammers work with empathy and emotion as their tools-in-trade – they generally don’t rely on malware, spyware or booby-trapped email attachments to access their victims’ bank accounts.

In other words, traditional technological tools for protecting against cybercrime, such as anti-virus blockers, web filters and email scanners, don’t help much.

Romance scammers, just like fraudsters who talk you into investing in bogus cryptocurrency schemes, trick their victims person-to-person by building up a facade based on trust, behind which the criminals persuade their victims to send money of their own accord.

Tech support scammers also use this approach, by phoning you up – or persuading you to call them – and telling you a pile of unreconstructed lies about “security problems” on your computer, hoping to convince you to pay for their “support” in “fixing” a computer problem that doesn’t exist. Unlike romance scammers, tech support scammers usually use fear and not love, frightening you with what they claim are the consequences of not getting the “problem” sorted out. Their primary goal is to persuade you to pay on purpose for a “service” that is not required, and indeed does nothing at all to improve your cybersecurity. As with romance scams, this leaves victims with outgoing payments they made themselves, and are therefore unlikely to report to the authorities or challenge as fraudulent.

The risk of alienation

As the NCA warns, romance scammers leave their victims out of pocket and emotionally shattered: knowing you’ve deeply trusted a person who never once meant anything they said about you is a bitter pill for anyone to swallow.

But there’s another aspect to the aftermath of this sort of crime that is often overlooked, namely that romance scam victims sometimes end up alienated from friends and family, even after the scam is exposed and the financial losses stop.

That’s because scammers who spot the signs that family members are trying to intervene will often go out of their way turn the victim against their own friends and family in order to prolong the scam.

What to do?

• Don’t blame yourself if you get reeled in. These people are confidence tricksters by profession, so they have loads of practice. Unlike many online scammers, they are willing to play a long game, investing weeks, months and even years into building up false friendships.
• Consider reporting your scam to the police. You almost certainly won’t get any money back, but with your evidence and that of other victims, there is at least a possibility of identifying and stopping the criminals involved, and of warning potential future victims away from these scammers.
• Look for a support group if you feel depressed after getting scammed like this. But beware of people “reaching out” to help you online after you’ve been scammed, lest you get drawn into a scam all over again. Ignore any offers of help to “recover your money” after a scam – it’s probably the very same scammers having another try. Ask your local police or health care professional for advice.
• Listen openly to your friends and family if they try to warn you. These criminals think nothing of deliberately setting you against your family as part of their scam, using romantic excuses such as “love conquers all”. Don’t let the scammers drive a wedge between you and your family as well as between you and your money.
• Get out as soon as you realise it’s a scam. Don’t warn the scammers you suspect them, or ask them if they really do love you after all, because they will only tell you what you want to hear. Cut off contact unilaterally, abruptly and completely, and get into a genuine support group if you need help.

Lots of people “run Linux” without really knowing or caring – many home routers, navigational aids, webcams and other IoT devices are based on it; the majority of the world’s mobile phones run a Linux-derived variant called Android; and many, if not most, of the ready-to-go cloud services out there rely on Linux to host your content.

But plenty of users and sysadmins don’t just “use Linux”, they’re responsible for hundreds, thousands, perhaps even millions of other people’s desktops, laptops and servers on which Linux is running.

Those sysadmins are usually responsible not merely for ensuring that the systems under their jurisdiction are running reliably, but also for keeping them as safe and secure as they can.

In today’s world, that almost certainly means knowing, understanding, deploying and managing some sort of full-disk encryption system, and on Linux, that probably means using a system called LUKS (Linux Unified Key Setup) and a program called cryptsetup to look after it.

FDE for the win

Full-disk encryption, usually referred to simply as FDE, is a simple but effective idea: encrypt every sector just before it’s written to the disk, regardless of the software, user, file or directory that it belongs to; decrypt every sector just after it’s read back in.

FDE is rarely enough on its own, because there’s basically one password for everything, so you usually end up by layering further levels of file-specific, app-sepcific or user-specific password protection on top of it.

But FDE can considered mandatory these days, notably for laptops, for exactly the same reason: there is AT LEAST one password for everthing, so there’s nothing left behind that isn’t encrypted at all.

With FDE, you don’t have to worry about files you might have forgotten to encrypt; or those temporary copies you made from an encrypted folder into an unencrytped one while preparing for a handover; or those annoyingly plentiful intermediate files that are unavoidably generated by your favourite apps when you use menu options such as Export, Compile or Print.

With FDE, everything gets encrypted, including unused parts of the disk, deleted sectors, filenames, swapfile data, the apps you’re using, the operating system files you’ve installed, and even the disk space you’ve deliberately zeroed out to forcibly overwrite what was there before.

After all, if you leave nothing unencrypted and your laptop gets stolen, the data on the disk isn’t much use to the thieves, or to the cybercrooks they sell it to.

If you can show that you did, indeed, install FDE on the now-missing laptops, then you can put your hand on your heart and swear to your auditors, to your regulators, to your customers – and even to inquisitive journalists! – that they have little or nothing to fear if that stolen laptop ever shows up on the dark web.

FDE considered green

Better yet, if you want to retire old equipment – especially if it’s not working reliably – then FDE generally makes it much less controversial to send the old gear for generic reuse or recycling.

FDE means that if someone with ulterior motives buys up superannuated kit from your recycling company, extracts the old disk drives and somehow coaxes ithem back to life, they won’t easily be able to dump your old data for fun and profit.

Without FDE, old storage devices become a bit like nuclear waste: there are very few people you dare trust them to for “repurposing”, so you typically ended up with old safes crammed with “we aren’t sure what to do with these yet” disk drives, or with a laborious device destruction protocol that is nowhere near as environmentally friendly as it ought to be.

(Dropping old materiel into a blast furnace is fast and effective – law enforcement teams have been known do this, live on TV, after weapons amnesties aimed at reducing endemic violence – but blindly vapourising computer kit and its many eosteric metals and polymers is no longer an acceptable face of “secure erasure”.)

But what if there’s a bug?

The problem with FDE – and, just as importantly, the software tools that help you manage it reliably – is that it’s easy to do badly.

Did you use the right cryptographic algorithm? Did you generate the encryption keys reliably? Did you handle the issue of data integrity properly? Can you change passwords safely and quickly? How easy is it to lock yourself out by mistake? What if you want to adjust the encryption parameters as your corporate policies evolve?

Unfortunately, the cryptsetup program, widely used to manage Linux FDE in a way that addresses the questions above, turns out to have had a nasty bug, dubbed CVE-2021-4122, in a useful feature it offers called re-encryption.

A well-designed FDE solution doesn’t use your password directly as a raw, low-level encryption key, for several good reasons:

• Changing the low-level key means decrypting and re-encrypting the entire disk. This may take several hours.
• Multiple users need to share a single key. So you can’t retire one user’s access without locking out everyone else at the same time.
• Users often choose weak passwords, or suffer password breaches. If you realise this just happened, the faster you can change the password, the better.

So, most FDE systems choose a master passphrase for the device – for LUKS, it’s usually 512 bits long and comes from the kernel’s high-quality random generator.

Each password holder, up to 8 of them by default, chooses a personal password that’s used to create a personally-scrambled version of the master key stored in what LUKS calls a keyslot, so that the master key itself never actually needs to be stored anywhere except in memory while the device is in use.

Simply put: you can’t derive the master key for the device unless and until you provide a valid user key; none of the user keys are stored anywhere on the device; and neither the user keys nor the master key are ever revealed or stored in their plaintext forms by default.

You can dump the master key for a LUKS device, but it’s hard to do by mistake, and you need to put in a valid user key to generate the master key data:

# cryptsetup luksDump /dev/sdb --dump-master-key WARNING!
========
The header dump with volume key is sensitive information
that allows access to encrypted partition without a passphrase.
This dump should be stored encrypted in a safe place. Are you sure? (Type 'yes' in capital letters): YES
Enter passphrase for /dev/sdb: ****************
LUKS header information for /dev/sdb
Cipher name: aes
Cipher mode: xts-plain64
Payload offset: 32768
UUID: 72f6e201-cbdc-496b-98bd-707ece662c9a
MK bits: 512 <-- MK is short for "master key"
MK dump: 7a 31 05 ba f3 68 b6 be e5 6c 6f 16 92 44 ea 35 0b 66 fe ce ae ec a9 ec 22 db ea c9 9e 15 4d 60 f8 d0 b9 cb b5 1f ab f4 8f d3 e9 c1 1f 05 37 73 7d 64 df 8b be 38 e4 49 29 d1 5d 95 cd a4 9b 04
#

Reencryption options

As mentioned above, you sometimes need to change the master encryption settings on a device, especially if you need to adjust some of the parameters you used to keep up with changing encryption recommendations, such as switching to a larger key size.

For this purpose, cryptsetup provides a handy, but complex-to-implement, option called reencrypt, which actually takes care of three different processes: decrypting, encrypting, and re-encrypting your data, even while the device is in use.

Re-encrypting can, of course, be implemented with nothing more than options called --decrypt and --encrypt, but to re-encrypt a device while it is being used would then require you to decrypt the whole thing first, and then encrypt again from pure plaintext later on

That would leave you exposed to danger for much longer than is strictly necessary: if the device took 12 hours to decrypt and another 12 hours to encrypt again from scratch, at least some of the data on the disk would be in plaintext form for a full day, and more than 50% of the data would be in plaintext form for at least 12 hours.

Streamlining re-encryption

So, cryptsetup allows you to streamline the re-encryption process by keeping some of the disk encrypted with the old key, and the rest of it encrypted with the new key, while carefully keeping track of how far it’s got in case the process breaks half way through, or the computer needs to be shut down before the process has finished.

When you start up again, and a duly authorised user enters a password to mount the device (the user’s password temporarily decrypts both the old master key and the new one, so the double-barrelled decrypt-recrypt process can continue), the re-encryption process continues from where it left off…

…and at the end, the old master key is wiped out, and the new one committed as the sole encryption key for the underlying data.

Unfortunately, code that had been carefully designed to handle re-encryption was reused to implement the less useful but sometimes necessary options for “fully decrypt to plaintext” (equivalent to re-encrypting with a null cipher in the encryption stage), and “fully encrypt from plaintext” (essentially re-encryption with a null cipher in the decryption part).

And when repurposed in this way, the careful checks used in reencrypt mode to make sure that no-one had tampered with the temporary data used to track how far the process had got, and thus to prevent the abuse of the re-encrypt procedure by someone with root access to the disk but no knowledge of the password…

…were not applied.

Assessing the security impact

As the description of the relevant bugfix puts it:

The problem was caused by reusing a mechanism designed for actual reencryption operation without reassessing the security impact for new encryption and decryption operations. While the reencryption requires calculating and verifying both key digests, no digest was needed to initiate decryption recovery if the destination is plaintext (no encryption key).

Simply put: someone with physical access to the disk, but who did not have the password to decrypt it themselves, could deceive the re-encryption tool into thinking that it was part-way through a decrypt-only procedure, and therefore trick the FDE software into decrypting part of the disk, and leaving it unencrypted.

As the bug-fix explains, the LUKS system itself cannot “protect against intentional modification [because someone with phsycal access to the disk could write to it without going through the LUKS code], but such modification must not cause a violation of data confidentiality.”

And that’s the risk here: that you could end up with a disk that seems to be encrypted; that still needs a valid password to mount; that behaves as if it’s encrypted; that might satisfy your auditors that it is encrypted…

…but that nevertheless contains (perhaps large and numerous) chunks that are not only stored in plaintext but also won’t get re-encrypted later on.

Even worse, perhaps, is the observation that:

The attack can also be reversed afterward (simulating crashed encryption from a plaintext) with possible modification of revealed plaintext.

What this means is that a malevolent user could silently decrypt parts of a disk, for example on a server, without the password, quietly modify the decrypted data while it was in plaintext form – thanks to the lack of integrity protection in plaintext mode – and then seamlessly and surreptitiously re-encrypt and “re-integrify” the data later on.

Loosely put, they could – in theory, at least – stitch you up for something quite naughty – fraudulent-looking entries in a spreadsheet, perhaps, or improper commands in your Bash history such as downloading a cryptominer – by inserting bogus “evidence” and then re-encrypting it under your password, even though they don’t actually know your password.

What to do?

• Upgrade to cryptsetup 2.4.3 or later. If you run a Linux distro that provides regular updates, you may already have this version. (Use cryptsetup --version to find out.)
• Learn how to detect when the reencrypt option is in use. You can use the luksDump function to see if partial decryption/enrcyption is in progress. (See below.)
• Restrict physical access as carefully as you can. Sometimes, for example if you are using cloud services or co-located servers, you don’t have total control over who can get at what. But even in a world of trusted computing modules and tamper-proof cryptographic chips, there’s no need to give everyone access if you can avoid it.

CRYPTSETUP COMMANDS TO TRACK RE-ENCRYPTION

 --> First command tells cryptsetup to boost the master key length to 512 bits # cryptsetup reencrypt /dev/sdb --key-size 512
Enter passphrase for key slot 1: [. . .] --> While re-encrypting, you will see two extra keylots in use, one to access
--> the new master key (slot 0 here) and the other to keep track of how far
--> the decrypt-and-recrypt process has got (slot 2 here) # cryptsetup luksDump /dev/sdb
[. . .]
Keyslots: 0: luks2 (unbound) Key: 512 bits [. . .] Salt: f4 be b9 3f 15 bc 8f 97 43 2c f8 1f 31 e3 60 d1 [. . .] 1: luks2 Key: 256 bits [. . .] Salt: 75 33 81 96 ba f3 ec 8a dc ef 28 dc 68 a9 a7 44 [. . .] 2: reencrypt (unbound) Key: 8 bits Priority: ignored Mode: reencrypt Direction: forward [. . .] --> After the re-encryption is complete, keyslot 1 (for access to the
--> old master key) is removed, keyslot 2 (denoting the progress of the
--> procedure) is removed, and keyslot 0 takes over for access to the device # cryptsetup luksDump /dev/sdb
[. . .]
Keyslots: 0: luks2 Key: 512 bits [. . .] Salt: f4 be b9 3f 15 bc 8f 97 43 2c f8 1f 31 e3 60 d1 [. . .]

According to the FSB, Russia’s Federal Security Bureau (ФСБ), the ransomware gang known in both Russian and English by the nickname “REvil” has been taken down:

ФСБ России установлен полный состав преступного сообщества «REvil»

The Russian FSB has identified the entire criminal enterprise known as “REvil”

In our zest to tell you what we’re told happened, we’re admittedly relying on automated translation of the report, but as far as we can tell, the FSB claims that the investigation has led to:

• Police raids on 25 addresses in at least Moscow, St Petersburg, Moscow, Leningrad and Lipetsk.
• Numerous arrests. Up to 14 individuals were implicated, but the report doesn’t say how many were actually taken into custody.
• More than US$5,000,000 confiscated in the form of rubles and cryptocoins.
• US$600,000 and EUR500,000 seized in cash.
• 20 fancy motors towed away on the grounds that they were “purchased with the proceeds of crime”.

The US connection

The FSB report explicitly mentions that the investigation and the raid were initiated by a request received from US law enforcement, which had apparently identified the REvil ringleader and provided evidence of the gang’s involvement in criminal extortion against US victims.

The FSB also offers a bullish conclusion, claiming that as a result of the raid “this cybergang ceased to exist, and its criminal infrastructure was neutralised”.

We hope that’s true, and that the core of the REvil ransomware-as-a-service operation really is now out of action…

…but the real problem with contemporary cybercrime is that [a] there are many ransomware gangs still operating, albeit now with less impunity than before, and [b] there are many other sorts of cybercrime.

Spammers, scammers, spyware pushers, phishers, password stealers, money launderers, fake support callers, and any number of other cybercrime perpetrators are still out there, and many of these will probably not be affected by this raid at all.

What to do?

So, despite this welcome news:

• Remember that prevention is better than cure.
• Don’t let your guard down.
• Patch early, patch often.
• Encourage your users to report suspicious online activity.

And, while you’re about it, why not read the advice from our latest State of Ransomware report?

LISTEN NOW

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