Ü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

Ok, es handelt sich nicht um eine Software-Schwachstelle oder ein Exploit, aber trotzdem:

" Van Eck Phreaking ist das Verfahren zum Abhören des Inhalts eines CRT- und LCD-Bildschirms durch Erkennung seiner elektromagnetischen Emissionen". (Aus Wikipedia)

Einfach... wow...

Answer 2

Erst gestern habe ich von einer cleveren Methode gelesen, den Browserverlauf zu stehlen: Durch das Hinzufügen von JavaScript, das die Farbe Ihrer Links untersucht (sie ändern die Farbe der von Ihnen besuchten Websites).

Damit können Websites angegriffen werden, die der URL ein Sicherheits-Token hinzufügen (wenn dieses Token nicht zu lang ist), indem einfach alle möglichen Kombinationen ausprobiert werden.

Answer 3

Ja, ja, wir alle wissen über SQL Injection Bescheid - und wir alle wissen, wie man sich dagegen schützen kann, richtig?
Ihre Anwendung sollte eine Eingabevalidierung durchführen, Stored Procedures aufrufen usw. usw.

Aber wussten Sie, dass in bestimmten Situationen, SQL-Schmuggel das alles einfach umgehen kann?
Das Schockierendste daran ist, dass dies durch eine wenig bekannte, meist nicht dokumentierte "Funktion" in einigen Datenbanken, Frameworks, DB-Objekten usw. verursacht wird. Kurz gesagt - die Datenbank (oder die Rohrleitungen auf dem Weg dorthin) könnte Ihnen den Gefallen tun, ein unbekanntes Zeichen fröhlich - und geräuschlos - in ein anderes zu übersetzen! Zum Beispiel könnte das Unicode-Zeichen U+CABC zu einem Anführungszeichen (U+0027) werden, das Sie in Ihrer Anwendung zu blockieren versuchten, aber leider hat die DB beschlossen, es zu erzeugen und dem Angreifer zu erlauben, seinen SQLi-Angriff direkt durch Ihre Abwehr hindurch zu starten.

Ja, ich habe den verlinkten Artikel veröffentlicht, aber als ich dieses Verhalten ursprünglich entdeckte, habe ich war schockiert.

Answer 4

Blue Pill Hypervisor-Rootkit .

Answer 5

Einer der am wenigsten ausgeklügelten Angriffe, die ich je gesehen habe, war einer der effektivsten. Ein mir bekannter Tester arbeitete am Test einer VB6-Anwendung unter Win98. Die Anwendung war so aufgebaut, dass sie sich in einem Fenster mit fester Größe öffnete. Der schlaue Tester erstellte eine Verknüpfung zu der Anwendung und stellte die Verknüpfung so ein, dass die Anwendung maximiert geöffnet wurde. Als die Anwendung in einer viel größeren Größe geöffnet wurde, als der Entwickler jemals beabsichtigt hatte, wurde ein Datensteuerelement sichtbar, das normalerweise nicht sichtbar wäre. Durch manuelles Klicken auf das Datensteuerelement gelang es dem Tester, zu einem Datensatz zu gelangen, den er nicht hätte sehen dürfen, und ihn zu ändern...