Angriffe über das Internet

Angriffspunkte im Internet

Wenn Sie im Internet eine Webseite besuchen, werden sehr viele Interaktionen dabei durchgeführt, die meisten verlaufen dabei im Hintergrund und sind für Sie als Besucher nicht sichtbar.

Beispiel: Webmail

  1. Verbindungsaufbau mit dem Server / Webdienst (im Hintergrund)
  2. Laden der Benutzeroberflächen (im Hintergrund)
  3. Login durch den Benutzer zur Authentisierung (aktiv)
  4. Laden der spezifische Benutzerdaten (im Hintergrund)
  5. Interaktion zwischen Browser und Server (im Hintergrund)
  6. Laden der Benutzeroberflächen (im Hintergrund)

Hierbei findet ein reger Datenaustausch über mehrere Ebenen und zwischen mehreren Systemen statt, je komplexer dieser Aufbau ist um so mehr Angriffspunkte hat ein Angreifer an spezifische Daten zu gelangen.
Folgende Angriffspunkte wäre bei diesem simplen Szenario möglich:

  • Netzwerk-Sicherheit: mithören der unverschlüsselten Verbindung
  • Passwortverwaltung: abgreifen der Logindaten
  • dynamische HTML-Seiten: XSS (cross site scripting) Möglichkeit
  • Datenbankanbindung: Ändern oder mitschreiben der Verbindung
  • Cookies oder Sessions Diebstahl: Identitätdsiebstahl
  • Angriff auf Java oder Flash: Trojaner

Angriffe auf Client-Seite

Angriffe auf Netzwerk-Kommunikation des Users kann beispielsweise durch Cross-Site Request Forgery durchgeführt werden. Hierbei kann je nach System entweder ein Cross-Site-Scripting Angriff durch geführt werden, oder den Nutzer auch einfach eine manipulierte URL untergeschoben werden. Ein einfaches und harmloses Beispiel wäre hier das unterschieben einer Logout-Anweisung für die gewünschte Seite:

http://security.haberland.it/index.php?title=Aktuell:Userlogout

Nach dem nun der Logout erzwungen wurde, könnte der Angreifer als nächstes die verschlüsselte SSL/TLS Verbindung (https) über den Port 443 blocken und den Nutzer dazu bewegen, über die unverschlüsselte http-Verbindung als Fall-Back sich wieder einzuloggen um dabei die Logindaten abzugreifen. Vorraussetzung ist hierbei natürlich, dass der Datenverker schon über den Rechner des Angreifers als Man-in-the-Middle läuft.

Angriffe auf Server-Seite

Hierbei gib es neben der bekannten SQL-Injection auch die Möglichkeit des Directory Traversal oder auch Forceful Browsing genannt an Daten auf dem Server zu gelangen, an die der Angreifer eigentlich garnicht kommen darf. Sind die Verzeichnisse auf dem Server nicht mit korrekten Rechten versehen und ist die .htaccess nicht ordentlich erstellt worden bzw. liegt auch keine standardisierte Index-File in den Verzeichnissen, kann sich ein Angreifer oft vieler Daten auf dem Server bedienen. Oft gelingt es sogar in das Root-Verzeichnisses des Servers zu gelangen, ab dann hat man quasi vollen zugriff auf den kompletten Server.

Directory Traversal

Beim Directory Traversal muss man den Systemaufbau des verwendeten Servers von Augen haben, beispielsweise ist die Verzeichnisstruktur bei einem Linux-(Web-)Server (z.B. Debian) so, dass die Webseiten unter /var/www/“eventuell ein weiter Ordner“/index.htm abliegen, d.h. wenn ich zwei oder drei Ordner im Path aufsteige, lande ich im Root-Verzeichnis des Servers. Von dort kann ich dann zum Beispiel wieder ein Verzeichniss in etc/ absteigen um dann an die passwd Datei des Servers zu gelangen.

Als URL Aufruf würde das wie folgt aussehen:

http://security.haberland.it/show-page?page=../../etc/passwd

oder so

http://security.haberland.it/../../etc/passwd

Nimmt der Server ../ nicht an kann ich auch das ASCI-Code Äquivalent: %2e%2e%2f , %2e%2e/ oder ..%2f ausprobieren. Bei einem gut konfiguriertem Server inkl. Firewall werden Sie aber diesen Angriff nicht durchführen können.

Cookie-Klau

Ein Cookie ist eine Datei die eine besuchte Webseite durch Ihren Browser auf Ihrem Computer anlegen lässt, um Sie bei Ihrem nächsten Besuch oder dem Besuch einer Partnerseite wieder zu erkennen. Bei Webmail-Diensten wird im Cookie beispielsweise Ihre e-Mail-Adresse, eine Session-ID und ein Datum gespeichert. Verlassen Sie die Seite des Webmail-Dienstleister und kehren zu einem späteren Zeitpunkt wieder zurück, liest der Webmail-Dienstleister Ihren Cookie aus und vergleicht diesen mit seinen hinterlegten Daten. Ist der Cookie für den Webmail-Dienstleister gültig, loggt dieser Sie automatisch ohne weitere Überprüfung auf seiner Webseite ein.

