Letzte Woche war ich damit beschäftigt, das Hacking einer PHP-basierten Website nachzuvollziehen. Die Analyse ergab gleich mehrere Fehler, die sich in Kombination zu einem massiven Problem auswuchsen:
- Eine zentrale Datei, die das Umschreiben von gewöhnlichen Web-Adressen auf PHP-Skripts vornahm und schon seit ca. über einem Jahr ohne Probleme im Einsatz war, war kürzlich an einigen Stellen modifiziert worden. In der Testphase war diese Datei "auf die Schnelle" leider mit Statements versehen worden, die Adress-Anteile ungefiltert über PHP-"echo"-Kommandos ausgab. Im Produktivierungsprozess wurde dann "in der Hektik" vergessen, diese Statements vollständig zu deaktivieren. Jeder, der sich ein wenig mit PHP und Sicherheit auskennt, weiß, dass solche Kommandos das primäre Einfallstor für XSS-Angriffe darstellen.
- In den Tests vor der Produktivsetzung wurde zwar verifiziert, dass die Website mit all ihren Links korrekt lief. Der geänderte Rewrite-Prozess für Adressen wurde somit positiv bestätigt. Leider wurden Negativtests für bestimmte Typen von fehlerhaften Adresseingaben bzw. Adresseingaben zu nicht vorhandenen Seiten nicht im notwendigen Umfang durchgeführt. Solche Tests hätten schnell und deutlich gezeigt, dass manipulierte Eingaben und z.T. auch erratische Eingaben zu fehlenden Seiten ungefilterte Programm-Ausgaben zeitigten. So fiel das aber leider gar nicht auf.
- Durch Einschleusen von Javascript-Code konnte von Angreifern die DOM-Ebene manipuliert werden. Das ließ sich relativ leicht nachstellen. Allein dieser Punkt eröffnete bereits ein großes Schadenspotential. Als schlimmer erwies sich aber die durch XSS eröffnete Möglichkeit zum Auslesen von Session-Cookies. Dadurch stand einer Session-Übernahme nur noch wenig entgegen. Als besonders schlimm stellte sich das für Sessions heraus, in denen ein Zugriff auf eine ältere PhpMyAdmin-Installation stattfand. Leider war das Programm wegen fehlender SSL-Zertifikate in der gleichen Web-Domäne untergebracht worden. Hier war am falschen Ende gespart worden: Das Gemeine ist, dass sich eine "Sicherheits"-Überlegung - nämlich die notwendige Verschlüsselung von Transaktionen zur Datenbank-Pflege - im hier beschriebenen Angriffsszenario als Bumerang erwies.
- Interessanterweise nutzten die Angreifer die Sessionübernahme nicht direkt zur Manipulation der Datenbankinhalte. Die ältere PHP-Version wies nämlich auch noch eine Verwundbarkeit nach CVE-2017-9841 auf: Ein standardmäßig mit ausgeliefertes PHP-Programm eines Vendors beinhaltete einen eval()-Aufruf. Dadurch wurde dann die Ausführung von relativ beliebigem PHP-Code ermöglicht.
- Für die Website wurde keine TLS/SSL-Verschlüsselung erzwungen.
Im Endeffekt war durch die Kombination der obigen Punkte das Tor zu einem Hacker-Paradies geöffnet wurde; missbraucht wurde die Site denn auch prompt von Angreifern mit IP-Adressen in Albanien, Bulgarien, Rumänien, USA.
Was lernt man aus diesem Szenario?
Der Ablauf ist geradezu klassisch: Hastiges Arbeiten und Unaufmerksamkeiten eines Entwicklers reißen in der Konsequenz ein großes Loch in den Betrieb einer Website.
Worin lag im Ablauf aber der eigentliche Fehler? Dass beim schnellen Coding ein sauberes Exception-Handling mal umgangen wird, ist eine Sache. Ein PHP-Code mit echo-Befehlen, die eine ungefilterte Ausgabe auch nur fragmentierter Teile irgend eines Inputs liefern, darf aber keine QS passieren.
Hier meine ich einerseits ein Code-Review samt Scannen des Codes auf print oder echo-Befehle. Ich meine andererseits aber auch den Testansatz: Wenn man einem Rewrite-Programm für Adressen arbeitet, sollte man natürlich unbedingt das Verhalten für ungewöhnlichen Adress-Input testen. Ferner hätte eine Überwachung der Log-Protokolle einen Missbrauch eher entdecken lassen, als es dann de facto geschehen ist (nämlich durch den Hosting-Provider).
Ein weiterer Fehler liegt natürlich in der alten Version von PhpMyAdmin - hierfür hätten die herausgegebenen Warnungen CVEs, etc. verfolgt werden müssen. Das Risiko, dass mit der Positionierung dieser SW in derselben Domäne im Fall eines XSS-Angriffs verbunden war, war unterschätzt worden.
Eine interessante Frage im Rahmen dieses Blogs ist nun:
Hätte hier ein ISMS nach der ISO /IEC 27000 geholfen?
Ich meine schon. Im Rahmen der Risko-Analyse und Risiko-Bewertung hätte das Thema Web-Anwendungen und zugrunde liegende Programme sicher eine Rolle gespielt. Die Problematik von XSS-Angriffen hätte dort (u.a.) untersucht werden müssen. Als Maßnahme zur Risikobehandlung wären dann mit hoher Wahrscheinlichkeit die hier unterlassenen Schritte als Teil eines einzuhaltenden "Produktivierungsplans" definiert worden. Betroffen sind im hier gegebenen Kontext gleich eine ganze Reihe von in der Praxis obligatorischen Maßnahmen-Vorgaben des Anhangs zur Norm ISO/IEC 270001: Zu nennen sind die Maßnahmen A10.1, A10.3, A10.9, A10.10. Relevant sind ferner A11.5, A12 (bes. A12.2.4, A12.4, A12.5, A12.6), A15.2, A15.3.
Ich will gar nicht auf Details der Punkte eingehen. Man ist aber immer wieder erstaunt, wie gut eigentlich der Maßnahmenkatalog der Norm bei geeigneter Umsetzung helfen würde, Szenarien wie das oben beschriebene zu vermeiden.
