Perpetual IT

If the big story of this month looks set to be Uber’s data breach, where a hacker was allegedly able to roam widely through the ride-sharing company’s network…

..the big story from last month was the LastPass breach, in which an attacker apparently got access to just one part of the LastPass network, but was able to make off with the company’s proprietary source code.

Fortunately for Uber, their attacker seemed determined to make a big, quick PR splash by grabbing screenshots, spreading them liberally online, and taunting the company with shouty messages such as UBER HAS BEEN HACKED, right in its own Slack and bug bounty forums:

The attacker or attackers at LastPass, however, seem to have operated more stealthily, apparently tricking a LastPass developer into installing malware that the cybercriminals then used to hitch a ride into the company’s source code repository:

LastPass has now published an official follow-up report on the incident, based on what it has been able to figure out about the attack and the attackers in the aftermath of the intrusion.

We think that the LastPass article is worth reading even if you aren’t a LastPass user, because we think it’s a reminder that a good incident response report is as useful for what it admits you were unable to figure out as for what you were.

What we now know

The boldface sentences below provide an outline of what LastPass is saying:

• The attacker “gained access to the [d]evelopment environment using a developer’s compromised endpoint.” We’re assuming this was down to the attacker implanting system-snooping malware on a programmer’s computer.
• The trick used to implant the malware couldn’t be determined. That’s disappointing, because knowing how your last attack was actually carried out makes it easier to reassure customers that your revised prevention, detection and response procedures are likely to block it next time. Many potential attack vectors spring to mind, including: unpatched local software, “shadow IT” leading to an insecure local configuration, a phishing click-through blunder, unsafe downloading habits, treachery in the source code supply chain relied on by the coder concerned, or a booby-trapped email attachment opened in error. Hats off to LastPass for admitting to what amounts to a “known unknown”.
• The attacker “utilised their persistent access to impersonate the developer once the developer had successfully authenticated using multi-factor authentication.” We assume this means that the hacker never needed to acquire the victim’s password or 2FA code, but simply used a cookie-stealing attack, or extracted the developer’s authentication token from genuine network traffic (or from the RAM of the victim’s computer) in order to piggy-back on the programmer’s usual access:

• LastPass didn’t notice the intrusion immediately, but did detect and expel the attacker within four days. As we noted in a recent article about the risks of timestamp ambiguity in system logs, being able to determine the precise order in which events occurred during an attack is a vital part of incident reponse:

• LastPass keeps its development and production networks physically separate. This is a good cybersecurity practice because it prevents an attack on the development network (where things are inevitably in an ongoing state of change and experimentation) from turning into an immediate compromise of the official sofware that’s directly available to customers and the rest of the business.
• LastPass doesn’t keep any customer data in its development environment. Again, this is good practice given that developers are, as the job name suggests, generally working on software that has yet to go through a full-on security review and quality assurance process. This separation also makes it believable for LastPass to claim that no password vault data (which would have been encrypted with users’ private keys anyway) could have been exposed, which is a stronger claim than simply saying “we couldn’t find any evidence that it was exposed.” Keeping real-world data out of your development network also prevents well-meaning coders from inadvertently grabbing data that’s meant to be under regulatory protection and using it for unofficial test purposes.
• Although source code was stolen, no unauthorised code changes were left behind by the attacker. Of course, we only have LastPass’s own claim to go on, but given the style and tone of rest of the incident report, we can see no reason not to take the company at its word.
• Source code moving from the development network into production “can only happen after the completion of rigorous code review, testing, and validation processes”. This makes it believable for LastPass to claim that no modified or poisoned source code would have reached customers or the rest of the business, even if the attacker had managed to implant rogue code in the version control system..
• LastPass never stores or even knows its users’ private decryption keys. In other words, even if the attacker had made off with password data, it would have ended up as just so much shredded digital cabbage. (LastPass also provides a public explanation of how it secures password vault data against offline cracking, including using client-side PBKDF2-HMAC-SHA256 for salting-hashing-and-stretching your offline password with 100,100 iterations, thus making password cracking attempts very much harder even if attackers make off with locally-stored copies of your password vault.)

What to do?

We think it’s reasonable to say that our early assumptions were correct, and that although this is an embarrassing incident for LastPass, and might reveal trade secrets that the company considered part of its shareholder value…

…this hack can be thought of as LastPass’s own problem to deal with, because no customer passwords were reached, let alone cracked, in this attack:

This attack, and LastPass’s own incident report, are also a good reminder that “divide and conquer”, also known by the jargon term Zero Trust, is an important part of contemporary cyberdefence.

As Sophos expert Chester Wisniewski explains in his analysis of the recent Uber hack, there’s a lot more at stake if crooks who get access to some of your network can roam around wherever they like in the hope of getting access to all of it:

---