An experience with Daimler’s vulnerability reporting program

Eaton • Dec 19, 2019

Background

Daimler AG is a German multinational automotive corporation commonly known for being the parent company of Mercedes-Benz. Daimler runs a white hat/vulnerability reporting program.

Mercedes-Benz USA, LLC (MBUSA for short) is the distributor of Mercedes-Benz cars in the United States. MBUSA runs a variety of websites, one of those being a Dealer Help Center website built on Oracle’s Service Cloud: mercedes-benz-dealer.custhelp.com. This website is only meant to be accessed in Mercedes-Benz dealerships on computers running their “NetStar” system. It’s accessible to the outside world, but everything is supposed to be protected with a login, or limited to access only from NetStar.

This post will go on to explain how 3 vulnerabilities could have exposed a decade’s worth of sensitive content on MBUSA’s Dealer Help Center website.

The Vulnerabilities

During the course of a simple Google search, I discovered an indexed PDF from the Dealer Help Center website. By modifying my search query to exclusively find all indexed content for the Dealer Help Center website, like this, this, and this, I was able to locate a fairly significant number of confidential documents. Some documents were not confidential at all, such as vehicle instruction manuals, published spec sheets & images. However, there were some documents that were clearly marked confidential and meant for Mercedes-Benz dealership management eyes only. There are also documents containing personal information, like cell phone numbers for MBUSA management individuals. I did not find any customer data nor do I believe any customer data was at risk since this website is just a help resource for dealers.

Looking at the URL for the PDFs (example: https://mercedes-benz-dealer.custhelp.com/app/answers/detail/a_id/3553 – I call this the “answers” endpoint/page), there is an ID number at the end. I wondered what would happen if I tried different ID numbers. Some times I was asked to log in, perhaps because the page didn’t exist and it was redirecting to somewhere else. Frequently, however, it gave me a downloadable PDF. Below is the header from one:

And here’s a page from another:

This is a classic example of an enumeration attack on an unsecured endpoint. It would take very little effort to create a script to go through thousands of ID numbers and download any PDFs the request returned. Some of the documents go back more than 10 years, so there was a possibility of being able to download a decade’s worth of confidential content. I did not check for any rate limits – attempting to dump their entire network would have been abusive and likely a violation of the program rules.

Important to note is that since I did not attempt to download every single document possible, the full scale of sensitive data exposure is not known.

But wait, there’s more!

The Google searches revealed another endpoint. Example: https://mercedes-benz-dealer.custhelp.com/ci/fattach/get/10704 – I call this the “attach” endpoint.

There is another opportunity for an enumeration attack there. This appears to be where all help article attachments are stored, so it is an attractive target for data exfiltration. All I needed to do was change the number at the end to be able to download more PDFs.

Oh, and one more thing!™🍏

This one is minor compared to the last 2, but still reveals sensitive data. When visiting an answers page that is not a document, and instead an actual page with simple text content, the page’s text/body content is protected, but the HTML title leaks out! (look at the browser tab)

A wordy page title has the potential to give away some interesting information, maybe even internal announcements of upcoming car models?

Reporting Timeline

I composed an email with clear instructions on how to reproduce the problem, explained the possible impact if left unfixed, and provided a few examples of exfiltrated confidential data. I sent it to Daimler’s security email address listed on their white hat website page. The back-and-forth lasted almost 5 months. The entire email timeline is below (US Eastern time):

• June 20, 2019 11:57 PM: Report email sent.
• June 21, 2019 4:07 AM: Daimler acknowledges receipt. Says they need time to evaluate it and will get back to me.
• July 4, 2019 10:41 AM: I ask for an update.
• July 5, 2019 2:21 AM: Daimler responds saying they need more time than usual for their analysis.
• August 3, 2019 8:48 PM: I ask for an update and get an auto-response right away (the only time I got one, maybe a glitch).
• August 13, 2019 2:29 PM: I ask for an update, assumed my last email was lost.
• August 14, 2019 8:07 AM: I receive the exact same reply I got on July 5.
• September 5, 2019 2:07 PM: I test the vulnerabilities again and notice 1 of them has stopped working – a login is now being requested. I ask for an update.
• September 9, 2019 6:54 AM: Daimler confirms a fix has been rolled out, and thanks me for my effort.
• September 9, 2019 11:46 AM: I express that I was happy to help, and ask if they have any rewards for their program.
• September 9, 2019 7:19 PM: Daimler thanks me again for my effort, and explains that they do not run a bug bounty program.
• September 9, 2019 8:16 PM: I ask if they are still working on the other 2 issues.
• September 19, 2019 11:50 AM (90 day mark): I follow up after no response and also notice all reported issues appear to be fixed.
• September 20, 2019 5:34 PM: Daimler explains they are still investigating and will update me on completion.
• September 20, 2019 5:43 PM: I respond saying I will wait for their final update, and also note another potential vulnerability they may want to check.
• October 23, 2019 1:59 AM: I ask if their investigation is complete yet.
• November 7, 2019 9:05 AM: After no response, I ask again.
• November 8, 2019 3:01 AM: Daimler provides the final update that everything is fixed, and thanks me again for my effort.
• November 8, 2019 11:22 AM: I express I am glad to help, and they should consider adding rewards to their program, and/or add a recognition section to their white hat website page.
• November 12, 2019 12:23 PM: I receive a “Digital Appreciation Certificate” via email, signed by the Daimler CISO: Michael Schrank.
• November 12, 2019 3:32 PM: I express my thanks in a final email, and confirm that all issues have been adequately addressed.
• No further correspondence since November 12, 2019.

Enjoyed this post? Like or repost it on X!