ReconUI - Open Source Reconnaissance (Alpha version)
ReconUI is a simple web application that combines different recon methods to find attack surface and identify assets of the in-scope targets. When you are given a scope like *.domain.com in bug bounty / vulnerability disclosure policies, it gives you a chance to find vulnerabilities in as many targets as possible. While that has its advantages, it also has its own disadvantages. Just for an example lets take yahoo.com. Yahoo's bug bounty accepts any vulnerability under *.yahoo.com. When you start looking for bugs, you end up finding thousands of subdomains and end up getting confused on what you should look for or how you should target something. In those cases, recon tools become handy because you can let them do the hard work and help identify possible crucial assets. However, as we (the bug bounty community) grow, multiple tools are released on GitHub that we can use. Simply running each of these tools on every scan or opening multiple terminals (despite how cool it looks) can sometimes get tedious. Personally, even though I love terminals I hate running multiple tools and having multiple terminals. This is when ReconUI makes it easy.
ReconUI right now covers most of the recon ideas shared by Ben Sadeghipour (@nahamsec) of HackerOne. Just this week he posted a picture to map recon process:
This pictures sums up what I usually do for the first hour of my bug bounty hunting in a fresh program. Instead of looking for low hanging fruits, I do recon for sometime and then use the results from that to focus on finding more severe vulnerabilities.
With ReconUI, it allows to do both: finding low hanging fruits manually and leave the recon and assets identification to a scanner UI. With this now, you can play around with the application and leave the web application to find subdomain takeovers, s3 buckets, port scans etc.
There is no better way to explain the use case of this scanner than to practically show how each process works. For this blog, we are going to do recon on a "target". This target allegedly designs counter-hacking tools for governments and intelligence agencies. Here is the website: https://www.securify.network. So lets begin.
Starting the scan
When we go to the website where you host your ReconUI, you are greeted with the scanner input section that looks like this:
There are certain thing to clear. First, for security reasons the scanner has a URL validation (you can remove it if you want but it is not recommended to do so). In order to run the scan you must have either a http or https before your valid url. Once you fill that, you need to paste in your Private Key (in the picture it says Beta users key). Private Key is given to you when the installer runs. Private key is used for your own security if you decide to host this UI in public facing website. Without the key, no one can run the scan.
Next, once you accept the agreement located at: https://scan.bugbounty.site/agreement, you can run the scan. You can remove the agreement checkbox if you want but running any scans through this tool means that you follow the agreement at: https://scan.bugbounty.site/agreement.
Once you initiate the scan, all the recon tools get to work. Each recon scan will be assigned a backend task because each task is hosted through celery. This helps to make your website and server respond faster. Your scan result might look something like this at first:
In the backend, there are multiple tasks running. One of the fastest task is the Possible IPv4 and Previous and Recent public vulnerabilities. Lets break them down first:
Possible IPv4 search
For this search, you need to have a valid Censys API. Censys allows you to create a free account that has 250 user queries per month allowed. With a valid api, this code will run a basic query to find any other hostnames or ipv4 that has a certificate that matches the domain you input. In this case it will run a query for securify.network. If no result is found it outputs the following result:
However, if there is any IPv4 found, its result will be showcased.
Previous and Recent Public Vulnerabilities
One of the beauties of bug bounty platforms are private bug bounty programs. In these programs only selected few that meet requirements for example: impact/signal/reputation (HackerOne) or activity/accuracy/average severity (Bugcrowd) are asked to hack. Fresh programs who are just launching a bug bounty program sometimes have a lot of low hanging fruits one of the most common one being XSS (either stored xss or reflected XSS) vulnerabilities.
Now, there are public websites that allow hackers to showcase their ability by XSSing any websites they want. While technically not legal because testing a website without permission is not considered ethical, most hackers tend to still contribute to this public database of vulnerabilities. One of such websites is openbugbounty.org. As a bug bounty hunter, if you get invited to a private program, researching that domain in openbugbounty.org might be helpful. Hackers who do not know that company X has a private program might still be reporting its XSS to OBB for fame and leaderboard. However, because you are invited to company X's private program, you can report the same XSS and get credit/bounty for it.
ReconUI helps you do the same by querying openbugbounty.org and then looking for any publicly released XSS. Even a XSS that was reported three years ago and now is considered fix can help you understand how an app is built and sometimes you might just find a bypass to the fix.
Now, after these basic recon comes the more critical part: subdomains, directory search and s3 bucket scanners.
Subdomains open new doors of finding more severe vulnerabilities because sometimes they tend to be hosting critical part of an application (admin interface, CMS, internal login informations etc). At the same time, some subdomains can still be vulnerable to subdomain takeover. Subdomain takeover happens when a domain points to a non-existent domain in a third party service. Most common examples of subdomain takeovers are through Heroku, S3 Buckets, CloudFront, and GitHub.
ReconUI brute forces subdomains of a target and runs basic scans on each of them. To find the subdomains, it uses Ben Sadeghipour's HostileSubBruteforcer. With this tool it will also check if a domain is potentially vulnerable to subdomain takeover. Here is a sample of a scan it runs and the results it shows:
In the picture above, we can see it currently outputs three results: Directories, Services, CORS result. In addition, because this domain is vulnerable to takeover, it alerts the user that they can also takeover the domain. This feature is allowed for S3 Buckets and Heroku apps at the moment. When we simply browse to storage.securify.network, it will show an AWS Misconfigured page:
So next, we want to takeover this domain without any hassle. The easiest way to do is just click the button Takeover Domain. Once the button is clicked a request is made to an internal function that initiates the takeover. Once the takeover is done a page loads that shows us certain options:
The options are: Download Report & View PoC. When you hit Download Report it will download a markdown report that was generated. This can easily be copy pasted in HackerOne to submit a report:
This makes it really easy to submit the bug faster. Not only that, as you can see it generates a PoC for you as well. For safety and privacy, the PoC gets added with a UUID so no one can query it. You can modify the sample.txt located at reports/ folder to have your own PoC text. For this domain, this is how the PoC looks like:
The same attack can also be done against a Heroku Subdomain Takeover. This is how to setup the Heroku auto-takeover.
- With a Heroku account that has credit card in place create an app (can be anything).
- Deploy the app to have some form of text with your takeover message.
- In the installer script when you first run it, put the app name when it asks for it.
Each subdomain that is found by the scanner will go through a directory brute force. Any valid directories that is found (either a 200 or 403) will be presented to the user in a table format. This helps to find some basic vulnerabilities for example existence of a .git folder. Sometimes this can be used to find hidden directories that might have user confidential information for example user ID verification through driving licenses which are stored in local directories.
Sometimes knowing what service a particular website is running on can help a lot. This can help to identify if it is running any CMS that might be outdated. For example an outdated Wordpress can be attacked with publicly known vulnerabilities. Example of this output is as follows:
Additionally, this application will also try to find some basic vulnerabilities like CORS misconfig. If an application allows you to set arbitrary Origin header, you can use it sometimes to pull information that is only allowed to login users. This is frequently common in API requests. If a CORS vulnerability is found, it will let you know:
The s3 bucket is a really simple scanner as well. It will run a brute force scan with different patterns that is obtained from Tom de Vries's script and then check if they are vulnerable to public read or not. If it is found to be leaking informations, it will print out the data with an alert:
In the end, this tool is still a work in progress and will have a lot of updates coming in near future with new tools and recon tricks for example finding leaked credentials directly without having to browse through series of searches. Additionally, there are some code fixes that will happen to make this more efficient and neat.
I hope you like the tool and will have some success with it. If you have any feedbacks or suggestions please reach out to me at email@example.com.
Also, if you are more a visual learner here is the video on how this tool works and looks:
Also, if you are more a visual learner here is the video on how this tool works and looks: