Exploit

aus Wikipedia, der freien Enzyklopädie
(Weitergeleitet von 0-Day-Exploit)
Zur Navigation springen Zur Suche springen

Ein Exploit (englisch to exploit ‚ausnutzen‘) ist in der elektronischen Datenverarbeitung eine systematische Möglichkeit, Schwachstellen auszunutzen, die bei der Entwicklung eines Programms entstanden sind. Dabei werden mit Hilfe von Programmcodes Sicherheitslücken und Fehlfunktionen von Programmen (oder ganzen Systemen) ausgenutzt, meist, um sich Zugang zu Ressourcen zu verschaffen oder in Computersysteme einzudringen bzw. diese zu beeinträchtigen. Als Zero-Day-Exploit wird die Ausnutzung einer Sicherheitslücke bezeichnet, für die noch kein Patch des Herstellers der Komponente verfügbar ist.

Ein Exploit wird oft auch nur zum Aufzeigen einer Sicherheitslücke entwickelt und dokumentiert. Damit soll erreicht werden, dass Softwarehersteller eine Sicherheitslücke schneller erkennen und schließen können. Oft bezeichnet man die reine Beschreibung eines Exploits bereits als Exploit.

Exploits machen sich zum Beispiel die Tatsache zunutze, dass Computer mit Von-Neumann-Architektur, das sind nahezu alle Heim- und Bürorechner, nicht zwischen Programmcode und Nutzdaten unterscheiden. So wird zum Beispiel bei einem Pufferüberlauf der Code des Angreifers in einen nicht dafür vorgesehenen Speicherbereich geschrieben, wodurch die Ausführung der Anwendung manipuliert werden kann. Eine andere Möglichkeit sind Formatstring-Angriffe, bei denen ungefiltert Benutzereingaben an Formatierungsfunktionen wie printf() übergeben werden. Ein Angreifer kann oft einen eigenen Code zur Ausführung bringen, der ihm beispielsweise eine Shell mit den Privilegien der ausgenutzten Anwendung liefert.

Man bezeichnet Exploits zumeist wie folgt:

  • Lokale Exploits
  • Remote-Exploits
  • DoS-Exploits
  • Command-Execution-Exploits
  • SQL-Injection-Exploits
  • Zero-Day-Exploits

Aspekt Angriffsart

[Bearbeiten | Quelltext bearbeiten]

Lokale Exploits

[Bearbeiten | Quelltext bearbeiten]

Lokale Exploits können beim Öffnen an sich scheinbar völlig harmloser Dateien (zum Beispiel Office Dokumente) aktiviert werden, sofern die dem Dateityp zugeordnete Anwendung durch fehlerhafte bzw. unsaubere Verarbeitung der Datei eine Sicherheitslücke aufweist. Meistens versucht ein Exploit (beispielsweise in einem PDF-Dokument[1][2][3] oder als Makro in einer Word- oder Excel-Datei) zunächst, Sicherheitslücken in dem Programm auszunutzen, mit dem die Datei eingelesen wurde, um dadurch eine höhere Privilegienstufe zu erreichen und so schädlichen Code in das Betriebssystem zu laden und auszuführen. Die eigentliche Aktion, die der Exploit ausführt, bezeichnet man als Payload (deutsch: Nutzlast). Bei vielen Exploit-Frameworks (etwa Metasploit) kann die Payload separat konfiguriert werden. Sie kann allerdings auch fest im Exploit verankert sein.

Remote-Exploits

[Bearbeiten | Quelltext bearbeiten]

Eine aktive Form des Exploits sind Angriffe aus dem Internet mittels manipulierter Datenpakete oder spezieller Datenströme auf Schwachstellen in Netzwerksoftware. Solche Exploits werden mitunter auch als Remote-Exploits bezeichnet.

Denial-of-Service-Exploits

[Bearbeiten | Quelltext bearbeiten]

Meist sind die ersten für eine bekanntgewordene Sicherheitslücke veröffentlichten Exploits sogenannte DoS-Exploits, die zwar die betroffene Anwendung überlasten, allerdings keine Ausführung von fremdem Programmcode und keine Privilegien-Eskalation beinhalten.

Command-Execution-Exploits

[Bearbeiten | Quelltext bearbeiten]

