Angriffsszenarien auf Web-Anwendungen

Samstag, 12.06.2021

Mirko Matytschak

Offensive Security ist der Ansatz, selbst als Hacker zu agieren und zu versuchen, die Sicherheitsmechanismen der eigenen Systeme zu überwinden. In einem Vortrag auf der Codegarden-Konferenz wurden zwei Szenarien gezeigt: Backoffice Rights Elevation, um Administratorrechte zu erhalten, sowie Code Execution mittels Views. Überhaupt sollten typische Angriffsszenarien wie Sql Injection immer bei der Entwicklung mit bedacht werden.

Auf der Codegarden-Konferenz 2021 gab es einen sehr guten Vortrag über "Offensive Security" in Bezug auf Umbraco. Offensive Security ist der Ansatz, selbst als Hacker zu agieren und zu versuchen, die Sicherheitsmechanismen der eigenen Systeme zu überwinden. Die gezeigten Szenarios waren Backoffice Rights Elevation, um Administratorrechte zu erhalten, sowie Code Execution mittels Views, die ja via Backoffice abgespeichert werden können.

Backoffice Rights Elevation

Die Rights Elevation nutzt eine Angriffskette, die an dem Punkt beginnt, dass ein Redakteur Html-Templates verändern kann, die zur Genierierung von Pdf-Dateien dienen (das Szenario funktioniert natürlich mit jeder Art Template, die ein Redakteur abspeichern darf). Der Angreifer versucht, in dem Template Javascript auszuführen, mit dem ein Html-Element mit Inhalten gefüllt wird.

Wenn dies gelingt, können in einem weiteren Schritt die Inhalte der Web.config-Datei (und ggf. der umbracoSettings.config) mit einem XmlHttpRequest gelesen und im Pdf angezeigt werden. Die Web.config-Datei enthält Passwörter, zum Beispiel für den Sql Server. Nun versucht der Angreifer, die Passwörter wiederzuverwenden, um sich im Backoffice als Admin anzumelden.

Die Moral aus der Geschicht: Verwendet nie ein Passwort für mehr als einen Zweck.

Das gezeigte Szenario gehört zur Gruppe der Local File Inclusion-Angriffe. Wann immer Sie es Nutzern ermöglichen, Dateien auf den Server hochzuladen, müssen Sie sicherstellen, dass diese keinen ausführbaren Code enthalten. Und wenn das nicht zu vermeiden ist, brauchen Sie eine Analyse, was dieser Code im schlimmsten Fall anrichten kann.

Hat man erst einmal Admin-Rechte im Backoffice, ist der folgende Angriff leichter.

Remote Code Execution

Der Code Execution-Angriff versucht, mit Hilfe der .NET-Methode System.Diagnostics.Process.Start einen Prozess zu starten. Wenn das gelingt, können Systeminformationen ausgegeben werden, mit Hilfe derer weitere Angriffsszenarien möglich sind. Super-Worst-Case in diesem Szenario: Der Start einer Powershell. Der Referent hat ein Tool gezeigt, mit dem via Powershell eine Art Service installiert werden kann, der dann eine Remote-Konsole zur Verfügung stellt.

Die Absicherung in diesem Fall besteht darin, die automatisch vom IIS angelegten Accounts für Web Sites zu benutzen. Wir werden immer wieder von IT-Abteilungen gefragt, warum wir für die Websites keine Domain-Accounts verwenden. Die Antwort ist immer der gleiche: Die Kontrolle über die Rechte dieser Accounts geht auf die Domäne über. Das vergrößert die Oberfläche des Systems und ist daher fehleranfällig. Passiert einmal ein Fehler, ist es zur Remote Code Execution, die wirklich etwas anrichten kann, nicht mehr weit.

Die IIS AppPool-Accounts dürfen nach dem Anlegen der Sites erst einmal gar nichts im System und sind ausschließlich auf dem Web Server bekannt – außerhalb des Webservers können sie also schon mal gar nicht aktiv sein.

Nun muss der Administrator die verschiedenen Ordner der Umbraco Site lesbar und – wo es nötig ist – beschreibbar für diesen Account machen. Das bin-Verzeichnis darf zum Beispiel nie beschreibbar sein. Ebenso die web.config-Datei, außer zum Zeitpunkt von Umbraco-Versions-Updates. Verzeichnisse unterhalb von App_Data sind gute Kandidaten für die Beschreibbarkeit. App_Code sollte tunlichst nicht beschreibbar sein. Wir nutzen vorgefertigte Scripts, die die Rechte für eine Umbraco-Site korrekt einstellen.

Sql Injection

Das Angriffsszenario ist so alt, dass man sich ernsthaft die Frage stellt, wie es sein kann, dass es immer noch das aum häufigsten genutzte Szenario ist. Ein solcher Angriff kann enstehen, wenn eine SQL-Anweisung mit Benutzereingaben zusammengesetzt wird, etwa in dieser Weise:

var sqlStatement = "SELECT * FROM Product WHERE Name LIKE '" + nameFragment + "'";

Wenn nameFragment etwas ist, das der Benutzer auf der Website frei eingeben kann, dann ist die Site schon für Sql Injection anfällig. Wenn jemand zum Beispiel als nameFragment folgenden String eingibt:

x';Delete FROM Product;--

Dann ist das resultierende SQL-Statement nach oben gezeigter Anweisung wie folgt:

SELECT * FROM Product WHERE Name LIKE 'x';Delete FROM Product;--'"

Das ist so ziemlich der maximale Schaden, weil die Site dann nicht mehr funktioniert. Hier entstehen zwei SQL-Anweisungen und ein Kommentar, der alles nach -- ausblendet. Bei CMS-Systemen wie WordPress oder Umbraco wissen die Angreifer, wie die Tabellen heißen und können mit Sql Injection ziemlichen Schaden anrichten.

Vermieden werden kann das Szenario durch konsequenten Einsatz von Query-Parametern. Damit ist der Datenbank klar, dass alles, was der Benutzer eingegeben hat, als String-Literal zu betrachten ist.

Bei der FORMFAKTEN GmbH verwenden wir einen OR-Mapper. Dieser erlaubt es, Abfragen mit Linq zu formulieren:

var foundProducts = pm.Objects<Product>().Where(p=>p.Name.Like(nameFragment)).ResultTable;

Jegliche Variable, die in einer Linq Expression zu einem Wert verarbeitet werden kann, wird automatisch in einen Parameter verwandelt. Die Variable nameFragment ist solch ein Beispiel. Damit können wir sicherstellen, dass auch nicht aus Versehen eine Sql Injection passieren kann.

Fazit

Insgesamt bleibt der Eindruck: Mit ein wenig Sorgfalt lassen sich die üblichen Angriffe vermeiden. Denken Sie die verschiedenen Szenarien immer mit: Sql Injection, File Inclusion, Buffer Overflow, Benutzerrechte im Dateisystem, um nur ein paar zu nennen. Tun Sie dies nicht, ist das fahrlässig und kann beim Verlust von personenbezogenen Daten auch empfindliche Strafen im Sinn der DSGVO nach sich ziehen.

 

 

Einen Kommentar verfassen

Anleitung zur Textformatierung

Zum Formatieren des Textes verwenden Sie [b][/b] und [i][/i]. Verwenden Sie [url=http://ihre-site]Text[/url] für Links.

* Pflichtfelder