Massive Data Breach at Uber

Comments

Jordan Sherb • September 16, 2022 9:18 AM

As I recall, Uber did the “expand fast” approach popular with business bros. Not surprised their implementation is bad. What a society.

Clive Robinson • September 16, 2022 9:48 AM

@ Bruce,

“This is the same thing that Mudge accuses Twitter of”

Yup, and I wonder how many other Silicon Valley Corps are on the actual list of,

“They Don’t care, and they Didn’t care”

About security with user PII they had collected and aggregated.

Also in those in breach of EU legislation including going back to lying on “Safe Harbour Agreements”…

When are there going to be industry regulators that are going to admit these Corps are being run by lying sociopaths, taking any unlawful short cut they can get away with to try to make a profit…

And more importantly the regulators that exist are not looking let alone stoping the unlawful activities.

Therefor regulators need the powers to just “go in and audit” and revoke “licences to operate” and similar.

I know it’s not popular to say, but unless you have regulators with real teeth and no fear to bite with them, then expect to see things get worse, a lot worse.

Ted • September 16, 2022 10:24 AM

The hacker also purportedly downloaded all the vulnerability reports in Uber’s HackerOne bug bounty program. The hacker would have had access to private submissions for issues that weren’t yet fixed. It’s possible these could be sold to others.

https://www.bleepingcomputer.com/news/security/uber-hacked-internal-systems-breached-and-vulnerability-reports-stolen/

Larry wannabe techguy • September 16, 2022 10:43 AM

@Clive
“Corps are being run by lying sociopaths”
yes & so are governments.
As always “Quis custodiet ipsos custodes?”

Grundoon • September 16, 2022 11:24 AM

Well Larry, at least we can vote the government sociopaths out of office. We’re stuck with the corporate ones.

One big incentive for corporations to not improve security is the law’s requirement for causation in order to win damages. If Person X’s information has been breached (whether or not X knew that a particular corporation had his information or not) from numerous corporations, then person X cannot win against any of the corporations that had his information and were breached. Each will say that Person X cannot prove that it was the breach of its particular system that leaked the information.

So improving security would actually hurt companies.

JonKnowsNothing • September 16, 2022 11:34 AM

A curious contrast…

If you have ever tried to deal with a Large Dog Company to request a simple change of data, and been told that the CSR doesn’t have authority to do the change… Generally followed by a series of transfers to the next-in-line person(s) and eventually to dead-air call drop, with no changes at all happening (see credit reporting agencies).
Huge swaths of people having access to every aspect of the company from soup to nuts with no restrictions and no limitations. A CSR who can take care of all issues with no referrals to another department and doesn’t “have to check with my supervisor about this” response. They just fix the problem.

I don’t think I’ve run into the second version very often. (1)

===

1) Except for Engineering Departments.

It irks engineers and cs folks to no end when they are restricted from any aspect of the code base. Even if the code is far distant from their own requirements, they still want access.

Removing access is a fight not worth your job, cause that’s what happens (see Mudge and Stamos and loads of others).

Stopping access before it becomes universal is the only manageable pathway, until someone bigger than you says I WANT IT. Then game over.

iAPX • September 16, 2022 11:35 AM

Not surprised at all, many companies are implementing a “candy” (candid) security strategy: hard on the outer shell and soft if not liquid inside.

I know a big company working on 9-digits revenue e-commerce website, where backend devs have full (admin) access to the production databases, without any control, without any access logs (they share one common account) nor logged SQL queries (this is the webservice account!), with 2FA on their own smartphones.

2FA having the ability to be reset and paired to a new device from their own computer.

It is just awaiting the right hacker to become a catastrophe. 🙁

JonKnowsNothing • September 16, 2022 11:54 AM

@Clive @All

re: “go in and audit” and revoke …

This maybe totally different in other countries but in the USA “audits” mean nothing at all. Primarily because most audits are not criminal investigations, they are simply a validation of a representation of some factoid.

