IBMs Websphere Application Server wird über die so genannte Administrationskonsole verwaltet. In diesem Web-Interface ist eine Sicherheitslücke entdeckt worden, über die ein entfernter Angreifer die Einstellungen des Websphere-Servers ändern kann.
Die Web-Konsole ist anfällig für eine Cross-Site-Request-Forgery-(CSRF) Attacke, dank der ein entfernter Angreifer Aktionen mit Administratorrechten ausführen kann. Natürlich hat IBM daran gedacht, die Konsole so gut wie möglich gegen solche Angriffe zu sichern. hat der Hersteller als Schutzmechanismus ein Token namens ‘csrfid’ auf jeder Seite als verstecktes Feld eingebaut. Nur Anfragen an die Konsole mit korrektem Token für die aktuelle Benutzer-Session werden abgearbeitet. Dieser Mechanismus ist sehr verbreitet und wird häufig gegen CSRF-Attacken eingesetzt. Allerdings setzt das voraus, dass die Entwickler auch wirklich bei jeder Aktion prüfen, ob das Token korrekt ist. Und genau hier liegt die Schwachstelle in der Websphere-Implementierung: Einige Teile der Administrator-Konsole überprüfen das Token einfach nicht.
Im einzelnen sind die folgenden kritischen Bereiche der Konsole betroffen: ‘Security | Global Security’ und ‘Save changes to the master configuration’. Ein Angreifer kann dies ausnutzen, um die Optionen für ‘Administrative Security’, ‘Application Security’ und ‘Java 2 Security’ zu deaktivieren und diese Einstellung dann zu speichern.
Wie führt der Angreifer die Attacke konkret aus? Sie verläuft nach dem Standardschema für CSRF-Angriffe. Zunächst identifiziert er sein Opfer, das heißt einen Websphere-Administrator, beispielsweise bei der Firma XYZ. Dann bastelt er sich eine einfache Website, die ungefähr
folgendermaßen aussieht:
<html>
<body>
<iframe id="iframe1" style="visibility:hidden"></iframe>
<iframe id="iframe2" style="visibility:hidden"></iframe> <script> document.getElementById("iframe1").src = "https://www.firma-XYZ.de:9043/ibm/console/adminSecurityDetail.do?action=Edit&displayActiveUserRegistry=Repositorios+federados&selectUserRegistry=WIM&activeAuthMechanism=LTPA&apply=Aplicar"; document.getElementById("iframe2").src = "https:///www.firma-XYZ.de:9043/ibm/console/syncworkspace.do?saveaction=save&directsave=true"; </script>
</iframe>
</body>
</html>
Hier verwendet der Angreifer Javascript für die Attacke, das zwei unsichtbare Iframes erzeugt und deren “src”-Attribut auf die Angriffs-URL setzt. Ist nun der Websphere-Administrator der Firma XYZ auf der Konsole angemeldet und lädt die HTML-Seite des Angreifers, werden die entsprechenden Aktionen ausgeführt. Die erste Anfrage dient dem Abschalten der ‘Administrative Security’- und ‘Application Security’-Optionen. Die zweite Anfrage speichert diese Änderungen permanent in der Websphere-Konfiguration.
Betroffen sind die Server-Versionen 7.0.0.11 und 7.0.0.13.
Als Workaround auf der Serverseite bietet es sich beispielsweise an, den HTTP-Referer zu prüfen, um herauszufinden, wo die HTTP-Anfrage herkommt. Hat der Angreifer obige Seite beispielsweise auf einem Rechner www.angreifer-xyz.de platziert, so kann der Server dies erkennen. Der Administrator könnte mit Hilfe einer Web Application Firewall festlegen, dass nur solche Anfragen von der Websphere-Administrator-Konsole angenommen werden, die auch von der Firmenseite stammen. Application-Firewalls arbeiten auf der Anwendungsebene und filtern das HTTP-Protokoll direkt, wodurch ein guter Schutz gegen solche Webbasierten Angriffe gegeben ist.
Auf der Clientseite können sich Firefox-Anwender beispielsweise mit der NoScript-Extension schützen. Diese Erweiterung enthält das Modul “Application Boundaries Enforcer” (ABE), womit der Anwender festlegen kann, dass Anfragen wie die obige nur von firma-XYZ.de gestellt werden dürfen. Hierzu muss er folgende ABE-Regel implementieren:
Site *.firma-XYZ.de Accept from SELF Deny
Diese Regel lässt alle Anfragen von und an die Seite zu, verbietet aber externe Anfragen, was den oben skizzierten Angriff verhindert.
Daneben gibt es auch Maßnahmen, die keinen effektiven Schutz gegen CSRF bieten: Geheime Cookies etwa stellen keinen effektiven Schutz gegen CSRF-Attacke dar. Das liegt daran, dass Cookies bei jeder Anfrage übermittelt werden. Klickt das Opfer auf den Angriffslink, so wird das Cookie trotzdem übertragen.
Auch reine POST-Übertragungen helfen nicht gegen CSRF-Attacken: HTML-Formulare können grundsätzlich via GET oder POST übertragen werden. Aufgrund der offensichtlichen Datenübertragung mittels URI beim GET-Verfahren könnte man meinen, dass POST besser vor CSRF-Attacken schützt. Das stimmt aber nicht nicht, denn ein Angreifer kann das Opfer auch dazu bringen, eine POST-Anfrage abzusetzen, wodurch sich genauso einfach die CSRF-Attacke durchführen lässt.
