Perpetual IT

Back in August 2022, popular password manager company LastPass admitted to a data breach.

The company, which is owned by sofware-as-a-service business GoTo, which used to be LogMeIn, published a very brief but nevertheless useful report about that incident about a month later:

Briefly put, LastPass concluded that the attackers managed to implant malware on a developer’s computer.

With a beachhead on that computer, it seems that the attackers were then able to wait until the developer had gone through LastPass’s authentication process, including presenting any necessary multi-factor authentication credentials, and then “tailgate” them into the company’s development systems.

LastPass insisted that the developer’s account hadn’t given the criminals access to any customer data, or indeed to anyone’s encrypted password vaults.

The company did admit, however, that the crooks had made off with LastPass proprietary information, notably including “some of our source code and technical information”, and that the crooks were in the network for four days before they were spotted and kicked out.

According to LastPass, customer passwords backed up on the company’s servers never exist in decrypted form in the cloud. The master password used to unscramble your saved passwords is only ever requested and used in memory on your own devices. Therefore, any passwords stored into the cloud are encrypted before they’re uploaded, and only decrypted again after they’ve been downloaded. In other words, even if password vault data had been stolen, it would have been unintelligible anyway.

Latest developments

Right at the end of November 2022, however, LastPass further admitted that there was a bit more to the story than perhaps they’d hoped.

According to a security bulletin dated 2022-11-30, the company was recently breached again by attackers “using information obtained in the August 2022 incident”, and this time customer data was stolen.

In other words, even if the criminals weren’t able to dig around in customer records directly from the account of the developer who got infected by malware back in August, it seems that the crooks nevertheless made off with internal details that indirectly gave them, or someone to whom they sold on the data, access to customer information later on.

Unfortunately, LastPass isn’t yet giving out any information about what sort of customer data was stolen, reporting simply that it is “working diligently to understand the scope of the incident and identify what specific information has been accessed”.

All that LastPass can say for sure right now [2022-12-01-T23:30Z] is to reiterate that “[o]ur customers’ passwords remain safely encrypted due to LastPass’s Zero Knowledge architecture.”

(Zero knowledge is a jargon term that reflects the fact that although LastPass holds some sort of data in its customers’ password vaults, it has no knowledge of what that data actually refers to, or even if it actually consists of account names and passwords at all.)

In short, even if it ultimately turns out that the crooks could have made off with personal information such as home addresses, phone numbers and payment card details (though we hope that’s not the case, of course), your passwords are still as safe as the master password you originally chose for yourself, which LastPass’s cloud services never ask for, let alone keep copies of.

What to do?

• If you’re a LastPass customer, we suggest you keep your eye on the company’s security incident report for updates.
• If you’re a cybersecurity defender, why not listen to expert advice from Sophos cybersecurity researcher Chester Wisniewski on how to protect your own IT estate from this sort of get-a-beachhead-and-go-forth-from-there attack?

In the podcast below (there’s a full transcript if you prefer reading to listening), Chester discusses a similar sort of breach that happened in September 2022 at ride-hailing business Uber, and reminds you why “divide and conquer”, also known by the jargon term zero trust, is an important part of contemporary cyberdefence.

As Chester explains, even though all breaches cause some harm, either to your reputation or to your bottom line, the outcome will inevitably be a lot worse if crooks who get access to some of your network can roam around wherever they like until they get access to all of it.

Forget Sergeant Pepper and his Lonely Hearts Club Band, who taught the band to play a mere 20 years ago today.

December 2022 sees the 35th anniversary of the first major self-spreading computer virus – the infamous CHRISTMA EXEC worm that temporarily crushed the major mainframe networks of the day…

… not by any deliberately coded side-effects such as file scrambling or data deletion, but simply by leeching too much network bandwidth for its own unauthorised purpose.