An audit of a statement-form where you claim an account has $X amount in it, mostly consists of looking at a provided bank statement and matching the bottom $X with the amount you filled in the blank. Audit Good (tick) and No Discrepancy (foot).

A criminal type of audit requires a criminal warrant for an investigation.

If you are applying for most types of social support help, you fill out the same form with $X amount in the income box. At the bottom of the document that you sign, is a clause something like: If you lie about your income you are subject to $500,000 fine, 5 years in jail. Or similar. The agency then does an audit from the bank statement (tick) but if there is a discrepancy (foot) then you may get a criminal charge.

It doesn’t have to be a crime only an error will do. The UK Post Office Admin wrongful cases are still rolling along. AU RoboDebt wrongful charges are still rolling along with the latest restitution being .96 AU cents.

If you want teeth, don’t ask for an Audit. Ask for a Criminal Investigation based on Presumption of Guilt. This is the newest application of laws particularly targeting people who are Post Masters in the UK, the Unemployed in AU, and for everyone in the USA who gets a pension or assistance.

As for those annual reports filed with the Stock Exchanges, read the accounting firm statements very carefully. No where will they say that they look for illegal actions. It’s finely worded and some of us had to memorize each type to recite by heart. It’s not a criminal investigation.

Ken • September 16, 2022 3:26 PM

Most companies in the US have Dumbos running Cybersecurity.

Just query Linkedin on the profiles of CISOs, VPs etc., in charge of Cybersecurity. You find totally unrelated backgrounds like Chemistry, Political science, MBA, Law, … None have no idea about Security Engineering. Of course, they can talk some BS about Cybersecurity and that is it.

This is really not the case in China or Europe. They do have qualified people running Cybersecurity for the most part.

Well, it may be just a matter of time Russia pulls the plug and cause a never seen disaster in the US.

x • September 17, 2022 9:01 AM

Apart from the lousy internal security, these 2FA commercial solutions are notoriously unreliable. Trying to log on five times (confirming the second factor every time) until it finally catches on is so common no one really cares about anomalies anymore.

Frank B. • September 17, 2022 10:08 AM

“Bruh, someone broke into our system!”

“Bruh! No way!”

“Bruh, how’d it happen?”

“No idea bruh.”

“Whad’re we dune ’bout it bruh?”

“No idea bruh.”

Repeat ad nauseum until investor money runs out.

SpaceLifeForm • September 17, 2022 3:36 PM

@ x, Clive, ALL

Can you be more specific as to which 2FA commercial solution is so unreliable?

I can guess (read: I am pretty sure I know, and may have noted the org here previously), but I want you to point exactly at which implementation that allows 5 trys and then succeeds.

Because that is pure Security Theatre and allows a race condition.

Clive Robinson • September 17, 2022 7:30 PM

@ SpaceLifeForm, x, ALL,

Re : 2FA unfit for service.

“Can you be more specific as to which 2FA commercial solution is so unreliable?”

There are many types of sustem claimed by those selling as 2FA, to meet “audit requirment”. We saw this back in the early days of PCI compliance. However on analysis many are not what I would agree with as being either truley 2FA, or secure.

In essence many are just two lists of potentially random strings one in the token held by the user of the “client device” the other in the software on the “server authentication service”.

These lists need to be kept sunchronized in various way.

If they fall out of synchronization there needs to be some way to regain it. But… the token needs to be both “reliable” and “usable” as well as “synchronized” with the server and importantly “securely” at all times and all events with the server. Without race conditions and other issues. So not open to duplicate/forked, replay, and MITM attacks etc

It’s a bit of a tall order and many 2FA devices for “usability” sacrifice some measure of secirity. For instance some 2FA sustems do not use a truly random list… They use a determanistic algorithm that is claimed to be “secure” but actually is not when the seed value is acquired from the TechSup systems of the 2FA system supplier.

So from my point of view your question should not be “which is unreliable” but “which is reliable” the answer to which is “darn few” when you get to analyze them sufficiently.

iAPX • September 18, 2022 6:15 AM

