• Skip to main content

ITSecurity.org

Technology Security Controls

  • Main
  • Products
  • Services
    • Compliance-Services
      • ISO27001 Compliance
      • ISO22301 Compliance
      • ISO27002 Compliance
      • Data-Protection
      • GDPR
      • PCI-DSS Services
    • Identity and Access Management Services
      • IAM Design
      • IAM Policies & Standards
    • Incident Management Services
      • Emergency Incident Response
      • Forensic Support
      • Incident Response
    • Information Security Services
      • Information Security Consultancies
      • Information Security Governance Services
      • Information Security Policies & Standards
    • IT Risk Management Services
      • Risk Management Framework
      • Auditing
    • IT Security Consulting Services
      • IT Security Governance Services
      • IT Security Policies and Standards
    • Additional Security Services
      • Managed Security Services
      • Mobile Security
      • Network Security Services
    • Physical Security Services
      • Physical Security Reviews
    • Policies and Standards Services
    • Programme and Project Services
    • Risk Management Services
      • Risk Management – Framework
      • Risk Management Acceptance & Waivers
    • Security Awareness Services
      • Security Awareness – Phishing Responses
      • Phishing Responses
      • Security Awareness Training – Rebranded Security Training
      • Security Awareness Training – Generic
    • Security Design Services
      • All Security Design and Architectural Services
      • Cloud Security Review
      • Security Appliance Design and Configuration
    • Security Metrics Services
    • Technical Security Assessment Services
      • Penetration Testing – Our Penetration Test Services
      • Database Security – Databases and Repositories
      • Application Security Code Testing
      • Application Security Services
    • Third-Party and Supplier Assurance Services
      • Third and Supplier Party Assurance Methodology
      • Third and Supplier Party Assurance Review
      • Joint Venture Due Diligence
  • Security Digest
  • FAQ
  • Contact Us

Mercedes-Benz Data Leak: Embarrassing But Endurable

May 25, 2020 by ITSecurity.Org Ltd

Application Security , Breach Notification , Endpoint Security

The Mistake Could Have Been Much Worse in an Era of Connected Vehicles Jeremy Kirk (jeremy_kirk) • May 25, 2020    

Mercedes-Benz Data Leak: Embarrassing But Endurable Mercedes-Benz’s Sprinter Panel Van (Source: Daimler AG)

Last week, a curious data breach occurred: Almost 9 GB of software development documentation from Daimler AG, the parent company of Mercedes-Benz.

See Also: Maintain a Clear Bill of (Third-Party Risk) Health

As first reported by ZDNet, the data encompassed more than 580 repositories in GitLab, the web-based tool for software development collaboration.

Daimler’s problem here was embarrassing, but endurable. It may not be next time, which is why organizations should not forget the basic access controls when using code repositories. 

The data was found by Swiss-based software developer and security researcher Till Kottmann.

He discovered Daimler’s GitLab pages by using hyper-specific Google searches, sometimes referred to as Google dorking. He created an account and found that Daimler AG didn’t verify that he had a control of an email account within domain that the company had sanctioned to join the GitLab pages.

Thus he had complete access. Kottmann then republished the data via Mega, the online storage platform, and on other outlets. He didn’t notify Daimler AG prior to doing this, which is contrary to the grace period most security researchers give companies in order to rectify a software vulnerability or data leak.

Credentials Leaked

The mistake by Daimler was a simple one: it should have made Kottmann verify he owned an authorized email address before granting access. This kind of inattentiveness to access controls or settings, whether it could be GitLab pages to Elasticsearch clusters, has led to big data breaches.

There were also passwords and API keys in the repositories, which ZDNet reported were found by threat intelligence firm Under the Breach. Kottmann says he didn’t realize that the data also included that type of information.

As for why he didn’t give Daimler a heads up, Kottmann tells ISMG: “I guess this just comes down to my personal beliefs, curiosity and not really caring too much about their corporate interests. I did not intend for there to be credentials and private keys, but apparently didn’t check this leak thoroughly enough.”

For automobile manufacturers, which are increasingly wrapping complex services into vehicles for new services delivered over the internet, the danger of sensitive software design data leaking could be devastating (see: IoT in Vehicles: The Trouble With Too Much Code).

An exploitable software vulnerability in a desktop web browser might end up in a malware infection. But it won’t result in an attacker remotely triggering the brakes in a car.

Data: Onboard Logic Unit

Luckily, the data from the Daimler AG leak doesn’t appear to be useful for any real-world attacks.

Much if it revolves around source code and development documentation for the Onboard Logic Unit (OLU), which Daimler describes as a control unit for vans. It’s designed to be the van’s interface to cloud services, delivering live data from the vehicle and connecting with third-party applications. There are also images of the Raspberry Pi, the multifunctional mini computer.

A list of some of the respositories leaked after Daimler AG made an access control error with GitLab.

Jan Pinkas, who is a lead solutions architect with the consultancy Hold Security, says the software appeared to be developed for car-sharing. Those types of services are growing in popularity, and tech plays a large role, as it can be used to provision vehicles to users and track and disable vehicles in case of theft.

The code and documentation revolves in part around the use of GPS data, unlocking doors and granting access to a vehicle. It means that the OLU plays a critical role in interfacing to certain physical aspects of a van’s operation. But Pinkas says the code appeared to clearly be just in development and not ready for production.

Pinkas, who analyzes forums and dark web sites, says he saw some fairly benign discussion amongst likely white hat security researchers about the leak on a Czech-language discussion forum.

Daimler: Access Was ‘Illicit’

Daimler AG says that neither customer data nor essential development data related to Mercedes-Benz vans was affected. The data was already published as part of Daimler’s open source strategy, says spokesman Thomas C. Rosenthal, who pointed to this Daimler GitHub repository. That repository, however, appears to be a small part of what was leaked.

Upon learning of the leak, “the affected platform was shut down at once; potentially affected credentials were immediately deactivated respectively deleted,” Rosenthal says. “We will examine the incident carefully and initiate appropriate measurements.”

Rosenthal characterized Kottmann’s access to the GitLab pages as “illicit.” Still, it doesn’t seem Daimler AG is interested in going after Kottmann in court. Kottmann says he received a “super chill” email from the company on May 19, asking him to take the data offline and letting him know about its Vulnerability Reporting Policy.

At a different point in time, and particularly if it has been production code, a leak could have been far more damaging. The security ramifications of vulnerabilities in connected cars have been shown to have far reaching consequences, such was demonstrated with a Jeep Cherokee in 2015.

Daimler’s problem here was embarrassing, but endurable. It may not be next time, which is why organizations should not forget the basic access controls when using code repositories.

Filed Under: IT Security

Contact Us

If there's any way we can help, please let us know
Call: +44 01606 642307