As a decoy to disguise the fact that it read in the 1980s IBM equivalents of your email address book (NAMES) and your known-hosts file (NETLOG) in order to find as many new recipients of the malware as possible to send itself to, the malware displayed this:

 * * *** ***** ******* ********* ************* A ******* *********** VERY *************** ******************* HAPPY *********** *************** CHRISTMAS ******************* *********************** AND MY *************** ******************* BEST WISHES *********************** *************************** FOR THE NEXT ****** ****** YEAR ******

If you’re wondering why the virus is widely known as CHRISTMA EXEC, rather than by the full word CHRISTMAS…

…that’s because filenames were limited to eight characters, which could be followed by a space and what we would today call an “extension” of EXEC in order to turn them into scripts that could be run directly by the user – executed, in technical jargon.

The virus itself was written in IBM’s powerful text-based scripting language REXX (the resoundingly named Restructured Extended Executor), so a non-programmer looking at the message would probably recognise it as “program code”, and therefore tend to ignore it as unimportant and irrelevant, for all that it might look interesting.

Except that the author of the virus found a cheerful way to embed an instructional lure right into the code itself, which starts with a remark (as in the C language, text between /* and */ in REXX programs is treated as a comment and ignored when the file gets used)…

/*********************/
/* LET THIS EXEC */
/* */
/* RUN */
/* */
/* AND */
/* */
/* ENJOY */
/* */
/* YOURSELF! */
/*********************/

…and then offers the following cheery advice to non-techies:

/* browsing this file is no fun at all just type CHRISTMAS from cms */

CMS is short for Conversational Monitor System, a command prompt environment on top of IBM’s venerable VM/370 operating system and its many variants, which offered individual users a real-time virtual machine that behaved like a computer all of their own, with its own disk space for storing personal files and programs.

Handily, the user didn’t have to be taught to leave the final -S off the word CHRISTMAS, because CMS would automatically ignore any extra characters and hunt for CHRISTMA EXEC, which was the very script program that the user had just received without expecting it or asking for it.

As stated above, the code did indeed display the Christmas Tree ASCII art – or, more precisely, EBCDIC art, given that IBM famously had its own character encoding system known as Extended Binary Coded Decimal Interchange Code (pronounced ebb-si-dick).

But it also trawled through your NAMES and NETLOG files, which listed other users and computers you regularly contacted, and copied itself to all of them, so that for every user who innocently typed CHRISTMAS at the command prompt…

…a sea of copies of the virus (20? 50? 200?) would be distributed, potentially worldwide, and if any of those recipients (20? 50? 200?) innocently typed CHRISTMAS at the command prompt…

…a sea of copies of the virus would be distributed, and so on, and so on.

Shades of the future

As we said in this week’s podcast, where we discussed this seminal worm:

[This is j]ust like modern macro malware that says to the user, “Hey, macros are disabled, but for your ‘extra safety’ you need to turn them back on… why not click the button? It’s much easier that way.”

35 years ago, malware writers had already figured out that if you ask users nicely to do something that is not at all in their interest, some of them, possibly many of them, will do it.

We also remarked that:

[The Christmas Tree worm] should have been a warning shot across all our bows, but I think it was felt to be a little bit of a flash in the pan.

Until a year later – then came the Internet Worm, which of course attacked Unix systems and spread far and wide.

And by then I think we all realised, “Uh-oh, this viruses-and-worms scene could turn out quite troublesome.”

If only we’d been wrong, eh?

Featured image of IBM 3279 terminal thanks to user Shieldforyoureyes via Wikimedia.

BUSINESS RISKS FROM AFTER-HOURS MALWARE

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

In a fascinating legal deliberation handed down by the French data protection regulator CNIL (Commission Nationale de l’Informatique et des Libertés), the energy company Électricité de France, or EDF for short, has been fined EUR 600,000 (about $600,000).

The legal declaration is, in the manner of such things, rather long and (to non-lawyers, at least) linguistically orotund, which means you need reasonable proficiency in French to understand all the ins and outs of the matter, but the overall case boils down to four infringements.

The first three are concerned with general data-related interactions with customers, covering:

