Renault: Car Manufacturers Security Posture Research

This blog post is part of a series on Char49 research about car manufacturers’ security posture. You can read the whole series or watch our DEF CON 32 AppSec Village presentation on YouTube.

This was not the first time we’ve looked at Renault’s digital assets or reported security flaws according to their Vulnerability Disclosure Policy but this time it was a bit different. Renault was yet another target in our car manufacturers’ research pool. In order to assess car manufacturers’ security posture we’ve adopted a simple methodology: map the attack surface, find some vulnerabilities, chain them together to prove the impact, report, and wait for them to be fixed. At the end of the research, we would have a clear picture of exposed asset types, common issues, and time to fix.

Security Findings

Subdomain Takeover

Back in 2021, we approached Renault due to a Subdomain Takeover via Abandoned Amazon S3 Bucket affecting pma.renault.com. At the time, the affected Renault hostname was configured as a CNAME of beta-am.goepik.io which was, in turn, pointing to Amazon infrastructure. For some reason, at the time, no bucket was available with that name (beta-am.goepik.io) meaning anyone could create it and suddenly control the content delivered not only by beta-am.goepik.io but also, by pma.renault.com. That’s exactly what’s demonstrated in the Proof-of-Concept (PoC) video below.

User Enumeration

One of Renault’s digital assets that popped up during attack surface mapping was gigya-prod-eu1.renaultgroup.com. We couldn’t dig that much into the application itself since authentication was required. In these cases, we tend to dig into the authentication mechanism itself and password recovery features are usually good candidates. As you may expect there was an underlying API endpoint whose responses allowed us to distinguish whether the provided email address belonged to a user account in the system.

figure-1

It may not sound like a big deal but it is quite useful to enumerate existing user accounts. Bad actors can easily leverage this flaw to know which credentials from the latest leak are worth testing (credential stuffing). Since the fix is so simple it doesn't make sense to expose users to the risk.

Cross-Site Scripting

Cross-Site Scripting (XSS) is a type of vulnerability that we can easily chain with other flaws such as cookies or Cross-Origin Resource Sharing (CORS) misconfigurations. Let’s start with two internet facing Google Cloud Platform (GCP) development environments: test.bee.dev.gcp.renault.com and app-elr.elr.dev.gcp.renault.com. Requests to test.bee.dev.gcp.renault.com including XSS payloads in the query string uid parameter were blocked due to a… security exception. The interesting thing is that the payload was being reflected as part of the error message along with some system internal information.

figure-2

In the second host (app-elr.elr.dev.gcp.renault.com) we found a common XSS pattern. The flaw was found on an authentication endpoint supporting a redirect_uri parameter with the URL to where users should be redirected after being successfully authenticated. Quite often parameters like this one are not properly validated leading either to Open Redirect or arbitrary JavaScript execution (XSS) as shown in the image below.

figure-3

A third XSS flaw was found on another internet-facing GCP development instance (app-react-int-skf-dev-gcp-renault.com) corresponding to a common pattern identified during this research: vulnerable self-hosted Swagger UI.

figure-4

Swagger UI “allows development team to visualize and interact with the API's resources without having any of the implementation logic in place”. It became so popular that some API development frameworks even have it built-in. The thing is, per Dawid Moczadło advisory from May 2022, some versions of Swagger UI are vulnerable to DOM XSS.

If your organization has REST APIs chances are that it also has somewhere a self-hosted Swagger UI. In that case, you’re better off updating it to the latest version without known vulnerabilities.

Session Cookie Misconfiguration

Chaining vulnerabilities to demonstrate impact was part of our strategy. With three XSS flaws already all we were looking for was a “juicy” Renault website with a misconfigured session cookie. The Originals Renault Store was that website.

Despite the variety of products, including the 30 euro, 1972 Renault 4 miniature and the 400 euro Renault 4 E-Tech 1/15 resin miniature, the most interesting to us was the THEORIGINALSSESSID session cookie.

figure-5

At the time the cookie’s Domain attribute was set to .renault.com and the HttpOnly attribute was set to false as shown in the image above. The former means web browsers would automatically send the cookie to any renault.com website including the vulnerable ones we found: test.bee.dev.gcp.renault.com and app-elr.elr.dev.gcp.renault.com. The latter makes the THEORIGINALSSESSID cookie accessible to any JavaScript running on the page, including our XSS payload. You have to wait no more to see it in action. Convince victims to click a link, exfiltrate their session token, and then, well... perform whatever actions you want on their behalf.

Security Posture

Organizations often struggle to build and maintain an assets’ inventory, namely DNS records, hosts, third-party software, etc. and Renault seems to be no exception. Without one, organizations fall short in terms of attack surface monitoring any small mistake becomes a big threat.

We at Char49 are aware that building a secure system is a lot harder than breaking it. This is one of the reasons why we keep doing this type of research in parallel with our usual business activities. We also believe that the key difference lies in the way organizations address security.

When we first approached Renault because of the Subdomain Takeover they replied and mitigated the risk really quick. The same didn’t happen with the later security advisory with the application security flaws. In fact, we never heard from Renault and had to request CERT-FR (Computer Emergency Response Team) help to get the vulnerabilities fixed.

Share this Post