Attackers exploit flaw in web’s security to steal $2M in cryptocurrency

https://freedom-to-tinker.com/2022/03/09/attackers-exploit-fundamental-flaw-in-the-webs-security-to-steal-2-million-in-cryptocurrency/

by sohkamyung • 4 years ago

123 79 4 years ago

freedom-to-tinker.com

egberts113• 4 years ago

The only (but arguably) remaining defense against BGP-hijack crypto heists is for you to run your own DNS resolver/caching in your own host that is configured only to allow to emit DNSSEC-verified DNS answers while you use your web-based cryptowallet.

This DNSSEC-only DNS caching is not a common thing to find in most desktops because it impacts many web sites that do not use DNSSEC (looking at you, Google.com).

Of course, this is assuming that your cryptowallet provider is ALSO using DNSSEC properly.

Sadly, none of today’s web browsers (including all of the DNSSEC Validator web browser extensions, that I could find) perform any detection for bad/unsigned DNS queries , much less do any active defensive blocking.

I blame the web browsers’ developers for this disabling of these DNSSEC validation capabilities through their poorly-planned but overly restrictive efforts in deploying newer browser extension APIs.

Those tested DNSSEC Validator browser extensions USED to be working but only back then and ONLY in passive detect mode; nowadays, they’re just a dead extension garnering nothing but downvotes).

Your only practical day-to-day recourse to all that jazz is to establish a windowed VM that does this DNSSEC-only DNS caching and any choice of a major web browser for the bestly secured crypto-exchanges. QubesOS is one such excellent option but VMware or VirtualBox would do just fine in a pinch.

detaro3• 4 years ago

DNSSEC does not protect at all against the attack described in the article.

egberts113• 4 years ago

No, but endpoint to endpoint DNSSEC server/client with no recursion enabled should have your host’s DNS caching do the hard authoritative lookups and should alert you of such BGP hijack and if configured for DNSSEC-only presumably prevents you from going through your crypto-based transaction in that scenario.

Of course, TLS, HTTPS, JavaScript and TCP attack vectors are another whole ball of wax.

jeroenhd3• 4 years ago

DNS was not attacked in this case, the IP addresses themselves were redirected through BGP. It would protect against BGP hijacks of the DNS server, but that wasn't what happened here.

There are ways to protect against such attacks (RPKI for BGP routers, DNSSEC + DANE or HPKP for servers) but none of those aren't available in most modern browsers.

I'm a strong proponent of DNSSEC, but it can't solve _all_ problems. Only with DANE would it benefit the situation.

egberts113• 4 years ago

If target (a crypto wallet website) has both DNS authoritative with DNSSEC and the website, you should be able to detect a change in signing as being invalid.

Key thing is thou that the authoritative DNS server must also reside on the web server.

And gotta turn that DNS cache off or keep TTL short.

tptacek• 4 years ago

Just for clarity: almost nobody uses DNSSEC. It's not just Google. Verify yourself with any list of popular/important domains; just write the shell loop to do a `dig ds +short $domain` across all of them.

egberts113• 4 years ago

Deployment is wider than you think.

Often times, heavy non-commerce sites skimp on DNSSEC (such as google.com)

http://stats.research.icann.org/dns/tld_report/

mkj2• 4 years ago

This is more interesting than the title suggests.

BGP hijack during domain validation to get a badly issued ssl cert, then use that for MITM. I guess it will happen again.

billyhoffman• 4 years ago

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?

ectopod• 4 years ago

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

Nextgrid• 4 years ago

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

charcircuit• 4 years ago

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.

tedunangst• 4 years ago

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

ianpurton3• 4 years ago

How do I know if my site is vulnerable to this attack?

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.

cotillion2• 4 years ago

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

armada6514• 4 years ago

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.

ianpurton3• 4 years ago

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

armada6514• 4 years ago

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

jeroenhd3• 4 years ago

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.

dboreham2• 4 years ago

If the CAA specifies LE, what then?

crunchatized• 4 years ago

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.

unyttigfjelltol• 4 years ago

The comment by Phill Hallam-Baker at the end of the article was the best part!