• Sending commercial marketing emails without proper consent.
• Collecting data without clarifying what or why.
• Not handling requests reliably when customers asked to see their data, to or get it deleted.

But it’s the last complaint that piqued our interest: Sur le manquement à l’obligation d’assurer la sécurité des données.

In English, this loosely translates as failure to store data securely, and relates very specifically to the insecure handling of passwords.

MD5 considered harmful

The regulator noted, amongs other things, that despite claiming it was salting-and-then-hashing passwords using an accepted hashing algorithm, EDF still had more than 25,000 users’ passwords “secured” with a single MD5 hash as recently as July 2022.

As you will have heard many times on Naked Security, storing the cryptographic hash of a password means that you can validate a password when it is presented simply by recomputing its hash and comparing it with the hash of the password that was originally chosen.

If the hashes match, then you can safely infer that the passwords match, without ever needing to store the actual password.

When presented, the password only ever needs to be held temporarily in memory, and can be discarded as soon as its hash is calculated.

As long as the hashing algorithm is considered cryptographically secure, it can’t usefully be “run in reverse”, so you can’t work backwards from the hash to reveal anything about the password itself. (A hash of this sort is known in the jargon as a one-way function.)

Similarly, a decent hashing algorithm prevents you starting with a known hash and devising some input value – any input, not necessarily the original password – that produces the desired hash.

You would need to try input after input until you got lucky, which for hashes even of 128 bits would take too long to be a practicable attack. (A hash with the safety precaution of not allowing you to figure out multiple inputs with the same output is said to be collision resistant.)

But MD5, as you probably know, has significant problems with collisions, as does its immediate successor SHA-1 (both these hashes came out in the early 1990s).

These days, neither algorithm is recommended for use anywhere, by anyone, for any purpose, given that there are similar but still-secure alternatives that can easily be used to replace them, such as SHA-256 and SHA-512:

MD5 hashes are 128 bits, or 16 bytes, long. SHA-256 and SHA-512 are 2x and 4x as long respectively. But it is not this extra hash length alone that makes them more suitable. Their primary advantage over MD5 is that they don’t have any specific known problems with collisions, so their cryptographic safety is not considered generally doubtful as a result.

Salting and stretching

In short, you wouldn’t expect any company, let alone an energy sector behemoth like EDF, to use MD5 for any cryptographic purpose at all, let alone for securing passwords.

Even worse, however, was the lack of salting, which is where a chunk of data that’s chosen randomly for each user is mixed in with the password before its hash is calculated.

The reason for a salt is simple: it ensures that the hash values of potential passwords cannot be calculated in advance and then brought along to help with an attack.

Without salting, every time any user chooses the password 123456, the crooks know in advance what its hash would be.

Even if the user chooses a more suitable password, such as 34DF6467!Lqa9, you can tell in advance that its MD5 hash will be 7063a00e 41866d47 f6226e60 67986e91.

If you have a long enough list of precomputed passwords, or of partially computed passwords (known rather splendidly in the jargon as a rainbow table), you may be able to recover the password via the table rather than by trying trillions of password combinations until you get lucky.

Salting means that you would need a complete, precomputed rainbow table for every user (the table is determined by the combination of salt + password), and you wouldn’t be able to compute each rainbow table – a task that can take several weeks and occupy terabytes of disk space – until you recovered the salts anyway,

But there’s more you need to do.

Even if you include a salt, so that precomputed “hash dictionaries” can’t be used, and you use a trusted cryptographic algorithm such as SHA-512, one hash calculation alone is sufficiently quick that attackers who have acquired a database of hashes can still try out billions of possible passwords a second, or even more.

So you should use what’s called stretching as well, where you not only salt the initial password, but then pass the input through the hashing algorithm thousands of times or more in a loop, thus making attacks considerably more time-consuming for any crooks who want to try.

Unlike repeated addition, where you can use a single multiplication as a shortcut to replace, say, the calcuation 5+5+5+5+5+5 with 6×5, there are no shortcuts for repeated hashes. To hash an input 1000 times requires 1000 “turns” of the cryptographic calculation handle.

