Hacker News Reader

Comment by Nextgrid | Hacker News Reader

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

View on HN

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.

Reply on news.ycombinator.com