summaryrefslogtreecommitdiff
path: root/updates/2014/cache-poisoning-attack.md
diff options
context:
space:
mode:
authorerdgeist <erdgeist@erdgeist.org>2014-02-12 16:54:01 +0000
committererdgeist <erdgeist@erdgeist.org>2020-05-23 13:39:35 +0000
commit47bd759a2af8492596194cb67ca62f0a143629d3 (patch)
treef8e29b1ab2edb3d81e1f79d52a6b9b57ebb2106f /updates/2014/cache-poisoning-attack.md
parentce6a7c85c3f72921ffe9cde6e18dd3ccfd1ebcdc (diff)
committing page revision 1
Diffstat (limited to 'updates/2014/cache-poisoning-attack.md')
-rw-r--r--updates/2014/cache-poisoning-attack.md143
1 files changed, 143 insertions, 0 deletions
diff --git a/updates/2014/cache-poisoning-attack.md b/updates/2014/cache-poisoning-attack.md
new file mode 100644
index 00000000..b3c8dfc0
--- /dev/null
+++ b/updates/2014/cache-poisoning-attack.md
@@ -0,0 +1,143 @@
1title: Cache Poisoning Attack auf offenen DNS-Resolver des CCC Berlin
2date: 2014-02-12 16:34:00
3updated: 2014-02-12 16:54:01
4author: erdgeist
5tags: update
6
7Der vom Chaos Computer Club (CCC) betriebene offene DNS-Resolver war heute früh Ziel eines Angriffs Unbekannter, die durch das Ausnutzen von Schwächen im DNS-Protokoll den Zwischenspeicher des Programms mit gefälschten Einträgen befüllten. In der Folge wurden diese fehlerhafte Antworten auf Anfragen nach bestimmten Domains an alle Benutzer ausgegeben, die den DNS-Server des CCC in ihren Systemen eingetragen haben. Zu keiner Zeit konnten sich die Angreifer Zugang zum Server verschaffen. Als Reaktion hat der CCC eine neue Software installiert, die nicht für die Attacken anfällig ist.
8
9TL;DR: Patch für dnscache 1.0.5 einspielen.
10
11<!-- TEASER_END -->
12
13## Was ist DNS
14
15Ans Internet angeschlossene Computer adressieren sich gegenseitig
16mittels für Menschen mehr oder minder bedeutungslos scheinender Adressen
17wie z. B. 2a00:1328:e102:ccc0::122 oder 213.73.89.123. Um einfach
18merkbare Namen wie www.ccc.de in diese Maschinenadressen umzusetzen,
19wurde das Domain Name System geschaffen. Es handelt sich bei DNS um eine
20hierarchisch verteilte Datenbank. So ist z. B. für alle Namen die auf
21.de enden, die deutsche Genossenschaft DeNIC e.G. zuständig. Diese
22delegiert die Zuständigkeit für z. B. ccc.de an den Chaos Computer Club.
23Auf technischer Ebene erfolgt dies durch einen Datenbankeintrag bei der
24DeNIC, der für alle Internetteilnehmer einsehbar ist.
25
26Wenn man einen der DNS-Server der DeNIC nach ccc.de fragt, antwortet
27dieser: "Liegt auf ns.ccc.de, und der hat die IP-Adresse 212.12.48.1".
28Der Server ns.ccc.de, also der mit der Adresse 212.12.48.1, betreibt
29eine ebensolche Datenbank, nur ist diese kleiner und enthält nur
30Einträge für Namen die in .ccc.de enden. Wird dieser Server nun nach
31www.ccc.de gefragt wird, antwortet dieser mit: "Das liegt hier:
322a00:1328:e102:ccc0::122 oder hier: 213.73.89.123". Diese Antwort hilft
33nun z. B. dem Browser eines Besuchers von www.ccc.de, der eine
34Verbindung zum Server "2a00:1328:e102:ccc0::122" herstellen kann. Damit
35nun nicht jedesmal immer erst die DeNIC und dann der CCC-DNS-Server
36gefragt werden muss, gibt es – meist bei Providern, doch zu deren
37Zuverlässigkeit später mehr – DNS-Resolver. Ein DNS-Resolver macht
38nichts anderes, als Anfragen von Nutzern entgegen zu nehmen und im
39Hintergrund die oben genannten Schritte zu vollziehen. Er erspart zum
40einen den langen Weg ab und speichert zum anderen die Ergebnisse für
41einen bestimmten Zeitraum zwischen, um sie später bei einer identischen
42Anfrage eines weiteren Nutzers schneller ausliefern zu können und keine
43Anfrage an die ranghöheren Server stellen zu müssen. DNS-Server spielen
44also eine zentrale Rolle in der täglichen Nutzung des Internets. Dies
45macht sie zu begehrten Zielen; sowohl für zensurfreudige Regierungen als
46auch für andere Bösewichte, die sie gerne zu Angriffen benutzen würden.
47
48## Geschichte der Netzsperren in Deutschland
49
50Bereits 1996 forderte die Bundesanwaltschaft das Deutsche Forschungsnetz
51(DFN-Verein \[1\]) auf, eine Internetseite zu sperren. Durch die
52IP-Sperrung des niederländischen Providers XS4ALL wurden sämtliche
53dortigen Webseiten dem Zugriff aus deutschen Forschungseinrichtungen
54entzogen. Ab Anfang 2002 erzwang die Bezirksregierung Düsseldorf unter
55ihrem Regierungspräsidenten Büssow mittels einer Sperrverfügung die
56DNS-Sperrung von Webseiten bei dutzenden Zugangsanbietern. Der Chaos
57Computer Club verwies bereits damals auf die Gefahr für das Netz, die
58durch solche technischen Zensurmaßnahmen erwächst. Sobald eine
59technische Möglichkeit entwickelt wurde, wird sie nicht mehr nur dort
60und für den ursprünglichen Zweck benutzt, wie sich durch bei Wikileaks
61veröffentlichte Zensurlisten aus verschiedenen, auch nichtdemokratischen
62Staaten zeigte. Aus Sicht des Clubs sollen technische Infrastrukturen
63nicht durch gezielte Manipulation geschwächt werden. Neben politischen
64Forderungen hat der CCC daher durch Bereitstellung einer Vielzahl von
65technischen Mitteln an der Gewährleistung der Integrität und
66Vertraulichkeit informationstechnischer Systeme mitgewirkt. Beispiele
67hierfür sind der Betrieb von Knotenpunkten im Anonymisierungsnetzwerk
68Tor sowie eben jenes offenen DNS-Resolvers.
69
70## Was ist cache poisoning
71
72Im konkreten Fall von dnscache.berlin.ccc.de wurde die Software dnscache
73\[2\] des US-amerikanischen Hochschullehrers Dan J. Bernstein \[3\]
74eingesetzt. Es handelt sich hierbei um eine sehr schlanke und sicherere
75Implementierung eines DNS-Resolvers. Bisher sind keine Schwachstellen
76bekannt geworden, die eine Kompromitierung des Servers erlauben, auf der
77sie läuft. Allerdings sind die in der DNS-Implementierung vorgesehenen
78Mechanismen, die vor einem sogenannten cache-poisoning-Angriff schützen
79sollen, nicht mehr zeitgemäß. Um erfolgreich einen gefälschten Eintrag
80zu platzieren, muss der Angreifer die zufällig vom Server ausgewählte
81Portnummer sowie die Transaktions-ID erraten. Bei einer einzelnen
82Anfrage ist dies sehr unwahrscheinlich, da es sich um eine Chance von 1
83zu 2×10⁹ handelt. Diese wird bei dnscache jedoch erheblich reduziert, da
84mehrere parallele identische Anfragen möglich sind. Ein erfolgreicher
85Angriff ist unter realistischen Bedingungen in unter zwanzig Minuten mit
86einer Bandbreite von nur 10MBit/s realisierbar. \[4\] Gegenmaßnahmen,
87die einen solchen Angriff vereiteln, wurden leider nie in die von Dan J.
88Bernstein veröffentlichte Software eingearbeitet, sondern sind lediglich
89von anderen Autoren veröffentlicht worden \[5\].
90
91Jedem dnscache-Betreiber sei die Verwendung dieser patches an dieser
92Stelle wärmstens ans Herz gelegt. Der CCC Berlin hat die Gelegenheit
93dazu genutzt, auf eine Neuentwicklung umzusteigen und setzt nunmehr die
94Software unbound\[6\] ein, die mit Unterstützung führender
95DNS-Infrastrukturbetreiber als Ersatz für die ursprüngliche DNS-Software
96BIND\[7\] geschaffen wurde und fortwährend weiterentwickelt wird. Sie
97bietet zeitgemäße und flexible Konfigurationsoptionen, insbesondere
98gegen verschiedene Angriffsmuster wie cache-poisoning und DNS-Verstärkte
99"Denial of Service"-Angriffe\[8\].
100
101Solange DNS-Antworten nicht signiert\[9\] sind, ist es für den
102betroffenen Nameserver nicht ohne Weiteres möglich, echte von
103gefälschten Antworten zu unterscheiden. Jeder recursive resolving
104nameserver ist daher mehr oder weniger anfällig gegen diese Art des
105Angriffs. Es gibt durchaus Gegenmaßnahmen, die Angriffe auf das
106Protokoll – wie cache poisoning – erheblich erschweren, jedoch besteht
107auch hier mangels der Verifizierbarkeit der Antworten keine absolute
108Sicherheit. Ein Angreifer wird sich in jedem Fall vorher die Reichweite,
109also das Erfolgspotenzial seines Angriffs ansehen. Daher sind rege
110genutzte Resolver grundsätzlich attraktivere Ziele. Dem kann man
111letztenendes nur durch dezentralisierte Infrastruktur vorbeugen. Je
112dezentraler die Infrastruktur ist, desto schwieriger werden derlei
113Angriffe, da die Anzahl der Opfer eher begrenzt ist. Aufgrund der
114geltenden Rechtslage sind Anbieter von DNS-Diensten einerseits dazu
115verpflichtet, das Telekommunikationsgeheimnis zu wahren und dürfen keine
116Kenntnis der Begleitumstände nehmen, andererseits sind sie aufgrund des
117Providerprivilegs im Gegenzug auch nicht für die übermittelten Inhalte
118haftbar. In der Folge können lediglich statistische Anomalien zur
119Fehlererkennung benutzt werden.
120
121Grundsätzlich zeigt sich hier die Stärke offener Protokolle und freier,
122quelloffener Software. Während in proprietären Umgebungen die Entdeckung
123von Sicherheitslücken schwierig ist, und die Hersteller oftmals Monate
124brauchen, um eine Produktrevision zu veröffentlichen, kann bei
125quelloffener Software eine Veränderung leichter und schneller eingebaut
126werden. Durch offen standardisierte und patentfreie Protokolle gibt es
127darüberhinaus Wettbewerb der Produkte und die Möglichkeit zur laufenden
128Modernisierung der Infrastrukturkomponenten.
129
130## Links und weiterführende Informationen
131
132- \[0\]
133 <http://de.wikipedia.org/wiki/Sperrungen_von_Internetinhalten_in_Deutschland>
134- \[1\] <http://www.dfn.de>
135- \[2\] <http://cr.yp.to/djbdns/dnscache.html>
136- \[3\] <https://en.wikipedia.org/wiki/Daniel_J._Bernstein>
137- \[4\] <http://www.your.org/dnscache/djbdns.pdf>
138- \[5\] <http://www.your.org/dnscache/>
139- \[6\] <http://unbound.net/>
140- \[7\] <http://en.wikipedia.org/wiki/BIND>
141- \[8\]
142 <http://en.wikipedia.org/wiki/Denial-of-service_attack#Reflected_.2F_Spoofed_attack>
143- \[9\] <http://dnscurve.org/forgery.html>