Not just an MD5 problem

Ironically, it seems that although EDF only had 25,800 passwords hashed with MD5, and claimed in its defence that it was mostly using SHA-512 instead, it still wasn’t always salting or stretching the stored hashes.

The regulator reports that 11,200,000 passwords had correctly been salted-and-hashed, but there were nevertheless 2,400,000 that had simply been hashed directly once, whether with MD5 or SHA-512.

Apparently, EDF has now got its password storage up to scratch, but the company was fined EUR 600,000 anyway, and will remain publicly listed online on CNIL’s “naughty step” for the next two years.

We can’t be sure what fine would have been imposed if the judgment had involved poor hashing only, and EDF hadn’t also had to answer for the three other data protection offences listed at the start…

…but it does go to show that bad cryptographic choices can cost you money in more ways than one!

What to do?

Store your customers’ passwords securely!

The extra computational cost of salting-and-stretching can be chosen so that individual users are not inconvenienced when they login, yet would-be attackers have their attack speeds increased by several orders of magnitude.

A password recovery attack that might take a week to extract 10% of passwords stored as simple one-shot hashes would, in theory, take 200 years (10,000 weeks) if you were to make the the cost of computing each trial password 10,000 times harder.

Read our excellent explainer article on this very subject:

In short, we recommend the PBKDF2 “stretching” algorithm with SHA-256 as its core hash, with a per-user random salt of 16 bytes (128 bits) or more.

This matches the recommendations in CNIL’s latest judgement.

CNIL doesn’t offer advice for the number of PBKDF2 iterations, but as you will see in our article, our advice (October 2022) is to use 200,000 or more. (You can regularly increase the number of loops to keep up with the increase in computing power.)

If you don’t want to use PBKDF2, we suggest reading up on the algorithms bcrypt, scrypt and Argon2 to help you make a wise choice.

Don’t get caught out on the cryptographic naughty step!

Researchers at secure coding company Checkmarx have warned of porn-themed malware that’s been attracting and attacking sleazy internet users in droves.

Unfortunately, the side-effects of this malware, dubbed Unfilter or Space Unfilter, apparently involve plundering data from the victim’s computer, including Discord passwords, thus indirectly exposing the victim’s contacts – such as colleagues, friends and family – to spams and scams from cybercriminals who can now pose as someone those people know.

As we’ve mentioned many times before on Naked Security, cybercriminals love social networking and instant messaging passwords because it’s a lot easier to draw new victims in via a closed group than it is to con people using unsolicited messages over “open to all” channels such as email or SMS:

The uninvisibility decloak

The scam in this case claims to offer software that can reverse the effects of TikTok’s Invisible filter, which is a visual effect that works a bit like the green screen or background filter that everyone seems to use these days in Zoom calls…

…except that the part of the image that’s blurred or made semi-transparent or translucent is you yourself, rather than the background.

If you put a sheet over your head, for example, like an archetypal comic book ghost, and then move around in a comic book ghost-like fashion (sound effects optional), the outline of the “ghost” will be discernible, but the background will typically still be vaguely, if blurrily, visible through the ghost’s outline, creating an amusing and intriguing effect.

Unfortunately, the idea of being pseudo-invisible has led to the so-called “TikTok Invisibility challenge”, where TikTok users are dared to film themselves live in various stages of undress, trusting in the Invisible filter to work well enough to stop their actual body being shown.

Don’t do this. It should be obvious that there’s very little to be gained if it works, but an awful lot to lose (and not merely your dignity) if something goes wrong.

As you can probably imagine, this has led to sleazy online posts claiming to offer software that can reverse the effects of the Invisible filter after a video has been published, thus allegedly turning otherwise innocent-looking videos into NSFW porn clips.

That seems to be exactly the path that cybercriminals took in the attack outlined by Checkmarkx, where the crooks:

