Pin Visual Coverage Tool for Binary Ninja

Introduction

I've been getting familiar with Vector 35's Binary Ninja. It's an incredible, affordable, cross-platform static analysis toolkit for binaries. Binary Ninja also has an intuitive Python API, which you will see soon.

Pin is Intel's dynamic binary instrumentation toolkit. It allows you to easily write your own plugins in C++ for dynamically instrumenting code on the fly. I've decided to use this tool in conjunction with Binary Ninja to provide visual code coverage for test cases, or for quickly identifying dead code paths. This has been an over simplification of both Binary Ninja, and Pin. You should check them both out, and see if they are right for you.

I am not an expert in either of these tools, and this has been my first endeavor writing plugins for either of them. As such, if you see something wrong, then please submit a pull request. This whole process has been a learning experience, and I'm always down to sharpen the toolkit.

Install Pin

This was all done on a Linux based system. First, go ahead and download + extract the Pin toolkit. You'll want to place the path where it's been extracted into your $PATH variable.

Example:

$ echo 'export PATH=$PATH:/home/whatever/pin-gcc-tool' >> ~/.bashrc
$ . ~/.bashrc

Inside of the pin directory you will see source/tools. This is where the plugins that are shipped with Pin. You can compile them individually, and play around with their functionality. A typical execution will look like the following, which will execute /bin/ls with the desired instrumentation.

$ pin -t (shared object of plugin) -- /bin/ls 

Go ahead and grab a copy of BasicBlocks from github. BasicBlocks is a pin tool written for this Binary Ninja plugin. It prints the address of each basic block that is executed. We'll import this data later into Binary Ninja, in order to get a visual analysis of code coverage.

$ git clone https://github.com/chokepoint/BasicBlocks.git
$ cd BasicBlocks
$ make
$ pin -t obj-intel64/BasicBlocks.so -- /bin/ls > /tmp/ls.ptrace

Install BN Pin Coverage into Binary Ninja

The plugin directory is generally stored in ~/.binaryninja/plugins on Linux based systems. Go ahead and clone the plugin into that directory.

$ git clone https://github.com/chokepoint/BNPinCoverage.git ~/.binaryninja/plugins/BNPinCoverage

Now, you can fire up Binary Ninja, and two menu items will be added under the Tool menu.

Go ahead and open /bin/ls. If you haven't generated a basic block trace, go ahead and run the pin command shown above. Our next step will be to import it into Binary Ninja.

If the binary is compiled as a Position Independent Executable (PIE), the plugin will attempt to calculate the slide from the initial Basic Block to the program's entry point. This has so far been successful on x86_64 Linux using both tcpdump, and tshark as examples. Below is a screenshot from tshark with PIE enabled, and a Basic Block trace using the pcap testcase that ships with AFL.

References

• Binary Ninja
• Binary Ninja API reference
• Pin
• Position Independent Executables
• Dynamic Binary Instrumentation

Exposing Server IPs Behind CloudFlare

Introduction

CloudFlare is a complete solution offering Content Deliver Network (CDN) style capabilities along with Web Application Firewalls (WAF). It's also a market leading solution for Distributed Denial of Service (DDoS) mitigation for websites. CloudFlare works by placing its server arrays in front of a website and determines whether or not to allow traffic to pass through. For a more detailed listing of capabilities, please read CloudFlare's own Blog.

In order for the system to remain effective, all traffic must pass through the CloudFlare network. If we are able to directly connect to end systems, we can often bypass the WAF or target specific systems for traffic shaping or DoS attacks.

Existing Techniques

There has been some effort in the past to unmask servers hiding behind CloudFlare. One website in particular maintains a database of IPs that appear to have been exposed. Not all of their techniques are public, and there appears to be a large gap in most of their data.

Many have also used historical DNS records to track previously exposed systems. Forcing a server to send an e-mail for user registration or mailing lists can also expose backend infrastructure. These techniques also create some gaps, and you may only be able to find an IP or two that is still relevant.

Synopsis

When you use CloudFlare to front your website, an SSL/TLS certificate is automatically registered by CloudFlare for your domain. This means that traffic going to your site is initially encrypted when it hits CloudFlare's servers. From there, traffic may very well be in plain text back to your server. Many sites opt to have their own certificates to protect the second half of the transaction.

In order to maintain a trusted certificate, you must prove to some level of degree that you are the owner of a domain. This burden of proof, and trust mechanism makes it easy to associate true server IPs to CloudFlare protected domains. By utilizing large data sets that have been scraped from the Internet, it's possible to find non-CloudFlare servers by associating previously generated certificates with live hosts.

Censys.io

Censys.io is a great resource that relies on data sets from Scans.io. Both are incredible repositories of information that have been gathered by scanning the Internet at regular intervals. There are multiple types of scans from dns and ftp to http/https scans of all public IPv4 space. Censys has graciously offered a public API for researchers to use. We are going to use the scraped certificates from across the Internet to identify potential servers hiding behind CloudFlare.

Cloudsnare

You'll need to utilize your API credentials after registering with Censys. These can be found under My Account. The only Python requirement is censys's maintained PIP package.

pip install censys

Example

./cloudsnare.py zoomit.ir
Certificates:
        Host: *.zoomit.ir zoomit.ir
        Fingerprint: 40b4b7b947cfe8fa96bf8b13244a6d0f535e372be455b8144cf12d5edfd5a490
Hosts: 40b4b7b947cfe8fa96bf8b13244a6d0f535e372be455b8144cf12d5edfd5a490
        Found host: 192.95.47.224
        Found host: 94.182.183.50

Examining Top Domains

I downloaded a top million list of domains from Statvoo. From there, I extracted the top 50k domain names, and ran scans to see which domains were using cloudflare. I stopped the scanning once the list was close to 9000 (9038). I then modified the cloudsnare script to add a soft form of rate-limiting. The numbers are not exact, as I did hit a few exceptions here and there in the script, but I was able to observe at least 1842 domains that leak some sort of IP address based on public certificate data. That's right at ~20% of top domains being affected. Note: I did not go through and check every domain for types of systems exposed, or weed out any false positives.

List of domains

Mitigation

CloudFlare has a great blog post about keeping your IP space private. You should restrict inbound traffic to your HTTP/HTTPs ports, and only allow connections from CloudFlare IPs. If you are worried about CloudFlare changing IP space, you can use your host's default domain while registering certificates. For instance in AWS, you might have an issued domain from your service provider similar to ec2-54-78-80-22.us-west-2.compute.amazonaws.com. Traffic will still be encrypted between your host and CloudFlare, but won't expose any of your systems to this technique.

References

• CloudFlare Origin Protection Blog
• CloudFlare IP List
• Censys.io
• Scans.io
• CrimeFlare
• List of domains with exposed IPs