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, so no rewards are offered – not even swag!
• September 9, 2019 8:16 PM: I express my disappointment and encourage them to offer rewards in the future. I also 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 again suggest that they should consider improving their program with rewards, or at least 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.

Closing thoughts and how Daimler can improve

Daimler has clearly put some thought into creating a program that encourages researchers to report security problems. At first glance, they appear to have done a lot of things right: a clear outline of what is/is not in scope, providing a good set of general rules to follow, and a contact email with estimated timelines. Simply having a white hat page is more than what some other companies have. Despite all this, I still feel there is some room for improvement:

1. Slow conversation and misunderstanding. The conversation lasted almost 5 months, which is quite a long time for what seems like a couple easy fixes. It was annoying how they continually said they will provide me with updates, but the only time I got updates was when I asked for them after long periods of silence, and sometimes I had to ask twice. As for the misunderstanding, it seems like on September 9th they were under the impression that the issues were fixed, when in reality only 1/3 were. If I didn’t push further, I’m not sure if the last 2 issues would have been addressed. I was pleased they fixed everything within 90 days, however.
2. A personal touch behind the Daimler security inbox would be nice. All the emails are simply signed “Daimler AG”.
3. Daimler should offer some basic rewards to entice security researchers and encourage quality bug reporting. A public acknowledgement list/hall of fame on their white hat website page would be a good start – BMW has one! I’m not even sure if I would have gotten the certificate if I didn’t suggest that they offer security researchers some form of recognition. It’s important to have formal recognition for résumés and such.

In the end, all the issues I reported were fixed, but as listed above, there are key items Daimler can improve on to make the experience better for future security researchers. For more serious vulnerabilities, fast and efficient communication will be paramount, especially as cars are being increasingly stuffed with tech and becoming more connected.

Find it on GitHub!

Update: Due to new security improvements in new versions of Pokémon GO, this method may no longer work.

Hello everyone, this is one of my first attempts at tinkering around on the Android platform. After spending so many years reverse engineering PowerPC executables on the Xbox 360 platform, I quickly got the hang of ARM and am happy to share some important information that will aid the Pokémon GO dev community.

By now, you have probably noticed you can no longer MITM HTTPS requests between your Android device and the Niantic Labs/Pokémon GO servers. This is because of something called certificate pinning.

What is certificate pinning?

Put simply, it is Pokémon GO performing additional validation against the certificate provided by the server. Pokémon GO expects the Niantic Labs certificate, but when you MITM with Fiddler, Pokémon GO sees Fiddler’s certificate. Pokémon GO detects this and aborts the connection before any data is sent to the server.

If you are interested in reading more about this in more detail, this page has a great explanation.

Has Pokémon GO always had certificate pinning?

On July 30th, 2016, version 0.31.0 of Pokémon GO was released. This is the second update for the game. The base game and the first update did not have certificate pinning. I was a little surprised that certificate pinning was not implemented from the beginning. However, once it was added, it was easily noticeable in Fiddler with all the failed CONNECTs.

And an error in Pokémon GO itself, even though the network and account are both fine.

Based on those observations, coupled with the fact that Fiddler worked fine on the previous version of Pokémon GO, there is a very high chance certificate pinning is now implemented in version 0.31.0.

Do I need root access?

You do not need root access! This method works on both rooted and non-rooted devices.

Will I be banned if I do this?

No bans were encountered during testing on version 0.31.0, but this can easily change in a future version. It is recommended you use a throwaway account when you need to MITM, just in case there are any custom/secret APK modification checks.

If you log in using Google…

Due to an Android security feature, you may be unable to log in to Pokémon GO using your Google account with a patched APK.

Reverse engineering the certificate pinning

Note: These steps are only valid for Pokémon GO version 0.31.0.

If you aren’t interested in learning how this was done and just want to patch your APK, scroll down to “Patching the APK”.

Pokémon GO obviously must have the entire leaf, intermediate, or root certificate or at least the public key to validate against somewhere in the APK, likely in a file that contains code. The first thing I tried was searching for the leaf certificate’s public key. To get that, I went to the Niantic Labs website and examined its leaf certificate using Chrome.

Let’s extract the APK and use a hex editor to do a byte sequence search in the files that contain code to find the public key.

classes.dex? Nope.
lib\armeabi-v7a\libmain.so? Nope.
lib\armeabi-v7a\libNianticLabsPlugin.so? DING!

One instance found for the public key. This definitely looks like a copy of the Niantic Labs leaf certificate.

This is an so (shared object) file which is full of native code. This is where things get more complicated. I’m going to be using IDA Pro version 6.9 to dig into this file. There are other disassemblers out there that can do the job, but IDA Pro is my tool of choice.

The fun begins.

Let’s search for that same sequence of public key bytes.

There is one instance, as expected. Scrolling up a bit eventually reveals a function that references the entire leaf certificate.