• Promoted their alleged “Unfilter” tool on TikTok. Sleazy users who wanted the app were lured to a Discord server to get it.
• Drew prurient users into their Discord group. The lure allegedly included the promise of already “unfiltered” videos to “prove” the software worked.
• Lured users into upvoting the GitHub project hosting the “unfilter” code. This made the software appear more reputable and reliable than a new and unknown GitHub project usually would.
• Persuaded users to download and install the GitHub project. The project’s README file (the official documentation that appears when you browse to its GitHub page) apparently even included a link to a YouTube video to explain the installation process.
• Installed a bunch of related Python packages that downloaded and launched the final malware. According to Checkmarx, the malware was buried in legitimate-looking packages that were listed as so-called supply-chain dependencies needed by the alleged “unfilter” tools. But the attacker-supplied versions of those dependencies had been modified with a single additional line of obfuscated Python code to fetch the final malware.

The final malware payload, obviously, could therefore be modified at will by the crooks by simply changing what gets served up when the bogus “unfilter” project is installed:

Data stealing malware

As mentioned above, the malware seen by Checkmarx seems to have been a variant of a data stealing “toolkit” variously known as WASP or W4SP that is disseminated via poisoned GitHub projects, and that budding cybercriminals can buy into for as little as $20.

Often, GitHub-based supply chain attacks rely on malicious packages with names that are easily confused with well-known, legitimate packages that developers might download by mistake, and the aim of the attack is therefore to poison one or more development computers inside a company, perhaps in the hope of subverting that company’s development process.

That way, the crooks hope to end up with malware (perhaps a completely different strain of malware) embedded into the official releases of software created by a legitimate company, thus not only getting someone else to package up their malware, but typically also to add a digital signature to it, and perhaps even to push it out automatically in the company’s next software update.

This results in a classic supply-chain attack, where you innocently and intentionally pull down malware from someone you already trust, instead of having to be tricked or cajoled into downloading it from someone or somewhere you’ve never heard of before.

LEARN MORE ABOUT SUPPLY-CHAIN ATTACKS AND HOW TO STOP THEM

In this attack, however, the criminals seemed to be targeting any and all individuals who installed the fake “unfilter” code, given that a “how to install packages from GitHub” video would be unnecessary for developers.

Developers would already be familiar with using GitHub and installating Python code, and might even have their suspicions increased by a package that went out of its way to state something that they would have considered obvious.

The malware unleashed in this case appears to have been intended to attack each victim individually, directly seeking out valuable data including Discord passwords, cryptocurrency wallets, stored payment card data, and more.

What to do?

• Don’t download and install software just because someone told you to. In this case, the criminals behind the (now shuttered) GitHub accounts that created the fake packages used social media and fake upvotes to create an artificial buzz around their malicious packages. Do your own homework; don’t blindly take the word of other people whom you don’t know, have never met, and never will.
• Never let yourself get talked into giving away likes or upvotes in advance. No one who installed this malware package would ever have upvoted it afterwards, given that the whole thing turned out to be a pack of lies. By giving your implicit approval to a GitHub project without knowing anything about it, you are putting others at risk by allowing malicious packages to acquire what looks like community approval – an outcome that that the crooks couldn’t easily achieve on their own.
• Remember that otherwise legitimate software can be booby-trapped via its installer. This means that the software you think you’re installing might end up present and apparently correct at the end of the process. This may lull you into a false sense of security, with the malware implanted as a secret side-effect of the installation process itself rather than showing up in the software that was actually installed. (This also means that the malware will be left behind even if you completely uninstall the legitimate components, which therefore act as a sort of cover story for the attack.)
• An injury to one is an injury to all. Don’t expect much sympathy if your own data gets stolen because you were grubbing around for a sleazy-sounding app that you hoped might turn harmless videos into unintentional porn clips. But don’t expect any sympathy at all if your recklessness also leads to your colleagues, friends and family getting hit up by spammers and scammers targeted by criminals who got into your messaging or social networking passwords this way.

Remember: If in doubt/Leave it out.