Uber data breach aided by lack of multi-factor authentication

For Uber CISO John Flynn, having to explain the company’s massive 2016 data breach to a senate hearing was never going to be an easy day out.
There are two strands to this incident – the company’s handling of the breach of 57 million customer and driver records once it found out about it, and the technical failings that allowed it to happen in the first place.
The first we already know a bit about, principally that the company realised it had been breached in November 2016 when it was sent a $100,000 ransom note. That ransom was paid through the company’s bug bounty programme, allegedly in the hope nobody would notice.
Uber then failed to tell anyone about the breach for a year, finally owning up to what had happened last November.

In an attempt to limit further criticism of Uber’s ethical failings, Flynn tried in his testimony this week to come clean about the security weaknesses that led to the breach.
According to Flynn, the hackers were able to access backup files on an Amazon AWS bucket after finding the credentials to access it inside code that had been posted to a weakly-secured GitHub repository.
But how had they accessed the repository?
Presumably by brute-forcing the password, which was a viable attack method because multi-factor authentication (which GitHub offers in several forms) had not been turned on.
As Flynn states:

We immediately took steps to implement multi-factor authentication for GitHub and rotated the AWS credential used by the intruder.

Standard practice, of course, although to anyone listening this will have sounded like the perfect definition of how to bolt a stable door with the horse miles down the road.
He concludes:

Despite the complexity of the issue and the limited information with which we started, we were able to lock down the point of entry within 24 hours.

As far as Flynn and Uber is concerned, its technical reflexes were good. Its security people got busy, closed the weakness, locked out the bad guys and stopped using GitHub except to post open source code.
And yet in the same testimony, Flynn admits that “to the best of Uber’s knowledge” the hackers gained access to the AWS bucket on October 13, 2016, a full month before Uber received the ransom note telling it the bad news.
This means that the only reason the company knew it had suffered a calamitous data breach was because the hackers told it so.
We don’t know what sort of logging Uber was using to track access to its external data, but this might have provided an early warning had it been in use.
Ditto, multi-factor authentication, which should have been implemented at the highest level available across all external services (with someone checking to make sure this was being done correctly).
Companies reading of Uber’s woes would do well not to gloat, however. The correct reaction should be to learn from its public mistakes to avoid making the same ones.