Command-Execution-Exploits kennzeichnen das Merkmal einer vom Angreifer steuerbaren Ausführung von Programmcode auf dem Zielsystem. Um ein solches Exploit erfolgreich zur Ausführung bringen zu können, muss der Programmierer über diverse Eigenheiten der Aufteilung des Speichers der Zielanwendung Bescheid wissen. Dieses Wissen bezieht er durch offene Quellen des Programmcodes oder durch bloßes Testen. Er muss seinen Code geschickt platzieren, um ihn zur Ausführung bringen zu können. Command-Execution-Exploits sind zumeist sehr gefährlich, da die betroffenen Anwendungen meist über erhebliche Rechte auf dem System verfügen und der Code des Angreifers mit ebendiesen Rechten gestartet wird.

SQL-Injection-Exploits

[Bearbeiten | Quelltext bearbeiten]

SQL-Injection-Exploits sind eine spezielle Art von Exploits und finden hauptsächlich Einsatz bei Webanwendungen, die eine SQL-Datenbank nutzen, da sie über das Internet sehr leicht zugänglich sind, sie können jedoch prinzipiell für jede Anwendung, die auf eine SQL-Datenbank zugreift, eine Gefahr darstellen.[4] Hierbei werden Anfragen in einer Schichtenarchitektur so gestellt, dass die fehlerhaft bzw. unsauber arbeitende Präsentationsschicht Daten zurückliefert oder schreibt, die sie weder für den Lesezugriff oder den Schreibzugriff verfügbar machen sollte. Beispielsweise können Eingaben in einem Loginformular so gestaltet werden, dass die betroffene Anwendung einen ungültigen Benutzer dennoch erfolgreich einloggt oder es können gezielt Datenfelder aus der Datenbank ausgegeben werden um z. B. die Passwörter oder E-Mail Adressen aller registrierten Benutzer auszugeben.[5] Werden Benutzereingaben in Programmoberflächen nicht ausreichend auf Gültigkeit geprüft (z. B. dass sie keine SQL-Kommandos und auch keine Teile davon enthalten) und gefiltert, kann eine SQL-Injection-Lücke entstehen.[6]

  • Über eine SQL-Injection-Lücke konnte im Oktober 2014 auf das Playstation-Netzwerk von Sony zugegriffen werden, um dort Kundendaten auszulesen.[7]
  • Das verbreitete Blog-System und Content-Management-System WordPress war von einer SQL-Injection-Lücke im Analytics-Plug-in Slimstat betroffen, wie Sicherheitsexperte Marc-Alexandre Montpas im Februar 2015 entdeckte. Dadurch liefen über eine Million Websites Gefahr, von Hackern übernommen zu werden.[8]

Aspekt Zeitabstand

[Bearbeiten | Quelltext bearbeiten]

Zero-Day-Exploit

[Bearbeiten | Quelltext bearbeiten]

Zero-Day-Exploit nennt man einen Exploit, der eingesetzt wird, bevor es einen Patch als Gegenmaßnahme gibt. Entwickler haben dadurch keine Zeit („null Tage“, englisch zero day), die Software so zu verbessern, dass der Exploit unwirksam wird, um Nutzer zu schützen. Entdeckt eine Person eine Sicherheitslücke und meldet sie nicht dem Software-Hersteller, sondern entwickelt einen Exploit, um diese auszunutzen, wird die Schwachstelle der Software oft erst lange nach dem ersten Angriff bekannt.[9] Von Hackern werden Zero-Day-Exploits gern geheim gehalten, um sie lange auszunutzen. Außerhalb der Öffentlichkeit werden Zero-Day-Exploits unter Hackern gehandelt oder Herstellerfirmen zu hohen Summen angeboten.[10] Die Preise stiegen von 2012 bis 2018 etwa um den Faktor 10 an.[11] Seit staatliche Organe offensive Cyberwar-Szenarien vorbereiten, versuchen legale staatliche und privatwirtschaftliche Organisationen Exploits zu kennen, um durch die Veröffentlichung von Patches Systeme abzusichern – oder um feindlichen Systemen schaden zu können.[12]

