How a JavaScript file led me to an Admin Access

It was just a usual penetration test. New target given — crawling the main website, then I see and click a button which redirects to its subdomain. I check the subdomain and see that you cannot register there (I believe that the usage was invite-only: Admins/Someone create you an account -> they invite you -> you can use the platform)

(I use multiple extensions in browser both for privacy and to aid in my pentests, and one of them suggests vulnerabilities in .js components of the app.) An extensions tells me that this website has X, Y, Z JS-libraries and refers to a .js file found on server as its proof — I then decide to click the file and investigate it myself first — as I scroll, I find a link to the API of that subdomain.

As I explore the API, I find out that the API's using Django REST Framework. Yet that isn't the interesting part. I thencheck the swagger — goldmine if its open — and yes, it was open, filled with so many endpoints. Yet, the interesting and critical part came after I registered myself an account for that subdomain through the API. As my account was created, it granted me admin privileges on default.

I now had access to:

• Create/Invite users (including setting their role to Admin)
• Read other people's chats and uploaded voice messages, I could EVEN CHANGE the contents of their messages (edit)!
• Create/change usernames for the participants of the conversation

And it all started just with a single found .js file — a chain from a .js file to Admin rights on the subdomain, where you should not be able even to register yourself.

And that's not the only thing a single .js file that's stored on the website could lead to — just having one doesn't automatically endanger you, it's what's inside that might — if you put there some extremely sensitive info inside of them, then you are just handing that to the attackers — I once had a pentest where a target has disclosed its API keys right in a .js file, and make no mistake the .js file might be found so easily — so always make sure to never include any hardcode secrets, API keys, tokens, or credentials in client-side code. If it's in the .js file, it's in the browser, and if it's in the browser — it's public, and keep your systems safe beyond the .js files too — at the end, it wasn't the .js file that led to the Admin, it was just the first step, it was a chain of multiple sites and vulnerabilities linked together.

Since such vulnerabilities might be encountered in your own pentest too, I built a security tool for authorized secrutiy research & penetration testing for this exact purpose — check the uploaded/pasted .js found on the target for:

• Secrets / API Keys
• URLs
• Relative endpoints
• Cloud storage buckets
• IPs & Emails
• Hosts / Subdomains

The tool is called JSlooting — a Python-based tool with a simple GUI. You just upload a .jsfile or paste its contents, hit Scan, and it will surface findings that might otherwise take you more time to manually dig through.

Note:_ Some of_ JSlooting_'s results might be false positive — always verify manually._

You can get more info/download the tool from its GitHub respository: https://github.com/SAsecurityN/JSlooting