Oh, The Threats You Will Block!
In my previous postings, I’ve outlined how the Blockade browser extension and cloud server function. Buried in those posts is a fact worth pointing out again — Blockade processes web traffic before it leaves the browser. Having that capability reveals some interesting data leaks and techniques we can block from being successful.
IP Decimals
A couple days ago, MalwareBytes published a blog detailing the use of “decimal IPs” by RIG exploit kit actors. Jason Trost was kind enough to point this out to us and asked if we could block it. This was a new technique for us, so went over to the blog and added the malicious decimal using our handy context-menu.
Attempting to visit the malicious resource revealed the trusty Blockade pop-up letting us know that a HEAD request to the translated IP address was blocked.
For those wondering why a HEAD request was created, it appears to be a helper function of Chrome (apparently other browsers do this too) in which they emit HEAD requests to see how the outbound DNS server will respond prior to sending the user along. In this case, it seems that Chrome issued the HEAD with the decimal address, blocked it and then sent back the translated result to the onBeforeRequest API call.
DNS Prefetching
Very early on in the testing of Blockade, I noticed that Blockade alerts would pop-up before I was able to visit the malicious resource in the browser. Initially, I thought it was some strange bug, but then later learned about DNS prefetching. As a means to reduce latency and improved perceived performance, Chrome will attempt to resolve resources prior to browsing to them.
What I thought were bugs were actual DNS requests being blocked in the browser. Blockade was able to identify the prefetch look-ups and stop them from being successful. So, not only is the content blocked, but DNS requests appear to be snubbed as well which can be helpful for preventing data leaks.
