10 ms·

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

123 points by sohkamyung 5y ago

unyttigfjelltol 5y ago
The comment by Phill Hallam-Baker at the end of the article was the best part!
- armada651 5y 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 5y 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.
    - nilsbunger 5y ago
      But EV would give you a way to make a more secure website by hosting all the content yourself
    - dboreham 5y ago
      That doesn't make sense since any content loaded from a second site has the ability to compromise the first. If nobody said that, they weren't thinking hard enough. Browsers already have this kind of transitive security enforcement -- you can't load a page with TLS that then pulls JS via plaintext http.
  - lexicality 5y ago
    You think every website with a form on it should have to pay hundreds of dollars per year to certificate authorities?
    - sp332 5y ago
      There should be a quick, visible way for a user to tell the difference between a connection that is merely encrypted and one where the identity of the certificate owner has been vetted. Then the user can decide for any given form whether they are comfortable sending that data over that kind of connection. Sometimes, the alternative to companies paying hundreds of dollars per year is customers losing millions.
    - natpalmer1776 5y ago
      I think if a website with a form on it that involves transferring any sum of money around should pay hundreds of dollars per year to certificate authorities. Not every building needs to implement the security measures of Fort Knox. That doesn't mean that the security measures in-place at Fort Knox shouldn't exist.
- natpalmer1776 5y 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.
  - randomhodler84 5y 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
    - natpalmer1776 5y ago
      I won't claim to have the degree of technical expertise to authoritatively comment on the actual implications of his comment. What I often find most valuable from these kinds of comments is the fact that these risks were acknowledged and either accounted for in the original specs, even if in a flawed manner, or explicitly discounted as being out of scope. What I take away from the comment on the article is that from a security perspective "we're not there yet" even if the cryptocurrency technology is useful, widely adopted, and frankly not going away. I don't think his issue is that cryptocurrency exists, or is being used widely on the world-wide web, but rather that underlying technologies (DNS/HTTPS/PKI) are being taken for granted and used in a manner that they weren't originally designed for.
      - randomhodler84 5y ago
        EV is expensive bits issued by a trusted third party. Cryptocurrency, Bitcoin, is expensive bits issued by a non-trusted third party. I don’t see how you can be bullish on the first without being bullish on the second, yet I can see how being bullish on the second can mean bearish on the first. Solutions involving no TTP are better than solutions involving TTP. I like PHB and he has done great things in the field of cryptography. His belief in centralization of public key systems for security runs counter to the cypherpunks who want to decentralize everything despite the costs.
- amalter 5y 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...)
mkj 5y 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 5y 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 5y ago
    It only takes a couple of seconds to acquire a certificate. Not long enough for people to raise support requests.
    - mittalprat 5y ago
      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/presentation/birge-lee 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).
ianpurton 5y 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_Authorization 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.
- cotillion 5y 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/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
  - armada651 5y 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.
    - cotillion 5y ago
      No, klayswap.com has CAA configured in DNS.
      - armada651 5y ago
        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.
        ianpurton 5y ago
mkj 5y 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-validation.html https://letsencrypt.org/2020/02/19/multi-perspective-validat...
- taspeotis 5y ago
  > The attackers hijacked developers.kakao.com, approached the certificate authority ZeroSSL, requested a certificate for developers.kakao.com,
donclark 5y ago
So if they stole my $2M in crypto, who should I legally sue? Or do I even have a case?
- anonporridge 5y 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 5y 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..
    - anonporridge 5y ago
      You don't start with a lawsuit in the case of a this kind of theft. You hope the FBI or some other law enforcement/criminal investigators can track down and prove the guilt of the thieves. Jumping to the question of "who do I sue" implies that you want to get money out of someone not directly involved in the crime. In the example of gold in a safe, the question might be "can I sue the safe company to try to recoup some of my loss, even though it wasn't their fault that my opsec was shit?". If there exists no explicit legal agreement that was violated (e.g. the bank that promised to secure your gold was robbed) then you're just being an overly litigious asshole acting in a way that will make our entire society weaker and more vulnerable.
  - yunohn 5y 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 5y 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 5y 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 https://btc-hijack.ethz.ch/files/btc_hijack.pdf [1] https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=9152616 https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=915...
- mittalprat 5y 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-internet-services 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-internet-applications-from-routing-attacks/fulltext https://cacm.acm.org/magazines/2021/6/252822-securing-intern...
l30n4da5 5y 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 5y 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 5y ago
I'd be interested to know if the services affected had certificate transparency monitoring enabled. If not, why?
deleted 5y ago
[deleted]
egberts1 5y 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.
egberts1 5y 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.
- detaro 5y ago
  DNSSEC does not protect at all against the attack described in the article.
  - egberts1 5y 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.
    - detaro 5y ago
      No, it wouldn't alert you. The DNS response isn't tampered with and is still legitimate.

