In major goof, Uber stored sensitive database key on public GitHub page

Ride-sharing service subpoenas GitHub for IP addresses that accessed security key.

Read the whole story

 

[psd]

rakkuuna[/url]":3rw7vh80]It is so easy mess up like this though. Passwords and secrets for databases are often stored in configuration files, just like database ports and urls and other settings. Every development framework I know encourages this. And where does this configuration end up when you want to get development started fast? In the same folder as you source code. Your source code goes to version control and that's how you get in a mess like this.

Almost every developer I know (including me) has committed passwords to version control. The lucky thing is usually you are not committing into public repositories. Common development frameworks should have some best practices on how to do it properly since everyone makes the same mistake...

Though in the case of Uber, they should hide internal databases behind a firewall to prevent things like this. You should not be able to access it from public internet, no matter how many passwords you know. That is the easiest fix for dumb developers.

integratedSecurity = true (or something equivalent)

 

[metafun]

psd[/url]":30a7kbx1]

chipmunkofdoom2[/url]":30a7kbx1]It's really simple: if we want these incidents to stop, we need penalties for the companies that leak information. The HIPAA act specifies penalties ranging from $100 to $50k per violation if PHI is leaked. Damages could even be assessed per record released, depending on the size of the breach. Healthcare data breaches happen, but they're relatively rare. Consumer data breaches are a dime a dozen, from Target to Home Depot to LinkedIn. The list goes on and on.

Businesses treat securing data properly as optional because it is. If a breach occurs with consumer data, there are no penalties except for potentially losing some business. Securing data properly needs to be required by law and punitive damages need to be assigned for violations. Securing personal data needs to be a cost of doing business, not something that's nice to do.

The key though is "willful neglect" which, I don't know can be said in this case or more generally, can be established in every db hack. IANAL, of course.

You are probably correct. Though just having the penalties in place would help ensure that the question of neglect gets proper scrutiny.

 

[TomXP411]

Someone tell me again how this is a trusted company, and we should be backing them as they Fight The System?

 

[hizonner]

uhuznaa[/url]":2cdhwe93]
Uber is expanding like a gas into a vacuum right now and is just as able to fill all the available vacuum in any meaningful way as the gas would be.

What vacuuum? They're a freaking taxi service. They're no different from owner-operator taxi services all over the world. Their business is probably older than cars. The last time it really changed was when radio dispatch came out.

Uber's advantages are a slightly more efficient dispatch system that enables them to take on more part time drivers (although I'm not sure they really have many), and a total lack of respect for drivers, passengers, or the law.

There's no vacuum of taxi services. The only vacuum Uber is expanding into is a vacuum of irresponsible, rule-ignoring taxi services with enough money to keep politicians at bay.

A smartphone app for dispatching cars is not comparable to the discovery of fire.

 

[lomifeh]

darkangel666[/url]":3b2z50ap]

Iphtashu Fitz[/url]":3b2z50ap]

yakumo[/url]":3b2z50ap]if the key is posted in public, how is anyone using it at fault?

Mainly because the database itself is likely not publicly accessible. Whoever used this key would have had to broken into Ubers corporate network to exploit it.

The article says that database was accessed from an IP not associated with Uber, so it looks like database IP itself was also publicly available. Usually, to accuse someone in unauthorized data access this person should access data against the reasonable measures to guard the data by the owner. In this case keys were place in public access, no reasonable measures to guard data were taken. So court shouldn't grant Uber's request to disclose IPs of those who accessed the guthub project. Uber pretty much gave database keys to public for anyone to access.

This increases the stupidity of it by tenfold. Database security 101 you never have your database publicly accessible.

 

[Pantagruel]

hizonner[/url]":1d8hgfdv]

uhuznaa[/url]":1d8hgfdv]
There's no vacuum of taxi services. The only vacuum Uber is expanding into is a vacuum of irresponsible, rule-ignoring taxi services with enough money to keep politicians at bay.

A smartphone app for dispatching cars is not comparable to the discovery of fire.

