| M | D | M | D | F | S | S |
|---|---|---|---|---|---|---|
| « Feb | ||||||
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | ||||
Soso, in der DNS-Rootzone gibt es also jetzt DNSSEC.
Ich muß mal darüber nachdenken ob das schon direkte Auswirkungen auf die von-der-Laienschen-Stoppschilder hat. Digital signierte DNS-Antworten sollten sich ja nicht mehr fälschen lassen. Oder kann/darf der DNS-Server meines Providers on-the-fly Signaturen fälschen, wenn er die Antwort manipuliert?
Wer auf einem der letzten Chaos Communication Congress war, erinnert sich sicher noch an die Vorträge von Dan Kaminsky. Eines seiner Themen ist immer wieder der böse Internetprovider, der Daten während des Transfers verändert. Gut, in UK sind wir mit Phorm bald soweit, aber Dan ist auf ein anderes aktuelles Problem gestoßen.
Viele Provider in den USA leiten Domains die es nicht gibt auf eigene Seiten um, die dann munter Werbung einblenden. Wir hatten das Problem schon einmal bei Verisign, die alle ungültigen .com-Domains auf ihre Seiten umgeleitet haben. Bei den Providern wird es jedoch noch schlimmer. Hier werden nicht nur komplett unbekannte Domains abgefangen sondern auch Subdomains oder Tippfehler, beispielsweise ww.example.com (man beachte das fehlende “w”). Das kann ganz schön unangenehm werden, beispielsweise mit Persistent Cookies die für eine ganze Domain gelten (also z.B. google.com) und dadurch vom Provider (oder dem Adbroker der die Werbung einblendet) abgefangen werden können.
Dan Kaminsky hat das auf der Toorcon auch schön vorgeführt.
Langsam fange ich an, mir Sorgen zu machen. Wenn schon die Internetprovider solche Schweinereien anfangen. Wie war das mit der alternativen DNS-Infrastruktur?
Dan Kaminsky war natürlich auch wieder da und hat in seinem Vortrag zu DNS Rebinding die Themen vom Camp wieder aufgewärmt. Ich will das gar nicht alles wiederholen. Wenigstens stand nicht mehr Black Hat auf den Folien. Lediglich ein paar Notizen für mich selbst:
Browser-Angriffe:
DNS Rebinding Angriff:
Und das ist alles innerhalb der “Same Origin Policy” erlaubt.
Außerdem zum DNS-Rebinding nochmal die DNS-Tricks:
Das CNAME-Verfahren geht so:
Eigentlich ganz einfach 
Ach ja, HaXe muß ich mir auch mal ankucken.
Nachdem die Zonendaten von Arcor offensichtlich frei zum Download angeboten werden (ein irgendwie gearteter Schutz wie ihn z.B. § 202a StGB fordert ist nicht zu erkennen) habe ich mir mal ein paar Gedanken gemacht.
Welche Zonen verwaltet Arcor?
Problem: Wie kommt man an Domains, die von Arcor entweder komplett gehostet werden oder zu denen von Arcor zumindest der Secondary bereitgestellt wird?
DeNIC kann man leider (zum Glück?) fast vergessen. Ein Zonentransfer der gesamten de-Zone ist nicht möglich, es bliebe lediglich, über ein Script die technischen Daten der diversen Domains unterhalb .de abzufragen. Dort steht nämlich der für die jeweilige Zone autoritative Nameserver und wenn dort die Arcor-Server auftauchen, ist ein Zonentransfer möglich. Nur verwaltet DeNIC inzwischen 11.482.128 Domains (Stand 13.11.07, 23:05), da dauern die Abfragen dann leider etwas länger. Sehr unbefriedigend.
Bei RIPE gibt es ein paar mehr Möglichkeiten. Immerhin gibt es dort eine Menge Suchmöglichkeiten, nur halt leider nicht so recht für DNS. Es gibt zwar einen RIPE-Eintrag “mnt-domains”, da steht dann auch gerne mal “ARCOR-MNT” drin aber leider läßt sich nach diesem Feld auch in der Advanced Suche nicht suchen. Ich vermute ja mal, ARCOR-MNT bedeutet, diese Daten werden von Arcor als Maintainer verwaltet. Nach den Netzwerk-Veraltern (”mnt-by”) läßt sich jedoch suchen, also muß diese Alternative herhalten. RIPE zeigt zwar nur 100 Einträge an, das reicht aber erstmal für eine erste Auswertung.
Ergebnis der Auswertung
Die meisten Unternehmen deren Netze bei Arcor liegen lassen auch die Domains von Arcor mitverwalten. Von ca. 50 untersuchten Unternehmen konnte ich immerhin 41 Zonenfiles ergattern. Von diesen enthalten wiederum 5 Zonenfiles interne private IP-Adressen oder sonstige interne Daten.
Zone “sdata.de”:
Hier wimmelt es nur so von internen IP-Adressen, eine kleine Auswahl:
luna A 192.168.33.67
obsidian A 192.168.33.68
rbsoft A 192.168.32.10
sisko A 192.168.33.65
wl100 A 192.168.133.100
wl101 A 192.168.133.101
wl102 A 192.168.133.102
wl103 A 192.168.133.103
wl104 A 192.168.133.104
Zone “spd.de”:
Auch hier gehen die privaten IP-Adressen nicht so schnell aus:
it-forum A 10.0.0.75
kis A 10.0.0.31
kis2 A 10.0.0.32
zeiterfassung A 10.0.0.56
Oha, die SPD läßt stempeln? Kein Vertrauen zu den ausgebeuteten Mitarbeitern der Arbeiterklasse?
vpngate A 195.50.146.134
webmail A 195.50.146.135
koalitionsvertrag A 195.227.129.132
Aha, hier kann man vielleicht den Koalitionsvertrag runterladen? Heute ist übrigens Franz Müntefering (lesenswerter Link!) zurückgetreten. Fehlen noch Schäuble, Jung, Zypris und Merkel.
Zone “insiders.de”:
Das ist eine besonders schöne Zone, hier hat ein Angreifer bestimmt viel Freude:
_msdcs NS nebukadnezar.insiders.de
_gc._tcp.Standardname-des-ersten-Standorts._sites SRV priority=0, weight=100, port=3268, jukebox.insiders.de
_gc._tcp.Standardname-des-ersten-Standorts._sites SRV priority=0, weight=100, port=3268, nebukadnezar.insiders.de
_kerberos._tcp.Standardname-des-ersten-Standorts._sites SRV priority=0, weight=100, port=88, jukebox.insiders.de
_kerberos._tcp.Standardname-des-ersten-Standorts._sites SRV priority=0, weight=100, port=88, nebukadnezar.insiders.de
_ldap._tcp.Standardname-des-ersten-Standorts._sites SRV priority=0, weight=100, port=389, jukebox.insiders.de
_ldap._tcp.Standardname-des-ersten-Standorts._sites SRV priority=0, weight=100, port=389, nebukadnezar.insiders.de
_ldap._tcp SRV priority=0, weight=100, port=389, jukebox.insiders.de
_ldap._tcp SRV priority=0, weight=100, port=389, nebukadnezar.insiders.de
_kerberos._udp SRV priority=0, weight=100, port=88, jukebox.insiders.de
_kerberos._udp SRV priority=0, weight=100, port=88, nebukadnezar.insiders.de
_kpasswd._udp SRV priority=0, weight=100, port=464, jukebox.insiders.de
_kpasswd._udp SRV priority=0, weight=100, port=464, nebukadnezar.insiders.de
jukebox A 193.22.3.16
nebukadnezar A 193.22.3.42
Für mich sieht das verdächtig nach zwei Domaincontrollern aus. Den Merowinger, Trinity und Neo gibt es in diesem Netz übrigens auch. Ein paar private Adressen fanden sich zum Schluß sowieso noch:
siemens A 192.168.22.23
Zone “tzdresden.de”:
Ein Eintrag ist mir in dieser Zone noch nicht ganz klar geworden:
b161f236-d9a2-43f4-bc8f-e9ba60373639._msdcs CNAME innovativ.tzdresden.de
Kann mir jemand mal bitte die Nummer erklären?
Und noch etwas sinnlose Statistik
Da die Gesamtdatenmenge etwas zu klein ist, sind die folgenden Aussagen natürlich Unsinn … aber amüsant.
Wer weitere Daten aus den Arcor-Zonenfiles zusammenträgt darf mir gerne eine Mail schicken …
C:\>nslookup
> set type=NS
> arcor.de
Server: dns1.meinprovider.de
Address: 1xx.7.30.125
Nicht autorisierte Antwort:
arcor.de nameserver = ns2.arcor-ip.de
arcor.de nameserver = ns3.arcor-ip.de
arcor.de nameserver = ns1.arcor-ip.de
ns3.arcor-ip.de internet address = 145.253.3.171
ns2.arcor-ip.de internet address = 145.253.2.80
ns1.arcor-ip.de internet address = 145.253.2.19
> server ns1.arcor-ip.de
Standardserver: ns1.arcor-ip.de
Address: 145.253.2.19
> ls -d arcor.de > arcor-zone.txt
[ns1.arcor-ip.de]
#
Erhalten 388 Eintrags.
>
Sehr schön, man kann sich auf einen Schlag die komplette Arcor-Zone ziehen. Das betrifft übrigens gerade alle Arcor-Kunden, deren Secondary DNS-Server auf einem der drei Arcor-Nameserver gespeichert ist.
Der L-Root-Server, betrieben von ICANN bekommt eine neue IP-Adresse. Das ist nicht so ganz ohne, weil die diversen Hint-Files in den Nameservern normalerweise manuell gepflegt werden und deshalb jetzt sehr viele DNS-Server manuell aktualisiert werden müssen. Zum Glück kommt das nicht allzu oft vor und es gibt ja noch 12 andere Server
Jedenfalls … hier die aktuell gültige Liste (auch zum bequemen nachkucken für mich selbst):
; formerly NS.INTERNIC.NET
. 3600000 IN NS A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4
;
; formerly NS1.ISI.EDU
. 3600000 NS B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET. 3600000 A 192.228.79.201
;
; formerly C.PSI.NET
. 3600000 NS C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12
;
; formerly TERP.UMD.EDU
. 3600000 NS D.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90
;
; formerly NS.NASA.GOV
. 3600000 NS E.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10
;
; formerly NS.ISC.ORG
. 3600000 NS F.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241
;
; formerly NS.NIC.DDN.MIL
. 3600000 NS G.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4
;
; formerly AOS.ARL.ARMY.MIL
. 3600000 NS H.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET. 3600000 A 128.63.2.53
;
; formerly NIC.NORDU.NET
. 3600000 NS I.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17
;
; operated by VeriSign, Inc.
. 3600000 NS J.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET. 3600000 A 192.58.128.30
;
; operated by RIPE NCC
. 3600000 NS K.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET. 3600000 A 193.0.14.129
;
; operated by ICANN
. 3600000 NS L.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET. 3600000 A 199.7.83.42
;
; operated by WIDE
. 3600000 NS M.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33
Der notorische Dan Kaminsky mit seinen jährlichen Black Ops. Ich frage mich ja, was er dann auf dem Congress im Dezember bringt, weil da kann er seine Black Hat Slides nicht schon wieder recyceln. Das gab übrigens ganz schön Buh-Rufe von den Zuhörern, daß auf den Slides nicht mal “Black Hat Conference” durch “Chaos Communication Camp” ausgetauscht war. Ich frag mich ja, was eigentlich originäre Arbeit von Dan in den Präsentationen ist und was er so zugetragen bekommt. Beim Thema Flash-Vulnerabilites fand ich den Vortrag von Fukami inhaltlich um Klassen besser. Nur die Show und das gehample auf der Bühne hat Dan besser drauf.
Angriffe mit Flash und DNS Rebinding
Jedenfalls hat Dan das Thema Flash und DNS Rebinding wieder aufgegriffen und ein wenig genauer erklärt. Das Problem wurde wohl erstmals 1996 als Princeton Attack veröffentlicht und für Flash von Dan Boneh von der Stanford University genauer untersucht. Zurückzuführen läßt sich das alles auf die “Same Origin Policy”, die davon ausgeht, daß eine Datenquelle mit einem Rechnernamen identisch ist. Nur stammen die Daten von einer IP-Adresse und der Rechnername aus DNS. Und die DNS-Einträge lassen sich schnell mal ändern. Zu einem Zeitpunkt zeigt www.example.com auf einen Webserver und lädt die Flash-Applikation, zu einem späteren Zeitpunkt (nur Sekunden später) auf eine private interne IP-Adresse und führt einen Angriff aus. Damit läßt sich natürlich sehr schön jede Firewall umgehen.
Dan unterscheidet zwischen Angriffen Level 1 (nur der Browser ist betroffen), Level 2 (Web-Plugins werden zum Angriff verwendet) und Level 3 (Plugins mit Socket-Funktion werden verwendet, Angriffe in das LAN sind möglich). Sockets finden sich beispielsweise in Flash und Java. Java war übrigens das Originalziel der Princeton Attacke von ‘96.
Für das DNS-Rebinding sieht Dan als alter DNS-Hacker drei Möglichkeiten:
Und nun setzt Dan ein paar Bausteine zusammen. Dazu verwendet er den Browser mit einer speziellen Flash-Anwendung, den Angreifer, der über den Browser in das lokale Netz eindringen will und einen speziellen Proxy (Slirpie). Dabei handelt es sich um einen Multiprotokoll-Server, der TCP-Stream von/zum Flash, HTTP für den Browser, DNS für das Rebinding und XML-Socket zur Kontrolle der Policy unterstützt. Anscheinend hat Dan sowas programmiert, leider jedoch nicht veröffentlicht.
Mit einem Rückgriff auf Slirp (1995) und PPTP ist es damit möglich, VPN über den Browser einzurichten, wobei der Browser nicht als VPN-Client sondern als VPN-Gateway dient. Scary!
Provider Hostality
Der zweite Teil des Vortrags beschäftigt sich mit der Thematik eines neutralen Netzes. Welche Möglichkeiten gibt es, um eine Provider zu entdecken, der einzelne Webseiten in seinem Netz bevorzugt transportiert und andere Seiten ausbremst oder noch schlimmer Content manipuliert in dem z.B. Werbeeinblendungen verändert werden.
Hier gab es ein paar interessante Ideen, z.B. über einen transparenten Proxy, der alle Seiten cached zu ermitteln, ob der Provider irgendwas manipuliert. Als geeignetes Werkzeug bietet sich ein Sniffer im Browser an, hier hat Dan etwas mit dem Namen “Inspector Pakket” gebastelt aber leider auch noch nicht veröffentlicht.
Mal sehen, was davon demnächst als reale Software auftaucht. So ein Metasploit als Flash im Browser um die Angriffe von innen auszuführen wäre schon cool
Die BIND-Software, der im Internet am weitesten verbreitete Nameserver mit vermutlich rund 50% Marktanteil hat einen fehlerhaften Zufallszahlengenerator. Ausgenommen ist nur die mit OpenBSD ausgelieferte BIND-Version, weil dem Entwickler die Implementierung des Zufallszahlengenerators schon damals komisch vor kam und er den vorsorglich ausgewechselt hat.
Kritisch ist das hauptsächlich, weil jede DNS-Anfrage mit einer 16-Bit Transaction ID gesichert ist und wenn die erraten werden kann, kann einem DNS-Server eine falsche Antwort mit hoher Cache-Lebenszeit untergeschoben werden. Dem DNS-Server passiert dabei nichts, aber Clients, die an diesen DNS-Server anfragen stellen, werden möglicherweise auf einen falschen Webserver umgeleitet, die Gefahr von Phishing-Angriffen steigt. Der Wikipedia Eintrag zu DNS Cache Poisoning erklärt das Problem recht anschaulich.
Mal sehen, ob uns da demnächst was um die Ohren fliegt.
Cain & Abel gilt inzwischen als eines der mächtigsten Universaltools für Windows. Dies zeigt auch die Übersicht der Top 100 Network Security Tools, auf der Cain & Abel zur Zeit auf Platz 9 geführt wird und zur vorherigen Liste 23 Plätze aufgestiegen ist.
Cain & Abel selbst ist die Vereinigung einer Vielzahl unterschiedlicher Programme unter einer gemeinsamen grafischen Oberfläche, die auch unbedarften Benutzern einige sehr komplexe Hacking-Angriffe eröffnet. So sind Funktionen wie DNS-Spoofing und ARP-Spoofing für Man-in-the-Middle Angriffe sehr einfach bedienbar, der eingebaute on-the-fly Zertifikatsgenerator erlaubt auf einfachste Weise sogar Angriffe gegen verschlüsselte HTTPS-Verbindungen.
Mein Kollege Matthias hat im Rahmen der Mitternachtshacking-Vorträge eine Präsentation zu Cain & Abel (PDF; 1,1 MB) zusammengestellt, die kurz die diversen Möglichkeiten des Programms beschreibt. Die Präsentation gibt leider nur einen Bruchteil des Abends wieder, da fast alle Funktionen praktisch ausprobiert wurden und einigen Teilnehmern dabei die Augen geöffnet wurden, wie einfach viele Angriffe doch sind.
Im Jahr 2005 haben ein Kollege und ich eine Reihe von Vorträgen zu unterschiedlichen Hacking-Themen bei CBT Training & Consulting gehalten. Diese Präsentationen wurden zeitweise auf der alten Mitternachtshacking-Seite veröffentlicht. Nach dem Redesign und weil es diese Vorträge nicht mehr gibt, wurde Mitternachtshacking.de inzwischen zum privaten Blog. Die Präsentationen möchte ich trotzdem gerne wieder hier bereitstellen, allerdings aufgrund des neuen § 202c im StGB ohne Links auf die bzw. Download der verwendeten Hacking-Tools.
Hier ist daher das erste PDF vom Januar 2005: Mitternachtshacking Firewall Tunneling (500 KB)
An diesem Abend ging es um die verschiedenen Möglichkeiten, eine Firewall zu umgehen, in dem beliebiger Datenverkehr über HTTP, HTTPS, SSH, ICMP und DNS getunnelt wird. Eine ähnliche Anleitung findet der geneigte Leser auch bei Heise.de unter dem Titel “Schleichpfade“