@Clive, SpaceLifeForm, x, All

As the source stated abusing “notifications”, and clarified by presenting itself as Uber IT asking the Uber employee to ACK the request, I would bet it’s the same totally flawed 2FA that I described earlier: a personal smartphone containing a “2FA” App (Okta verify, Duo Mobile, etc.)

A personal smartphone is not a security device in any way.
These Apps are also too intrusive on a personal device, doing tracking as much as possible, in the name of “security”.

Both could be somewhat mitigated, by using a dedicated device containing only the requested 2FA App, not connected to any personal Cloud account nor professional account, protected as much as possible, up-to-date (meaning it is regularly updated and updates are available!).

You will find some people with old devices, non-updated but considered as updated because no more updates are proposed for it, loads of apps installed, and it’s a security flaw, not a security device.
These people usually add their Slack/Teams/Gmail professional accounts through Apps on their smartphone too, making it a single point of failure (or hack).

I do understand it cost less for companies than physical U2F USB keys, but it’s a total blunder.

PS: excuse my english skill level, it’s my third language

Clive Robinson • September 18, 2022 11:48 AM

@ iAPX, ALL,

My reply is in several parts due to the continuing “blog software” issues.

So Part 1

“PS: excuse my english skill level, it’s my third language”

Like many here, English is my first language, and you will find I make more than enough mistakes for every one 🙁

So consider yourself in “friendly territory” on that account.

With regards,

“A personal smartphone is not a security device in any way.”

That is a message I wish a lot more people either realized or actually took notice of.

Clive Robinson • September 18, 2022 11:50 AM

@ iAPX, ALL,

Part 2,

I kind of made myself unpopular back when “Secure Messaging Apps” came out by pointing out they were not secure… Because you had to consider the whole system not just a small part of it. So either they have accepted what I said or have given up 😉 Either way I don’t think you will hear anyone here disagree with you now.

But even if they did you are on very solid ground with,

‘These Apps are also too intrusive on a personal device, doing tracking as much as possible, in the name of “security”‘

One of my long running complaints about the Android and Apple “Walled Garden” App Stores was the promise to all users that the environment that Google and Apple profit by greatly would “be secure” thus for the user “safe”… well that’s turned out to be compleatly untrue…

Clive Robinson • September 18, 2022 11:54 AM

@ iAPX, ALL,

Part 3,

With hundreds if not a lot more Apps being quite deliberately “compromised” at any one time. Now both Apple and Google have built “tracking” into the base levels of their OS’s which you can not turn off properly. Thus not just makeing the phones “insecure” but due to the extra battery usage an “environmental disaster”. Even the latest lithium technologies have a limited number of “recharge cycles” and as some will know packing more energy density in phones can cause their users to suffer injury such as burns. But others will remember back in the days of Nokia plain phones you usually only had to recharge them once a week. Smart phones on the other hand end up fairly quickly being “tethered” by their charging cords because they use so much energy over a very short time (we saw this with laptops and also pads and no manufacturer wants to solve it).

As you say,

“Both could be somewhat mitigated, by using a dedicated device containing only the requested 2FA App…”

For my sins way back last century, I suggested and pioneered the use of mobile phones and SMS messaging as a “secure second channel” for “user security”.

Clive Robinson • September 18, 2022 11:58 AM

@ iAPX, ALL,

Part 5,

It turned out to be a bad idea, as technology changes fast and it quickly made my suggestion insecure.

But the use of a stand alone “token” if implemented properly is a good idea… The problem is I’ve yet to see one implemented properly. There are various reasons for this but the main one is “user convenience”. So security fails because users will not tolerate it in their work life even when on six or more figure salaries…

One aspect of this is the “I’ve forgoton where I put down…” issue. Fashion and security say “no pockets” and “no bags” respectively so people have to “put things down” and the more they do the more likely they are to not pick them all up, or try to “stash thrm away” somewhere.

The advent of the mobile phone and the rapidly diminishing size of technology means that every year they squeezed in more and more functionality… Then a problem occurred the phones were too small for ordinary humans to use them in the way they want. So we now have the equivalent of flat screen TV’s in our pockets, so even more has to go on them to justify the cost and inconvenience.

Which is why,

“These people usually add their Slack/Teams/Gmail professional accounts through Apps on their smartphone too, making it a single point of failure (or hack).”

Clive Robinson • September 18, 2022 12:00 PM

@ iAPX, ALL,

Part 6,

The writer and techno-evangelist Douglas Adams in one of his books, not just predicted the “put everything on it” mentality but that it would be used against the user by others (Ford Prefect in the book). Worse and ironically he made the “victim” a very senior computer security person…

In my “proffessional experience” going back further than I actually care to remember, almost always the vulnerability in a system was the person who should know better, but… Thought they were better or above such considerations.

But as in all things there are exceptions…

Clive Robinson • September 18, 2022 12:05 PM

@ iAPX, ALL,

Part 7,

One of my more endering memories has an instructive lesson in it for the “can do” types…

It goes back to a large finance organisation and the personal assistant to the boss. She was unusual in that not only was she very good at her job she was very likable and almost a “mother hen”. Well I was there as a consultant, and realised she was breaking a lot of financial regulations inadvertently. She had sent me an internal memo that was just a few lines, but the file size was enormous. So I opened it using a few *nix commandline tools, and quickly saw why… It had hundreds of memos inside, some extreamly confidential. After a few moments thought, I decided to go see her to see why.

It turns out the “secure” memo software being used had an “undelete” function that apparently never stopped recording deletes. Her work habit was to just open the last memo sent, highlight the content, hit the delete button start typing in the new memo, adjust who it was being sent to in a similar way and then just hit send…

When I explained and showed her she nearly fainted. Luckily I and the SysAdmin were on good terms and we spent the next few evenings going through the system “cleaning up” and we found that she was not the only person who “worked that way”.

Needless to say the problem with the unlimited delete was not something the software developers or those who specified the system had thought about. They had been so focused on securing the users work they had not realised the bigger picture.

It was easy enough to sort of fix, the software but that brought up issues with the work styles of other people… None of the things these people were doing was wrong, it’s just that you can not design a system with every eventuality in mind, and that is a problem for security, that can not be fixed.

Clive Robinson • September 18, 2022 12:11 PM

@ iAPX, ALL,

Part 8,

2FA is nowhere near being an ideal security system, it’s quite deficient and it’s most oftenly used incorrectly, thus fails to be secure even in it’s “hardware token” form.

Like the password that came before it, it 2FA has long outlived it’s usefulness and is now acting like “a boat anchor” stopping our forward progress. But as a poster I have framed on my wall says,

“In order to realize the worth of the anchor, first we must feel the stress of the storm”

I used to sail a lot, and have felt the stress of the storm on more than one occasion. But I’ve never used the anchor during one. Preffering to be safely moored to “ride it out” well in advance, or if not I would head for deep water well away from the shore even if it was blowing off shore. Storms can be weathered but rocks and leeward shores not, and winds are like many managers, fickle in their direction and can not be relied upon.

If you are ever in a storm in a well found sailing craft that you can not weather in open water, then the chances are very real you will not survive on just an anchor[1]…

It’s a lesson the ICT industry needs to learn.

[1] As with “rules” there is an exception. It’s called a “sea anchor” it’s job is not to hold a “ground track position” but when you have taken down all sail or have lost your rigging, it will help keep your boat to the wind and help reduce or stop it becoming awash or capsizing. At which point you attach the sea anchor bow or stern depends on what you are trying to achive, but that’s a long discussion best had, and the methods well practiced, long befor you need them in anger.

iAPX • September 18, 2022 2:24 PM

@Clive, ALL

“For my sins way back last century, I suggested and pioneered the use of mobile phones and SMS messaging as a “secure second channel” for “user security”.”

Ken Thomson summed it up in 1984, it’s checkmate.
I think anyone interested in security should read it, understand it deeply, see how it applies to silicon too, and funnily understand our silicon security is only a sand castle.