armada6514• 4 years ago

I never understood why, after finding out that users don't notice the EV security badge, Google/Mozilla decided the best course of action was to remove it completely.

Rather the conclusion should've been that the browser gives the user a warning when attempting to submit information to a website that doesn't have an EV security certificate.

Or at the very least allow websites to use HSTS to prevent downgrading an EV certificate.

pjsg• 4 years ago

Of course, it wouldn't have helped in this case as it was the third party site that had the bad certificate. That fact is not signalled anywhere. I don't recall anybody (even the most ardent supporters of EV) saying that the browser should warn you if any third party references were not EV.

lexicality• 4 years ago

You think every website with a form on it should have to pay hundreds of dollars per year to certificate authorities?

natpalmer17764• 4 years ago

The comment made my whole day. I love it when 'old-guard' engineers who literally built the playground we're on come out to yell at everyone to get off the damn grass.

It's a weird combination of inspiring and humbling at the same time. Inspiring to think that this massive ecosystem of interconnected computers was actually made by real people, and humbling because yeah, I should get off the damn grass.

randomhodler843• 4 years ago

PHB was there when satoshi dropped the white paper. He didn’t get it at the time. He still doesn’t get it, commenting on the same forum recently. PHB, dude, time to admit you were wrong. Not only does this technology work wildly better than you have claimed, it has more value today than it did 13 years ago, both as a savings device, or a trustless medium of exchange

amalter2• 4 years ago

I posted another response off this article and I still don't quite get the gist of his response?

The system we built in the 90s would have protected against this attack.

Is "the system" the human to human EV certificate process? There were so many obvious and awful social and technical engineering holes in that process that I find it hard to believe anyone would defend it?

Certificate expiration was always a danger. There was a single technical contact that could be spoofed or just walk away with the private key. The wider web audience never noticed the EV annotation, and basic human factors tells you they never would. Heck, we can't get people to notice HTTP downgrade attacks. The only protection is TLS everywhere - which never would be possible with slow and expensive authorization methods.

(I suppose it was good business for Verisign though...)

mkj2• 4 years ago

Which CA was used for the exploit? I know letsencrypt had work to validate from multiple paths [1]. If it were a more lax CA then just pointing CAA at somewhere like letsencrypt could possibly be sufficient protection.

1 https://letsencrypt.org/2020/02/19/multi-perspective-validat...

taspeotis• 4 years ago

The attackers hijacked developers.kakao.com, approached the certificate authority ZeroSSL, requested a certificate for developers.kakao.com,

donclark• 4 years ago

So if they stole my $2M in crypto, who should I legally sue? Or do I even have a case?

anonporridge2• 4 years ago

If they stole $2M in gold from my home safe, whom should I legally sue? Or do I even have a case?

You don't get the self sovereignty without the responsibility.

thehappypm• 4 years ago

I don’t think this is true? Crypto doesn’t exist outside the law, you can certainly sue someone for stealing it, if you know who to sue..

yunohn• 4 years ago

If they stole $2M in gold from my home safe, whom should I legally sue? Or do I even have a case?

What are you talking about? This is a standard theft/robbery case, the police absolutely file, investigate, and solve such cases regularly.

lizardactivist• 4 years ago

Something that is also easily glossed over when it comes to certificates is that a browser will happily accept any valid certificate, with no notion or presumption of specifically who should have issued the certificate.

chatmasta• 4 years ago

The described attack is one of the more straight-forward applications of a BGP hijack, and as mentioned, not specific to Bitcoin or any cryptocurrency. The problem is ultimately with BGP, slow adoption of RPKI, and inconsistent certificate issuance/transparency practices. We will see definitely see more of this, because once the attacker accomplishes the BGP attack, the rest of the exploit is extremely simple. It doesn't rely on victims doing anything out of the normal course of operations.

But guess what? The Bitcoin network itself is _also_ vulnerable to BGP hijacking, but the attack vectors are much more complex and so we haven't seen many of these attacks yet. The literature is really interesting though, e.g. Apostolaki 2017 [0] and Tran 2020 [1].

