Hacking on CIDR ranges

It’s safe to assume that @sw33tLie is a wealth of knowledge when it comes to bug hunting. Not only did he win our 2021 TeamHunt Challenge, but his forever passion for hacking and computers have also led to a career as a top ranked researcher on the BugCrowd platform. Besides all that, @sw33tLie is an amazing person to learn from and a great friend to have.

We’re excited to collab with him on fun educational pieces that will undoubtedly help your bug hunting game. He loves chatting about automation, parsing differentials, and other weird quirks of the HTTP protocol.

This blog post by @sw33tLie will cover what CIDR ranges are, the best ways to scan and monitor them, and some common tricks that often come in handy when looking for juicy bugs!

Hacking on CIDR ranges

Most web assets on today’s bug bounty programs are single applications or domain wildcards, such as *.example.com, where all subdomains are in-scope. However, some virtuous companies let hackers hunt on their whole CIDR ranges. Since such programs are still a minority, they are often overlooked, offering unique opportunities to the people that know how to deal with them.

Basics of CIDR ranges

A CIDR range is a set of IP addresses that share the same prefix. Companies often buy them in bulk to satisfy all their hosting needs.

They are usually specified using the CIDR notation: an example of such notation is 1.2.3.4/22. Several online tools can be used to get a list of IP addresses from a CIDR range, as well as CLI utilities like mapcidr.

Portscanning

Unless otherwise specified, when CIDR ranges are in-scope hackers are allowed to hack on whatever open port they can find on any host: this means all ports from 1 (or, should we say 0?) to 65535! Several portscanning tools are available, but this blog post will focus on one of the most common scenarios in bug bounty hunting: a large number of hosts to scan, all ports to probe, and the need of doing that fast.

For these reasons, one of the best tools for the job is masscan by Robert Graham. This tool is special because it relies on its own TCP stack in order to be as fast as possible. While it’s designed to be cross-platform, due to OS limitations its max speed can only be achieved using a Linux-based distro.

After installing the tool, which can be done by following the readme on its GitHub repository, a scan can be launched with the following command:

sudo masscan 1.2.3.4/24 -p 1-65535 –exclude 255.255.255.255 –rate 100000 –output-format json –output-filename scan-results.json

This will scan all ports on all IPs within our demo 1.2.3.4/24 CIDR, and save the results in the scan-results.json file. If we have multiple ranges, we can put them in a text file and pass its path to masscan using the -iL flag. Note that the –rate value should depend on your machine’s stats and if it’s too high you may miss many open ports: if you’re looking for better accuracy, consider lowering the rate or even using a different tool such as Nmap, but keep in mind that it will take more time to run a portscan.

Parsing masscan results

In order to actually use the scan results from masscan, the output file needs to be converted into a format that can be processed by other tools.
To do so, the following bash one liner can be used:

cat scan-results.json | sed -e ‘/^\[/d’ -e ‘/^\]/d’ -e ‘s/,$//’ | jq -r ‘[.ip, .ports[0].port] | @tsv’ | sed ‘s/\t/:/’ | sort -u > alive-hosts

This command will create the alive-hosts file, containing one host per line along with its port, like in this example:

1.2.3.2:80
1.2.3.6:3000
1.2.3.167:443

Such format is often very useful as it can be used as input for various HTTP probing tools such as httpx by Project Discovery.

While HTTP servers aren’t the only piece of technology that can be hacked, it is the most common so it makes sense to start from there. With the following command, we can probe for them using httpx, while displaying useful data such as the HTTP page title, response size, and status code:

cat alive-hosts | httpx -status-code -content-length -title -follow-redirects -threads 500 | tee probed-hosts

Now, by inspecting the probed-hosts file containing all results, we have a nice overview of (hopefully) all alive HTTP hosts: from here, the classic hacking methodology can usually be applied.

Sometimes, however, accessing HTTP servers directly by IP isn’t useful: this often happens with IIS servers and a couple of other tech stacks, where if the Host header doesn’t match one defined on the server, a default page will be provided as a response.

When that’s the case, we have to find the right subdomain that points to that IP. There are multiple ways to do that, but sometimes it’s definitely not a trivial task. One of the first tools that I like to run is crobat: assuming our IP is 2.3.4.5, this command will hopefully find subdomains pointing to it:

crobat -r 2.3.4.5

Further material: Recon Over time vs Point of Time

The scanning methodology that was explained above can be classified as “Point of Time” recon, as explained in this video by codingo. It’s a good start, but it gets a lot better when it’s used to implement a “Recon Over Time” pipeline: instead of scanning some assets once, we can scan them continuously to spot differences in the scan results.

–@sw33tLie

Want More from @sw33tLie?

His next piece will offer some effective ways to implement your own Recon! Follow us on Twitter and Instagram to be in the know.

About the author (@sw33tLie / Paolo Arnolfo)

I’ve always been passionate about hacking and computers, and I started hunting on Bugcrowd consistently during the Covid pandemic. Since then, I’ve been lucky enough to talk to many people and meet new friends along the way thanks to bug bounty platforms. In 2021, I was one of the winners of Bugcrowd’s #teamhunt2021 hacking event. I enjoy talking about automation, parsing differentials, and other weird quirks of the HTTP protocol.