Vorbeugend versuchen Experten, Sicherheitslücken im Voraus aufzuspüren und Software-Herstellern aufzuzeigen. Dies wird in Fachkreisen manchmal kritisiert, da die Tester dabei mitunter Gesetze oder Hersteller-Richtlinien verletzen.[13]

  • Zero-Day-Exploits treten aufgrund wachsender Software-Komplexität und steigender Preise immer häufiger auf. Im August 2012 erschien ein Exploit[14], der auf einfache Weise den Security-Manager von Java abschaltete. Dadurch waren beliebige Programme zu starten.[15][16]
  • Fast alle Windows-Versionen waren im Oktober 2014 von einer Zero-Day-Lücke in Microsoft-Office-Dokumenten betroffen.[17]
  • Es gab im November 2014 Hinweise darauf, dass der BND Zero-Day-Exploits ankauft, um SSL-Verschlüsselungen abzuhören. Funktionsfähige Zero-Day-Exploits für weit verbreitete Programme wie Internet Explorer, Flash, Android oder iOS kosten bis zu 100.000 Dollar. Es wird vermutet, dass für den Ankauf (unter dem Codenamen „Swop“) im Jahr 2015 bis zu 4,5 Mio. Euro bereitgestellt wurden.[18]
  • Der Präsidiumsarbeitskreis „Datenschutz und IT-Sicherheit“ der Gesellschaft für Informatik kritisierte, dass das BSI Zero-Day-Exploits zwar sammeln solle, sie aber nicht zu veröffentlichen brauche. Durch die Nichtveröffentlichung wären deutsche Unternehmen und Privatpersonen IT-Angriffen schutzlos ausgeliefert, es drohten Verluste der Unternehmen in Milliarden-Euro-Höhe.[19]
  • Google veröffentlichte 2019 eine Dokumentation aller seit dem Jahre 2014 öffentlich bekannt gewordenen Zero-Day-Exploits (Projekt Zero).[20]

Gegenmaßnahmen

[Bearbeiten | Quelltext bearbeiten]

Oft wird der Speicherschutz als Gegenmaßnahme genannt. Das ist jedoch nicht korrekt, denn eingefrorene Speicher können mit verschiedenen Programmen ausgelesen werden. Ebenso kann mittels Intrusion-Detection-Systemen ein Angriff auf Basis bestehender Funktionalitäten festgestellt oder mittels Intrusion-Prevention-Systemen auch verhindert werden; ein solches System schützt indessen ebenso wenig gegen das Ausnutzen eines systematischen, unbekannten Fehlers in einer Software. Das Grundproblem ist oft unsaubere Programmierung (z. B. durch die Verwendung von hängenden Zeigern) oder, noch schwerer zu entdecken, ein systematischer, meist sehr komplexer Fehler in der Architektur des Programms oder eines ganzen Systems. Die einzige Lösung für solche Probleme wäre, die durch Verarbeitungsfehler entstehenden Sicherheitslücken schon bei der Entwicklung zu vermeiden, was bei heutigen Systemen aber praktisch unmöglich ist. Managed Code bietet einen gewissen Schutz; so werden zum Beispiel Pufferüberläufe effektiv verhindert. Dies ist aber nur eine Teillösung der Gesamtproblematik. Komplexe Systeme, die von unterschiedlichen Herstellern und Sublieferanten zusammengefügt werden, bestehen aus vielen Schichten von Hard- und Software, was die Schwachstellensuche während der Entwicklung enorm erschwert. Deshalb wird dann meist noch im Betrieb, weit nach der Beta-Phase, die Suche nach Schwachstellen fortgeführt. Existenziell wichtig ist diese Suche bei extrem kritischen Systemen, bei denen Menschenleben auf dem Spiel stehen, z. B. bei Autos, Zügen, Flugzeugen und Schiffen, die alle Software enthalten (meist in Form von Firmware), welche prinzipiell angegriffen werden kann.

  • Dass die Untersuchungen der Blackhat-Konferenz zur Hackbarkeit von Autos nicht nur theoretischer Natur waren, zeigte der Hack eines Jeep Cherokee. Den Sicherheitsexperten Charlie Miller und Chris Valasek ist es gelungen, durch eine Schwachstelle im Infotainmentsystem übers Internet die Kontrolle über solch einen Jeep zu übernehmen. Es konnten aus der Ferne die Bremsen, Beschleunigung, Türverriegelung, Klimaanlage und Scheibenwischer gesteuert werden. Im Rückwärtsgang war es sogar möglich, auch das Lenkrad fernzusteuern. Es soll auch ohne Zustimmung des Fahrzeuginhabers möglich sein, den genauen Aufenthaltsort des gehackten Fahrzeugs zu bestimmen. Diese Schwachstelle wurde inzwischen mit einem Update behoben, das allerdings vom Fahrzeughalter per USB-Stick oder durch eine Werkstatt installiert werden muss.[23][24]

