[Atlassian Confluence CVE-2021–26084]::: The other side of bug report!
tl;dr
A pull request for Nuclei template of CVE-2021–26084 turned out to be a leak of our Pre-Auth RCE exploit payload for Atlassian Confluence that had been provided to VMWare.
When CVE-2021–26084 advisory came out, our team as usual tried to reproduce the bug with a reliable exploit. I noticed that iamnoooob and rootxharsh finished the PoC for CVE-2021–26084 on Aug 29 but no PoC was released. I and Jang finished the exploit on Aug 31 and at this time, no PoC was public on the internet and most people still believed Atlassian that this is a Post-Auth RCE bug. However, we figured out that it’s totally Pre-Auth RCE instead, and a lot of confluence instances were still vulnerable at that time.
One of my teammates noticed that confluence.eng.vmware.com was vulnerable but our exploit failed due to their WAF rules. After modifying our payload to bypass the WAF, we managed to exploit it successfully and send an email to VMWare at security@vmware.com to report the issue.
17 hours after our first report to VMWare, there was a guy called Dhiyaneshwaran had pulled a request template for CVE-2021–26084 on Nuclei project github (Nuclei is vulnerability scanner of Project Discovery) with the detect payload 100% identical to the specifically crafted exploit payload that we sent to VMWare.
Timeline of the whole story
1. We first sent to Vmware on Aug 31, 10:39 AM (GMT+7) with a full Pre-Auth RCE exploit payload, specifically crafted to bypass their WAF
2. On Sept 1st, 3:44 AM (GMT+7) there was a guy called Dhiyaneshwaran who pulled a request template for CVE-2021–26084 on Nuclei project’s github with the detect payload 100% identical (look at the query & headers!!) (** no PoC was public on the internet at this time)
3. A few hours after our exploit got into the public via Nuclei’s github, on Sept 1st, 05:22 AM, iamnoooob and rootxharsh published their write-up and their exploit.
Later, Nuclei’s maintainer had modified the template for CVE-2021–26084 to remove our exploit payload after we sent them a message asking for the source of information.
In the next section, we will compare our exploit payload which was sent to VMWare v.s the pull request on Nuclei. We will also explain how the original payload was specifically crafted for just only VMWare’s target endpoint to prove our belief that it was leaked from VMWare.
1. Query and headers are identical between the payload we sent to VMWare and the Nuclei’s template. Notice the identical JSESSIONID, dummy string aaaaaaaa, SpaceKey=x!
2. Because confluence.eng.vmware.com is an old version, we had to add SpaceKey=x to reach the vulnerable endpoint
3. If the exploit contains the keyword “eval”, their WAF, AkamaiGhost, would block the request so we had to bypass with “\u0065val”. If you work on this bug, you will know that we can escape strings with Unicode value.
In summary, as the exploit payload we sent to VMWare was specifically crafted for their server and we did not use this payload on any other target and/or sending it to any other companies/bug bounty programs, it’s very clear to us that our payload somehow was leaked from VMWare to the Nuclei project.
After realized that our exploit was leaked, we asked VMWare for an explanation.
And this is their response
We think that the response from VMWare is nonsense because
- iamnoooob and rootxharsh’s writeup was publised after the leak of our payload.
- Our exploit payload was different from iamnoooob and rootxharsh’s public exploit.
- Our exploit payload was specifically crafted for VMWare’s server target, and the leaked payload is identical to our payload.
The exploit we sent to VMWare is our copyright property and we did not grant VMWare the right to re-distribute it. We would like to get more explanation from VMWare but they have stopped replying to our emails, refused to admit the leak, and ignored us. Hence, we decided to write this blog.
— cheers
