The attackers were advertising that they handled the routes for the 2 IP addresses to which developers.kakao.com resolves. They did this so the CA would send the domain validation request to their systems (which is done over HTTP), "proving" they owned the domain, allowing them to get a valid TLS cert for developers.kakao.com.
But during that time, wouldn't they have also received HTTPS traffic from real users trying to load developers.kakao.com? I understand BGP hijacks can be somewhat localized, but still. The attackers presumably are getting real user HTTPS traffic for a domain for which they don't yet have a valid certificate. Which means those requests would fail to negotiate TLS properly, or the attackers could just not run anything on [IP address they hijacked]:443, which would make the requests for the JS file on developers.kakao.com timeout.
My question is, wouldn't real users whose traffic was also hijacked during that window before the TLS cert was issued notice the web application not working? Wouldn't a rise in incoming support requests or something indicate that something was breaking?
If you can maintain a route to the real host, you could pass through real HTTPS traffic back to it until you got your certificate, making it undetectable from the outside (besides maybe some extra latency).
Hi, I am one of the authors of this blog post, and I felt it would be relevant to mention that this attack (where HTTPS traffic is forwarded back to the victim before a certificate is issued) is actually exactly what we did in our live demo at HotPETS 2017: https://www.youtube.com/watch?v=TYBq2ammTRg
In the case of the KLAYswap attack, based on public routing data, it is highly unlikely the adversary forwarded any traffic back to Kakao. As mentioned in the comments, certificate issuance only takes seconds, so it would not have been a very noticeable outage. Also, the adversary did not seem to mind causing connectivity issues given that they actually checked the referer HTTP header to only serve their malicious JS file to people that were downloading it from KLAYswap.
Thanks for the clarification. Could you address the comment left directly on the post?
How was the this client-side JavaScript being used as part of the security of the transaction? Shouldn't the transaction have been recorded as part of an atomic database transaction, which should only be possible on the correct server?
I'm not privy to any details, but a simple possibility would be to replace the destination address of any transfers initiated during the time period. You could even re-write all the DOM to hide double checks. It might have even been possible to initiate the server side request directly - but even if there was a 2FA confirmation of the transaction that included the address - I could easily see $2m worth of transfers successfully rerouted. This attack easily could have been against a bank with online wire transfers - the challenge there would be laundering the money.
I don't know much about this specific third party javascript and it's possible that tighter CSP policies could have mitigated some of the attack vectors. However, once you can MITM, it's really game over.
Before we blame usage of the js CDN, they could have performed the TLS attack on KLAYswap instead and then just reverse proxied while strategically rewriting data. It's possible that with this specific setup that the js CDN was the lowest hanging fruit.
This is such an fundamental and structural attack (BGP poisoning to screw with certificate ownership validation) that I find the comment by Phill Hallam-Baker incredulous. Perhaps there is a hobby horse against automatic certificate exchange (there is a mention on EV certs, which were such an obvious scam) or it's just a middlebrow rant about "javascript dependent pages".
There are many attacks possible with this method and plenty that will work on the simplest request/response Web 1.0 architectures.
Sure you might know somewhere the internet was broken, but you wouldn't know what caused it. It's a downstream issue from you so it's hard to deal with beyond filing a ticket with with some service provider.
But during that time, wouldn't they have also received HTTPS traffic from real users trying to load developers.kakao.com? I understand BGP hijacks can be somewhat localized, but still. The attackers presumably are getting real user HTTPS traffic for a domain for which they don't yet have a valid certificate. Which means those requests would fail to negotiate TLS properly, or the attackers could just not run anything on [IP address they hijacked]:443, which would make the requests for the JS file on developers.kakao.com timeout.
My question is, wouldn't real users whose traffic was also hijacked during that window before the TLS cert was issued notice the web application not working? Wouldn't a rise in incoming support requests or something indicate that something was breaking?