123 points by sohkamyung 5y ago

unyttigfjelltol 5y ago

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

armada651 5y 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 5y 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.
  - nilsbunger 5y ago
    But EV would give you a way to make a more secure website by hosting all the content yourself
  - dboreham 5y ago
    That doesn't make sense since any content loaded from a second site has the ability to compromise the first. If nobody said that, they weren't thinking hard enough. Browsers already have this kind of transitive security enforcement -- you can't load a page with TLS that then pulls JS via plaintext http.
- lexicality 5y ago
  You think every website with a form on it should have to pay hundreds of dollars per year to certificate authorities?
  - sp332 5y ago
    There should be a quick, visible way for a user to tell the difference between a connection that is merely encrypted and one where the identity of the certificate owner has been vetted. Then the user can decide for any given form whether they are comfortable sending that data over that kind of connection. Sometimes, the alternative to companies paying hundreds of dollars per year is customers losing millions.
  - natpalmer1776 5y ago
    I think if a website with a form on it that involves transferring any sum of money around should pay hundreds of dollars per year to certificate authorities. Not every building needs to implement the security measures of Fort Knox. That doesn't mean that the security measures in-place at Fort Knox shouldn't exist.
natpalmer1776 5y 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.
- randomhodler84 5y 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
  - natpalmer1776 5y ago
    I won't claim to have the degree of technical expertise to authoritatively comment on the actual implications of his comment. What I often find most valuable from these kinds of comments is the fact that these risks were acknowledged and either accounted for in the original specs, even if in a flawed manner, or explicitly discounted as being out of scope. What I take away from the comment on the article is that from a security perspective "we're not there yet" even if the cryptocurrency technology is useful, widely adopted, and frankly not going away. I don't think his issue is that cryptocurrency exists, or is being used widely on the world-wide web, but rather that underlying technologies (DNS/HTTPS/PKI) are being taken for granted and used in a manner that they weren't originally designed for.
    - randomhodler84 5y ago
      EV is expensive bits issued by a trusted third party. Cryptocurrency, Bitcoin, is expensive bits issued by a non-trusted third party. I don’t see how you can be bullish on the first without being bullish on the second, yet I can see how being bullish on the second can mean bearish on the first. Solutions involving no TTP are better than solutions involving TTP. I like PHB and he has done great things in the field of cryptography. His belief in centralization of public key systems for security runs counter to the cypherpunks who want to decentralize everything despite the costs.
amalter 5y 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...)

mkj 5y 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 5y 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 5y ago
  It only takes a couple of seconds to acquire a certificate. Not long enough for people to raise support requests.
  - mittalprat 5y ago
    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/presentation/birge-lee 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).

ianpurton 5y 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_Authorization 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.

cotillion 5y 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/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
- armada651 5y 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.
  - cotillion 5y ago
    No, klayswap.com has CAA configured in DNS.
    - armada651 5y ago
      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.
      - ianpurton 5y ago

mkj 5y 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-validation.html https://letsencrypt.org/2020/02/19/multi-perspective-validat...

taspeotis 5y ago
> The attackers hijacked developers.kakao.com, approached the certificate authority ZeroSSL, requested a certificate for developers.kakao.com,

donclark 5y ago

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

anonporridge 5y 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 5y 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..
  - anonporridge 5y ago
    You don't start with a lawsuit in the case of a this kind of theft. You hope the FBI or some other law enforcement/criminal investigators can track down and prove the guilt of the thieves. Jumping to the question of "who do I sue" implies that you want to get money out of someone not directly involved in the crime. In the example of gold in a safe, the question might be "can I sue the safe company to try to recoup some of my loss, even though it wasn't their fault that my opsec was shit?". If there exists no explicit legal agreement that was violated (e.g. the bank that promised to secure your gold was robbed) then you're just being an overly litigious asshole acting in a way that will make our entire society weaker and more vulnerable.
- yunohn 5y 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 5y 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 5y 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 https://btc-hijack.ethz.ch/files/btc_hijack.pdf [1] https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=9152616 https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=915...

mittalprat 5y 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-internet-services 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-internet-applications-from-routing-attacks/fulltext https://cacm.acm.org/magazines/2021/6/252822-securing-intern...

l30n4da5 5y 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 5y 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 5y ago

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

deleted 5y ago

[deleted]

egberts1 5y 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.

egberts1 5y 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.

detaro 5y ago
DNSSEC does not protect at all against the attack described in the article.
- egberts1 5y 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.
  - detaro 5y ago
    No, it wouldn't alert you. The DNS response isn't tampered with and is still legitimate.