Einzelnachweise

[Bearbeiten | Quelltext bearbeiten]
  1. Thorsten Holz: Tatort Internet: PDF mit Zeitbombe. In: Heise online. 20. Juli 2010, abgerufen am 14. August 2024.
  2. PDF Exploit für Adobe Reader. In: Pastie. 25. Februar 2013, archiviert vom Original am 6. Januar 2014; abgerufen am 14. August 2024 (englisch).
  3. Analyse des Exploits. In: virustotal.com. 16. Februar 2013, abgerufen am 14. August 2024 (englisch).
  4. SQL Injection. In: PHP.net. Abgerufen am 19. August 2011.
  5. Jürgen Schmidt: Deutlicher Anstieg der SQL-Injection-Angriffe. In: Heise Security. 24. Juli 2012, abgerufen am 14. August 2024.
  6. Daniel Bachfeld: Giftspritze. In: Heise Security. 6. Januar 2004, abgerufen am 14. August 2024.
  7. Hanno Böck: SQL-Injection: Sicherheitslücke erlaubt Zugriff auf Sony-Kundendaten. In: Golem.de. 30. Oktober 2014, abgerufen am 14. Januar 2015.
  8. Björn Greif: Über eine Million WordPress-Sites von SQL-Injection-Lücke bedroht. In: ZDNet. 25. Februar 2015, abgerufen am 18. November 2015.
  9. Zero-Day-Exploit. In: „Viruslist.com“. Archiviert vom Original am 2. Februar 2012; abgerufen am 18. November 2011.
  10. Charles Miller: The Legitimate Vulnerability Market: The Secretive World of 0-day Exploit Sales. (pdf; 283 kB) Independent Security Evaluators, 28. Februar 2007, abgerufen am 18. November 2011 (englisch).
  11. Patrick Beuth: Handel mit Sicherheitslücken: Der perfekte iPhone-Hack kostet zwei Millionen Dollar. In: spiegel.de. 10. Februar 2018, abgerufen am 14. August 2024.
  12. Tom Simonite: Welcome to the Malware-Industrial Complex. In: MIT Technology Review. 13. Februar 2013, abgerufen am 19. November 2022 (englisch).
  13. Ronald Eikenberg: Metasploit schreibt Kopfgeld auf Exploits aus. In: Heise online. 15. Juni 2011, abgerufen am 14. August 2024.
  14. CVE-2012-XXXX Java 0day. In: pastie.org. 27. August 2012, archiviert vom Original am 17. Februar 2013; abgerufen am 14. August 2024.
  15. Ronald Eikenberg: Java-0-Day unter der Lupe. In: Heise Security. 28. August 2012, abgerufen am 14. August 2024.
  16. Esteban Guillardoy, Nico Waisman: Java 0day analysis (CVE-2012-4681). In: Immunity Products. 28. August 2012, archiviert vom Original am 31. August 2012; abgerufen am 14. August 2024 (englisch).
  17. Ronald Eikenberg: Zero-Day-Lücke in Windows. In: Heise Security. 22. Oktober 2014, abgerufen am 14. August 2024.
  18. Jürgen Schmidt, Detlef Borchers: SSL abhören: Kritik an BND-Plänen zu Zero-Day-Exploits. In: Heise Security. 10. November 2014, abgerufen am 14. August 2024.
  19. Cornelia Winter: IT-Sicherheitsgesetz schafft Unsicherheit. In: gi.de. 18. November 2014, abgerufen am 19. November 2022.
  20. 0day In the Wild. In: Google Project Zero. 15. Mai 2019, archiviert vom Original am 20. Mai 2019; abgerufen am 14. August 2024.
  21. Brian Donohue: Black Hat: Angriffe auf Flugzeuge, Züge und Autos. In: Kaspersky lab daily. Abgerufen am 25. November 2014.
  22. Hacker-Angriffe auf Autos – Fernsteuerung per Laptop: Diese Automodelle sind leicht zu manipulieren. In: Focus Online. 14. August 2014, archiviert vom Original am 24. September 2015; abgerufen am 14. August 2024.
  23. Ronald Eikenberg: Hacker steuern Jeep Cherokee fern. In: Heise Security. 22. Juli 2015, abgerufen am 14. August 2024.
  24. Andy Greenberg: Hackers Remotely Kill a Jeep on the Highway—With Me in It. In: Wired.com. 21. Juli 2015, abgerufen am 16. November 2015 (englisch).