‎W724V Typ C: Falsche DNSSEC Antworten werden als korrekt weitergegeben

Telekom hilft Community

Telekom Business Community

Privatkunden

Telekom Shops

Kontakt

Gelöst

W724V Typ C: Falsche DNSSEC Antworten werden als korrekt weitergegeben

vor 8 Jahren

Anlässlich des bevorstehende Tausch des KSK in der DNS Root Zone habe ich mal die DNSSEC Fähigkeiten meines privaten Telekom VDSL Anschlusses überprüft:

Der DNS-Resolver im W724V Typ C (aktuelle FW 09011603.05.012) behandelt falsch signierte DNS Antworten wie korrekt signierte. Als Testfall eignet sich die bewusst falsch signierte Domain fail05.dnssec.works. Hier getestet unter Windows 10 mit dem Cygwin Port von dig 9.11.0-P3.

Die erste Anfrage sollte eigentlich schon SERVFAIL liefern, löst aber den Namen auf:

$ dig @192.168.2.1 fail05.dnssec.works
...
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51569
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
...
;; ANSWER SECTION:
fail05.dnssec.works.    3600    IN      A       5.45.109.212

Die zweite Antwort aus dem DNS- Cache ist noch schlimmer. Das AD (Authenticated Data) Flag ist jetzt gesetzt. Die Antwort signalisiert also, dass die DNS Signatur des A Records verifiziert wurde:

$ dig @192.168.2.1 fail05.dnssec.works
...
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37179
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
...
;; ANSWER SECTION:
fail05.dnssec.works.    3589    IN      A       5.45.109.212

Beide im Speedport eingetragenden DNS-Forwarder der Telekom (217.237.150.115, 217.237.151.205) verhalten sich wie erwartet.

Eine Anfrage mit Validierung liefert SERVFAIL:

$ dig @217.237.151.205 fail05.dnssec.works
...
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 32706
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
...

Eine Anfrage ohne Validierung (CD: Checking Disabled) liefert eine Antwort, aber ohne gesetztes AD Flag:

$ dig @217.237.151.205 +cdflag fail05.dnssec.works
...
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32613
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
...
;; ANSWER SECTION:
fail05.dnssec.works.    3600    IN      A       5.45.109.212
...

Scheinbar fordert der Speedport von der eingetragenen Forwardern immer nicht validierte Antworten an, und gibt sie dann (ab der 2. Anfrage) sogar als validiert weiter. Das geht doch wohl garnicht, oder?

570

vor 8 Jahren
Ich habe mal ein wenig gespielt.
Konsistent sieht das nicht aus:
475] hostaddr dnssec arg: dnssec name: dnssec.lokal.biz addr: 72.52.4.122 476] hostaddr lokal.biz arg: lokal.biz name: lokal.biz addr: 72.52.4.122 477] hostaddr 72.52.4.122 arg: 72.52.4.122 name: a72-52-4-122.deploy.static.akamaitechnologies.com addr: 72.52.4.122
478] hostaddr 5.45.109.212 arg: 5.45.109.212 name: ipv6gw.strotmann.de addr: 5.45.109.212 479] hostaddr strotmann.de arg: strotmann.de name: strotmann.de addr: 37.120.183.122 480] hostaddr ipv6gw.strotmann.de arg: ipv6gw.strotmann.de name: ipv6gw.strotmann.de addr: 5.45.109.212 481] hostaddr schellong.de arg: schellong.de name: schellong.de addr: 217.160.231.191 482] hostaddr schellon.de arg: schellon.de name: schellon.de addr: 62.138.238.45 addr: 62.138.239.45 483] hostaddr 62.138.238.45 hostaddr: Unknown host 484] hostaddr 62.138.239.45 hostaddr: Unknown host 485] hostaddr 217.160.231.191 arg: 217.160.231.191 name: kundenserver.de addr: 217.160.231.191 486] hostaddr kundenserver.de arg: kundenserver.de name: kundenserver.de addr: 213.165.67.109 487] hostaddr 213.165.67.109 arg: 213.165.67.109 name: ml.kundenserver.de addr: 213.165.67.109 488]
.
4
Antwort
von
vor 7 Jahren
Hallo @Gelöschter Nutzer,

danke, dass Sie hier noch einmal auf das Thema aufmerksam gemacht haben. Das Thema Sicherheit nehmen wir als Telekom tatsächlich sehr ernst. Eine interne Anfrage zu einer möglichen Sicherheitslücke beim W 724V Typ C ist in Arbeit. Sobald ich mehr Informationen habe, melde ich mich hier.

Grüße von

Schmidti
Antwort
von
vor 7 Jahren
Hallo @Snafu42, @maglite und @Gelöschter Nutzer,

ganz herzlichen Dank nochmal für den Hinweis! Wir konnten den Fehler inzwischen verifizieren. Er wird schnellstmöglich behoben werden.

Falls dem einen oder anderen noch einmal eine mögliche Sicherheitslücke auffällt, kann er sich sehr gern direkt per E-Mail an unsere Abteilung für Sicherheit wenden. Die Adresse lautet cert@telekom.de.

Ich wünsche allen ein schönes Wochenende!

Grüße von

Schmidti

Antwort
von
vor 7 Jahren
Noch eine späte Rückmeldung: In den Releasenotes der Firmware v09011603-05-015 findet sich der Hinweis: "Verbesserung im Heimnetzwerk: DNS Proxy AD FLag einer DNS Query".Tatsächlich wurde das Problem beseitigt. Die falsch unterschriebene Domain löst nur noch bei gesetztem CD flag auf: $ dig @192.168.2.1 fail05.dnssec.works
...
;; ->>HEADER>HEADER...Das AD flag wird auch bei signierten Domains nicht weitergegeben. Das ist mW richtig, da der Speedport vermutlich keine eigene Validierung durchführt und keine gesicherte Verbindung zum nächsten Forwarder besteht. Am Rande interessant finde ich, dass die Domains telekom.de und t-online.de nach wie vor nicht signiert sind Siehe z.B. https://dane.sys4.de/smtp/telekom.de
Uneingeloggter Nutzer
Antwort
von
Akzeptierte Lösung
akzeptiert von
vor 7 Jahren
Hallo @Snafu42, @maglite und @Gelöschter Nutzer,

ganz herzlichen Dank nochmal für den Hinweis! Wir konnten den Fehler inzwischen verifizieren. Er wird schnellstmöglich behoben werden.

Falls dem einen oder anderen noch einmal eine mögliche Sicherheitslücke auffällt, kann er sich sehr gern direkt per E-Mail an unsere Abteilung für Sicherheit wenden. Die Adresse lautet cert@telekom.de.

Ich wünsche allen ein schönes Wochenende!

Grüße von

Schmidti

0