Path Traversal – von gestern bis heute
Vor gut 20 Jahren, irgendwann um die Jahrtausendwende. Millennium-Probleme? Nein, nochmal alles gut gegangen und alle Computer laufen noch. Ich bin erleichtert und euphorisch, da ich die Lehrstelle als Informatiker starten durfte. Die Informatik begeisterte mich schon als kleines Kind. Bereits im Alter von 7 Jahren habe ich von meinem Vater – er hat ebenfalls gerne an Computern herumgebastelt – einen (damals schon alten) Computer erhalten. Ich spielte uralte DOS-Spiele wie Wing Commander, Space Quest und Lemmings. Meine ersten Berührungen mit dem Computer waren eher im Bereich des Gaming angesiedelt. Wobei, für die Schule durfte ich auch schon Aufsätze schreiben und ausdrucken. Eine grossartige Sache! Später, im Windows-Zeitalter, kam dann das Internet dazu. Es war ein unbeschreibliches Freiheitsgefühl. Downloaden was das Zeug hält (angefangen mit 33,6Kbit/s), IRC-Chats, Warez-Boards und andere Sachen, wovon lieber die Finger zu lassen sind. Sehr bald wurde ich auch darauf aufmerksam, dass es Sicherheitslücken gibt und diese teilweise einfach auszunutzen sind. Eine beliebte Sicherheitslücke in der Szene und um die Jahrtausendwende war im Microsoft Internet Information Services (IIS) vorhanden. Es handelte sich um eine Path Traversal-Schwachstelle (CWE-23: Relative Path Traversal Vulnerability), welche es erlaubte, aus dem Webroot auszubrechen und beliebige Dateien auf dem Server zu lesen. Unglücklicherweise konnten sogar Anwendungen ausgeführt werden. Das sah dann beispielsweise folgendermassen aus:
http://target/scripts/…/..%255c..%255cwinnt/system32/cmd.exe?/c+dir+c:\
Das %255c ist URL Encoded und steht für einen Backslash (\). Mit 2 Backslash und jeweils 2 Punkten davor bewegen wir uns um 2 Verzeichnisse zurück und anschliessend in das Zielverzeichnis der CMD.exe-Datei. Mit ein wenig Fantasie konnten so beliebige Dateien auf dem betroffenen Server heruntergeladen und bei Bedarf auch ausgeführt werden. Die FXP-Scene wurde geboren. Selbstverständlich habe ich mich von solchen illegalen Gräueltaten distanziert. Mich interessierte, wie leicht und aufregend es war, sich mit diesem Thema zu beschäftigen. Später dann, aufgrund meiner Lehre, Freunden und Ausgang, hatte ich keine Zeit mehr für solche spannende Dinge und habe es leider aus den Augen verloren.
Heute
Nun beim System meines Kunden wurden die Eingaben in den Paramenten nicht oder nur unzureichend validiert. Nach etwas herumprobieren habe ich es geschafft, auf das System, also den Windows Webserver zuzugreifen. Eigentlich sollten wir uns im Webroot befinden (standardmässig ist es bei IIS C:\wwwroot). Doch ich konnte eine beliebige Datei auf dem System ansehen. In folgendem Beispiel ist es die Systemdatei c:\windows\system.ini:
Es konnten sogar Dateien, welche nur durch einen Administrator geöffnet werden dürfen, geöffnet werden. Dies weist darauf hin, dass die Webapplikation im Kontext eines lokalen Administrators (bzw. Local System) ausgeführt wird. Ein Fauxpas sondergleichen.
Die Sicherheitslücke wurde vom Hersteller Phillips geprüft und für valid befunden. Übrigens, die Lücke konnte nur mit einem gültigen Account (Klient oder Arzt) ausgenutzt werden. Es war also nicht ganz so einfach wie anno dazumal mit dem IIS 4.0. Ein bisschen stolz bin ich dann trotzdem, wenn ich als Researcher erwähnt und in die Hall of Honors der Firma Philips aufgenommen wurde. Ich hoffe nun, dass alle, welche diese Webapplikation verwenden, zeitnah vom Hersteller informiert werden.
https://www.cisa.gov/uscert/ics/advisories/icsma-21-187-01 (Kapitel 4.2.16)
https://www.philips.com/a-w/security/coordinated-vulnerability-disclosure/hall-of-honors.html
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-39369
Massnahmen
Oftmals wird den Herstellern von Software blind vertraut. Mein Beispiel zeigt, dass es eben doch sinnvoll ist, genau hinzuschauen und ein scheinbar bewährtes System genauer unter die Lupe zu nehmen. Wer selbst Webapplikationen entwickelt, sollte auf eine sichere Programmierung achten.
Eine bewährte Quelle ist die Non-Profit-Organisation OWASP (Open Web Application Security Project). Die Organisation veröffentlicht regelmässig die aktuellen Gefahren und entsprechende Massnahmen im Bereich der Web-Sicherheit.
Eine weitere Möglichkeit ist der Einsatz einer Web Application Firewall (WAF). Diese kann als zusätzliche Schutz-Schicht eingesetzt werden. Wir empfehlen aber immer zuerst, die Webapplikation selbst abzusichern und erst dann, als zusätzliche Hürde, eine WAF einzusetzen.
Zu guter Letzt, sollte eine Webapplikation vor jedem produktiven Einsatz einem Penetration Test unterzogen werden. Menschen machen Fehler und dies wirkt sich negativ auf die Sicherheit aus. Mit einem solchen Test können offensichtliche Schwachstellen in Applikationen auf ein Minimum reduziert werden.
Abschied
Dies ist mein letzter Blog, welchen ich für goSecurity schreiben darf. Nach bald 9 Jahren werde ich ab dem März 2022 einer neuen Herausforderung nachgehen. Hiermit bedanke ich mich bei der goSecurity und allen Mitarbeitenden für die spannende und lehrreiche Zeit. Ich werde mich weiterhin für eine Schweiz ohne Schäden durch Cyberattacken einsetzen, so wie ich es bei goSecurity lernen durfte. Über eine Kontaktanfrage bei Linkedin oder XING würde ich mich freuen.