Edit.
Seems that some preventative steps are....
- have all your javascript assets hosted under your domain.
- have a CAA record see https://en.wikipedia.org/wiki/DNS_Certification_Authority_Au...
- If you use a third party to host JS then THEY need to have CAA configured or you need to use sub resource integrity.
The best you can probably do is pay for a TLS certificate signed by a CA that only signs certificate requests after actual, human verification, and pin that in a CAA record. This should prevent other certificate authorities from handing out a domain-validated TLS certificate.
If you're going for the monitoring route, keep the amount of domains your site connects to to a minimum. Self-host your fonts, frameworks, etc, so you only need to monitor your own host. If the developers of the attacked site had hosted their own JS, they might have noticed that something was up when the attack took place, because they can't know for sure if a route change for an external company like Kakao is intentional or a mistake.
The core of the problem is that advertisements by routers that have no business announcing specific routes like these are taken at face value. Certain ISPs that do not require RPKI or other security mechanisms will happily route traffic headed for your IP addresses to some router on the other side of the globe.
Web technologies like DANE used to be popular for this purpose (using DNS to distribute the certificate of your website, with DNSSEC validating the DNS records) but it has seen little actual implementation so far. HTTP key pinning (HPKP) was implemented in some browsers for a while, but its potential for holding websites hostage and general unfriendliness towards bigger websites caused it to be phased out.
If you have apps that operate your service, you can pin your TLS certificate in those and that should protect you against such hijacks.
In this case it seems like the attackers targeted an SDK. Subresource integrity would have helped here.
https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
In any case they could've hijacked the IP for the authorative DNS server, but that would at least add some complexity.
Also, this assumes their CA actually did their due diligence and the hackers didn't just fool them into reissuing the certificate to them.
So if your site pulls in js from another site without sub resource integrity, and the other site doesn't have CAA configured you are vulnerable.
Personally, I think anyone who has a heightened attack risk ought to contemplate a CA that does some form of more thorough validation.
Sub resource integrity wouldn't help if they could have re-routed requests from klayswap.com
> In multiple vantage point verification, a CA performs domain control validation from many vantage points spread throughout the Internet instead of a single vantage point that can easily be affected by a BGP attack. As we measured in our 2021 USENIX Security paper, this is effective because many BGP attacks are localized to only a part of the Internet, so it becomes significantly less likely that an adversary will hijack all of a CAs diverse vantage points (compared to traditional domain control validation). We have worked with Let’s Encrypt, the world’s largest web PKI CA, to fully deploy multiple vantage point validation, and every certificate they sign is validated using this technology (over a billion since the deployment in Feb 2020). Cloudflare also has developed a deployment as well, which is available for other interested CAs.
> But multiple vantage point validation at just a single CA is still not enough. The Internet is only as strong as its weakest link. Currently, Let’s Encrypt is the only certificate authority using multiple vantage point validation and an adversary can, for many domains, pick which CA to use in an attack. To prevent this, we advocate for universal adoption through the CA/Browser Forum (the governing body for CAs).
That defense alone is still not perfect ("some BGP attacks can still fool all of a CA’s vantage points"), but that's the state of the art.