4 ms·

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 o

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.
    - egberts1 5y ago
      So what you are (and the article is) saying is that this BGP hijack is more about inserting a MitM transparent TLS thus leaving both endpoints intact? This is why we can’t have nice things (such as TLS Client Side (or mutual TLS) easily enforced).
      - NovemberWhiskey 5y ago
        No - the point is that if your CA allows an HTTP-01 challenge for certificate issuance, then anyone who can hijack the IP addresses (to which your DNS points) with a BGP attack can subvert that CA to issue their own TLS certificates and subsequently impersonate your service.
        egberts1 5y ago
        Of which all that could have been averted by having another TLS public/private key issued but this time by the client side and it’s public key then given to the website , no? But who does that nowadays? I still do for my mutual TLS APIs. It’s only if the client public key (which is stored only in the web server could ALSO get hijack then all that would be … for naught (to the hacker’s gain, that is).
        NovemberWhiskey 5y ago
        Mutual TLS doesn't help here - the server TLS implementation can easily be configured to accept any certificate. Mutual TLS gives you mutual authentication, but if the server doesn't care whether the client is authentic or not (because it's been replaced by a malicious implementation) then how does that help?
        egberts1 5y ago
jeroenhd 5y 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.
- egberts1 5y 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.
  - tedk-42 5y ago
    No DNS records were changed. They literally tricked IP routes so users received traffic from malicious servers. Nothing to do with DNS which translates names to IPs
  - jeroenhd 5y ago
    No. DNS was not affected by the attack. DNSSEC verifies that the contents of the DNS responses were not altered or spoofed. During this attack, the DNS records were left alone. The DNS response returned the real IP addresses in response to queries and the DNSSEC signature would still be valid. The IP addresses themselves were hijacked. DNS has no authority over IP addresses so DNSSEC would be pointless.
tptacek 5y 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.
- egberts1 5y 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/ http://stats.research.icann.org/dns/tld_report/
  - wolf550e 5y ago
    https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=tptacek%20dnssec&sort=byPopularity&type=comment https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
    - egberts1 5y ago
      DNSSEC only protects their records which includes the mapping of domain name to IP address (and vice versa), nothing else. But why bother when web browser don’t even use DNSSEC itself? Because you can still send data securely under BGP hijack between your two endpoints with using DNSSEC-protected CAA record and a properly-CA-verified mutual TLS (mTLS).

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.
  - egberts1 5y ago
    So what you are (and the article is) saying is that this BGP hijack is more about inserting a MitM transparent TLS thus leaving both endpoints intact? This is why we can’t have nice things (such as TLS Client Side (or mutual TLS) easily enforced).
    - NovemberWhiskey 5y ago
      No - the point is that if your CA allows an HTTP-01 challenge for certificate issuance, then anyone who can hijack the IP addresses (to which your DNS points) with a BGP attack can subvert that CA to issue their own TLS certificates and subsequently impersonate your service.
      - egberts1 5y ago
        Of which all that could have been averted by having another TLS public/private key issued but this time by the client side and it’s public key then given to the website , no? But who does that nowadays? I still do for my mutual TLS APIs. It’s only if the client public key (which is stored only in the web server could ALSO get hijack then all that would be … for naught (to the hacker’s gain, that is).
        NovemberWhiskey 5y ago
        Mutual TLS doesn't help here - the server TLS implementation can easily be configured to accept any certificate. Mutual TLS gives you mutual authentication, but if the server doesn't care whether the client is authentic or not (because it's been replaced by a malicious implementation) then how does that help?
        egberts1 5y ago

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

egberts1 5y 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.
- tedk-42 5y ago
  No DNS records were changed. They literally tricked IP routes so users received traffic from malicious servers. Nothing to do with DNS which translates names to IPs
- jeroenhd 5y ago
  No. DNS was not affected by the attack. DNSSEC verifies that the contents of the DNS responses were not altered or spoofed. During this attack, the DNS records were left alone. The DNS response returned the real IP addresses in response to queries and the DNSSEC signature would still be valid. The IP addresses themselves were hijacked. DNS has no authority over IP addresses so DNSSEC would be pointless.

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

egberts1 5y 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/ http://stats.research.icann.org/dns/tld_report/
- wolf550e 5y ago
  https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=tptacek%20dnssec&sort=byPopularity&type=comment https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
  - egberts1 5y ago
    DNSSEC only protects their records which includes the mapping of domain name to IP address (and vice versa), nothing else. But why bother when web browser don’t even use DNSSEC itself? Because you can still send data securely under BGP hijack between your two endpoints with using DNSSEC-protected CAA record and a properly-CA-verified mutual TLS (mTLS).