Let’s go into sub_A9BE4. Conveniently, the compiler has left a string at the top that identifies this function.

After a little research on Google, I discovered that NianticTrustManager is basically Niantic’s customized X509TrustManager, and they have chosen to override the default GetAcceptedIssuers method. By overriding it, they, according to Java documentation, have the option to “Return an array of certificate authority certificates which are trusted for authenticating peers.”

Let’s see if there is anything interesting in this function.

I’ve spent enough time reverse engineering to know that a memcmp (compare two blocks of memory) and a “Rejected” string appearing in the same function is definitely something worth investigating. unk_1E2584 is the embedded Niantic Labs leaf certificate, so this function must be comparing it against another certificate. In this case, the other certificate is the Fiddler certificate. Looking at the flow of the assembly, we can NOP (no-operation) that branch below the memcmp and it will eliminate the possibility of getting to that “Rejected” block because of a memcmp failure. A NOP opcode in ARM is 0x00BF, so let’s patch that in and see what the function looks like.

As you can see, our NOP is in place and there is no chance of getting to that “Rejected” block anymore.

One more patch is needed. Before the memcmp, the function is checking the server certificate’s length. It is making sure the server certificate is 0x5FF in length. The Niantic Labs leaf certificate is that long, but Fiddler’s is not. Unfortunately, the flow of the assembly does not allow us to NOP this branch. Right now, it is a BEQ, which, in this context, means “branch if the server certificate’s length is equal to 0x5FF.” Let’s change that to just a B, which is an unconditional branch, meaning it will always branch to a specified location. This will eliminate the possibility of getting to that “Rejected” block because of a length mismatch. To change this BEQ to a B, all we need to do is to update the opcode from 0x14D0 to 0x14E0.

Looks good! There are a few more possibilities of getting to that “Rejected” block, but let’s test this out before we worry about them.

Patching the APK

Note: These steps are only valid for Pokémon GO version 0.31.0.

Open libNianticLabsPlugin.so using a hex editor, or use IDA Pro’s Edit->Patch program menu functions to do the following:

1. Go to offset 0xA9C76 and change 14 D0 to 14 E0. If you do not see 14 D0, you might be looking at the wrong file, or are looking at the wrong version of Pokémon GO.
2. Go to offset 0xA9CB0 and change E2 D1 to 00 BF. If you do not see E2 D1, you might be looking at the wrong file, or are looking at the wrong version of Pokémon GO.
3. Save the changes and close the hex editor.
4. Replace the old libNianticLabsPlugin.so file in the APK with the patched one. You can do this using any program that can open zip files – an APK is basically a zip file.
5. Sign the APK using your tool of choice or ZipSigner in the Google Play store.
6. Uninstall Pokémon GO on your device if it is installed and then install the patched APK, ignoring the unknown sources warnings.

If everything was done correctly, you will be able to see the HTTPS requests in Fiddler, and Pokémon GO will function without displaying any error messages.

Does this work on iPhone?

You need a jailbroken iPhone to modify apps. Thanks to reddit user Mila432, we know that the function is very similar and can be patched the same way.

Also see the comments for another tip.

Important Note: Please do not abuse the Pokémon GO API. Putting additional load on the already-stressed servers could degrade the experience of millions of players around the world and encourage Niantic Labs to implement further API restrictions. Develop responsibly.

Thanks for reading! I plan to write about more security related topics in the future, so feel free to use the option on the sidebar to subscribe to new posts, or follow me on Twitter.
-Eaton

The site has just been updated to include full HTTPS support. Modern security features such as HSTS (with preloading) and HPKP have also been implemented. Update: HPKP has been deprecated and thus removed.

An old, private Xbox 360 development application has been released.

Check it out!

An update to the FATXplorer application has been released. The purpose of this update is to bring further stability to the previous version and to address various issues reported by customers.

More information

Eaton Works and all subdomains have been fully updated to support the Disqus commenting system. Disqus provides a superior commenting system over the one WordPress provides.

To finalize the transition, all Eaton Works and FATXplorer user accounts have been deleted. Reason being, there are no longer any uses for them and an initial scan showed that up to 90% of registered users were actually spam bots. Disqus provides multiple ways to sign in and having a Disqus account will extend your commenting experience beyond Eaton Works websites.

You’ve probably already seen or used the Disqus commenting system, it is used on some of the biggest and most popular websites in the world, such as IGN, CNN, and many other major news outlets. If you have any problems with it, feel free to contact the webmaster.

Feel free to use this post as a means to try it out!

A major update is now available for FATXplorer. Check it out!

More information

A small and simple Xbox 360 patch viewer/editor.

Project page

Designed by EdenWebs, my new homepage is designed to be the ultimate portal for my projects. It includes a usable slider and a blog view.

This is still a work in progress, expect many changes over the coming weeks.

Until then, many sections of this site may be broken.

Feel free to leave feedback or suggestions.