5 ms·

Yes. It does. Someone noticed that the 4 of the 7 hostnames that were assigned for authoritative names servers for .IO were available for registration. They re

Yes. It does. Someone noticed that the 4 of the 7 hostnames that were assigned for authoritative names servers for .IO were available for registration. They registered them, and started receiving DNS lookups for .IO hosts from what appears to be actual internet users. Since the user had 4 or the 7, its possible that the majority of DNS lookups for .IO hosts would be sent and answer by the author's systems. The author could have started replying with malicious lookups. "Oh some-sexy-saas.io? yeah, that's [evil IP]." "oh, billing.otherapp.io? what a surprise that site is also available at the same [evil IP]!" How could .io sites have avoiding getting spoofed? HTTPS + HSTS would prevent the author from spoofing the DNS of that those sites and sending them to a server over HTTP thus avoiding the certificate errors. update: I overlooked that sites would also need to leverage Public Key Pinning to be protected, since getting a valid DV cert for a spoofed cite when you control DNS would be likely. https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning

Kenji 9y ago
When I skimmed your message, I read some-sexy-ass.io. I think that would be a more likely domain for people to look up ;) EDIT: C'mon, you know I'm not wrong.
nvarsj 9y ago
Couldn't you just use letsencrypt to create arbitrary SSL certs for the io domains you now own? Then https isn't going to help you much.
- JoshTriplett 9y ago
  HSTS (correction: HPKP) preloading would help avoid that, and Certificate Transparency monitoring would help detect it, but yes, in general, if you control DNS for a domain, you can get a valid certificate for the domain.
  - toast0 9y ago
    HSTS preloading doesn't help if you can get a Domain Validated certificate. HPKP preloading helps, but only if you pin to a CA that won't issue a DV certificate to someone who controls 4 out of 7 of the nameservers for the TLD your domain is in. And also only helps if the incident is cleaned up before the browser preload process catches the malicious server when confirming the preload. It might be a good idea to require DV certificate issuance to respect DNSSEC -- in this case, the poison nameservers wouldn't be able to sign the responses properly, and .io is DNSSEC enabled. Certificate transparency should help you know what's going on, but only if you're getting notifications through a method that's not compromised (email to your domain may not make it to you).
    - JoshTriplett 9y ago
      Edited in a correction, thanks. But also: you can pin to a specific certificate, not just a CA. > It might be a good idea to require DV certificate issuance to respect DNSSEC -- in this case, the poison nameservers wouldn't be able to sign the responses properly, and .io is DNSSEC enabled. That seems like a good idea. DNSSEC isn't perfect, but for this purpose it's better than nothing. (That said, I'd love to know where we stand on getting a better replacement for it.) > Certificate transparency should help you know what's going on, but only if you're getting notifications through a method that's not compromised (email to your domain may not make it to you). Definitely a good idea to point domain-related notifications of any kind to an email that doesn't go through that domain.
      - toast0 9y ago
        > But also: you can pin to a specific certificate, not just a CA. I think the general best practices for pinning are to pin a CA or two, and a backup key; in case your keys get compromised, you can reissue with your preferred CA; in case your CA gets delisted, you can get a cert issued with your backup key from a still trusted CA. You could have a series of keys and trust those, but it seems like that would be an easy way for you to shoot yourself in the foot.
finnn 9y ago
>HTTPS + HSTS would prevent the author from spoofing the DNS of that those sites and sending them to a server over HTTP thus avoiding the certificate errors. I'm confused, how would that help? Could the attacker (the author, in this case) not get a valid https certificate for these domains, returning spoofed DNS responses when the CA goes to validate it?
- billyhoffman 9y ago
  Depends, but for DV certificates, most likely. Certificate Transparency could/would help alert the original site if that was the case.
  - finnn 9y ago
    yes, but HTTPS + HSTS would not enforce a certain validation level, eg you can't enforce EV certs only in HSTS (as far as I know), so a DV cert would be sufficient
- theEXTORTCIST 9y ago
  the attacker MITM TLS has to present a certificate for the spoofed domain that was signed by a Certificate Authority the victim's browser trusts
  - discreditable 9y ago
    Very easy to do. You can even automate it with Let's Encrypt since you can serve whatever DNS records you want.
simias 9y ago
>HTTPS + HSTS would prevent the author from spoofing the DNS of that those sites and sending them to a server over HTTP thus avoiding the certificate errors. Unless I'm missing something if you own the DNS it should be trivial to get a valid HTTPS certificate for any .io domain. Then the only thing that can save you is certificate pinning. That makes me think: I wonder if you could "trick" a CA into giving you a wildcard *.io certificate when you own the TLD. Would that even be accepted by the browsers?
- wolfgang42 9y ago
  I believe the major web browsers all reject wildcard certs for TLDs. For more discussion: https://security.stackexchange.com/questions/6873/can-a-wildcard-ssl-certificate-be-issued-for-a-second-level-domain/6874#6874 https://security.stackexchange.com/questions/6873/can-a-wild...
