Auch immer mehr interne Applikationen werden mit Hilfe von Web Technologien umgesetzt. Dies ermöglicht den Zugriff auf die Anwendung mit verschiedensten Geräten und meist ohne Installation zusätzlicher Software. In manchen Kundenumgebungen sprießen die Web Apps gerade so aus dem Boden, man könnte denken, dass auf jede Anforderung die besteht, die Antwort eine Web Anwendung ist. Dabei wird leider oft die Sicherheit vernachlässigt.

Entwickler sind nur äußerst selten geschult in Secure Coding und Anwendungen gehen live, bevor die Sicherheit überprüft werden konnte. Oft wird auch das Risiko, das von unsicheren Web Apps ausgeht unterschätzt, da diese nur intern oder über VPN erreichbar sind. Dabei muss immer davon ausgegangen werden, dass der Perimeter früher oder später überwunden wird und dann bieten derartige Anwendungen für Angreifer attraktive Ziele und Möglichkeiten sich weiter im Netzwerk auszubreiten.

Ein Begriff, viele Möglichkeiten

Web Application Pentests existieren wie die meisten Information Security Assessments in verschiedenen Varianten. Der Scope beschreibt, welche Teile der Anwendung bzw. der darunterliegenden Infrastruktur Teil des Tests sein soll. Wenn gewünscht werden auch Angriffspunkte auf die Security des Betriebssystems und des Webservers in den Test miteinbezogen. Vielleicht soll aber sogar nur ein Teil der Applikation getestet werden. Wurde die Anwendung bereits mehreren Überprüfungen unterzogen und wird diese nun um einen Bereich erweitert, muss nicht zwingend die ganze Anwendung wieder getestet werden. Es kann auch ausreichend sein die neuen Bereiche, bzw. die Schnittstellen zum Rest der Anwendung unter die Lupe zu nehmen.

Web App Pentests sind meist listenbasiert. Das bedeutet es wird step by step eine Kategorie von Schwachstellen nach der anderen überprüft und versucht diese auszunutzen. Es ist jedoch auch möglich die Tests szenariobasiert durchzuführen. Dabei wird nicht versucht möglichst viele Schwachstellen zu finden, sondern ein definiertes Ziel zu erreichen. Ein Ziel kann z.B. wie folgt beschrieben werden: Ausweitung von Benutzerberechtigungen um Zugriff auf administrative Funktionen zu erhalten, ohne eine Alarmierung auszulösen. Der Pentester wird hier also gezwungen sich unter dem Radar zu bewegen und nicht aufzufallen. Gleichzeitig sind für Ihn nur Schwachstellen interessant, die alleine oder gemeinsam mit anderen Schwachstellen eine Privilege Escalation erlauben.

Schwachstellen sterben nicht aus

Damit man sich unter dem Thema auch etwas vorstellen kann, sollen hier ein paar Beispiele veranschaulicht werden. Diese sind entweder nachgestellt oder im Sinne der Demonstration künstlich herbeigeführt…nichtsdestotrotz treffen wir bei nicht wenigen Pentests auf genau diese Arten von Schwachstellen.

Public Exploit

Bei diesem Finding hat der Pentester wenig Arbeit. Funktioniert das Patch Management nicht richtig oder existiert eventuell gar nicht, laufen OS, Webserver oder Frameworks mit veralteten Versionen, für welche Informationen zu bekannten Schwachstellen und dazugehörende Exploits öffentlich verfügbar sind. Der Tester beginnt damit die verwendeten Programmiersprachen, Frameworks, Libraries und Tools zu enumerieren. Anschließend kann überprüft werden, ob Schwachstellen für die verwendeten Produkte bekannt sind und ob die eingesetzten Versionen verwundbar sind.

In unserem fiktiven Beispiel zeigt sich dem Tester, dass die Anwendung mit Hilfe des Apache Struts Frameworks erstellt wurde, welches gern von Entwicklern eingesetzt wird um Java-basierende Web-Anwendungen zu erstellen.

