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