If this month’s big story seems to be the Uber data breach, where a hacker could have roamed the ride-sharing company’s network extensively…
…last month’s big story was the LastPass breach, in which an attacker apparently only gained access to part of the LastPass network, but was able to get away with the company’s proprietary source code.
Luckily for Uber, their attacker seemed determined to make a big, quick PR splash by grabbing screenshots, liberally spreading them online, and taunting the company with garish messages such as UBER HAS BEEN HACKEDdirectly in his own Slack forums and bug bounty:
The LastPass attacker or attackers, however, appear to have acted more stealthily, apparently tricking a LastPass developer into installing malware that the cybercriminals then used to break into the company’s source code repository:
LastPass just released a official follow-up report about the incident, based on what he was able to discover about the attack and the attackers following the intrusion.
We think the LastPass article is worth reading even if you’re not a LastPass user, as we think it’s a reminder that a good incident response report is also useful for what ‘He admits you couldn’t figure that out for what you were for.
What we know now
The bold sentences below give an overview of what LastPass is saying:
- the attacker “has been granted access to the [d]development environment using a developer’s compromised endpoint. We suspect this is due to the attacker planting system-spying malware on a programmer’s computer.
- The trick used to implant the malware could not be determined. This is 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 the next time around. Many potential attack vectors come to mind, including: unpatched local software, “shadow IT” leading to insecure local configuration, phishing click error, dangerous download habits, betrayal in the source code supply chain that the affected coder relies on, or a booby-trapped attachment opened by mistake. Hats off to LastPass for admitting what amounts to a “known unknown”.
- the attacker “used their persistent access to impersonate the developer once the developer 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 theft attackor extracts the developer’s authentication token from real network traffic (or the RAM of the victim’s computer) in order to piggyback on the programmer’s usual access:
- LastPass didn’t notice the intrusion immediately, but detected and expelled the attacker within four days. As we noted in a recent article on the risks of timestamp ambiguity in system logs, being able to determine the precise order in which events occurred during an attack is an essential part of incident response:
- LastPass physically separates its development and production networks. This is good cybersecurity practice because it prevents an attack on the development network (where things are inevitably in a continuous state of change and experimentation) from turning into an immediate compromise of the official software that is directly available to customers and the rest of the company.
- LastPass does not store any customer data in its development environment. Again, this is good practice given that developers typically work, as the job name suggests, on software that has not yet undergone a full security review. and a quality assurance process. This separation also allows 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 to simply say “we have found no evidence that it has been exposed. Keeping real-world data out of your development network also prevents well-meaning coders from inadvertently grabbing data that is supposedly under regulatory protection and using it for unofficial testing purposes.
- Although the source code was stolen, no unauthorized code modifications were left behind by the attacker. Of course, we only have LastPass’ own claim, but given the style and tone of the rest of the incident report, we see no reason not to take the company at its word.
- Source code moving from development network to production “can only occur after the completion of rigorous code review, testing, and validation processes”. This allows LastPass to claim that no modified or poisoned source code has reached customers or the rest of the company. even if the attacker had successfully implanted malicious code in the version control system.
- LastPass never stores or even knows the private decryption keys of its users. In other words, even if attacker got away with password data, it would have ended up as so much shredded digital cabbage. (LastPass also provides a public explanation how it secures password vault data against offline hacking, including using client-side PBKDF2-HMAC-SHA256 to salt, hash and stretch your password offline with 100,100 iterations, making thus making password cracking attempts much more difficult even if attackers get away with locally stored copies of your password vault.)
What to do?
We think it’s fair to say that our initial assumptions were correct, and that while this was an embarrassing incident for LastPass, and could reveal trade secrets that the company considered part of of its shareholder value…
…this hack can be considered LastPass’s own problem, as no client passwords were reached, let alone hacked, in this attack:
This attack, and LastPass’s own crash report, are also a good reminder that “divide and conquer”, also known as the lingo Zero Trustis an important element of contemporary cyber defense.
As Sophos expert Chester Wisniewski explains in his analysis of the recent Uber hack, much more is at stake if the scammers who have access to some of your network can roam wherever they want in the hope of gaining access to everything of this one:
Click and drag on the sound waves below to jump to any point. You can also listen directly on SoundCloud.