There’s no secure channel, no security warranty, it’s only risk mitigation, we only do that.

SpaceLifeForm • September 18, 2022 3:24 PM

Two problems stand out

First, the employee bit on the MFA Fatigue problem. Allegedly.

As I have mentioned before, no employee should fall for it, no matter how tired or hungover they are. You call your NOC and find out what is going on. You could also just turn your phone off. If one is supposed to be ‘on-call’ and should be available for tech support, then they call the NOC.

I am thinking this MFA Fatigue problem is really just a cover story for insider attacks. There really is no excuse.

The other problem is the hard-coded creds that are needed to interoperate with external databases. You could store those creds inside of your core databsse, and have the interfacing software query the core database for the creds, so that the interfacing software can then connect to the external databases. This is safer than putting the creds in a flat file that is readable over a network share.

If you only have one database, then you are in position to enforce access control and auditing. If you have to rely upon external databases, then you made your access control and auditing problem almost impossible to enforce.

Old Man yells at clouds.

Clive Robinson • September 18, 2022 4:24 PM

@ SpaceLifeForm,

Re : Not the way we do it

“Old Man yells at clouds.”

Where I come from we,

1, Cuss the Trees asunder.
2, Shoot the clouds from a’far.

The first goes back centuries, thus there are now many choice words with which to vent your spleen.

The second is more modern, for some reason there is something tension relieving about firing a 12 guage up into the sky, with nary a hope of hitting a cloud[1]…

It is said of lightning struck trees that they had be caught by the cussing so riven asunder. Thus damage of a biblical proportion, only most don’t give a fig 😉

[1] Almost as much fun as getting a few off in a “falling plates” competition,

https://www.fieldsportschannel.tv/run-and-shoot-falling-plate-targets/

I’ve put my fair share of rounds down that range, and for those who get the chance, I always did better in the right hand side. Oh the trick is not to aim at the plate but the gravel just in front, sometimes you can get two for the price of one… Oh and to make it realy fun “noddy suits at high noon mid summer” as the dress code. Back in the late 80’s there was a short tubby lad from the RGJ’s who dveloped what got called the “seal flop” he would kind of throw himself at the ground in what looked like a “belly flop” seals do when getting onto the ice, but he’d land in the full prone position to get atleast two away before anyone else could get down and boogie. Having tried to emmulate it on a judo mat, I concure with the general feeling that the dude must be dead from the neck down to not feel it.

Winter • September 18, 2022 11:43 PM

@iAPX

Ken Thomson summed it up in 1984, it’s checkmate.

Not checkmate. David A Wheeler solved the trusted trust attack in his PhD thesis.

‘https://dwheeler.com/trusting-trust/

This dissertation’s thesis is that the trusting trust attack can be detected and effectively countered using the “Diverse Double-Compiling” (DDC) technique, as demonstrated by (1) a formal proof that DDC can determine if source code and generated executable code correspond, (2) a demonstration of DDC with four compilers (a small C compiler, a small Lisp compiler, a small maliciously corrupted Lisp compiler, and a large industrial-strength C compiler, GCC), and (3) a description of approaches for applying DDC in various real-world scenarios. In the DDC technique, source code is compiled twice: once with a second (trusted) compiler (using the source code of the compiler’s parent), and then the compiler source code is compiled using the result of the first compilation. If the result is bit-for-bit identical with the untrusted executable, then the source code accurately represents the executable.

Simular approaches can be used for evaluating (un-)trusted communication channels.

SpaceLifeForm • September 19, 2022 12:29 AM

@ Clive

winds are like many managers, fickle in their direction and can not be relied upon

Well said.

Years ago, I was sailing on a lake. The lake is broad, but not very deep. The surrounding terrain is flat. Being the WX person I am, I noticed storms building to the west (prevailing movement would be eastward toward the lake during summer), and decided to start tacking back to dock being some distance away. The winds had already shifted. The storm was pulling the air in a different direction than the earlier winds.

