Suchen

Die Webanwendung als Sicherheitsrisiko – Teil 2 Direkte Attacken mittels SQL Injection und Remote Command Execution

Autor / Redakteur: Marcell Dietl / Stephan Augsten

Schon kleinste Fehler bei der Programmierung von Webanwendungen erlauben es einem technisch versierten Angreifer das gesamte System und alle darauf befindlichen Daten unter seine Kontrolle zu bringen. Die Schäden für Unternehmen betragen jährlich hunderte Millionen Euro. In diesem Beitrag unseres Dreiteilers widmen wir uns Angriffen auf Web-Applikationen, die einen direkten Zugriff auf Systeme ermöglichen.

Firma zum Thema

Über dynamische Website-Inhalte lassen sich angebundene Systeme mittels injizierter Befehle und Dateien kompromittieren.
Über dynamische Website-Inhalte lassen sich angebundene Systeme mittels injizierter Befehle und Dateien kompromittieren.
( Archiv: Vogel Business Media )

Mit der Einführung der Hyper Text Markup Language (HTML) wurde für viele auch technisch unerfahrene Nutzer die Möglichkeit geschaffen sich selbst im Internet zu präsentieren. Auch Firmen setzten schnell auf diese Möglichkeit, um neue Kunden zu gewinnen.

Zu Beginn des World Wide Web war es zum Erstellen von Webseiten notwendig jede einzelne Seite in HTML statisch zu programmieren. Mittlerweile haben Sprachen wie PHP und andere diese Statik ersetzt.

Was Anfangs noch undenkbar war ist heute zum Standard geworden: Dynamische Webseiten, welche einfach verwaltet werden können und dem Besucher einen interaktiven Umgang mit Informationen bieten.

Durch die Anbindung an Datenbanken und mit Hilfe von Parametern, welche in der URL an die Webapplikation übergeben werden, reagiert die Webseite auf die Aktionen des Nutzers und generiert die zu erzeugende Ausgabe dynamisch. So können für jeden Nutzer gezielt bestimmte Informationen bereit gestellt werden, welche für andere nicht zugänglich sein sollten.

Doch bei der Umsetzung werden häufig Fehler gemacht, welche es erlauben diese Einschränkungen zu umgehen und sich höhere Rechte und somit auch mehr Informationen zu verschaffen.

Seite 2: Die Risiken eines SQL-Injection-Angriffs

Die Risiken eines SQL-Injection-Angriffs

Es gibt derzeit etwa eine handvoll Datenbanksysteme, die auf der so genannten Structured Query Language (SQL) aufbauen. Ziel dieser „Programmiersprache“ ist es, große Datenbanken schnell und einfach zu administrieren und mit einer einzigen Abfrage nur jen Informationen zu erhalten, welche jeweils nötig sind.

Diesem Prinzip folgen Webseiten, die entsprechende Datenbank-Systeme als Backend benutzen. So werden zum Beispiel Suchanfragen eines Benutzers an die Datenbank übergeben und das Ergebnis dieser für den Nutzer unsichtbar ablaufenden SQL-Befehle anschließend präsentiert. Ohne eine Filterung der Eingaben eines Benutzers kann dieser die Abfrage manuell verändern und letztlich auch die für ihn sichtbaren Ergebnisse beeinflussen.

Ist ein Angreifer imstande einen solchen Fehler auszunutzen, kann er alle in der Datenbank gespeicherten Informationen gezielt auswerten und die für ihn interessantesten Datensätze herunterladen. Gerade bei Firmen sind dies oftmals Informationen über Mitarbeiter und Kunden – wie etwa Bankverbindungen, Sozialversicherungsnummern oder ähnliches.

Auch der Zugriff auf Systemdateien sowie das Ausführen von Kommandos mit den Rechten der Webanwendung ist unter bestimmten Umständen möglich.

Das Sytem dank RCE-Fehlern steuern

Die als Remote Command Execution (RCE) bekannte Schwachstelle ist vergleichsweise selten vorzufinden. Jedoch stellt sie die größte Gefahr für ein System dar, welches eine Person mit Hilfe der Webapplikation versucht unter seine Kontrolle zu bringen.

Durch fehlende Filterung der Eingaben von Nutzern ist es – ähnlich dem vorher bei Datenbanken beschriebenen Problem – möglich, den ausgeführten Befehl anzupassen. Bei RCE jedoch wird dieser Befehl nicht an die Datenbank übergeben, sondern direkt an das Betriebssystem.

Ein Angreifer kann dadurch all jene Aktionen ausführen zu denen der jeweilige Nutzeraccount, unter dem die Anwendung läuft, berechtigt ist. Von dem Auslesen von Daten bis hin zum Anlegen neuer administrativer Nutzer sind alle Möglichkeiten gegeben.

Seite 3: Einbinden externer Dateien durch Remote File Inclusions

Einbinden externer Dateien durch Remote File Inclusions

Namen wie R57 und C99 mögen für den normalen Programmierer eher wie ein RFC-Standard klingen, bezeichnen jedoch die sowohl unter professionellen Hackern wie auch Script Kiddies am meisten genutzten Backdoors für Webanwendungen. Wenn diese so genannten PHP Shells sie einmal auf einem Webserver gespeichert sind erlauben sie es, dessen Inhalt zu durchforsten, Dateien zu verändern, Befehle auszuführen und vieles mehr.

Um diese nur wenige Kilobytes großen Dateien auf dem Server zu speichern, nutzt der Angreifer eine Remote File Inclusion (RFI). Viele Webseiten binden Dateien anhand eines Parameters in der URL dynamisch ein.

Wird jedoch nicht überprüft, was eingebunden werden soll, kann der Nutzer diesen Wert manipulieren und die Webapplikation dazu veranlassen externe Dateien wie PHP Shells einzubinden und lokal zu speichern. Dieses Risiko besteht immer dann, sobald ein Nutzer imstande ist Dateien auf dem Server anzulegen, etwa durch ein Formular zum Hochladen persönlicher Daten, welche mit Hilfe der Webanwendung abrufbar sind und von dem Server interpretiert sowie ausgeführt werden.

Da PHP eine der am weitesten verbreiteten Programmiersprachen im Web ist, sind auch die meisten Backdoors dieser Art in ihr geschrieben. Aber natürlich gibt es auch Backdoors für Java Server Pages (JSP), Ruby, Perl und andere Sprachen, da sie sich prinzipiell kaum unterscheiden.

Fazit

Die in diesem Teil der dreiteiligen Artikelreihe von Security-Insider.de erläuterten Schwachstellen kann man unter dem Begriff „direkte Angriffe“ auf Webanwendungen zusammenfassen. Alle hier beschriebenen Probleme lassen sich von einem erfahrenen Eindringling binnen kürzester Zeit ausnutzen, um die Daten eines Systems sowie den Rechner selbst unter Kontrolle zu bringen.

Die Interaktion eines Nutzers oder Mitarbeiters ist dazu nicht notwendig. Somit ist der einzige Schutz gegen solche Angriffe, präventive Maßnahmen zu treffen, wie sie im dritten und letzten Teil dieser Serie beschrieben werden.

Artikelfiles und Artikellinks

(ID:2019283)