This is quite a different post as it is not related as usual to Windows vulnerabilities 😉. In the past period, I have been looking into the myAudi connected vehicle platform “Audi Connect and Remote Control”, specifically the APIs behind the myAudi web and mobile apps. The reason is quite simple. I was frustrated by my own app suddenly stopping working intermittently, going dark for 2-3 days and then starting to work again as if nothing had happened. I opened a couple of tickets with Audi Digital, but they ultimately led nowhere 😦 So I decided to understand how it was working under the hood. In fact there are some resources online that interface with this digital platform, from the login process up to accessing some calls about vehicle information. These community projects gave me a starting point to understand the authentication flow and the general API structure before diving deeper into my own analysis. Being a hobby security researcher, rather than just waiting for an improbable fix I decided to look under the hood properly. I set up Burp Suite, analysed the web portal and the Android APK, and started to look at the API calls… My goal was to understand what happens when you refresh the status of your vehicle from the mobile app, given that in case of error I got back some weird error code E:CV.PA.5 (…). Intercepting these calls means that you have to set up a smartphone emulator and do some work to intercept the traffic with Burp. I was not that enthusiastic given that I’m lazy, but this was the only opportunity so I decided to install Android Studio, set up a virtual Pixel 7 Android device, download the myAudi app, push it on the device, configure the proxy and start the app. But nothing happened – no traffic in Burp. Obviously the app used certificate pinning! So I had to add some additional components: Frida server and Objection to hook into the app and bypass certificate pinning validation at runtime. After several attempts I was finally able to get the beast working: The “wakeup” endpoint resulted in being hosted by emea.bff.cariad.digital : Once the request with the Vehicle Identification Number (VIN) was created, the ID of the request was returned. The next step was to check the pending requests endpoint and verify the status for each request ID, essentially a polling mechanism to determine whether the vehicle had successfully received and processed the command. The callback URL is the endpoint that the vehicle connects back to once it has successfully processed the wakeup command. With all this information in hand, I created a PowerShell script that runs on a schedule once per day. It authenticates against the VW/Audi identity endpoints, retrieves the JWT tokens, and executes the wakeup request to keep the vehicle connection alive. So I noticed that the wake-up request stops working for 2-3 days and then starts working again. I still don’t know what or who it depends on. The car? The portal? Who knows🤷‍♂️​ With this whole set of APIs now mapped out, my curiosity naturally turned to the security of these implementations, specifically whether there could be any unexpected information disclosures or potential for abuse. The first thing that seemed at least somewhat strange to me was that, once you create an account on the myAudi portal (and other related VW Group brand portals), you can add any vehicle simply by knowing its VIN. After doing so, you become a “GUEST_USER”, which in theory should provide only very limited access to the vehicle’s configuration and features. A VIN is not a secret , it appears on insurance documents, registration papers, service records and is visible through the windscreen of every car on the road. The vehicle association model needs to treat it accordingly This piqued my curiosity, so I started digging deeper. Luckily, up to now I could not find so many things that could be abused without becoming a primary or secondary user, a process that requires some additional security steps to perform, but nevertheless I found some issues worth reporting. Testing was limited to my own accounts and voluntarily associated vehicles for the purpose of responsible security research. 1.GraphQL Introspection Enabled in Production When logging in into the web portal or via app, you get a list of associated cars via GraphQL query: The first thing I tried, as a “Guest User” after associating my own car, was to check if the “Introspection Query” was enabled. If so, it gives the full API schema, exposing all available queries, mutations, arguments, and internal data types: Even if I was not able to find undocumented “privileged” mutations, GraphQL introspection is commonly disabled in production environments to reduce unnecessary exposure of API structure and internal object model During my tests, I found other GraphQL endpoints that had the Introspection disabled. 2.Vehicle Data Disclosure There is information that a guest user can access, including license details and expiration dates, ser...