Table of Contents
Every security engineer has that one story—an unexpected discovery that changes the course of their career. For me, that moment came when I stumbled upon a serious vulnerability in a tool we were using.
What started as a pretty routine security test turned out to be a journey for earning my very first CVE ID, my first Bug Bounty, and discovering the intricacies of API security.
In this engineering blog, we share the key lessons and insights from that experience, focusing on the importance of vigilance in security testing and beyond. So, let’s get started.
The Not So Routine Security Task
It began as what seemed like just another security test. Our fintech product was set to launch in a few short weeks, and it was important to ensure that everything was secure.
As part of our routine process, we run multiple security tests on all our applications before they are sent to production. I approached this assessment as any other, starting by focusing on the potential authorisation issues in the APIs.
Discovering a Third-Party Tool
As I began my testing, I soon realised that this new product was built on top of a third-party tool called Retool.
Retool makes it easy to build internal apps, such as admin panels and dashboards, on top of your data sources.
The Testing Process
For this testing, I had three distinct roles based on different user privileges:
- Admin: For Administrator Controls and Tasks
- Requester: For Requesting the Resource
- Approver: For Approving/Rejecting the Requester’s Request
The authorisation for this application was handled by JWT tokens, which is a well-known practice for securing APIs and handling authentication and authorisation.
My goal was quite straightforward: “Can the admin APIs be accessed by other roles?”
I set up a proxy tool and explored the application by logging in as the admin and capturing all the admin-related API calls.
Interestingly, one of those calls, named “/api/resources,“ fetched access resources for the user.
After logging out, I logged in again as “Requester.” As the admin-related API(s) was already captured by the proxy tool, I took the /api/resources Admin API(s) request, replaced the admin JWT token with the requester’s token, and sent the request.
Burp Repeater showing response for “/api/response” token
The unexpected vulnerability
To my surprise, the server-side response was identical. This meant that admin APIs were accessible to a regular user—an unequivocal case of ‘Broken Access Control.’
Taking a closer look at the response, the bell continued to ring even louder: the response was leaking a database username and password.
This was not just a case of broken access control, where data was exposed to a larger audience than intended, but also a case of sensitive data exposure.
The first lesson learned: “Never blindly trust that a third-party tool’s security is flawless. Your product’s security is still your responsibility.”
Reporting and Realisation
I quickly reported the issue to our developers, only to find out that the problem was rooted in Retool.
We immediately brought it up to Retool’s team, and to their credit, they acted swiftly. Just a few days later, they released a security advisory to all its users, including us.
Security advisory email from Retool
The Lightbulb Moment
When the security advisory hit my inbox, my eyes opened wide. I realised how seriously the situation could go—this was no local issue at all with our product.
It was a global vulnerability that could potentially affect many users. That’s when I took a call to take things forward.
I reached out to Retool, sent a request for credit of discovery, and requested a bug bounty along with a CVE ID.
This time, Retool was helpful too. In just a matter of a few days, the “CVE-2024-42056″ was issued to my name along with a bug bounty.
CVE ID acknowledgment
My First Bug Bounty Earning
Key Learnings
This experience reinforced some valuable lessons about API security and the need for vigilance:
- Never Blindly Trust Third-Party Tools: Just because a tool is used often doesn’t mean that it is immune to flaws in terms of security. Always run your own security tests on third-party tools as well.
- Broken Access Control: Always test for broken access controls, especially when you are using an application with multiple user roles. Ensure no user has access to data or functionality beyond the designated role.
- Too Much Data Exposure: Know what your APIs expose. Sensitive information such as database credentials. should never appear in API responses, regardless of the user’s role.
- Always Ask for Credit: If you find something big, do not be afraid to ask credit for it. This could have just been another report, but I took it beyond that and made it a career milestone for me.
- Stay Curious and Persistent: What started as routine testing led to a significant discovery because I didn’t stop at the surface. Always dig deeper and explore every possible angle.
Conclusion
In the field of cybersecurity, even the most routine tasks can lead to extraordinary outcomes. This experience has not only marked my first CVE ID and bug bounty but also reinforced the importance of thorough security testing, especially when dealing with APIs and third-party tools.
