Ubiquiti Security Breach: How Zero Standing Privileges Stop Rogue Developers

The Ubiquiti Security Breach

Last year, Ubiquiti disclosed a security breach involving their AWS and GitHub accounts. During the breach, the attacker accessed AWS via a privileged user account, moved across the company’s cloud environment, and proceeded to clone gigabytes of data repositories from GitHub.

Ubiquiti’s disclosure gained massive attention when a so-called whistleblower claimed the breach was much more severe than the company admitted. Brian Krebs published the whistleblower’s claim on his blog, the security community shared the story widely, and the FBI got involved. Then all hell broke loose.

The whistleblower turned out to be Nicholas Sharp, a senior software engineer at Ubiquiti. Following an investigation, Ubiquiti and the FBI determined he was also responsible for the breach.

Sharp used high-level user access to clone company data and attempted to extort Ubiquiti for $2M (or 50 Bitcoins). When the company refused to pay the ransom, he adopted the role of deceptive whistleblower and, maligning the company, claimed Ubiquiti downplayed the breach and did not protect sensitive information appropriately. Ubiquiti subsequently lost over $4B in market cap.

The story’s details are fascinating and numerous security experts have analyzed how it unfolded. You can read the FBI’s indictment here, and watch Crosstalk discuss the technical details here.

The Rogue Developer

We’ve all heard about the software developer gone rogue. Typically, either a current or former employee uses a privileged account or backdoor to hijack and/or expose sensitive company data. In the case of Sharp, we have all the hallmarks of a determined rogue. Frustrated that his ransomware approach was unsuccessful, he attempted to drag Ubiquiti through the mud.

What a guy.

Unfortunately, his story is all too common.

Sure, Sharp went to great lengths – and for a time succeeded – to inflict harm. That’s why the media’s been so captivated.

The crux of the matter, though, is that Ubiquiti was hacked and did suffer serious losses – regardless of whether or not they paid the ransom. What’s more, the hack exposed a notorious security gap in their cloud environment: abuse of an unmonitored and uncontrolled AWS account.

With insider breaches, a bad actor may demand a payout or seek to malign a company’s reputation; he may be motivated by revenge, greed, or what he believes is a moral duty to expose a company’s malfeasance. But from a security perspective, the attacker’s motivation and desired outcome are irrelevant. They are merely symptoms of a more serious problem.

The more serious problem, and the common denominator among insider threats, is user access.

When companies lack visibility and control over cloud environments, it can lead to users with perpetual access – or standing privileges. Standing elevated privileges hand baleful users an opportunity to compromise more data than standard users. This is the side of the story that might not be quite as compelling to the media. But if you want to avoid becoming the next subject of a developer-gone-rogue story, you should pay close attention.

Why Companies Should Pay Attention

For companies operating in the cloud, thousands of human and non-human (service IDs) users create a difficult to manage situation. In many cases, users receive overly broad permissions they do not need to do their jobs – standing permissions that remain accessible and vulnerable 24/7. Least privilege access (LPA) is one path companies may follow to combat this. By only granting specific permissions a user needs to complete a task, the company reduces its attack surface because the user does not have access to valuable data outside his domain. However, as evident in the Ubiquiti hack, even LPA would not have prevented the employee from the access he needed to cause harm.

LPA may shrink your privilege attack surface, but it does reduce the user’s blast radius once inside. That’s why companies should also introduce the concept of zero standing privileges (ZSP) for developers and applications in the cloud.

When you remove an open account and replace it with temporary access, you significantly reduce the risk of malicious or negligent insider behavior. Ideally, you would provision the access of cloud users – not just the user. Sharp demonstrated that provisioning the user and not his access is extremely dangerous.

In a LPA scenario, a bad actor (Sharp) misuses his cloud user account. In addition to having admin-level privileges that effectively provided him the keys to the kingdom, these privileges were also standing privileges that were, presumably, neither monitored, nor revoked when not in use.

Enforce Zero Standing Privileges

ZSP blocks the path bad actors use to target data. In Sharp’s case, he would not have been able to use his employee access because the access tied to his user would be temporary – his keys would expire and revoke. Consequently, he would not have access to any apps or data to cause damage.

In this way, the brokering of access is temporary for any human (keys) or non-human (tokens) that need access in the cloud. This prohibits bad actors from accessing critical apps and data.

Cross-Cloud Privileged Access Management

A final but critical point for companies to consider concerns multi-cloud environments:

Sharp’s attack focused on AWS, which can be hard enough to protect without the right security solution. But what happens if you’re on multiple CSPs? The complexity and challenge of managing and securing users exacerbate. That’s why it’s so important to use a cross-cloud solution with a Unified Access Model.

Being able to monitor and manage all users across AWS, Azure, GCP, OCI, IBM Cloud, and anything SaaS allows your company to scale and build with the flexibility and speed business demands. It minimizes cost and complexity and helps companies meet compliance. It supports DevOps and SecOps mutually, without impacting performance or sacrificing security. And, as a case in point, it prevents insider abuse.

Developers are less likely to go rogue when they can’t inappropriately access critical data and apps.