Klaut nun ein Angreifer Ihren Cookie und legt diesen bei sich in den Speicher und besucht dann die Seite des Webmail-Dienstleister, kann er ohne die Eingabe Ihrer Logindaten Ihre E-Mails lesen und auch in Ihrem Namen E-Mails verschicken.

Eine Gegenmassnahme ist darum, sich beim Verlassen der Seite des Webmail-Dienstleister immer auszuloggen, dadurch wird die Session-ID in Ihrem Cookie auf Seiten des Servers „gelöscht“ dadurch sind Sie bei Ihrem nächsten Besuch auch mit gültigem Cookie dazu gezwungen Ihre Logindaten erneut einzugeben. Ein automatisierter Login findet nicht statt.

GMX Cookie hier ist das Ablaufdatum gleich mit dem Schliessen des Fensters / Tabs
Bei dem Cookie von der Telekom könnte sich ein Angreifer noch ein ganzes Jahr ohne die Eingabe von Logindaten unbemerkt einloggen.

Cross-Site-Scripting (XSS)

Ist ein webseitenübergreifender Skripting Angriff, bei dem eine Sicherheitslücke in der Webanwendungen des Webseiten- / Serverbetreibers ausgenutzt wird. Dabei fügt der Angreifer seine manipulierten Daten auf der Webseite des Betreibers ein um dadurch zugriff auf das System des Benutzers oder seine sensiblen Daten zu gelangen. Oft wird Cross-Site-Scripting zum Identitätsdiebstahl benutzt.

DOM XSS-Angriff

Hierbei wird die Webapplikation auf dem aufgerufenen Server gar nicht benötigt, wodurch statische HTML-Seiten (mit JavaScript-Unterstützung) für diesen Angriff benutzt werden können. Der Schadcode wird hierbei direkt an ein Skript übergeben, welches auf Auf dem Gerät des Nutzers ausgeführt wird. Dies kann beispielsweise ein JavaScript sein. Ein solcher Angriff bedarf den gezielten Aufrufs einer manipulierten URL, welche beispielsweise durch einen Link in einer E-Mail oder Whatsapp-Nachricht dem Nutzer gesendet wurde. Eine maipulierte URL könnte dann wie folgt aussehen:

http://security.haberland.it/index.html?arg=<script type="text/javascript">alert("You have been hacked!")</script>

Da dieser Angriff die HTML-Seite lokal beim Client aktualisiert ist dieser Angriff Serverseitig nur sehr schwer zu erkennen und so gut wie nicht zu verhindern.

reflected (non-persistent) XSS-Angriff

Das reflected Cross-Site-Scripting funktioniert analog zum DOM-XSS-Angriff, nur dass der schädliche Scriptcode auf der Seite des Servers in die HTML-Seite eingefügt wird. Dabei wird die Eingabe eines Benutzers vom Server wieder zurück an den Benutzer gesendet. Der Angreifer manipuliert also die Eingabe des Benutzers so, dass diese den schädlichen Skriptcode beinhaltet. Der Server sendet dann die manipulierte Seite zurück an den Benutzer, dessen Browser dann den Schadcode ausführt.

Dieser Angriff eignet sich bestens bei dynamisch generierte Webseiten , deren Inhalt über die URL mittels GET- oder POST-Methode übergeben Eingabewerte erstellt werden. Nicht-persistent heißt, dass der Schadcode nur temporär eingeschleust und nicht gespeichert wird. Somit ist dieser Angriff schwer nachweisbar.

persistent XSS-Angriff

Der persistente Angriff unterscheidet sich vom obigen, reflektierten, dass der Schadcode auf dem Webserver abgespeichert wird. Dadurch wird der Angriff bei jeder Anfrage ausgeführt. Dies ist bei Webanwendung wie beispielsweise Foren möglich, bei denen Benutzereingaben serverseitig speichert und später wieder ausliefert werden. Beispielsweise erstellt PHP lokal auf dem Server dynamische HTML-Seiten, die dann an den Besucher der Seite ausgeliefert werden.

WordPress Seiten war 2016 von diesem Angriff betroffen, Quelle: wordpress.org

SQL-Injection

Bei der SQL-Injection werden einer Datenbankabfrage ausführbare Befehle injiziert. D.h. schlecht programmierte Webseiten prüfen die Eingaben der Benutzter nicht ausreichend. Dadurch ergibt sich die Möglichkeit, dass Angreifer durch bestimmte Eingaben die Datenbank auslesen oder manipulieren können. Im schlimmsten Fall erlangt ein Angreifer darüber sogar Root-Rechte auf dem server. Selbst bei einer Webseite, bei der ein Nutzer keine Eingaben für eine Datenbankabfrage eingeben kann, ist ein SQL-Injection-Angriff möglich.

