Public DNS in Taiwan the Latest Victim of BGP Hijack | Hacker News Reader

Public DNS in Taiwan the Latest Victim of BGP Hijack

blog.apnic.net

142 pointspjf25 comments

Operators, where are your MANRS?

https://www.manrs.org/

Interesting that this is going to Brazil again. So someone should check if there have been letsencrypt certificate created using DNS verification during those 3 minutes, like in 2016 https://www.thesslstore.com/blog/ssl-certificates-used-in-ma...

also interesting for the timing. lots of political pressure from US and others on Taiwan "independence" on internal policies happening these last weeks.

e.g. http://m.focustaiwan.tw/news/aipl/201905280016.aspx

Independence from whom? Taiwan writes its own laws, the only influence other countries have on that process is via pressure. Nobody else can legislate for them.

You're free to parse through the 1.6 million certificates issued yesterday! https://crt.sh

  "Does CT prevent certificate mis-issuance?"
  "No."
  "So certs were mis-issued, your bank got hacked, and all your money is gone?"
  "Yes."
  "So are you going to fix internet infrastructure to prevent cert mis-issuance in the future?"
  "Why would we do that? We've got logs, we can see it happen."
  "But banks will get hacked again!"
  "I don't see your point."

interesting how little info we have from companies that can do that.

https://ipinfo.io/AS268869

One would think there would be a little more trust and transparency. But I guess you only need to buy 1k ips and you are in the same league

I have heard that rpki helps prevent this type of BGP misdirection i.e. signed BGP routes. However does anyone know about its deployment?

https://rpki-monitor.antd.nist.gov/

Does dns over https do anything to mitigate this?

No. Routing attacks divert traffic on the IP address level to another destination. It does not matter if you protect the DNS so it resolves to the correct IP address.

It mitigates it in the sense that the attacker presumably wont have the TLS identity required for the client to trust it.

The client won't be able to resolve anything, but it can't be used to send the client to other places, turning it into a denial of service

They can try getting a new DV cert for the domain. It may or may not work depending on how thoroughly the CA checks the domain resolution from multiple places.

If I understand this correctly, does this mean that this is not a weakness in Quad101, but the internet infrastructure itself?

>but the internet infrastructure itself?

Kind of. The Internet is similar to a chain link fence. Every link in the chain needs to perform its role as expected, otherwise shit breaks.

In the case of the Internet, there are many ISPs that are leak links in the chain.

Yes. On the routing level. The attacker literally announces 'This IP address network is mine now' via BGP and gets the traffic. Most such incidents are not real attacks though, but misconfigurations. And there are the MANRS recommendations, which can prevent a lot of problems, including the one described in the article.

Well, it protects against the DNS server itself being redirected. But it doesn’t do anything for IPs that were in the DNS answer being redirected.

There is already DNSSEC is you care about these kinds of attacks.

DNSSEC doesn’t really do anything against a BGP attack, since it’s redirecting IPs. So even if the DNS record is signed the same IP goes somewhere else.

This is described as an attack on DNS. DNSSEC protects again these kinds of attacks.

If you then want to use the IP address to connect to a web server, then you can use TLS. Which, in the case of letsencrypt, again depends on DNS to prevent issuing a certificate to the wrong party.

So if you start with securing DNS, then you can bootstrap from that into securing higher level protocols.

At the moment there is no practical technique to prevent route hijacks using BGP. So it is best to consider that insecure.

One of the records you can write into DNS, where it can be protected by DNSSEC, is CAA. The CAA record tells a Certificate Authority what policies you have about certificates. The high level (if CAA is present) is just which CAs are allowed to issue for this part of the DNS hierarchy at all.

As an example, you can forbid Let's Encrypt outright, if you so choose. CAs can also define more nuanced policies, so when they define one you could instead require Let's Encrypt but only with DNS (and thus DNSSEC verification). Because the Ten Blessed Methods have associated OIDs the CAs could (but so far as I know haven't plans to) have a way to say I'm OK with anybody issuing so long as they used a method with DNSSEC checks.

Now, as Thomas Ptacek points out previously, banks like many other security critical organisations have lousy security and so none of this will get done, but that's because they're bad at what they do, as is illustrated by them causing a global financial crisis. They're bad at real world security too, plus ca change.

Nobody's using DNSSEC, especially in Asia.

Actually, about 16% of all DNS queries in Asia are being validated by DNSSEC, per APNIC Labs: https://stats.labs.apnic.net/dnssec/XD?hc=XD&hx=1&hg=1&hr=1&...

And if you scroll down the page you will see that validation rates are significantly higher in some countries in Asia.

Routing queries through a centralized resolver service that happens to do performative DNSSEC checking is not the same thing as "using DNSSEC". Rather: go to any list of the top domains in any Asian country and take them to "DNSSEC-NAME-AND-SHAME.COM" to see if they're actually signed. Yahoo.co.jp? Rakuten? Google.co.jp? Nope, nope, and nope.

Possibly --

You would need to actually validate certificates for your chosen DNS over HTTPS server cover the IP addresses you've connected with.

And, you would need to be sure that none of the CAs in your root store (or any certificate they've signed with CA privileges) will issue a certificate that covers that IP while the IP is BGP hijacked.

Unfortunately, if the IP is successfully hijacked, at least to a point near to where the CA does it's observation, it seems likely that the hijacker would be able to successfully demonstrate control over the IP.

> 3.2.2.5.1. Agreed-Upon Change to Website Confirming the Applicant's control over the requested IP Address by confirming the presence of a Request Token or Random Value contained in the content of a file or webpage in the form of a meta tag under the "/.well-known/pki-validation" directory, or another path registered with IANA for the purpose of validating control of IP Addresses, on the IP Address that is accessible by the CA via HTTP/HTTPS over an Authorized Port. The Request Token or Random Value MUST NOT appear in the request.

Reply on news.ycombinator.com