I couldn't have said it better. And I think this applies to many of the "old business made with an app" startups.

 

[Iphtashu Fitz]

Rookie_MIB[/url]":3gre2boy]I'm curious as to how much trouble the person who downloaded the dbase could get into. You have a public facing website. A publicly posted key. Person takes public posted key, enters public facing website, downloads what's there...

No security was 'hacked', encryption wasn't 'circumvented', any curious 12 year old could have been responsible for this, which would have been double the age of the person who apparently designed their security.

You're assuming that the website has a location to enter this private key in order to access the database directly. Most applications abstract access to the database so that you can't interact with the database directly. Chances are that obtaining the private key was only one piece of the puzzle in accessing this data. The perpetrators likely also implemented a SQL injection attack or some other sort of remote exploit of Uber's website to indirectly access the database.

Not that Uber should be let off the hook for sloppy programming and/or security practices if the database was in fact accessed via an an exploit of these sorts.

 

[truthyboy15]

Bob.Brown[/url]":3j1ak9cz]

chipmunkofdoom2[/url]":3j1ak9cz]It's really simple: if we want these incidents to stop, we need penalties for the companies that leak information. The HIPAA act specifies penalties ranging from $100 to $50k per violation if PHI is leaked. Damages could even be assessed per record released, depending on the size of the breach. Healthcare data breaches happen, but they're relatively rare. Consumer data breaches are a dime a dozen, from Target to Home Depot to LinkedIn. The list goes on and on.

Businesses treat securing data properly as optional because it is. If a breach occurs with consumer data, there are no penalties except for potentially losing some business. Securing data properly needs to be required by law and punitive damages need to be assigned for violations. Securing personal data needs to be a cost of doing business, not something that's nice to do.

Sadly, health care data breaches are not rare. Anthem (a major health insurer) released my SSN and other identifying data along with that of 80 million of my closest friends. Fined? Naaaaah!
http://www.npr.org/blogs/health/2015/02 ... s-multiply

Anthem doesn't give a damn about data security period. Just this weekend I received a notice from my health plan I had to select one of three companies for benefit coordination. One of those companies was Anthem after that latest fuckup you couldn't pay me to give you my data.

Disclosure: Years ago I had Anthem but only for a month because they decided to charge for something that was covered. Oh a few months ago I received a consumer alert from a hospital I attended as a child that their data was breached and my data was in it. It was never in the news so apparently it wasn't anything big.

 

[SixDegrees]

Huh. So their database was encrypted.

Where's the guy who always chimes in, when encrypting databases is brought up as a security requirement, and claims that such encryption is both impossible and useless?

 

[Iphtashu Fitz]

darkangel666[/url]":dj65gz7d]

Iphtashu Fitz[/url]":dj65gz7d]

yakumo[/url]":dj65gz7d]if the key is posted in public, how is anyone using it at fault?

Mainly because the database itself is likely not publicly accessible. Whoever used this key would have had to broken into Ubers corporate network to exploit it.

The article says that database was accessed from an IP not associated with Uber, so it looks like database IP itself was also publicly available. Usually, to accuse someone in unauthorized data access this person should access data against the reasonable measures to guard the data by the owner. In this case keys were place in public access, no reasonable measures to guard data were taken. So court shouldn't grant Uber's request to disclose IPs of those who accessed the guthub project. Uber pretty much gave database keys to public for anyone to access.

That's a bit of a stretch to assume it means the database was publicly available. It's also possible that a bug in Uber's web application or an exploit in some library allowed the attacker to perform a SQL injection attack or remote code execution attack.

 

[Findecanor]

Am I the only one who finds that the biggest wrong-doing by Uber in this story is that they are requesting that Github should yield their user-access records to Uber instead of to law-enforcement?
Or is there something that I missed in this story?

 

[andrewb610]

Just another example of how Uber's cockiness is going to be the end of them

 

[Hawaiijim]

If Uber made their database keys public knowledge, then they fully deserve the coming class-action lawsuit.

