Uber & Thycotic: Are Password Vaults a Huge Security Vulnerability? by@jamesbores
38,498 reads

Uber & Thycotic: Are Password Vaults a Huge Security Vulnerability?

October 3rd 2022
4 min
by @jamesbores 38,498 reads
tldt arrow
Read on Terminal Reader

Too Long; Didn't Read

Security is complicated and managing credentials is tough. A 17 year old hacker, TeaPot, got hold of the credentials of an Uber contractor and began sending multi factor authentication requests to them repeatedly. Once the contractor got annoyed and hit accept, their account was used to access a script with admin credentials to Uber's password vault, Thycotic, giving them access to almost everything else.

Companies Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - Uber & Thycotic: Are Password Vaults a Huge Security Vulnerability?
James Bore HackerNoon profile picture


James Bore

Security professional, homebrewer, amateur butcher, techie, board gamer, and beekeeper....

About @jamesbores
react to story with heart

Very often when people talk about security, the discussion of password managers or vaults come up. These can be useful for individuals. However, they carry some real risks for companies, if they’re not carefully considered.

Uber was recently breached, and by all accounts from the attacker thoroughly so. A password vault system called Thycotic came heavily into play along with some other measures designed to add rather than remove security.

There are a few things I want to start off with:

  • the technology and tools themselves are not at fault here, instead it’s down to the implementation of them and the wider design of Uber’s systems
  • password managers and vaults are used interchangeably, but usually a password vault will be more of an enterprise system for a company to protect credentials across the business rather than for a single user
  • security is complicated, and when it hasn’t been designed in from the start you end up with large vulnerabilities that mean the smallest mistake can become a massive breach with very little notice

What happened in the Uber hack?

We start off with notification fatigue. The attacker, supposedly a 17 year old “TeaPot” from the UK found credentials (likely purchased online) of an Uber contractor and began sending multi factor authentication requests to them repeatedly. This is rapidly becoming a common attack, simply trying to annoy people into accepting the notification, although in this case they also sent a message via WhatsApp claiming to be from Uber IT and telling the contractor that there was an error, and if they accepted the notification it would stop the alerts.

After the contractor accepted the alert TeaPot claims to have accessed the intranet and found a script with admin credentials for the Thycotic Secrets Vault Uber uses to manage their credentials.

Admin credentials could mean everything in the password vault was available to the attacker, and this seems to be what happened. Supposedly it included access to the bug bounty programme, meaning TeaPot gained access to unfixed vulnerabilities in Uber’s apps and systems.

So are password vaults bad?

Here’s the problem. Security is complicated and managing credentials is tough. At the scales Uber and other unicorns work at, many not built for security from the start they are effectively working on a foundation of quicksand. Desperately trying to retrofit security into systems never designed for it while still trying to operate as a business and keep up with investor demands.


Password vaults such as Thycotic are not, themselves, a bad idea, but what would have helped in Uber’s case? You’ll see a lot of talk about zero trust principles, which mean not trusting any one device in a network to access anything, but while these principles are talked about a lot they are impossibly hard to implement if they’re not built in from the start.

Not having a password vault is another option, and that might have helped simply because it would mean less likelihood of having all those credentials in one place. On the other hand, it means users are much more likely to use weak passwords in the first place and to store them in insecure ways such as on a spreadsheet or text file.

If they’re implemented properly, password vaults make managing secure systems much, much easier for users. The real fault here was in having admin credentials to the password vault in the first place, instead individual accounts should be created with access only to the credentials they need. No external contractor, no matter how trusted, should ever have access to that level of credentials - they simply do not need it.

I wouldn’t be comfortable even with the most trusted of employees having that sort of access. It’s the type of thing you split into multiple pieces, spread between several members of the board, and lock in a safe for emergencies, such as your whole IT team being abducted by aliens.

Should I use a password vault?

One thing that did come up after the attack was a lot of security product vendors selling their solution as the one and only that would have prevented it. At best, these should be completely ignored, as the weaknesses that led to the breach were (and almost always are) complex and multifaceted with no easy fix. The other was that a lot of people were questioning whether password vaults or managers were suddenly a new and massive risk to take, and whether they were safe to use.


Image via URegina

The simple answer is yes, if it’s useful and makes sense for you. A well-set-up vault lets you use much more secure passwords, rotate them regularly, and manage them well. Many enterprise secret vaults will change passwords after each use and manage a lot more than user credentials such as certificates and other private keys.

The more complex answer is that any tool you use to simplify security will introduce trade offs and their own risks to an environment. A password vault will give you more secure passwords and better management of credentials, but the trade off is that all of these credentials in one place make it a tempting target for an attacker and can cause a minor breach to become more serious fast.


. . . comments & more!
Hackernoon hq - po box 2206, edwards, colorado 81632, usa