[0] https://btc-hijack.ethz.ch/files/btc_hijack.pdf

[1] https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=915...

mittalprat3• 4 years ago

Indeed, a number of internet services and applications are vulnerable to BGP hijacking and interception attacks, including TLS/digital certificates, anonymity systems such as Tor, and cryptocurrencies such as Bitcoin.

We discussed this in an earlier blog post on freedom to tinker: https://freedom-to-tinker.com/2018/04/11/routing-attacks-on-....

A more technical description of these attacks is available in our Communications of the ACM article: https://cacm.acm.org/magazines/2021/6/252822-securing-intern...

l30n4da5• 4 years ago

As part of their platform, KLAYswap relied on a javascript library written by Korean tech company Kakao Corp. When users were on the cryptocurrency exchange, their browsers would load Kakao’s javascript library directly from Kakao’s servers

Am I the only one that yelled "NO" at their monitor when reading this snippet?

It is usually not good practice to load js from 3rd-party domains into your app. Just grab the file and serve it yourself.

For things like payments, I would hope that most of it is server-side, and that js doesn't play a critical role in it at all.

upofadown• 4 years ago

As I am fond of saying these days: the key fingerprint is the identity. The TLS public key infrastructure (PKI) exists to map an alphanumeric string (domain) to a particular key fingerprint. So for critical stuff involving, say, executable cryptographic code, it would be good if there was a way to specify the fingerprint as well as the domain to the browser in the provided link. Completely inflexible, but that is what you want in this case.

The PKI is great, but there are times when you really don't want to have to trust a third party...

bastawhiz• 4 years ago

I'd be interested to know if the services affected had certificate transparency monitoring enabled. If not, why?

egberts113• 4 years ago

Just wanted to summarize the challenges faced by today’s web browser.

The only way to survive a BGP hijack intact is also a deal breaker for today’s typical common web browser.

Web browsers do not bother with DNSSEC (which remains quite very relevant despite what the article doesn’t says.

It is true that this particular BGP hijack doesn’t change your endpoints’ DNS records (such as A, AAAA, PTR, NS, MX). But this attack did not attempt to fake the DNS CAA at all, which would have protect web browsers; Faking CAA record was not needed then, but it will be leverage next. So DNSSEC, being secured as they are now however is not culpable there nor would they ever be. It is only the DNSSEC-unprotected CAA record that will be the next target.

The Culpability is the malicious PKI substitution which occurred during that event is the fault of web browser, but it is NOT the fault of the TLS protocol, nor HTTP; web browser is guilty. It is the design of using TLS function calls by the application. TLS API, while makes heavy use of PKI certificates, leaves out PKI management to the “other people’s problem” category. TLS protocol and its API is not the problem, they still work as designed.

PKI management is the problem. By direct user experience, web browser is also the problem.

However … your data still can survive a BGP hijack (DNS or not) as intact and securely so if your use case for B2B calls for a secured endpoint using HTTPS/mTLS that has the following aspects:

- use a pair of server and client PKI and its public key stored on opposite ends for use with mTLS (mutual two-way server/client TLS)

- DNSSEC resolver on both ends configured in cacheless authoritative-only lookup mode (no forwarder) with the 13 Root Server key configured/compiled in.

- Deploy the DNS CAA record for your PKI and ensure that each of the chained PKI uses CAA and ensure that all that needed CAA are secured that under DNSSEC

- your endpoint app properly use TLS/SSL function calls AND verified the PKI chains but not before verifying DNSSEC-only DNS queries needed for chain validation.

It remains arguable that given above, one can still use a 3rd party intermediate CA to sign your intermediate CA in which to deploy your needed PKIs for your endpoints. I am now asserting that if you separate your server PKI and client PKI to each of two different vendors, you should get a pretty good security provided that you figured out your own PKI distribution securely and that your own intermediate CA PKI is also imprinted into your app’s own mTLS.

That summary should help your data survive a BGP hijack in your “B2B”pipeline.

A bit safer than IPSec.

Thank you.

Attackers exploit flaw in web’s security to steal $2M in cryptocurrency

Related Stories