LastPass was hacked and their source code was stolen. What can we learn from this?

LastPass, just sent an email to its customers saying that it has been hacked. Again. LastPass has publicized that it’s been hacked at least 4 times: in 2011, 2015, 2021, and now in 2022. In addition, there have been a number of other security events where security researchers have identified vulnerabilities in the LastPass platform that could have led to data loss or password compromise. You can see the list of historical security incidents here. This time, the attack vector is different than previous incidents, so let’s drill into what happened.

What we know so far:

LastPass alerted its customers yesterday that there had been a security incident and that they had hired an incident response company. We don’t know which IR firm they’ve hired.
The attack happened two weeks ago and targeted its development environment.
LastPass is saying that a single developer’s account was compromised and that source code and some “proprietary LastPass technical information” was accessed.
LastPass says that no passwords or vault material was accessed

You can find the LastPass official blog post here: https://blog.lastpass.com/2022/08/notice-of-recent-security-incident/

Other than that, there are no other details, which is a bit concerning. But, let’s take this at face value right now. According to the LastPass press release no passwords appear to have been stolen or accessed. This is a good thing! Unfortunately, this type of attack is potentially more dangerous than a data breach where a set of point-in-time passwords was stolen. Let me explain why.

How could this be worse than my passwords being stolen?

This attack appears to have targeted the LastPass development environment where the company writes, stores, and manages its source code. It’s essentially where all the intellectual property for a software-based company is stored. And the reality is that most companies are software-based now, with most of their revenue and growth tied to their software-based systems. This centralized storage of a company’s intellectual crown jewels is a very sexy target for criminals. Unfortunately, as we’ll see below, this core IP is not as protected as other parts of the IT infrastructure.

Developers are the best place to target it you want to own someone

Software engineers have access to the source code for the platforms they work on. For LastPass that access probably includes how things like encryption of passwords are performed, when MFA challenges are performed and how LastPass detects anomalies. Thes are core fundamentals of how the LastPass Vault works.

So imagine if you had access to that source code and you could change one small thing that sent all the passwords to a remote API endpoint you owned? Or worse, maybe you sabotaged the encryption algorithm to give yourself a backdoor so you could easily decrypt any master passwords stored with LastPass. Or more realistically, if you stole the source code and didn’t have the opportunity to add anything malicious to it, you would still have access to how core LastPass functions worked because you had the source code.

All of that is speculation, and hopefully, that’s not what’s happened with LastPass this time. But the reality is that access to source code is one of the most sensitive things you can get, and yet we don’t generally protect it very well.

Why are developers so easily targeted?

Most source code management (SCM) platforms use someone’s work email for the username that they use to interact with the SCM platform. This is common practice as it’s the easiest way to manage a large number of devs instead of letting them choose their own usernames. However, this means that if you know a developer’s email you have half of their login credentials already. This is made worse by the fact that many orgs don’t sync their SCM logins with Active Directory so the management of those SCM creds is a manual process. Also, the use of password controls mandated by AD is ignored by SaaS providers like Bitbucket, GitLab, and GitHub as they are managed independently.

Unfortunately, this common practice means that developers are constantly being targeted by automated phishing campaigns that can be very effective as the logins themselves are easy to copy. The one to the right uses a domain that is similar to GitHub but is in fact malicious.

Okay, if it’s so easy to phish developers, what other security controls can we use?

The reality is that developers don’t typically use any other security controls other than a username and password, which we’ve just shown are under constant attack. The centralized versioning system that most developers use is called Git and it has several security functions built into it. Unfortunately, most development teams don’t take advantage of these security features, so if you can successfully phish them you are in. I can’t say this is how the LastPass incident went down, but it’s certainly possible.

Contrary to what you might have heard, security is relatively easy to add to developers workflow

There are many security controls that software engineers can use to secure how they write, test and deploy code. Even better, many of them are simple, easy to implement, and are automatable. Why then do so few devs actually use these security controls? In my experience, it’s a cultural thing. They aren’t incentivized as software engineers to prioritize security, so they don’t. We need to change this culture and instead help devs understand that if they use these security controls, we are all better off.

Earlier this year I wrote and published the DevSecOps Playbook, which is an open-source step-by-step guide to implementing DevSecOps for any type and size company.

You can find the Playbook at: https://github.com/6mile/DevSecOps-Playbook

The DevSecOps Playbook is 58 controls and is very detailed and prescriptive. If you are looking for some simpler tips you can use to protect your software engineers from the same thing happening to you that happened to LastPass, we’ve got you covered!

6 easy things to increase source code security

Enable MFA for SCM

Bitbucket, GitHub, and GitLab all support the use of MFA for logins. This simple security control means that there’s more than just a crappy password between your source code and attackers. Even better, if you use GitHub or Bitbucket or GitLab for SSO to other platforms the requirement to use MFA at login will propagate across automatically, providing security there too.

The obvious limitation with this method is that you are only going to get an MFA challenge when you log in, so doesn’t provide any security when you are actually interacting with code (pulls, fetches, clones, etc). That’s why the next option is particularly important.

Use SSH keys to interact with SCM

There are two protocols that are supported when you interact with source code in your SCM. The default is HTTPS which is encrypted but doesn’t offer any additional security. The other option is to use SSH for transport which requires SSH keys as it’s PKI based. This is significant as you can change, expire, and update your keys based on company requirements.

My team has gone even further, as we use an app that manages SSH private keys behind an MFA challenge. This means that each time we push code we get a challenge on our mobile devices. Combining this control with the first one (MFA) adds a layer of security that is very powerful. You can see how to add SSH keys to your GitHub account here.

Signed commits

When an engineer makes an important change to source code they will “commit” that code to version control so it’s protected. Unfortunately, by default git just keeps track of the author via the email address of the author which can be easily faked. If you want to verify that the person pretending to be linus@linux.org really is Linus Torvalds, then you need to sign your commits with GPG. It takes 60 seconds to set up and then can be easily automated so that every commit is signed. Find out how to sign commits here.

Scan your source code for vulnerabilities

While this control wouldn’t have stopped the LastPass hack, it’s still a super important security control. Good engineering teams will use software composition (SCA), secret scanning tools, and static analysis (SAST) code scanning solutions in their local environments. It’s super important to scan source code for issues when it goes through your CI/CD pipelines, but it’s important to do on your developer’s laptops too. Git provides an automated function to do this when you commit code with something called a pre-commit git hook. Unfortunately, a lot of engineering teams are NOT running security tooling on their laptops so there is no way to stop security issues or malicious code from getting into the centralized source control system. Yes, you can eventually remove it there too, but it’s a lot harder to do than if you stopped it before it got there. I like to use the analogy of someone poisoning a city’s water supply. It’s a lot easier to stop them from pouring the poison into the lake than it is to take the poison OUT of the lake.

Sync your SCM provider to AD

One of the common themes I see is that enterprise orgs will use a cloud-based SCM like GitHub or Bitbucket, but not connect their active directory to it (usually because of cost). Because they aren’t linked, the users in the SCM platform must be managed separately. This causes challenges as users have to manage two separate sets of credentials, one for AD and one for SCM. It also means that accounts are often out of date with people still having accounts in SCM when they no longer work for the company. Onboarding, off-boarding, password resets, and everything else is more complicated in this scenario.

Security training for your software engineers

Because of the unique security challenges presented to developers, they need specialized security training. That’s why we use partners that teach how to create more secure code, but also how to secure the systems they use to manage the code. Reach out to me if you would like an intro to one of our partners that does this.