IP address associates Lyft CTO with Uber data breach of 50,000 drivers’ details
Thu 8 Oct 2015
A former Google software engineer who became the Chief Technology Officer at P2P ridesharing provider Lyft is currently being associated with a data breach reported by ridesharing behemoth Uber earlier this year, according to a new exclusive from Reuters.
In February of this year Uber announced its discovery that one of its databases had been accessed by an unauthorised third party in late 2014, an incursion estimated to have involved the data disclosure of 50,000 Uber drivers across multiple states in the U.S.
Documents filed in Uber’s case disclose that the San Francisco-based company’s legal efforts to discover the culprit have led them to an IP address apparently associated with Lyft CTO Chris Lambert. The report emphasises that the IP address is not the one associated with the act of the breach itself; instead it was obtained by a process of elimination as Uber’s investigations team worked through all the IPs which accessed a critical security key that had accidentally been deposited on the public code-sharing and versioning platform GitHub in March of 2014 – approximately nine months before the breach occurred.
The only one it could not account for is, according to the report, a Comcast IP address associated with Lambert.
The court’s case documentation does not correlate the Comcast IP address with the actor who undertook the breach, but U.S. Magistrate Judge Laurel Beeler had allowed Uber to subpoena the Comcast records since this was “reasonably likely” to establish the identity of the “bad actor” behind the incident. According to two ‘sources familiar with the matter’, the Comcast address was directly associated with Lambert and matched up to other internet activity by him.
The IP address associated directly with the breach was one used by a Virtual Private Network (VPN) service in Scandinavia, though the address itself is redacted.
On Monday Lyft spokesman Brandon McCormick dismissed the claim, stating that Lyft had investigated the matter “long ago” and determined that “there is no evidence that any Lyft employee, including Chris, downloaded the Uber driver information or database, or had anything to do with Uber’s May 2014 data breach.” McCormick did not comment on whether or not the IP address in question was Lambert’s, nor on the scope or details of Lyft’s own investigation into the matter. Lawyers representing the person associated with the Comcast address had at the time of writing refused interview requests.
The lawyers also argued that the automated search engines which accessed the GitHub information could have left duplicated copies of information about the key. Presumably this is a reference to caching or to metadata; search engines able to establish the true ‘content’ of a post will feature it in results pages, omitting swathes of preceding data as necessary. Additionally web-archiving institutions such as Wayback Machine trawl sites in order to keep inviolable chronologies of sites, if the sites’ robots.txt permissions allow this.
However Judge Beeler countered that there is “no evidence” of the key’s availability outside of the context of the inadvertent GitHub post. The subscriber’s lawyers protested in court that their client has been singled out for attention by Uber’s investigation at the cost of all other possible perpetrators.
The data accessed during the breach contained the name and driver’s license number of approximately 50,000 of Uber’s drivers, though it is not known what use, if any, was ever made of the information.
Chris Lambert has been the CTO of the $2.5bn company since 2012, and formerly worked on the Google Maps and Google location project as a software engineer.
Opinion On the assumption that he would do it at all, or that he was actually the individual who accessed the Uber key at GitHub, it is very hard to credit that a former Google software engineer and major player in the technology market would browse over to something as critical as a carelessly-deposited security key to the database of a major rival company unprotected by VPN masking. Clearly the hacker had more sense, not only in using a VPN for the incursion, but also in selecting one in a country with such protectionist zeal about user-privacy.