ThreatVector is an ongoing series where we break down recent security incidents in the news to understand how they happened, how they spread and what the ramifications are for companies as they evolve their defenses.
Details have just emerged about a devastating, wide-ranging compromise of Uber from their corporate network, VPN, Google GSuite and their production AWS infrastructure, including databases.
Our last ThreatVector post covered how social engineering allowed the Twilio compromise and subsequent Signal account takeover and this situation appears to have unfolded in similar fashion:
- Socially engineer employee with high levels of access
- Access network through Uber’s VPN
- Scan Google Drive for interesting content or credentials
- Use hard coded credentials to access secret store
- Gain full access to significant infrastructure accounts like AWS
In the Twilio case, it was unclear how the Two Factor Authentication (2FA) was bypassed, but here it appears that the victim was socially engineered to share the 2FA code.
After the initial user compromise was complete, the attacker accessed the Uber VPN and started scanning Google Drive for interesting content.
Hardcoded credentials in PowerShell script
The attacker found hard coded credentials within a Powershell script. This is clearly a bad practice. The executor of the script, either human or a machine, should have the authorization instead. This situation is effectively the same as storing a hardcoded credential in a private Git repository, something that nobody would advocate.
Even worse than embedding any credential, this credential was the “key to the kingdom”. It was an admin account on Uber’s Privileged Access Management (PAM) tool, which contains secrets for significant IT systems like GSuite, AWS and VMware.
You can see how devastating this is and we won’t go into any more detail on the rest of the attack. Instead, let’s focus on two defensive practices that can help in these types of situations.
Embracing Machine Identities
Machine identities are one mechanism for granting a “caller”, or an executor of a piece of software, credentials for accessing resources. If you’ve interacted with an AWS “instance role” or queried the EC2 instance metadata service, you’re using a machine identity.
The benefit of this is twofold: first, it doesn’t require hardcoded credentials and second, the identity of the machine is very hard to steal, because it’s built into the cloud infrastructure itself.
Now, if you can get onto the machine in question, you now have the ability to access what it can access. The common ways to obtain access are stealing credentials of a human with those privileges (like an SSH key) or by exploiting a bug in the software running on the machine.
A defense in depth would necessitate that access to a machine and the code on it is not enough to access sensitive data. Additional protection should make it impossible to steal customer data even when using a machine identity.
Embracing Code Identity aka Attestation
The next level of defense is to use the identity of your code itself as the authorization to access sensitive data or talk to other systems. This takes the human out of the loop as a target, because no human can pretend to be your code – it’s impossible.
Popular forms of this include a blend of hardware and software called secure enclaves, like those supported by Intel, AMD and AWS.
The Secure Production Identity Framework for Everyone (SPIFFE), is a mix of machine identity and workload identity based on attestations derived from how code is executed.
More from EdgeBit in the future
We’re looking for design partners to influence how we tackle the wider journey of building security-centric and privacy-preserving features of their SaaS applications. We would love to chat about your ideas and test out our software.
If you’re a customer of a SaaS platform and want to influence the platforms you are already using, we would also love to hear from you.