That said, as a developer I know it's way too easy to accidentally include the keys in source control.

 

[Wall]

This sounds like a sabatour, not simply ignorance. Ignorance is using a sticky note on a monitor. This is the equivalent of putting it on a highway billboard.

 

[darkangel666]

Github actually has several hosting plans. Free plan Uber used is intended for open source projects of (potentially) wider public interest. Were the projects shared by Uber actually intended to be publicly used, or Uber just tried to save money and used the free plan for purely internal project?

Other (paid) github plans include totally private hosting, control-by-login hosting, when the project owner decides which github users get access. One example of control-by-login I know is an Unreal gaming engine, when Unreal charges developers $20/month for access, and also pays github for such setup.

 

[Pantagruel]

Hawaiijim[/url]":36r8bbor]If Uber made their database keys public knowledge, then they fully deserve the coming class-action lawsuit.

That said, as a developer I know it's way too easy to accidentally include the keys in source control.

You are just one developer, though. Uber is a billion dollar company. I am sure they can afford at least a team of security guys.

 

[bcassada]

Wall[/url]":986zxmtb]This sounds like a sabatour, not simply ignorance. Ignorance is using a sticky note on a monitor. This is the equivalent of putting it on a highway billboard.

In this day, the sticky note is negligence. If you don't know by now not to do that you've been living under a rock and never should have been hired (negligence of hiring manager who should have vetted your ignorance).

 

[Drakkenmensch]

Findecanor[/url]":2ezih3xa]Am I the only one who finds that the biggest wrong-doing by Uber in this story is that they are requesting that Github should yield their user-access records to Uber instead of to law-enforcement?
Or is there something that I missed in this story?

Uber just wants to make sure that the evidence of their own wrongdoing is handled...

... properly.

 

[NemesisX00]

It's a sign of the times when a company can make such an egregious mistake and then think the correct action is to sue the service provider whose service was used (by said company) to cause the mistake.

It really doesn't matter what data they took, these "John Does" did nothing explicitly wrong according to the law. They clearly were given access purely based upon the fact that Uber put up the access key on a publicly accessible page. EVERYONE had access.

 

[siliconaddict]

The contents of these internal database files are closely guarded by Uber,"

Not close enough apparently.

 

[SPCagigas]

thegrommit[/url]":175f3pu8]Heh, not suprised. This is Uber. Not paying attention to security and privacy is part of their business model.

To be fair, is anyone surprised? Paying attention to anything other than "being disruptive" is not part of their core business model.

 

[SPCagigas]

hizonner[/url]":761a9f7s]

thegrommit[/url]":761a9f7s]Heh, not suprised. This is Uber. Not paying attention to security and privacy is part of their business model.

Not paying attention to security, privacy, labor conditions, longstanding laws directly targeted at their main business...

Basically Uber appears to be run by douchebags who think they're above it all, and that paying attention to WTF you're doing is for little people who aren't "disruptive". No surprise if the attitude trickles down.

You hit the nail on the head. Uber is what happens when mommy's special snowflake starts a business in the 21st century.

 

[bcassada]

NemesisX00[/url]":2ye20xhk]It's a sign of the times when a company can make such an egregious mistake and then think the correct action is to sue the service provider whose service was used (by said company) to cause the mistake.

It really doesn't matter what data they took, these "John Does" did nothing explicitly wrong according to the law. They clearly were given access purely based upon the fact that Uber put up the access key on a publicly accessible page. EVERYONE had access.

Having the ability to access the key doesn't grant you authority to access the data from a legal perspective.
This sounds like a costly mistake on the part of someone who either didn't realize they had uploaded it AND on the person(s) responsible for checking the repo didn't contain something it shouldn't. That may be part of the perils of being in a startup (I'm in one, too), but it doesn't excuse it.

And it certainly doesn't make it ok to use the key if you aren't authorized.

 

[tacothursday]

