Your site is probably vulnerable to this attack and there is very little you can do to prevent it. You can monitor for BGP hijacks but you can't really do anything about it when it happens.

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.

You are most likely vulnerable to some extent, protection has to be done by your ISP.

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...

It would not have prevented it, because they could've just as easily attacked the server that serves the HTML instead of the CDN that served the JS.

No, klayswap.com has CAA configured in DNS.

Then it sounds like a misconfiguration after all? Because that would mean they didn't configure CAA for their CDN.

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.

I think the CDN has to configure CAA.

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.

It's not enough for everyone involved to have CAA enabled. They need to have CAA enabled and to select a certificate authority that does effective domain ownership validation, which - as the article suggests - means (at minimum) multiple-origin checking of network-based challenge protocols like HTTP-01.

Personally, I think anyone who has a heightened attack risk ought to contemplate a CA that does some form of more thorough validation.

Yes I saw they attacked the sub domain holding the javascript (developers.kakao.com), but could they have also attacked the main domain?

Sub resource integrity wouldn't help if they could have re-routed requests from klayswap.com

Does it use the internet? If so, you are vulnerable.

If the CAA specifies LE, what then?

Let's Encrypt is the lone, singular CA that actually already had a defense against this attack.

> 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.