Alas, the proverbial calm before the storm arose.

This sailboat was not that small (slept 4), and had a motor, which normally would only be used to maneuver within the dock area. Fired it up. Much slower than actual sailing, but at least making progress.

So, as I am manning the tiller, I am watching the storm approach. What surprised me, was that each time I saw a lightning strike that reached the lake, I felt a shock thru the tiller. Made it back just in time. It was a big storm, with some hail.

Later, two former coworkers of mine also were out sailing on the same lake, but a different day, different sailboat. Again, a storm moved in. One of them did not survive.

SpaceLifeForm • September 19, 2022 2:34 AM

@ iAPX, Winter

So Orwellian 😉

Ken Thompson was thinking ahead, but that was long ago.

I highly recommend that younger folks that have the time and energy to go thru the process of building an OS from source code. Oh, and cross-compile while you are at it. You will learn a lot. Let’s say more than 4 years degree worth.

https://www.schneier.com/blog/archives/2006/01/countering_trus.html

These days, you only have to worry about the Silicon Turtles.

Carey • September 21, 2022 11:55 AM

Wow its crazy how good this threat actor is at a young age. The fact that he was able to manipulate a employee at Uber and was able to get their password. Even though the Uber employee account was protected by a multi-factor authentication, the hacker still managed to get past that defense. I wonder did Uber manage to solve the incident and get their some of their information that was taken by the hacker.

SpaceLifeForm • September 21, 2022 7:21 PM

@ ALL

Just want to flag a link that Bruce added to this article. Worth a read.

Reminder: Attribution is hard.

Some snips.

‘https://www.darkreading.com/attacks-breaches/uber-breach-external-contractor-mfa-bombing-attack

Though the attacker also accessed a database of vulnerability disclosures in its platform submitted via external researchers through the HackerOne bug-bounty program, all the bugs have been remediated, Uber said.

I have bridges for sale.

The reality is that MFA remains vulnerable to man-in-the-middle (MitM) attacks, he says.

See SS7.

The rapid adoption of SaaS has created an unmanaged risk in the form of complex integrations between poorly managed services.

Old man yells at clouds.

Ted • September 21, 2022 11:05 PM

Thanks Bruce and SpaceLifeForm! Always interesting to see what additional details emerge.

I thought it was notable that the DR article remarks on the commonness of some of Uber’s practices, particularly their implementation of MFA. This is really a challenging problem.

It’s been interesting to see folks in InfoSec cut Uber a bit of slack.

Even Dave Aitel – talking on the Cyberlaw podcast – said when he ran a penetration testing company it was extremely common to find a script with keys to the kingdom in a share. In Uber’s case I think this was the admin credentials for the PAM.

Not to mention, is anyone really safe from teenagers?

(Side comment: I felt bad bc when I originally posted on this thread I hadn’t seen that Bruce had already linked to the Bleeping Computer article I referenced. Ah! All obliviousness aside, always super grateful for the stream of wonderful posts and shared info!)

Clive Robinson • September 22, 2022 2:14 AM

@ SpaceLifeForm, ALL,

With regards,

“The rapid adoption of SaaS has created an unmanaged risk in the form of complex integrations between poorly managed services.”

I keep saying that for most things SaaX –where X is marketing naming magic– is a bad idea for a whole host of reasons. I’d thought at one point AWS had kind of proved it enough for most mortals with normally firing neurons but hey…

I guess the question for everyone at some point will be,

“Can we stuff the genie back in the bottle.”

In fairy tales the advice is,

“Use your third wish carefully it’s the one to undo the first two.”

The trouble with SaaX is generally there is no third wish just painfull regrets.

Especially when people realise “loss of data” has many more meanings than they think and likewise causes.

When I was young the advice for those contemplating stupid behaviour was,

“Don’t do it on your doorstep”

I would never in any reality I could have envisioned back then, expected a whole industry to misunderstand it and do entirely the wrong thing…

Comments

Leave a comment Cancel reply