There is no certainty that the key's presence on github is how it was obtained.
This wide net casting is absurd. I hope the court does not give into this.
If uber could provide a suspected IP address to cross-reference, I would be more inclined to entertain the sharing of info... But this is outright surveillance in the same way that our government wishes to intercept and replay all its citizens communications / transactions.

 

[SPCagigas]

psd[/url]":qdzmtzpq]

chipmunkofdoom2[/url]":qdzmtzpq]It's really simple: if we want these incidents to stop, we need penalties for the companies that leak information. The HIPAA act specifies penalties ranging from $100 to $50k per violation if PHI is leaked. Damages could even be assessed per record released, depending on the size of the breach. Healthcare data breaches happen, but they're relatively rare. Consumer data breaches are a dime a dozen, from Target to Home Depot to LinkedIn. The list goes on and on.

Businesses treat securing data properly as optional because it is. If a breach occurs with consumer data, there are no penalties except for potentially losing some business. Securing data properly needs to be required by law and punitive damages need to be assigned for violations. Securing personal data needs to be a cost of doing business, not something that's nice to do.

The key though is "willful neglect" which, I don't know can be said in this case or more generally, can be established in every db hack. IANAL, of course.

But how many security incidents have to happen to establish a pattern of wilfully negligent behavior? Doing this once? Hard to make a case for willful negligence. Failing to secure drivers' personal data, followed up by failing to secure customers' personal data? Now it starts to look a little more . . . I hesitate to say "sinister", but it certainly looks like Uber isn't that interested in protecting the personal data of the people they interact with. Toss on top of that the doxxing allegations and the accusations that they weren't actually doing the background checks they said they were from last year, and you're starting to paint a picture of a company that is willfully placing profit about security. . .
The barrier for williful neglect may be high, but it certainly doesn't look insurmountable.

 

[SPCagigas]

TomXP411[/url]":cxfapnr7]Someone tell me again how this is a trusted company, and we should be backing them as they Fight The System?

They aren't. This latest eff-up just confirms that my decision to avoid dealing with them was the right one.

 

[bcassada]

tacothursday[/url]":xqc7jnlw]There is no certainty that the key's presence on github is how it was obtained.
This wide net casting is absurd. I hope the court does not give into this.
If uber could provide a suspected IP address to cross-reference, I would be more inclined to entertain the sharing of info... But this is outright surveillance in the same way that our government wishes to intercept and replay all its citizens communications / transactions.

It seems reasonable to me that they pursue the IP of whomever pulled that file on that day. Not sure why you think that is a wide net unless you assume (and perhaps rightly...I dunno) that they haven't already taken reasonable steps to eliminate other avenues to obtain said key.

If you're paying Git for the repo, then access to these logs is absolutely reasonable and proper from a security perspective.

 

[BananaBonanza]

rakkuuna[/url]":e76rnuhq]Though in the case of Uber, they should hide internal databases behind a firewall to prevent things like this. You should not be able to access it from public internet, no matter how many passwords you know. That is the easiest fix for dumb developers.

That's not a fix. There is no such thing as a private repository. At the very least, disgruntled employees or contractors will have access to it. And the people granting access have no idea (or don't remember) that they are giving away the keys to the castle instead of just the floor plan.

Instead, developers should not have direct access to production servers and data in the first place.

If you take privacy (and security) seriously, you need consequently to restrict power. Allowing a developer to look up (or worse modify) an ex-partner's account, e.g. should be your nightmare scenario. (Not preventing or monitoring it is even illegal in many countries with strong privacy laws.) You wouldn't want your architect to keep a key to your house after you moved in, either.

 

[tacothursday]

bcassada[/url]":3v3ivdze]

tacothursday[/url]":3v3ivdze]There is no certainty that the key's presence on github is how it was obtained.
This wide net casting is absurd. I hope the court does not give into this.
If uber could provide a suspected IP address to cross-reference, I would be more inclined to entertain the sharing of info... But this is outright surveillance in the same way that our government wishes to intercept and replay all its citizens communications / transactions.

