Comment by billyhoffman | Hacker News Reader

Comment by billyhoffman | Hacker News Reader

Parent Full thread

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.

Best, Henry

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.

If you can get JS executing on the client desktop, with their cookies, with cors whitelisted, you can make a request just like their JS would.

i.e. make the same POST to their api, using the cookie/auth as the original user would, to transfer the files. Its just an ajax call.

Outstanding research! I particularly enjoyed how the presenter in the video shut up the arrogant person from the audience.

>indicate that something was breaking

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.

It only takes a couple of seconds to acquire a certificate. Not long enough for people to raise support requests.

Indeed, your comment illustrates the importance of proactively strengthening the domain validation protocol used for issuing digital certificates.

Our work with Let's Encrypt demonstrated the feasibility of validating domains from multiple vantage points on the Internet: https://www.usenix.org/conference/usenixsecurity21/presentat...

We hope and advocate for universal adoption of this approach via the CA/Browser forum (since the internet is only as strong as its weakest link).

Don't start TLS negotiations until you get the cert. Site's slow for a few seconds, nobody cares.

Reply on news.ycombinator.com