How zero trust protects from crunchyroll hack

Posted November 5, 2017 by David Redekop to Case Study DTTS

Crunchyroll is in the top 1,000 sites globally. When a site this popular is hacked to distributed malware, it’s a big deal. Here’s an overview of how the hack worked:

The homepage suggested a new player to download, which, when you look at the source, was a actually updating the player from somewhere else *other* than crunchy roll:

It is worth noting that when websites are hacked for malicious intent, the actual payload is never hosted on the hacked site. The attacker simply changes the content of web server files so that unsuspecting visitors retrieve the malicious payload from a server elsewhere, usually one that is more completely controlled by the attacker.

In short, the victim’s computer retrieves the crunchyroll.com home page but along with it a request to download a new player from the attacker’s choosing. In this case, the IP address of 109.232.225.12 is based in the Netherlands, but even leading threat intelligence providers had no negative reputation scores for this IP address. Furthermore, the malware-laden CrunchyRoll.exe was digitally signed, allowing this to sneak by many layers of typical cybersecurity protection.

Compare that with the Zero Trust Model with what we call Don’t Talk To Strangers. “Strangers” are IP addresses that were not preceded with a DNS lookup. To use an example different from the Crunchyroll hack, consider if you want to ping 8.8.4.4 (and the result fails, in red below) vs ping google-public-dns-b.google.com (which succeeds in pinging 8.8.4.4 because it was preceded with a DNS lookup, in green below).

The zero trust model deployed in this manner protected Crunchyroll visitors from the very first moment their site was hacked. It provides the same protection for any other similar type of attack.

Version 3.2 firmware upgrade

Posted October 31, 2017 by David Redekop to Feature

When your device auto-upgrades to version 3.2, you will enjoy the following enhancements:

1. Block page now utilizes an IP subnet (vs a single static IP on the LAN interface). This allows for faster unblock page processing, coming shortly.

2. Better NetBIOS name discovery. In cases where our service host is not the DHCP server, better name discovery is now included.

3. IP enforcement and DNS services combined into a single service. Previously there were two processes in place to facilitate load balancing across devices, but in cases where only one appliance is in use, a single process is more efficient.

4. Under mytools.management/log, logging capability has been enhanced with many view filter options (Status, IP, Name, Answer, Rule, Rule Kind, etc).

5. Logging capability addition for traffic logging in order to easily visualize blocked/allowed packets while narrowing the list down by source, destination or blocked/allowed status

Better Browser Experience for blocked SSL sites

Posted September 7, 2017 by David Redekop to Feature

Traditionally, DNS-level filtering for SSL has been problematic because the block page SSL certificate would never match the host header requested by the browser.

For example, https://badactor.co access would be presented with https://someblockurl.com certificate. This would result in the end-user having to approve an SSL mismatch warning, illustrated to the right, which incidentally, is exactly what bad actors would do with DNS poisoning attacks. This makes it very difficult to train end-users when to ignore and when to heed warnings like that!

Our approach is different. By default, all TCP port 443 (used for TLS/SSL connections) that attempt to connect to the block page server are rejected (a TCP reset). This achieves the following results:

  • End-user device response is immediate, so the user isn’t waiting and wondering what’s going on
  • Bandwidth usage is reduced
  • Device resources are never congested due to wait times

Some DNS-based SSL blocking approaches, will offer a DNS answer of 0.0.0.0 which achieves the above results as well, but then cannot present the end-user with anything helpful.

What we do want, is for the end-user to have some sort of feedback to indicate what just happened. This is where our browser extension comes in handy. To see it in action, here’s a short demonstration:

And here’s a direct link to the knowledge base article with further details and extension access.

Now you can enjoy a user-friendly SSL block page experience!

How a scam should fail

Posted August 25, 2017 by David Redekop to Case Study Security Whitelist

I’m dumbfounded at how often I personally receive deceptive SMS messages like this one here I just received:

When I opened the message, I see that it would be a motivating message for someone to click on if there’s hope to receive some “refund”, even if it’s someone else’s:

Fortunately I was confident with our zero trust model that I could go ahead and click on the link and was unable to go any further:

This is really what it looks like when you protect an end-user, even if that’s yourself 🙂

Using a Zero Trust Model to block outbound VPN, Proxy, TOR, and P2P

Posted July 28, 2017 by David Redekop to Feature Security Whitelist

Traditionally, it has been difficult to block unwanted traffic that is initiated behind an Internet gateway. This is completely understandable considering that a traditional consumer, prosumer, and SMB gateways take an allow all, block some approach. This means that workarounds just need to find one protocol, destination or port that isn’t blocked, and bingo! Your egress channel is now unrestricted using that open hole.

What we are demonstrating here, though, is the opposite. A zero trust model works like this: block all, allow some. This idea of whitelisting is far from new. However, a practical and convenient way to do so has been the challenge. We would like to share with you how we implement a practical solution:

The DTTS (Don’t Talk To Strangers) is currently available for an early adopter group. If you’re interested, kindly contact us via support.

How we are different from OpenDNS

Posted July 11, 2017 by David Redekop to DNS

For those familiar with the great service from our OpenDNS friends, a common question we get is “How are you different from OpenDNS?”

Well, we don’t compete with them. Assuming you also like them, our service complements theirs! In fact, quite a number of our subscribers are OpenDNS subscribers as we integrate quite well as you’ll see if you try it out, including a native built-in OpenDNS Updater so you don’t need to run your dynamic IP updater on any other device.

There are many other differences though, here’s a partial list that most often applies:

  • Deterministic answers – apply different DNS policies to different devices. For example:
    • IoT devices for example, need a very limited whitelist
    • Guest iOS devices may just want obviously-bad content blocked
    • CFO money transfer devices need a very limited whitelist only to the bank in use
  • Whitelisting is our specialty
    • Start with nothing, add what you need
    • Cloud-based web crawler searches and identifies dependencies and threat intelligence to allow only what is safe
  • Domain-joined devices do not need to use Active Directory’s DNS servers:
    • Our rainbow (or re-direct) lists feature AD domain redirection to AD so that all non-AD queries are never sent to AD DNS.
    • Benefit #1 is that your Active Directory DNS servers can now experience a high-level of protection by having strict egress control
    • Benefit #2 is that your devices can experience different treatment from others (appropriate policy based on use case)
  • A live log for complete visibility of DNS queries (and their answers) that occur on your network
  • Tight integration with firewall rules disallows the easiest of DNS filtering circumvention:
    • This also hijacks the hijackers – if you have malware that changes your DNS servers to 8.8.8.8, for example, DNSthingy hijacks the DNS queries and answers them by the policy/rule set applied to the device
    • If you use the “No Internet” rule, it’s more than just a DNS firewall. All traffic is blocked while maintaining internal visibility. Perfect for a NAS or devices that should never have egress access at all (a simple way to stop exfiltration).
  • Importantly, we do not offer public resolver services at all. DNSthingy has a focus in the on-premise space where layer 2 (mac address) can be followed for IP address changes, etc. This is how we are completely different and yet integrates with OpenDNS (and other cloud public resolvers, for that matter). We also appreciate the security that DNSSEC and DNScrypt bring to Internet security, so those are included and dashboard switches for you to enable are coming shortly.

Thanks for reading, we have much more coming to our blog in the next few days!

Making your life easier

Posted March 4, 2017 by David Redekop to Feature

Our newest firmware (3.1.4) supports our largest feature upgrade yet! Most of it you will experience in the Internet experience itself as well as the dashboard, as you learn about the new capabilities that you asked for, such as:

  • Brand new tool at http://mytools.management/ which is available from any computer or device on your network
  • Automated way to check a website for dependencies so when you have a whitelisted device asking to whitelist eBay.com for example, the system crawls it for dependencies and shows you which ones are safe and which ones aren’t
  • Auto-whitelisting allows for automatic approval of unblock requests provided that
    • the domain has a positive reputation
    • no known threats hosted on the domain
    • is not categorized as adult content

    (more than 90% of unblock requests will be auto-approved with this method)

  • Don’t Talk To Strangers (DTTS) new feature is included in the firmware itself; watch our blog for more details coming shortly
  • “Last seen online” option coming back soon to your dashboard; your firmware will now include the required software to offer this
  • Automatic tagging of discovered devices by Operating System coming soon; your firmware will now include the required software to offer this also
  • Business-grade platforms now include additional per-interface features; a DNS listener for each VLAN
  • Watch for new plans available soon to take advantage of these features now available in your firmware

New firmware goodies

Posted August 9, 2016 by David Redekop to Feature

We are very excited about all of these new features in our production firmware scheduled to be released at your router’s next update cycle:

  • DNSthingy now supports authoritative entries, allowing you to use a name instead of IP for internal (or external) resources.
  • Device discovery has been changed from ARP broadcasts to enrollment on “first-seen” basis from the perspective of receiving a DNS request.
  • Unknown devices including queries from foreign subnets including internal vlans not locally-connected, are now treated with your default ruleset.
  • A new utility is included to support future NVRAM migrations (on ASUS routers only).
  • The feature to allow remote support has been improved (previously it required some additional manual steps which are no longer required).
  • DNScrypt support is included in firmware, and will be introduced in the dashboard very soon.
  • Many more bug fixes and stability improvements.

It is also worth noting that ClearOS marketplace subscribers will be updated automatically as long as you’re auto-updating/upgrading your ClearOS software.  pfSense subscribers will need to visit your Packages section and confirm your update/upgrade.