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 188.8.131.52 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 184.108.40.206 (and the result fails, in red below) vs
ping google-public-dns-b.google.com (which succeeds in pinging 220.127.116.11 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.
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 🙂
iOS apps, especially with little children, are often completely unusable unless the ads and trackers are all blocked. Many parents are used to putting an app in airplane mode before letting kids play. Unfortunately that disqualifies all apps that require connectivity.
|DNSthingy ad-blocking disabled:
||DNSthingy ad-blocking enabled:
While Apple has their own iAd ecosystem, many mobile apps use alternate ad providers (mopub is a popular one), which are already blocked in our default blacklists.
But to have a truly beautiful iOS app experience and cover all the bases, follow these steps for the ruleset applied to your iOS devices:
The blacklist above does not include hosts that prevent services from working.
- Now you want to create a separate list (Dashboard -> Manage Rules -> My Lists -> Create a List -> blacklist) called iAds and include these hosts:
Finally, go to your Ruleset and turn it on like this:
Note: blocking Apple iAds will prevent iTunes radio (does anyone still listen to that?) from working as well as the occasional tracked ad. For most subscribers, this is a small price to pay for a superior iOS app experience.
In many parts of the world, even the western world, bandwidth is expensive. One of our subscribers is out in the “middle of nowhere” as they call it, far away from any affordable fibre, DSL or cable, and the only connectivity option is a metered LTE connection.
It didn’t take long to find out that their $1,100+/month bill came from the video content being consumed by the 30+ stone quarry labourers near the office during their breaks and lunches. As probably is common in many parts of the world, they were browsing YouTube, Netflix and Facebook.
The owners felt they had two basic options:
- Disallow staff the usage of WiFi altogether. This would have an impact on morale and may not be an effective move.
- Disallow the bandwidth-consuming services and explain to the staff the high cost of bandwidth in this geographic region.
They chose the latter option, and it was literally as simple as creating a DNSthingy black list with these domains in a list called Bandwidth hogs:
However, the owners wanted to naturally exempt themselves from this blacklist, so they simply created two rulesets as follows:
||How it's used
||For which devices
||Bandwidth hogs blacklist applied
||Ruleset applies to all devices as well as new ones by default (i.e. when a new wifi device joins for the first time)
||Bandwidth hogs blacklist not applied
||Ruleset applies to owners' devices
On the DNSthingy dashboard, here’s how it looks now:
||How it looks
|Block the bad (ruleset used by default)
|Business Owners (ruleset applied to owners' devices)
|This is how it looks when rulesets are assigned (under Dashboard -> Manage Network -> Devices):
This subscriber is going to save an estimated $10,000 in bandwidth costs this year based on the above steps.
- This approach still allows for general Facebook access, but the videos do not play and therefore bandwidth is saved.
- This blacklist is available for you to subscribe to, so when domains are added to it in the future, you automatically benefit. Once you’re logged into your own dashboard, simply visit:
(will open new tab/window)
You will then need to Subscribe (inherit changes by the author, yours truly), or Make a copy (manage your own changes in the future) as shown in this screenshot:
If you have a favourite list of your own, you can use the share feature (available on any list in your account) and share the URL with others to subscribe. A public-facing site for those that want to share their list is in development.