Javascript for bug bounty hunters — part 2

This is a follow up to https://medium.com/@bitthebyte/javascript-for-bug-bounty-hunters-part-1-dd08ed34b5a8

Chapter 4–3: Bundle Splitting

Bundle splitting is pretty simple. If you have one giant file, it would take a long time to download rather than sending the whole file at once we will just send the part which the browser needs thus reducing the downloading time. From an optimization standpoint, it’s a perfect solution however for bounty hunters we need to access the full source code at once as it may contain sensitive pieces of information

Chapter 4–4: Detecting and Merging Splitted Bundles

First, We need to detect the bootstrap code. this could be done easily by using Chrome’s DevTools Search “Three dots > More Tools > Search” and Search for “Loading Chunk”

Don’t worry if the file is not named main-[hash].js or has a different name from the one at the screenshot. the bootstrap code is usually the same the following example shows a real production level bootstrap code

Using Chrome’s Dev tools Console we need to edit the bootstrap function to return the full URL of the hosted file. Notice I also added .map extension to the file URL

Unforthenty we can’t use the built-in source map decoder here instead we will use an awesome tool called unwebpack-sourcemap

After running the above command on every map file we will be able to access the full frontend source code as before

A not recommended workaround if you want to use the browser’s map decoder is by injecting the javascript files at the source page with BitMapper enabled

Chapter 4–5: Some Thoughts

As you have seen map files could have a lot of information and it’s exactly the same source code at the original developer's box. Depending on the situation this could be considered as source code disclosure (CWE-200). Don’t just go reporting map files as source code disclosure understand your target and understand how this would affect them before reporting it

Please notice I’m not authorized to disclose any of the targets hostnames or the path. however, I’ll just give you a general understanding of the weakness found ( everything is being done after acquiring the map files — no direct analysis )

Chapter 5 -1: Sensitive API keys found at comments

Most of the developers know that comments won’t make it into production build thus they may keep some sensitive keys as a comment However since I’m able to access the map files I’m also able to access the same source code with the same comment the developer as left it on his/her machine

Chapter 5 -2: DOM Based XSS

This is not fixed yet so I’ll not provide any screenshots or code snippets. A secret parameter named emredirect was found at the source code and has no validation on the user’s input thus allowing the attacker to perform DOM Based XSS

Chapter 5 -3: Admin Panel Access

This is issue doesn’t affect the site’s javascript code directly however accessing javascript files was a big help in it. The full admin panel UI was accessible but protected by a simple redirection if the user was not logged. By just adding a breakpoint on the redirect condition and changing it to the other branch I was able to access the UI revealing that it doesn’t have any server-side protection allowing anyone to access the internal log with some other juicy stuff :)

I’ll leave it here to your imagination to discover and learn more using this trick

Meteor is an open source platform for web, mobile, and desktop used by over half a million developers around the globe to make shipping javascript applications simple, efficient, and scalable. Personally I love Meteor applications it’s a powerful framework but lucky for us most of the developers don’t know how to properly secure it.

Prerequisite(s):

Same as ReactJS Meteor applications will be bundled and minified however it may not has the map file by default However we don’t need it

I’ll not get much in details as it’s very similar to React.JS

In Meteor.js based applications you just need your chrome console and the search. Just know we are interested in everyMeteor.call() function as this invokes real functions at the server using sockets

The attack surface is so large so I’ll leave that for the next article and also to give the people some time to learn about the prerequisites.
Next Writeup(s): SSRF & Unauthnication bypass & NoSQLI at Meteor.JS Application