deleted 9y ago
[deleted]
detaro 9y ago
HTTPS + HSTS + HPKP with restrictive settings might help against the attacker just getting another certificate.
- rocqua 9y ago
  Without preloading, HSTS and HPKP still have the trust-on-first-use problem.
kcorbitt 9y ago
> HTTPS + HSTS would prevent the author from spoofing the DNS of that those sites and sending them to a server over HTTP thus avoiding the certificate errors I'm not sure that's true. From a CA's perspective the attacker would own the redirected domain 4/7 tries, so they could probably convince at least one CA to issue them a valid certificate for it.
deleted 9y ago
[deleted]
mattferderer 9y ago
I feel any mention of HTTP Public Key Pinning should have the words "WARNING" surrounding it. It can take down your site if you screw it up - https://www.smashingmagazine.com/be-afraid-of-public-key-pinning/ https://www.smashingmagazine.com/be-afraid-of-public-key-pin... I also believe it is one of the more difficult security features to implement & doesn't work well with Let's Encrypt https://community.letsencrypt.org/t/hpkp-best-practices-if-you-choose-to-implement/4625 https://community.letsencrypt.org/t/hpkp-best-practices-if-y... I'm not against it and this case does seem to make me reconsider my prior risk balance assessment of implementing it.
AndyMcConachie 9y ago
The best way to protect yourself against this kind of attack is DNSSEC. Plain and simple.
- rocqua 9y ago
  Only if your resolver fails closed. Otherwise, an attacker can just return non-signed responses. This is all client side, as a domain owner you simply need to trust your TLD. As long as most clients don't run tight DNSSEC, you're screwed if the TLD fucks up.
  - AndyMcConachie 9y ago
    .io is signed and it has a DS record in the root zone. If you're using a DNSSEC validating recursive resolver(e.g., Google, Comcast) they should replace their cached NS records from auth resolvers that don't return signed respones, with cache entries that do return signed responses. If a stub tells a recursive resolver to return a DNSSEC signed response(by setting the DO bit to 1 in the query) that recursive should keep trying to find a signed response until it has exhausted all possible NS records in the parent zone. This assumes of course that the second-level zones are also signed. So it would only protect people going to example.io if example.io was signed. If you have a .io child zone then you should sign it.
- tptacek 9y ago
  I dispute this, even though this seems like the one case where we're talking about an attack that actually lines up with what DNSSEC actually does. The reason is, what we're talking about is a massive misconfiguration. It's not an elaborate technical spoofing attack that takes advantage of the weakness of the underlying DNS. The mistake the .IO team made is just as easy to make in DNSSEC as it is with vanilla DNS.
  - AndyMcConachie 9y ago
    But if the attacker is unable to sign DNS responses, and you're validating those responses, then you're not going to have a bad time. I don't really understand your argument. I'm talking specifics and you seem to be talking about some hypothetical.

Kenji 9y ago

When I skimmed your message, I read some-sexy-ass.io. I think that would be a more likely domain for people to look up ;) EDIT: C'mon, you know I'm not wrong.

nvarsj 9y ago

Couldn't you just use letsencrypt to create arbitrary SSL certs for the io domains you now own? Then https isn't going to help you much.

JoshTriplett 9y ago
HSTS (correction: HPKP) preloading would help avoid that, and Certificate Transparency monitoring would help detect it, but yes, in general, if you control DNS for a domain, you can get a valid certificate for the domain.
- toast0 9y ago
  HSTS preloading doesn't help if you can get a Domain Validated certificate. HPKP preloading helps, but only if you pin to a CA that won't issue a DV certificate to someone who controls 4 out of 7 of the nameservers for the TLD your domain is in. And also only helps if the incident is cleaned up before the browser preload process catches the malicious server when confirming the preload. It might be a good idea to require DV certificate issuance to respect DNSSEC -- in this case, the poison nameservers wouldn't be able to sign the responses properly, and .io is DNSSEC enabled. Certificate transparency should help you know what's going on, but only if you're getting notifications through a method that's not compromised (email to your domain may not make it to you).
  - JoshTriplett 9y ago
    Edited in a correction, thanks. But also: you can pin to a specific certificate, not just a CA. > It might be a good idea to require DV certificate issuance to respect DNSSEC -- in this case, the poison nameservers wouldn't be able to sign the responses properly, and .io is DNSSEC enabled. That seems like a good idea. DNSSEC isn't perfect, but for this purpose it's better than nothing. (That said, I'd love to know where we stand on getting a better replacement for it.) > Certificate transparency should help you know what's going on, but only if you're getting notifications through a method that's not compromised (email to your domain may not make it to you). Definitely a good idea to point domain-related notifications of any kind to an email that doesn't go through that domain.
    - toast0 9y ago
      > But also: you can pin to a specific certificate, not just a CA. I think the general best practices for pinning are to pin a CA or two, and a backup key; in case your keys get compromised, you can reissue with your preferred CA; in case your CA gets delisted, you can get a cert issued with your backup key from a still trusted CA. You could have a series of keys and trust those, but it seems like that would be an easy way for you to shoot yourself in the foot.

