Share Dialog
<100 subscribers
A year has passed since I left my job at CoinDCX and embarked on my journey as an entrepreneur. During this time, I have been busy building Cryptocurrency Wallet apis as a service and haven't had much time to write about my experiences in the world of web3. However, I have made it a point to occasionally participate in web3 bug bounty programs to stay up-to-date with the latest security hacks, CVEs, writeups, and attack vectors. By contributing to web3 security and immersing myself in different protocols, I have gained valuable knowledge and even earned some magic internet money. Throughout the past year, I have discovered and reported multiple vulnerabilities in various apps. All of these reported vulnerabilities have been patched. My goal in publishing these writeups is to raise awareness of common security pitfalls, share my methodology with other developers and security researchers, and create a reference material for myself and others to refer to in the future.
In my previous writeup titled "How to Share a Secret?", I delved into the concept of Shamir's Secret Sharing. In this write-up, however, I will be discussing a different topic: the exposure of sensitive keys in Plaintext to the internet especially ways in which sensitive critical secrets can get leaked and compromise an application.
Let's jump right in and start the discussion. Today's target for our analysis is one of the biggest institutional non-custodial staking providers in the crypto industry. Their self-managed program has a wide scope, including all subdomains under *.target.tld, with the exception of a few third-party sites such as support.target.tld and others.
The first step in my hacking methodology is reconnaissance or recon. It involves gathering as much information as possible about the target by performing subdomain enumeration, google dorking, github dorking, network scan, service discovery and other such activities. Check out this brilliant presentation by Jason Haddix if you want to learn more about recon. The aim is to gain a deeper understanding of the target, the application frameworks they use, and the tools at their disposal. During subdomain enumeration, I discovered multiple subdomains, and while scanning through the list, I stumbled upon https://acme.newstaging.k8s.target.tld/. Upon opening the website in a browser, I was presented with a user interface similar to that of the target's production application. During the analysis, i found that sensitive production API keys of Target were exposed in a JavaScript file of this instances. The API keys were hardcoded in the JS file at https://acme.newstaging.k8s.target.tld/v/js/chunk-vendors.randomstring.js
On deeper inspection i found several API keys including API keys of fortmatic, Coinbase Commerce and others. The APIkey for Coinbase Commerce caught our attention. The target used Coinbase Commerce for crypto payment processing.
I immediately started looking at coinbase commerce api documentation and came across the following curl request to check the liveliness of key.
curl https://api.commerce.coinbase.com/charges -H "X-CC-Api-Key: leaked-secret-api-key" -H "X-CC-Version: 2018-03-22"
This request responded with 200 and a paginated json containing charges object as can be seen in burp repeater screenshot below
This proved that the plaintext API KEY in the js was working when we verified it using sample requests in coinbase docs. The json object contained data like user email address, payments urls, transaction reversal urls and other such highly sensitive data as can be seen in image above. Using these API keys, we were able to access production data of Target. This data includes email addresses, charges raised against target’s end users who used Crypto payment medium and perform other sensitive actions on behalf of target.
I immediately created a report of the vulnerability and sent it to the team .The team was able to verify and patch the vulnerability by removing plaintext keys from frontend and deleting exposed keys. I verified the patch and confirmed it to the team and was rewarded bounty for critical severity.
Concluding Remarks
Storing sensitive backend API keys in frontend JavaScript code can pose a significant security risk for any web application. API keys are used to authenticate and authorize access to backend services, and if they fall into the wrong hands, they can be used for unauthorized access or even for malicious purposes. A vulnerability like this can be prevented by following steps like:
Avoid storing sensitive API keys in client-side JavaScript files.
Use server-side encryption techniques to secure sensitive data.
Conduct regular vulnerability assessments and penetration testing to identify and fix potential vulnerabilities.
Educate developers and employees on secure coding practices and the importance of protecting sensitive data.
Disclaimer: This writeup is for educational purpose only. I am buidling Cryptocurrency Wallet Apis as a Service . Do reach out if you have any queries