Beispiel (vereinfacht): Nehmen wir Bezug auf die oben genannten Cookies, bei der der Webmail-Dienstleister nur seinen eigenen Cookie ausliest, um über die darin enthaltene E-Mail-Adresse oder Session-ID den Benutzer in seiner Datenbank zu finden. Die Abfrage ist hier relativ simpel, die Seite des Webmail-Dienstleister erfragt nach seinen eigenen Cookie und der darin enthaltenen Daten. Der Browser extrahiert die angeforderten Daten aus dem Cookie und überliefert diese der Webseite. Die Webseite erstellt mit diesen Daten eine Datenbankanfrage, z.b. ist die e-Mail-Adresse info@haberland.it und die dazugehörige Session-ID: 12345 vorhanden und noch gültig. Wird diese Abfrage nicht richtig vom Server überprüft, so konnte ein Angreifer beispielsweise in seinem Cookie die enthaltene E-Mail-Adresse durch den SQL-Befehl „; DROP TABLE Accounts;“ ersetzen. Würde dann der Server die E-Mail-Adresse in seiner Datenbank suchen, so würde dieser automatisch den SQL-Befehl „; DROP TABLE Accounts;“ ausführen und alle Kundendaten löschen.

Datenbank gestützter Content wie bei WordPress wird über die URL aus einer Datenbank abgerufen und dann mit dem Inhalt mittels PHP eine HTML Seite erstellt. Datenbank gestützten Content können Sie leicht an der URL erkennen, beispielsweise:

http://security.haberland.it/post.php/find.cgi?ID=42

hierbei wird eine SQL Abfrage an Content Management System (CMS) gestellt, dass der Benutzer den Seiteninhalt mit der ID 42 anfordert. Der dazugehörige SQL-Befehl, der dann im Hintergrund vom CMS ausgeführt wird könnte dann wie folgt aussehen:

SELECT title, subject, text, comments FROM pages WHERE ID=42;

Ein SQL-Injection-Angriff über die URL könnte dann beispielsweise so aussehen:

http://security.haberland.it/post.php/find.cgi?ID=42;
UPDATE+USER+SET+TYPE="admin"+WHERE+ID=CURRENTUSER

Hierbei schleust der Angreifer den folgenden SQL Befehle in das System ein:

SELECT title, subject, text, comments FROM pages WHERE ID=42;
UPDATE USER SET TYPE="admin" WHERE ID=CURRENTUSER;

Würde das CMS jetzt diesen Befehl ausführen, so hätte der Angreifer, der den Befehl abgesendet hat Administratorrechte im CMS und könnte von dort anfangen die Webseite zu manipulieren.

Gängige SQL-Injection Befehle zur Manipulation:

  • …?id=42; DROP TABLE Accounts; (löscht die Tabelle Accounts)
  • …?id=42; INSERT INTO Accounts(…); (fügt etwas in die Tabelle Accounts hinzu)
  • …?id=5; UPDATE Accounts SET … WHERE …; (aktualisiert etwas in der Tabelle Acoounts)

Darüber hinaus kann sich ein Angreifer bei schlecht programmierten Webseiten auch durch gezielte Auswertungsabfragen einloggen. So wird bei einigen Webseiten der Login-Prozess durch eine simple „true“ oder „false“ Abfrage geregelt. Zur Vereinfachung, der Nutzer „John Doe“, loggt sich normalerweise mit dem Benutzernamen: „John“ und dem Passwort : „Doepass“ auf einer Webseite ein. Der Server überprüft diese Eingabe durch eine generierte SQL-Abfrage:

SELECT EXISTS (
  SELECT * FROM login WHERE username=John AND password=Doepass;
);

Findet der Server den Benutzer John mit dem password Doepass in seiner login Datenbank, wertet er diese Abfrage als „true“ aus und gewährt dem Benutzer zutritt. Möchte nun der Angreifer sich als „John Doe“ mittels SQL-Injection auf der Webseite anmelden und überprüft die Webseite Eingaben nicht, so gibt der Angreifer den Benutzernamen „John“ und das Passwort „‚ or 1=1–“ ein. Der Server erstellt nun die folgende SQL-Abfrage:

SELECT EXISTS (
  SELECT * FROM login WHERE username=John AND password= ' or 1=1;
);

Zur Erklärung die Abfrage lautet suche den Benutzer John mit dem leeren Passwort oder 1=1. Der Server wird den Benutzer John finden, jedoch ist sein Passwort nicht leer, da aber 1=1 wahr ist, wird die Abfrage trotz falschem Passwort auf „true“ ausgewertet, da falsch oder wahr immer wahr ergibt und der Angreifer wird als John angemeldet.

Wissenswertes über SQL-Injections finden sie hier.

TOP 10 Schwachstellen

Quelle: OWASP das komplette PDF gibt es hier

Genauere Angaben über das Ausnutzen von Schwachstellen finden Sie auch auf owasp.org, dem Open Web Application Security Project.