It seems reasonable to me that they pursue the IP of whomever pulled that file on that day. Not sure why you think that is a wide net unless you assume (and perhaps rightly...I dunno) that they haven't already taken reasonable steps to eliminate other avenues to obtain said key.

If you're paying Git for the repo, then access to these logs is absolutely reasonable and proper from a security perspective.

If it's paid / closed to the public, that's different. I'm assuming it was in a public repo and that Uber is essentially suing for the license plate # of everyone at drove through (for over 6 months was it?) that gate.
I don't like to think to myself, "Hey, I wonder how Uber put its application together... Maybe it can help me out with my homework" is going to get my identity revealed through my ISP, etc.

 

[bcassada]

tacothursday[/url]":3q4ti3mr]

bcassada[/url]":3q4ti3mr]

tacothursday[/url]":3q4ti3mr]There is no certainty that the key's presence on github is how it was obtained.
This wide net casting is absurd. I hope the court does not give into this.
If uber could provide a suspected IP address to cross-reference, I would be more inclined to entertain the sharing of info... But this is outright surveillance in the same way that our government wishes to intercept and replay all its citizens communications / transactions.

It seems reasonable to me that they pursue the IP of whomever pulled that file on that day. Not sure why you think that is a wide net unless you assume (and perhaps rightly...I dunno) that they haven't already taken reasonable steps to eliminate other avenues to obtain said key.

If you're paying Git for the repo, then access to these logs is absolutely reasonable and proper from a security perspective.

If it's paid / closed to the public, that's different. I'm assuming it was in a public repo and that Uber is essentially suing for the license plate # of everyone at drove through (for over 6 months was it?) that gate.
I don't like to think to myself, "Hey, I wonder how Uber put its application together... Maybe it can help me out with my homework" is going to get my identity revealed through my ISP, etc.

I see what you're saying. I'm on the fence on this even if it was public. The fact a crime (allegedly) was committed doesn't make the act of pulling the key down something that we should not be able to see. If you access Git, it clearly says your activity is logged so whoemever did it should have read the ToS.

Treat the key file like you would a real key. If someone had taken the key to your house from under your publicly accessible doormat, you would love it if the store across the street had a camera that filmed the person taking it.

 

[famousringo]

thegrommit[/url]":3w25ynn5]Heh, not suprised. This is Uber. Not paying attention to security and privacy is part of their business model.

Somebody at Uber noticed it had been a month since the last time the company had pissed off a bunch of people, and took bold action to rectify the issue.

 

[conan77]

John Doe was just disrupting traditional, careless business models. The entrenched buggy whip makers better step up and start caring more about security.

 

[potato44830]

rakkuuna[/url]":31mj4mp0]It is so easy mess up like this though. Passwords and secrets for databases are often stored in configuration files, just like database ports and urls and other settings. Every development framework I know encourages this. And where does this configuration end up when you want to get development started fast? In the same folder as you source code. Your source code goes to version control and that's how you get in a mess like this.

Almost every developer I know (including me) has committed passwords to version control. The lucky thing is usually you are not committing into public repositories. Common development frameworks should have some best practices on how to do it properly since everyone makes the same mistake...

Though in the case of Uber, they should hide internal databases behind a firewall to prevent things like this. You should not be able to access it from public internet, no matter how many passwords you know. That is the easiest fix for dumb developers.

If safety of user data is given top priority, instead of speed, time to market, and all the other silly things that might be pushed in front of it, there would be processes and procedures to prevent entrance of passwords into configuration files. There could also be code run during github checkins that would scan for this type of thing and prevent it. There could also be checklist systems that some auditor would run through periodically to audit the code base for accidental passwords. And on and on. It's just a problem, and problem solving is what Engineering is about. The hard part is deciding that user data security is a problem worth solving, worth spending time on, and worth coming up with solutions for.

If programmers really want to be called Software Engineers then they would do well to adopt the philosophy of engineering professional societies, where upon committing errors that result in harm to the public, the person would face consequences from their professional society, perhaps including suspension from that society.

 

