Find out how has been done

ritze · September 19, 2019, 7:50pm

It looks like somebody has been able to get a certificate for one of our domains. Or at least for a subdomain. The funny thing is that because of an configuration failure since May the entry of the DNS servers point to IPs that do no longer have a working DNS server. Is there any technical way to lookup how does the authorisation has worked?

stevenzhu · September 19, 2019, 8:00pm

Hi,

If you believe there’s a breach in your domain (or system), please contact security@letsencrypt.org.

Also pinging @lestaff to correct me

Thank you

mnordhoff · September 19, 2019, 8:28pm

By the way, it should be possible for you to revoke the certificate(s) yourself, with an ACME client and some work.

After validating a name, a Let's Encrypt account can currently issue certificates for 30 days. (Unless the CA is prevented from doing so by CAA records, which CAs cannot reuse for more than 8 hours.) Disabling their ACME account(s) or the authorizations would require intervention by Let's Encrypt staff.

There's not really a way for you to do it. Let's Encrypt staff can search the CA's logs. I'm not sure how much they can share.

If you're not very familiar with how ACME or Let's Encrypt work, there's general documentation about the validation methods here:

What kind of configuration failure? Were there A, AAAA, CNAME, DNAME or NS records pointing to a host or IP under someone else's control? Could they have then validated the name?

ritze · September 19, 2019, 9:21pm

The whois record for the DNS points to 2 subdomains that do not have a runing DNS server on the IPs. For sure the whole domain was not reachable. But somebody was able to get a certificate in between. Strange.

mnordhoff · September 19, 2019, 9:29pm

The IPs were under your exclusive control the whole time?

No computer or person could have validated the domain at the time the certificate was issued, or in the previous 30 days?

The TLD’s whois records show that there were zero modifications in that time period?

The TLD doesn’t have a history of compromises?

Edit:

There is not evidence of BGP hijacking of any of the IP addresses involved in that time period?

Was every zone involved secured with DNSSEC?

ritze · September 20, 2019, 6:19am

I tryed but they let me know that Letsencrypt does not provide “support” via email. Looks like issue of certificates without checking the DNS of the domain owner is normal operation

ritze · September 20, 2019, 6:29am

I did not get a notice that someting on the domain registration has changed in this time frame. But I dont know if there is a service that monitor domain changes of .RU domains. So I can not check this.

The domain of both DNS servers has no DNSSEC. Shame on me. BUT: Both DNS servers have “glue records” and as far as I know these records are secured by DNSSEC. So if Letsencrypt get a request, at least the issuer has to do an DNS lookup on our domain that should be save. Because of a configuration problem at our datacenter the DNS does not running on these IPs. So Letsencrypt would not be able to process the ACME I think. Or is there any other way that does not involve DNS requests of the domain?

stevenzhu · September 20, 2019, 6:38am

Could you please at least provide us your domain name and the certificate issued? (From certificate transparency logs like crt.sh)

Thank you

ritze · September 20, 2019, 6:45am

Oh sorry! I tryed to avoid this on a public forum because the domain is not really in use. But you are right, it is difficult to investigate if Letsencrypt does not want help with check the logs. So perhaps it would help here crt.sh | mail.respondi.ru

_az · September 20, 2019, 6:56am

That is helpful, thank you for posting your domain.

According to this tool that tracks historical DNS, the domain did have an valid configured A record up until 2019-07-23.

The latest certificate for your domain was issued on 2019-07-11, which is during the period where there was valid DNS.

So from what I can see, it is still possible that Let’s Encrypt performed proper authorization of the order.

ritze · September 20, 2019, 7:27am

Thank you for the hint with historical DNS data. Was really helpfull! The IP (only port 80, 8080 and 443) has been used by one of our developers at this time. I fear he has simply done a lookup of a domain that points to this IP and than used it to get a valid certificate for testing.

mnordhoff · September 20, 2019, 5:49pm

For what it's worth, glue records aren't signed.

If you're using DNSSEC, your authoritative A and AAAA and NS records are signed, but the TLD's non-authoritative A, AAAA and NS records sent in the referral are not.

(The DS record set is signed, of course.)

For example:

$ dig +dnssec +norecurse @b.gtld-servers.net powerdns.com

; <<>> DiG 9.15.1-Ubuntu <<>> +dnssec +norecurse @b.gtld-servers.net powerdns.com
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35249
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;powerdns.com.                  IN      A

;; AUTHORITY SECTION:
powerdns.com.           172800  IN      NS      pdns-public-ns1.powerdns.com.
powerdns.com.           172800  IN      NS      pdns-public-ns2.powerdns.com.
powerdns.com.           86400   IN      DS      44030 8 1 B763646757DF621DD1204AD3BFA0675B49BE3279
powerdns.com.           86400   IN      DS      44030 8 3 7DD75AE1565051F9563CF8DF976AC99CDCA51E3463019C81BD2BB083 82F3854E
powerdns.com.           86400   IN      DS      44030 8 2 D4C3D5552B8679FAEEBC317E5F048B614B2E5F607DC57F1553182D49 AB2179F7
powerdns.com.           86400   IN      RRSIG   DS 8 2 86400 20190925042307 20190918031307 17708 com. lg0t8/7gL2l1D2BsAfRrxY2DyWtCrEIOl/LRcb5hrzin1ACsw9HVQYQw rqbUJqpm0hPPViByKe1WLUG6r5+KTf/CYieBoIuyraNR5VuHJQ4nZyfM X/0u2UA2047nqw7a9tEvk2Kh6d6fOO0/PuUudKwUTsxTekXagvsZM93Q 1m8=

;; ADDITIONAL SECTION:
pdns-public-ns1.powerdns.com. 172800 IN A       188.166.104.87
pdns-public-ns1.powerdns.com. 172800 IN AAAA    2a03:b0c0:2:d0::4af:b001
pdns-public-ns2.powerdns.com. 172800 IN AAAA    2604:a880:1:20::132:5001
pdns-public-ns2.powerdns.com. 172800 IN A       45.55.10.200

;; Query time: 2 msec
;; SERVER: 2001:503:231d::2:30#53(2001:503:231d::2:30)
;; WHEN: Fri Sep 20 17:43:23 UTC 2019
;; MSG SIZE  rcvd: 484

$ dig +dnssec pdns-public-ns1.powerdns.com aaaa

; <<>> DiG 9.15.1-Ubuntu <<>> +dnssec pdns-public-ns1.powerdns.com aaaa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51596
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;pdns-public-ns1.powerdns.com.  IN      AAAA

;; ANSWER SECTION:
pdns-public-ns1.powerdns.com. 3600 IN   AAAA    2a03:b0c0:2:d0::4af:b001
pdns-public-ns1.powerdns.com. 3600 IN   RRSIG   AAAA 8 3 3600 20191003000000 20190912000000 36021 powerdns.com. blK/UeCoIEg6gu/pMMVI3O++DtSYb3rUr7cU/jFBFAQlwR4XLkUjallS 1n+7otquJylekN6MO3JOVgC4y6edqdAFJEqMI4jZhMyrfFpm1SVBNwtm 93Y0wsZthPOY9sHaP0ixhRRCQXQbYDnHAoECN61TubicuE2hacZ2fXKb aGk=

;; Query time: 68 msec
;; SERVER: ::1#53(::1)
;; WHEN: Fri Sep 20 17:47:49 UTC 2019
;; MSG SIZE  rcvd: 257

system · October 20, 2019, 6:03pm

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.