This Is The Story Of Making Almost $50,000 In Bounties From The Adobe VIP Bug Bounty Program
Introduction
It all started when we came across Nahamsec's $100k video - https://www.youtube.com/watch?v=TKIEXwOcbfc. This piece of content immensely motivated us to hit a similar goal within a months timeframe. Between the period of June 8th to July 30th, Tirtha (@tirtha_mandal) and I (@naaash) decided to take part in Adobe's VIP program.
Why Adobe? It was nothing more than a coincidence, where they openly mentioned about their VIP program on HackerOne, and asked researcher to fill up their form to get access to it - Adobe VIP Blog Post.
A week later...
Adobe's VIP program is huge and it divided into different tiers. We knew that we'll majorly be focusing on the tier 1 assets as they would yield a better ROI, so we specifically chose Adobe Workfront for this particular challenge. Workfront is basically a work/project management software which was acquired and developed by Adobe. It is designed to help teams and organisations manage, their projects, tasks, collaboration, and workflow process more effectively.
List of Vulnerabilities
| No. | Title | Severity | Bounty |
|---|---|---|---|
| 1 | [Workfront] LFI on https://REDACTED/attask/api-internal/ACTLOG/download?fileName=../../etc/passwd | Critical | $8,000 |
| 2 | [Workfront] Stored XSS via Proof Message - https://REDACTED/proof/account/profile/XXX | High | $4,580 |
| 3 | [Workfront] Stored XSS on Proof Documents via The File name - POST /attask/api-internal/PROOF | High | $2,265 |
| 4 | [Workfront] Stored XSS on Proof Name - POST /attask/api-internal/DOCU/XXX | High | $4,580 |
| 5 | [Workfront] Stored XSS on Proof Settings Via Custom Devices for proofs - https://REDACTED/proof/account/settings | High | $3,320 |
| 6 | Stored XSS via "First Name" Field Leading to Full Account Takeover | High | $4,580 |
Rest of the issues are mostly still in Open state or were privilege escalation & bypasses of stored XSS which ended up getting paid almost $3000 to $4000 per bypass.
Vulnerability Write-Ups
1. [Workfront] LFI on https://REDACTED/attask/api-internal/ACTLOG/download?fileName=../../etc/passwd
The web application has a normal functionality of exporting data. The admin of the instance can export any of the following data:
- Teams
- Job Roles
- Custom Forms
- Companies
- Approval Processes
- Audit Logs
Note: There are a lot more places where an admin can avail export functionality, but I've listed a handful of them for the time being.
For the most part, the following API would be called to fetch the exported file:
But when we tried to export our audit logs, the following API call was being made:
The only thing "sus" over here was the parameter - fileName, that is being used to fetch the exported file (because in most of the cases, fileID parameter was being used). We just changed the value of the fileName parameter to ../../etc/passwd and the response disclosed the entire content of /etc/passwd.
To make it a little worse, we even went ahead and fetched the service token - /var/run/secrets/eks.amazonaws.com/serviceaccount/token.
2. [Workfront] Stored XSS via Proof Message - https://REDACTED/proof/account/profile/XXX
While browsing through the web application, we came across a dashboard - ProofHQ. ProofHQ was actually the legacy dashboard for what is now called Workfront. It had a different sign-in page but was still very much a part of the in-scope asset.
A certain section of the web application allowed any lower privileged user to set message templates.
The message were being created/edited using a rich-text editor, but to our luck, it was using a much older version of the rich-text editor, which was vulnerable to XSS. We inserted a link, clicked on Save, and changed the value of the value parameter to <a href="https://google.com" onpointerenter=prompt(document.domain)>https://google.com</a%.
The payload would fire, as the admin could view the message templates generated by the other users within the same organisation.
Impact: The lower privileged user could've stolen admin's session token as it was being disclosed in the DOM of the webpage where the XSS payload was executed. Once the lower privileged user would've had the token then they could've elevated their privileges within the organisation by making calls to ProofHQ APIs.
3. [Workfront] Stored XSS on Proof Documents via The File name - POST /attask/api-internal/PROOF
On the main Workfront dashboard, the web application has a functionality where any user can push their documents from Workfront dashboard to ProofHQ dashboard. We'd initially tried setting the file name as the XSS payload, but that didn't render on the Workfront dashboard.
Things were kinda different on the ProofHQ dashboard though.
Once the document was pushed from the Workfront dashboard to ProofHQ dashboard, the user had the option to print summary of their documents on the ProofHQ dashboard. On doing so, the XSS payload would get triggered, but this was still a self stored XSS.
The lower privileged user had the option to share the file summary with the other team members (including the admin), which helped us converting it from self stored XSS to stored XSS.
Impact: The lower privileged user could've stolen admin's session token as it was being disclosed in the DOM of the webpage where the XSS payload was executed. Once the lower privileged user would've had the token then they could've elevated their privileges within the organisation by making calls to ProofHQ APIs.
4. [Workfront] Stored XSS on Proof Name - POST /attask/api-internal/DOCU/XXX
This is a simple XSS vulnerability where the Workfront web application allows users to upload a file in the form of Proof, but it fails to sanitize the payloads if the file name contain arbitrary JavaScript code.
By exploiting the issue, lower privileged user could've stolen admin's session token as it was being disclosed in the DOM of the webpage where the XSS payload was executed. Once the lower privileged user would've had the token then they could've elevated their privileges within the organisation by making calls to ProofHQ APIs.
5. [Workfront] Stored XSS on Proof Settings Via Custom Devices for Proofs - https://REDACTED/proof/account/settings
On the ProofHQ dashboard, the lower privileged user had the functionality to add new custom devices as per their requirements.
We filled in the XSS payload - " onmouseover=confirm(document.cookie) " in the Name & User Agent String input fields.
The XSS payload would get triggered when the admin user would try to edit the custom device details on their end, as the admin would have access to all the custom devices added by the lower privileged users.
Impact: The lower privileged user could've stolen admin's session token as it was being disclosed in the DOM of the webpage where the XSS payload was executed. Once the lower privileged user would've had the token then they could've elevated their privileges within the organisation by making calls to ProofHQ APIs.
6. Stored XSS via "First Name" Field Leading to Full Account Takeover
At this point we had come across a handful of stored XSSs on the ProofHQ dashboard, and barely any XSS on the Workfront dashboard, so as a challenge we wanted to get a alert box over here as well.
We had tested most of the endpoints where an XSS payload could've been added, but didn't have any luck with it as such. The only thing that was left for us to do was to check functionalities where the input/payload is being taken from a completely different module of the web application. One such functionality was to add updates to document, tasks, portfolio, projects, etc.
Over here, the lower privileged user changed their name, and added the XSS payload - "><img src=x onerror=alert()>. They then, dropped an update on a document, task, project, etc. and tagged themself in that particular update.
When the admin user would visit the update section of the module, then the XSS payload would get executed.
To convert it into a full account takeover, we added a bXSS payload and was able to smuggle the session cookie - wf-auth & CSRF token - XSRF-TOKEN of the admin user, which lead to full account takeover.
Acknowledgement
Huge thanks for the following people:
- Tirtha - @tirtha_mandal, for collaborating and proof-reading the entire blogpost.
- Ben - @NahamSec, for making the $100k YouTube video.
- The entire security team of Adobe for running a fair, great & successful public and private program.
- The awesome triage team of HackerOne - Thanks a lot for quickly & fairly triaging our reports.