Die in diesem Beispiel eingesetzte Version von Apache Struts könnte verwundbar gegenüber CVE-2017-5638 sein, welches es erlaubt Befehle abzusetzen, welche auf dem Server ausgeführt werden. Ein schneller Scan mit Hilfe eines Nmap Scripts soll dies zeigen:

Um sicherzugehen, dass das Finding des Nmap Scripts korrekt ist, kann dies auch manuell überprüft werden. Dazu fügen wir einen speziell präparierten Content-Type-Header ein, welcher testet, ob der Server Befehle ausführt, die ihm ein Client unterjubelt. In diesem Fall lassen wir den Server 42 * 42 berechnen.

Und wie angenommen zeigt sich, dass der Server uns zu Diensten steht.

Da nun Gewissheit besteht, dass die verwendete Version anfällig auf die beschriebene Schwachstelle ist, kann das System mit Hilfe eines simplen Exploits kompromittiert werden:

ADMIN INTERFACE / DEFAULT CREDENTIALS

Viele werden es bereits aus der eigenen Erfahrung kennen: Ein Entwickler oder Admin installiert “nur schnell mal” eine Applikation zu Testzwecken. Nach den Tests wird auf das deprovisionieren vergessen und so schlummert eine unsicher konfigurierte Web Applikationen vor sich hin, bis (im besten Fall) ein Pentester, oder (im schlimmsten Fall) ein Angreifer darüber stolpert. Die Betreiber haben oft die Meinung, dass ein Angreifer mit einem fast leeren Test-Server nicht viel anfangen kann, jedoch ist ein kompromittierter Server z.B. in der DMZ meist bereits hinter dem strengsten Firewall-Ruleset und anderen Schutzmechanismen platziert. Von so einem Server aus lässt sich viel anstellen.

Ist an dieser Stelle nun auch noch der Login mit Hilfe von Zugangsdaten wie Username = admin und Kennwort = admin oder Username = admin und Kennwort = (leer) erlaubt, dauert es nicht lange bis ein Angreifer oder Pentester den Server komplett übernommen hat. Diese Kombination von Schwachstellen sehen wir (leider) viel zu oft in unseren Assessments, teilweise sogar öffentlich erreichbar über das Internet. Auch wenn nicht derartige Zugangsdaten zum Einsatz kommen, werden Anwendungen und die darauf erfolgten Logins oft nicht überwacht. So kann der Pentester entweder tage- und wochenlang versuchen mit verschiedenen Kennwörtern Zugriff zu erhalten oder einfach Zugangsdaten benutzen die er an anderer Stelle bereits sammeln hat können.

 

UNSICHERE SESSION IDS

Auch die Generierung und Verwendung von Session IDs entspricht oft nicht den Anforderungen an eine sichere Web Application. Die Übertragung der Session ID als GET-Parameter führt dazu, dass die Session ID in der Adresszeile des Browser angezeigt wird. Da die Session ID nach dem Login oft das einzige Authentifizierungsmerkmal einer Sitzung darstellt, sollte diese gut gehütet werden. Die Anzeige der ID in der Adresszeile erlaubt es jedoch Shoulder Surfern die ID abzuschreiben oder zu fotografieren. Wird die ID anschließend in einer anderen Sitzung wiederverwendet, hat der Angreifer erfolgreich eine authentifizierte Session übernommen.

Manchmal ist es aber nicht der Transport der Session ID welcher sich als problematisch herausstellt, sondern die Generierung der IDs im Vorhinein. Werden Session IDs nicht zufällig genug gewählt, können Angreifer diese vorberechnen oder Abweichungen in der Zufälligkeit nutzen um gültige Session IDs zu erraten. Oft fließen Daten wie Uhrzeit, Datum oder Servernamen in die Generierung der IDs ein, was aufgrund deren statischer oder linearer Eigenschaften zu allem anderen als einer hohen Entropie in den Session IDs führt. Um dieser Schwachstelle auf die Schliche zu kommen, können viele IDs generiert und anschließend statistisch analysiert werden. Wie man am folgenden Beispiel sehen kann, gibt dieser Algorithmus zur Generierung von Session IDs Werte aus, welche an bestimmten Zeichen- oder Bit-Positionen keine akzeptable Zufälligkeit aufweisen.