finnn 9y ago

>HTTPS + HSTS would prevent the author from spoofing the DNS of that those sites and sending them to a server over HTTP thus avoiding the certificate errors. I'm confused, how would that help? Could the attacker (the author, in this case) not get a valid https certificate for these domains, returning spoofed DNS responses when the CA goes to validate it?

billyhoffman 9y ago
Depends, but for DV certificates, most likely. Certificate Transparency could/would help alert the original site if that was the case.
- finnn 9y ago
  yes, but HTTPS + HSTS would not enforce a certain validation level, eg you can't enforce EV certs only in HSTS (as far as I know), so a DV cert would be sufficient
theEXTORTCIST 9y ago
the attacker MITM TLS has to present a certificate for the spoofed domain that was signed by a Certificate Authority the victim's browser trusts
- discreditable 9y ago
  Very easy to do. You can even automate it with Let's Encrypt since you can serve whatever DNS records you want.

simias 9y ago

>HTTPS + HSTS would prevent the author from spoofing the DNS of that those sites and sending them to a server over HTTP thus avoiding the certificate errors. Unless I'm missing something if you own the DNS it should be trivial to get a valid HTTPS certificate for any .io domain. Then the only thing that can save you is certificate pinning. That makes me think: I wonder if you could "trick" a CA into giving you a wildcard *.io certificate when you own the TLD. Would that even be accepted by the browsers?

wolfgang42 9y ago
I believe the major web browsers all reject wildcard certs for TLDs. For more discussion: https://security.stackexchange.com/questions/6873/can-a-wildcard-ssl-certificate-be-issued-for-a-second-level-domain/6874#6874 https://security.stackexchange.com/questions/6873/can-a-wild...

deleted 9y ago

[deleted]

detaro 9y ago

HTTPS + HSTS + HPKP with restrictive settings might help against the attacker just getting another certificate.

rocqua 9y ago
Without preloading, HSTS and HPKP still have the trust-on-first-use problem.

kcorbitt 9y ago

> HTTPS + HSTS would prevent the author from spoofing the DNS of that those sites and sending them to a server over HTTP thus avoiding the certificate errors I'm not sure that's true. From a CA's perspective the attacker would own the redirected domain 4/7 tries, so they could probably convince at least one CA to issue them a valid certificate for it.

deleted 9y ago

[deleted]

mattferderer 9y ago

I feel any mention of HTTP Public Key Pinning should have the words "WARNING" surrounding it. It can take down your site if you screw it up - https://www.smashingmagazine.com/be-afraid-of-public-key-pinning/ https://www.smashingmagazine.com/be-afraid-of-public-key-pin... I also believe it is one of the more difficult security features to implement & doesn't work well with Let's Encrypt https://community.letsencrypt.org/t/hpkp-best-practices-if-you-choose-to-implement/4625 https://community.letsencrypt.org/t/hpkp-best-practices-if-y... I'm not against it and this case does seem to make me reconsider my prior risk balance assessment of implementing it.

AndyMcConachie 9y ago

The best way to protect yourself against this kind of attack is DNSSEC. Plain and simple.

rocqua 9y ago
Only if your resolver fails closed. Otherwise, an attacker can just return non-signed responses. This is all client side, as a domain owner you simply need to trust your TLD. As long as most clients don't run tight DNSSEC, you're screwed if the TLD fucks up.
- AndyMcConachie 9y ago
  .io is signed and it has a DS record in the root zone. If you're using a DNSSEC validating recursive resolver(e.g., Google, Comcast) they should replace their cached NS records from auth resolvers that don't return signed respones, with cache entries that do return signed responses. If a stub tells a recursive resolver to return a DNSSEC signed response(by setting the DO bit to 1 in the query) that recursive should keep trying to find a signed response until it has exhausted all possible NS records in the parent zone. This assumes of course that the second-level zones are also signed. So it would only protect people going to example.io if example.io was signed. If you have a .io child zone then you should sign it.
tptacek 9y ago
I dispute this, even though this seems like the one case where we're talking about an attack that actually lines up with what DNSSEC actually does. The reason is, what we're talking about is a massive misconfiguration. It's not an elaborate technical spoofing attack that takes advantage of the weakness of the underlying DNS. The mistake the .IO team made is just as easy to make in DNSSEC as it is with vanilla DNS.
- AndyMcConachie 9y ago
  But if the attacker is unable to sign DNS responses, and you're validating those responses, then you're not going to have a bad time. I don't really understand your argument. I'm talking specifics and you seem to be talking about some hypothetical.