Überraschende Software-Schwachstellen oder Exploits?

Question

Welches sind die seltsamsten/raffiniertesten/überraschendsten/tiefsten versteckten Software-Schwachstellen oder Exploits, die Sie je gesehen haben? Stellen im Code, von denen Sie dachten, dass sich dort keine Gefahr verbirgt, aber falsch lagen?

[Zur Klarstellung: Jeder kennt SQL-Injektionen, XSS oder Pufferüberläufe - Fehler, die oft durch unvorsichtige Kodierung entstehen. Aber Dinge wie Ken Thompsons versteckter Trojaner (Reflections on Trusting Trust: http://cm.bell-labs.com/who/ken/trust.html ), die jüngste NULL-Dereferenz-Schwachstelle im Linux-Kernel ( http://isc.sans.org/diary.html?storyid=6820 ), oder ein komplexer Angriff auf RNG mit Denial of Service ( http://news.ycombinator.com/item?id=639976 ) haben mich sehr beunruhigt].

Update: Vielen Dank für alle Antworten, sie waren großartig. Ich hatte die Qual der Wahl. Letztendlich habe ich mich entschieden, das Kopfgeld für den Seitenkanal-/Stromüberwachungsangriff zu zahlen. Nichtsdestotrotz zeigen all eure Antworten zusammen, dass ich mehr über Sicherheit lernen muss, da es ein wirklich tiefes Thema ist :).

Answer 1

Mein Favorit und das beeindruckendste, was ich bisher gesehen habe, ist eine Klasse von Kryptographietechniken, die als Seitenkanal-Angriffe .

Eine Art des Seitenkanalangriffs nutzt die Leistungsüberwachung. Verschlüsselungsschlüssel wurden von Smartcard-Geräten wiederhergestellt, indem sorgfältig analysiert wurde, wie viel Strom von der Stromversorgung bezogen wird. Die eingebetteten Prozessoren verbrauchen unterschiedlich viel Strom, um verschiedene Anweisungen zu verarbeiten. Mit dieser winzigen Information ist es möglich, geschützte Daten wiederherzustellen, und zwar völlig passiv.

Answer 2

Jeder kennt SQL-Injektionen, aber eine der überraschendsten Angriffe, von denen ich kürzlich hörte, war die Einfügung von SQL-Injektionen in Strichcodes. Prüfer sollten ALLE Eingaben auf bösartiges SQL überprüfen. Ein Angreifer könnte bei einer Veranstaltung auftauchen und das Registrierungssystem zum Absturz bringen, die Preise in Geschäften ändern usw. Ich denke, dass das Hacken von Strichcodes im Allgemeinen für mich überraschend war. Das hat keinen Wow-Faktor, sondern ist nur etwas, das man beachten sollte.

EDIT: Ich hatte gerade eine Diskussion, in der die Idee aufkam, die SQL-Injektion auf einen Magnetkartenstreifen zu setzen. Ich denke, man kann sie überall anbringen, also alle Eingaben testen, vor allem die von Benutzern und diese Art von Datenspeichern.

Answer 3

Ich denke, dass eine relativ neue Linux-Schwachstelle auf Ihre Beschreibung der Ausnutzung von Code, der sicher (wenn auch etwas unstrukturiert) erscheint, zutrifft.

Dabei handelt es sich um ein Stück Code im Linux-Kernel:

struct sock *sk = tun->sk;  // initialize sk with tun->sk
…
if (!tun)
    return POLLERR;  // if tun is NULL return error

Aufgrund einer GCC-Optimierung werden die if-Anweisung und der Body entfernt (was für Userland-Code sinnvoll ist, nicht so sehr für Kernel-Code). Durch etwas Cleverness konnte eine Person daraus einen Exploit bauen.

Eine Zusammenfassung:

http://isc.sans.org/diary.html?storyid=6820

Ein veröffentlichter Exploit:

http://lists.grok.org.uk/pipermail/full-disclosure/2009-July/069714.html

EDIT : Hier finden Sie eine sehr viel ausführlichere Zusammenfassung, wie dieser Code ausgenutzt wurde. Es ist eine kurze Lektüre, aber eine sehr gute Erklärung der für den Exploit verwendeten Mechanismen.

http://lwn.net/SubscriberLink/342330/f66e8ace8a572bcb/

Answer 4

Ein klassischer Exploit war Ken Thompsons Hack, der ihm Root-Zugriff auf jedes Unix-System der Welt verschaffte.

Damals, als Bell Labs der einzige Anbieter von Unix war, verteilten sie den Quellcode, so dass jede Installation ihr eigenes Betriebssystem erstellen und anpassen konnte. Dieser Quellcode enthielt den Unix-Anmeldebefehl. Ken modifizierte den C-Compiler, um zu erkennen, ob er den Anmeldebefehl kompilierte, und fügte in diesem Fall eine anfängliche Passwortprüfung hinzu. Dieses Passwort war sein eigenes magisches Passwort und gewährte Root-Zugriff.

Natürlich würde jeder, der den Quelltext des C-Compilers liest, dies erkennen und herausnehmen. Also modifizierte Ken den C-Compiler erneut, so dass er beim Kompilieren eines C-Compilers den Logon-Hack wieder einfügte.

Jetzt kommt der verblüffende Teil: Ken kompilierte den C-Compiler mit seinem gehackten Compiler und löschte dann alle Spuren seines Hacks, indem er ihn aus dem Quellcode, den Sicherungskopien, der Versionskontrolle und allem anderen löschte. Er existierte nur noch in der kompilierten Binärdatei, die Teil der Unix-Distribution war.

Jeder, der dieses Unix von Bell Labs erhielt, bekam ein gehacktes Login und einen C-Compiler. Wenn man sich den Quellcode ansah, war es sicher. Wenn man das Betriebssystem neu erstellte, hackte der gehackte Compiler den neu erstellten Compiler, der den Hack wieder in den Anmeldebefehl einfügte.

Die Lehre, die ich daraus ziehe, ist, dass man mit keiner noch so umfangreichen statischen Analyse (Untersuchung des Quellcodes, des Betriebssystems, der Anwendungen) Sicherheit garantieren kann.

Ken hat dies in einem ACM-Artikel mit dem Titel Überlegungen zum Vertrauen in das Vertrauen .

Answer 5

Vor Jahren habe ich mir ein Programm (auf dem Acorn Archimedes) angesehen, das mit einem komplexen Verschlüsselungssystem geschützt war (nur um zu sehen, wie es gemacht wurde, und um daraus zu lernen). Es war sehr raffiniert gemacht, mit dem Entschlüsselungscode selbst als Teil des Entschlüsselungsschlüssels, so dass jeder Versuch, ihn zu manipulieren, die Entschlüsselung zerstören und somit Müll im Speicher hinterlassen würde.

Nachdem ich 2 Tage lang versucht hatte, herauszufinden, wie es gemacht wurde und wie man es umgehen konnte, besuchte mich ein Freund. Mit Hilfe eines Betriebssystem-Tools (ein Klick und ein Ziehen, um die RMA-Speicherzuweisung zu maximieren) begrenzte er den verfügbaren Arbeitsspeicher, in dem der Prozess ausgeführt werden konnte, auf eine Größe, die nur geringfügig größer war als die Größe der .exe-Datei. Dann führte er ihn aus. Unmittelbar nach der Entschlüsselung versuchte er, Speicher zuzuweisen, was fehlschlug, und stürzte ab. Anschließend speicherte er das entschlüsselte Programm aus dem Speicher. Gesamtdauer des Knackens: etwa 2 Minuten, nur durch Ziehen mit der Maus und einen Speicherbefehl in der Befehlszeile.

Ich habe daraus gelernt, dass es sich nicht lohnt, zu viel Zeit und Mühe in den Schutz Ihrer Software zu investieren - wenn jemand sie knacken will, wird er es tun, und zwar wahrscheinlich mit einer einfachen Methode, die Ihnen nie in den Sinn gekommen wäre.

(Haftungsausschluss: Wir hatten beide legale Kopien dieses Programms gekauft und den geknackten Code nie in irgendeiner Weise verwendet. Es war wirklich nur eine intellektuelle Programmierübung)