FEHLENDE HEADER

Es existieren mehrere Header, die in einer Web Applikation gesetzt werden können, welche Einfluss auf die Sicherheit der Anwendung haben. Abschließend sollen hier noch 2 Beispiele gezeigt werden:

X-Frame-Options

Mit Hilfe des Headers “X-Frame-Options” kann die Anwendung signalisieren, dass diese nicht in einem IFrame dargestellt werden soll. Dies dient dazu sogenannte ClickJacking-Angriffe zu verhindern. Bei diesen Angriffen bindet ein Angreifer eine Applikation als unsichtbaren IFrame ein und legt diesen über eine andere sichtbare Anwendung. Glaubt der Benutzer gerade einen Button in der sichtbaren Anwendung zu klicken, wurde in Wirklichkeit sein Klick auf z.B. einen Passwort Reset Button in der geframeten Applikation platziert. Um sich vor derartigen Angriffen zu schützen, sollte der X-Frame-Options Header auf folgende Weise gesetzt werden.

Strict-Transport-Security

Ist eine Website über HTTPS erreichbar (und das sollten ziemlich alle sein) wird oft ein Redirect genutzt um die User von der HTTP-Version auf die HTTPS-Version der Seite umzuleiten. Kann ein Angreifer jedoch den Traffic vom User zur Website kontrollieren, kann er den Redirect entfernen und zukünftige Aufrufe welche HTTPS:// beinhalten mit HTTP:// ersetzen. So zwingt er den User unverschlüsselt auf die Seite zuzugreifen und kann Kennwörter und andere schützenswerte Daten im Klartext einsehen. Dieses Verfahren ist auch bekannt als SSL-Stripping. Um den unverschlüsselten Zugriff via HTTP auf eine Website zu verhindern, kann der Betreiber den Header “Strict-Transport-Security” (auch bekannt als HSTS) setzen.

 

Dies bewirkt zwei Verhaltensänderungen des Browsers:

  1. Der User kann nicht mehr via unverschlüsseltem HTTP auf die Seite zugreifen.
  2. Der User kann bei Zertifikatsfehlern diese nicht mehr im Browser ignorieren und trotzdem auf die Seite zugreifen.

 

Die Aktivierung dieses Headers setzt natürlich voraus, dass die TLS-Konfiguration und das Zertifikat eines Webauftritts einwandfrei sind, da sonst Probleme beim Aufrufen auftreten werden. Der Header wird beim ersten Aufruf der Website eines Clients gesetzt und verhindert so eventuelle zukünftige Angriffe. Nun stellt sich natürlich die Frage was passiert, wenn ein Angreifer bereits die erste Verbindung zwischen Benutzer und Website manipulieren kann. In diesem Fall kann der Header einfach aus dem Datenstrom entfernt werden und die weiteren Attacken funktionieren wie gewohnt. Um dem entgegenzuwirken wurde das sogenannte Preloading etabliert. Dabei kann der Betreiber eines Auftritts darum bitten, in die HSTS-Liste direkt im Browser aufgenommen zu werden. Somit ist bereits direkt nach der Installation des Browsers die Website nur via HTTPS erreichbar.

 

Der HTTP Strict Transport Security Header schaut wie folgt aus:

Um Preloading wirklich auszulösen, muss der Betreiber über dieses Portal noch einen Antrag stellen: https://hstspreload.org/

 

FAZIT

Trotz der einfachen Möglichkeiten heutzutage eine Web Applikation zu erstellen, erfordert die Absicherung dieser das Wissen über verschiedene in sich greifende Technologien.

Besonders aufgrund der fortschreitenden Verbreitung von internen und externen Web Applikationen, finden sich in den meisten Unternehmen viele Angriffsvektoren, welche durch unsaubere oder fehlende Web Application Security ausgenutzt werden können.

Gerne beraten wir Sie bei der Absicherung einer Web App und stehen mit Rat und Tat zur Seite.

RELAX, WE CARE.