[Carewolf]

theSeb[/url]":1vm5636b]

MoonUnit[/url]":1vm5636b]I was going to make a comment that security is hard, but this goes way deeper than that.

Yes, we must never forget that common sense is important.

It appears common sense is surpringly hard.

 

[tacothursday]

Per the article on theregister.co.uk:
"The ride-booking app vendor is trying to force GitHub [PDF] to hand over the IP addresses of anyone who visited a particular gist post between March and September 2014."

GitHub offers the option to download entire archives as zip, so obtaining that key did not even rely on remotely technical tasks such as git/rsync checkout.

 

[Carewolf]

Hawaiijim[/url]":1u09k8kh]If Uber made their database keys public knowledge, then they fully deserve the coming class-action lawsuit.

That said, as a developer I know it's way too easy to accidentally include the keys in source control.

Which is why you shouldn't be using external source control for internal infrastructure projects. Especially not public ones. Seriously, it just one machine running some source control software, maybe a backup, but hundreds if not thousands of developer can run on a single server. You never have the loads with developers you have with users, so why the fuck would you use external ones?

And if you do use an external one. Pay the handfull of dollars a year it costs for a non-public account. Seriously.

 

[kdemello1980]

Wow, the idea a company that believes it may simply ignore laws it does not like to completely ignore any common-sense security best practices is truely shocking.

 

[Dyn Blin]

chipmunkofdoom2[/url]":qqp9a6ov]It's really simple: if we want these incidents to stop, we need penalties for the companies that leak information. The HIPAA act specifies penalties ranging from $100 to $50k per violation if PHI is leaked. Damages could even be assessed per record released, depending on the size of the breach....Securing personal data needs to be a cost of doing business, not something that's nice to do.

HIPAA is a good template. There is another precedent set in Gramm-Leach-Bliley, regulating financial institutions since 1999, requiring adequate encryption and safeguarding consumer non-public information:

A financial institution can be fined up to $100,000 for each violation
The officers and directors of the financial institution can be fined up to $10,000 for each violation

IANAL, but I find it interesting that GLB may fine individuals. That might put some teeth into a similar measure for such breaches elsewhere.

 

[Bob.Brown]

SixDegrees[/url]":2u3m9a8r]Huh. So their database was encrypted.

Where's the guy who always chimes in, when encrypting databases is brought up as a security requirement, and claims that such encryption is both impossible and useless?

That would be me. If Uber's database really was encrypted, and it's not clear that it was, note that it didn't do any good.

 

[Dilbert]

rakkuuna[/url]":90b1nnvu]It is so easy mess up like this though. Passwords and secrets for databases are often stored in configuration files, just like database ports and urls and other settings. Every development framework I know encourages this. And where does this configuration end up when you want to get development started fast? In the same folder as you source code. Your source code goes to version control and that's how you get in a mess like this.

Almost every developer I know (including me) has committed passwords to version control. The lucky thing is usually you are not committing into public repositories. Common development frameworks should have some best practices on how to do it properly since everyone makes the same mistake...

Though in the case of Uber, they should hide internal databases behind a firewall to prevent things like this. You should not be able to access it from public internet, no matter how many passwords you know. That is the easiest fix for dumb developers.

What's this?!

They didn't commit passwords to source control. They published the private key on a public web site. That is not a mistake. That's negligence, brought on by apathy or incompetence.

They should hide the database behind a firewall? What is this the 90s? The database server should be on an isolated internal LAN away from the front end web server and away from the user's machines, with all ports outbound (originating) disabled and only the ports inbound enabled required for the database queries. Private key needs to be on the DB server only, and any archival copies need to be OFFLINE, not even on an internal machine somewhere, let alone on a public web server. Gods damn how dumb can someone over there be?! How deep does the rabbit hole go?

Multiple layers of defense need to exist. Not just a simple perimeter firewall. This is pretty much standard practice nowadays.