Ausgenutzt! Schwachstellen und ihre Exploits

titelbild-exploit

Seit es Programme und Programmierer gibt, gibt es auch Fehler in der Software. Je nachdem, um welche Art von Fehler es sich handelt, kann das Programm falsche Ergebnisse erzeugen, abstürzen oder ein Sicherheitsleck aufweisen. In diesem Fall nennt man den Fehler dann „Schwachstelle". Gibt es einen Weg, diese Schwachstelle systematisch und wiederholbar für Angriffe auf die Systeme auszunutzen, spricht man von einem sogenannten „Exploit", also einem Befehl, einer Eingabe oder einem kleinen Code-Schnipsel, der die gefundene Schwachstelle ausnutzt (eng. to exploit – ausnutzen/ausbeuten). Eine besonders schwere Bedrohung stellen die „Zero Day Exploits" dar – aber dazu später mehr.

Hacker vs. Entwickler - ein unfairer Kampf

Eine Schwachstelle kann viele Gestalten haben. Je nach verwendeter Programmiersprache und Technologie variieren die Angriffsmöglichkeiten von sehr hardware-nahen Speicherüberläufen (Bufferoverflow), über die Einschleusung von Datenbankabfragen (SQL-Injection) durch fehlerhafte Prüfung von Eingabefeldern, bis hin zu durch den Angreifer frei definierbaren und ausgeführten Systembefehlen (Command Injection). Diese große Varianz führt zu einem Dilemma: Der Entwickler muss alle Bereiche und Komponenten der Systeme sicherheitskritisch betrachten und bewerten, während der Angreifer nur eine Schwachstelle finden muss, die dabei übersehen wurde.

Doch Schwachstellen werden nicht nur von Hackern identifiziert. Über so genannte „Bug-Bounty"-Programme animieren Softwarehersteller freie Sicherheitsforscher und Security-Experten, gegen eine Belohnung nach ausnutzbaren Fehlern zu suchen und diese zu melden. Erkennt der Hersteller die Meldung an, werden diese Lücken behoben und dann unter Umständen veröffentlicht, um andere Softwareentwickler auf den Patch und die vorher vorhandene Unzulänglichkeit aufmerksam zu machen.

Ein Blumenstrauß an Möglichkeiten

Sobald eine Schwachstelle öffentlich ist, machen sich bösartige Angreifer an die Arbeit und entwickeln Skripte oder Tools, durch die sie die Schwachstelle in noch nicht aktualisierten Versionen des betroffenen Programms ausnutzen. Wie sich diese Entwicklung darstellt, hängt sehr von der Art der Schwachstelle ab. Die entstehenden Exploits lassen sich aber in der Regel wie folgt klassifizieren:

  • „Remote (Code) Execution": Der Hacker kann durch die Ausnutzung der Schwachstelle, lediglich unter der Verwendung einer Netzwerkverbindung, (jeden) beliebigen Code auf der Opfermaschine ausführen. Hierbei handelt es sich um die mächtigste Variante eines Exploits, da keine weiteren Zugriffe auf die Zielsysteme nötigt sind.
  • „Injection"-Angriffe: Durch Anwendung des Exploits ist es möglich, Befehle (zum Beispiel via SQL oder Kommandozeilenanweisungen) zu injizieren und von der Opfermaschine ausführen zu lassen. Im Vergleich zu einer Remote Code Execution sind die Möglichkeiten hier teilweise deutlich eingeschränkt.
  • „Local (Code) Execution": Der Angreifer kann (beliebigen) Code ausführen, benötigt dazu aber Zugriff auf die Maschine (zum Beispiel über einen SSH-Login - diesen müsste er sich auf anderem Wege beschaffen).
  • „Denial of Service": Der angegriffene Dienst wird durch die Anwendung des Exploits außer Kraft gesetzt, eine Interaktion mit dem Dienst ist nicht mehr möglich.

Die unsichtbare Gefahr

Eine besondere Gefahr stellen so genannte „Zero Day Exploits" dar. Sie nutzen Schwachstellen aus, die der Öffentlichkeit (und damit auch dem Hersteller) noch nicht bekannt sind, und folglich auch noch nicht behoben werden konnten.

Das führt dazu, dass noch niemand in der Lage ist, den Angriff abzuwehren, da der Entwickler der Software aber auch Hersteller möglicher Verteidigungssoftware (Virenscanner, Intrusion Detection / Intrusion Prevention) noch keine Gegenmaßnahmen ergreifen konnten. Wer Opfer einer solchen Schwachstelle wird, ist dem Angriff daher schutzlos ausgeliefert. Die Bezeichnung „Zero Day" bleibt bis zum (öffentlichen) Bekanntwerden der Sicherheitslücke bestehen. Danach handelt es sich „nur noch" um einen Exploit.

How to do it right

Die große Varianz der möglichen Schwachstellen führt dazu, dass es einem ungeübten Entwickler kaum möglich ist, ohne externe Unterstützung (z.B. durch Code-Reviews oder statische/dynamische Codeanalyse) oder die Verwendung geprüfter Frameworks sichere Anwendungen zu entwickeln.

Aber auch jeder, der sich mit IT-Sicherheit beschäftigt, kann seinen Beitrag dazu leisten, dass es weniger (Zero Day) Exploits in der freien Wildbahn gibt. Sollten Sie selbst (durch Zufall oder mit Absicht) eine Schwachstelle finden, ist es immer ratsam, diese an den Softwarehersteller zu melden, damit dieser die Möglichkeit hat, sie zu beheben. Meist revanchieren sich die Unternehmen mit Belohnungen für gefundene Schwachstellen.

Zusammenfassung

Auch wenn das Thema Softwaresicherheit auf den ersten Eindruck komplex wirken mag, gibt es im Internet viele IT-Experten (ob gut oder böse), die Schwachstellen finden und möglicherweise ausnutzen. Deshalb ist man immer gut beraten, sich an Coding-Guidelines zu halten und die eingesetzte Software aktuell zu halten. Gefundene Schwachstellen sollten immer gemeldet werden, und wer Spaß daran hat, kann mit der Teilnahme an Bug-Bounty-Programmen noch den einen oder anderen Euro dazu verdienen.

Im Rahmen dieser Serie werden zu den Angriffsmethoden via „SQL-Injection" und „Bufferoverflow" noch weitere Blogbeiträge erscheinen, die diese Themen noch ausführlicher beleuchten.

By accepting you will be accessing a service provided by a third-party external to https://blog.ordix.de/