“Navigating Risks: Vulnerability Stemming from a Third-Party Integration”
This article is split into two parts. The first part explores details about the third-party vendor, The second part focuses specifically on the website where I discovered the vulnerability, providing a more in-depth analysis of the findings
By covering both aspects, this article aims to provide a comprehensive overview of the situation. This vulnerability is not associated with the third-party vendor discussed in the first section of the article, it stems from misconfigurations in the utilization of the service
Chameleon allows you to create beautiful product guidance that helps, guides, and delights your users throughout their journey. Great for on boarding new users, feature announcements, and reducing support.
By tracking specific events in your web application, such as when a user engages with specific features or when he does not complete critical actions, you can engage them to help them succeed
Once Chameleon is installed it starts to collect data about your users. There are different types of user data you can send to Chameleon. You can send in user properties, company properties, and user events.
- User properties : User properties are attributes that describe your users and are unique to them. These attributes persist over time, and some examples are name, email address, sign-up date, role, or browser type
- Company properties: Company properties are similar to user properties but attached to a company, and some examples we see often include plan, account name, company name, company size, or industry.
- User events: Events represent the actions users take in your product and can be anything you set up to track, like clicking specific buttons, inviting other team members, making payments, or visiting certain pages of your app
🐞 Let’s talk about the Vulnerability ?
- I can’t disclose the domain name, so let’s refer to the target as redacted.com
- After successfully creating an account on the target website, I was redirected to the dashboard. However, upon reviewing my HTTP History tab, I noticed an unusual request to an external host.
3. I included the external host in the scope list solely to analyze the interactions between the host and the external host
4. On further research, I found out that target host is interacting with chameleon.io and once chameleon is installed it starts to collect user data in order to enable Tours, Tooltips, Microsurveys, Launchers
5. When I replayed the request, surprisingly, I received my user data in the response. Did you catch it? IDOR on ‘_profile_id’? Absolutely. There was no mechanism in place to verify the authenticity of the request.
However, I realized that these ‘profile_ids’ are part of the Chameleon user identification ecosystem rather than the web application itself. These ‘profile_ids’ are not linked to any user in the target’s database. Hence, enumerating profile IDs other than your own would be next to impossible. This is primarily because our concern lies with the target application itself, not Chameleon, the third-party vendor
6. As a result, I resorted to the documentation. I thoroughly read their data collection process and found out that users are also identified by their UID i.e specific to web application
📚 Vendor’s Documentation: https://help.chameleon.io
📝HackerOne Report: https://hackerone.com/reports/1073420
7. I utilized Burpsuite search feature in order to check if there is any parameter named “uid” being sent in the request or received in the response
8. I discovered that the my “uid” was exposed in the response from the preceding request [reexamine Point 4–5].
9. To verify the facts provided by the documentation and previous hackerOne reports, Let’s attempt to replay the same request using “uid” instead of the “_profile_id” [reexamine Point 6].
10. Surprisingly, I got the same user object in the response. In summary, we can retrieve user data from Chameleon using two parameters: “uid” and “_profile_id”. The former is linked to a user in the target’s database, making it more likely to be discovered, while the latter is not associated with any user in the target’s database, reducing the likelihood of its discovery.
11. Dear reader, I understand your thoughts — now, there’s no requirement for a _profile_id; instead, we need a uid to perform IDOR. However, the question remains: how could one obtain a uid that doesn’t belong to them?
12. There is a functionality in which we can collaboratively create folders and projects, meaning that we can invite other users and even assign them roles.
13. Create a Folder > Invite to Folder> Enter victim’s email > Intercept
14. This is the request that gets generated when we send an invitation for someone to join our folder. Let’s forward the request
15. guess what? I got the victim’s user ID in the response. GAME OVER !!
In conclusion, I was able to disclose the victim’s PII with zero interaction from the victim. All I really needed was to figure out the victim’s email address.
Create a Folder > Invite to Folder > Enter victim’s email > Intercept > UID > Query Chameleon Service > Sensitive Data Exposure
16. I continued by crawling the emails of the target’s employees from the public databases. However, I decided to stop the research, recognizing that it would violate ethical conduct.
17. I obtained the triager’s email from our earlier conversations, and as a result, I ended up including the triager’s personally identifiable information (PII) in the proof of concept (POC).
18. According to them — “I am not really gaining more new PII info (you already have the email address when you invite someone to the project). This type of info disclosure is on the lower end of severity according to their risk matrix vs an XSS or RCE for example”. I was little disappointed by the bounty awarded but it can’t be helped since they are using their own Vulnerability Rating Taxonomy (VRT) .
🛠️ How to fix ?
Vendor’s Documentation: https://help.chameleon.io/en/articles/4281577-using-identity-verification-secure-mode
Why Supply Chain Risk Management is necessary ?
While managing third-party risks is crucial for supply chain risk management, it’s important to note that the identified issue was, in fact, a result of consumer negligence. Despite established protocols and assessments, a lapse in consumer diligence inadvertently contributed to the vulnerability. This highlights the need for not only robust supply chain risk management practices but also targeted efforts in user education and awareness to enhance the overall security posture of the supply chain ecosystem
