hasegawatadamitsu/cve-2014-0094-test-program-for-struts1CVE-2014-0094 Testprogramm für struts1
Dies fasst die Auswirkungen von CVE-2014-0094 auf Struts 1 zusammen. Sofern nicht anders angegeben, wurden alle Tests mit Java 1.7.0_02, Struts 1.3.10, Apache-Tomcat-6.0.39 und FreeBSD 8.2 durchgeführt.
Es wird keinerlei Gewähr für den Inhalt von Quellen, Texten usw. übernommen. Auch übernehme ich keine Verantwortung für irgendwelche Ereignisse, die eintreten könnten. Insbesondere bei Missbrauch dieses Inhalts bin ich in keiner Weise beteiligt. (Dennoch gibt es nichts Neues.)
Dieses Mal habe ich konkrete Lösungsbeispiele in Anlehnung an verschiedene Webseiten vorgestellt. Sofern nicht allgemein bekannt, habe ich die referenzierten URLs in den Quellen angegeben. Ich bin dankbar für die Veröffentlichung der Informationen.
Ich habe versucht, ohne allzu viele Fachbegriffe auszukommen, auch wenn dies möglicherweise irreführend ist, aber in verständlichen Worten zu beschreiben.
Die vorliegende Sicherheitslücke in Struts 1 wird als CVE-2014-0094, S2-020 usw. bezeichnet, ob es einheitliche Namen gibt oder nicht, ist nicht ganz klar, jedenfalls nenne ich sie hier CVE-2014-0094.
Es muss nicht noch einmal betont werden, aber CVE-2014-0094 birgt ein sehr großes Problem.
http://www.nta.go.jp/sonota/sonota/osirase/service.htm
„e-Tax-Software (WEB-Version)“, „Bereich zur Erstellung von Steuererklärungen“, „NISA (japanische ISA) Ecke“ – Mitteilung zur Serviceunterbrechung (wichtig) vom 25. April 2014 zeigt, dass der Webdienst der japanischen Steuerbehörde Struts 1 verwendet und der Service noch am Tag der Entdeckung eingestellt wurde.
Um den Schaden so gering wie möglich zu halten, wurde offenbar schnellstmöglich eine Abschaltung durchgeführt.
In eigenen Experimenten konnte ich feststellen, dass allein durch den Zugriff auf eine URL der Service zum Stillstand gebracht und beliebige Dateien preisgegeben werden können.
Allein durch das Aufrufen einer URL und das Senden einer E-Mail mit dieser URL an eine Mailingliste über eine anonyme E-Mail-Adresse wird die Identifizierung des Täters erschwert, und der Service kann leicht zum Stillstand gebracht werden.
Es ist ein so einfach angreifbares Problem.
Dies ist wohl das Wichtigste. Wenn Dritte mindestens eine mögliche Betroffenheit ankündigen, ist der eigentliche Ansatz, den Service zuerst zu stoppen, um eine Ausweitung des Schadens zu verhindern. Selbst wenn spätere Untersuchungen ergeben, dass keine Auswirkungen bestehen, sind die einmal preisgegebenen Informationen nicht wiederherstellbar. Dennoch sind politische Entscheidungen erforderlich. In Unternehmen wird beispielsweise die ethische Haltung, das alltägliche Problembewusstsein, das Risikomanagement usw. hinterfragt.
Das Problem beruht darauf, dass einige Konfigurationswerte des Systems teilweise überschrieben werden können. Es muss untersucht werden, welche Konfigurationswerte überschrieben werden können. Anhand dieser Werte lässt sich beurteilen, welche Angriffe möglich sind.
Diese Konfigurationswerte unterscheiden sich je nach Servlet-Container. Bei Tomcat 6 ist die Ausführung beliebigen Codes vermutlich nicht möglich, aber bei Tomcat 8 ist eine beliebige Ausführung möglich. Bei anderen Umgebungen wie Jetty, WebSphere Application Server usw. muss geprüft werden, welche Konfigurationswerte vorhanden sind.
Bei Tomcat 6 sollen 23 solcher Konfigurationsänderungen möglich sein. Wenn class.classLoader.resources.dirContext.docBase geändert wird, wird der normale Systembetrieb unmöglich, und statt der Anzeige von JSPs kann durch Angabe einer Datei auf dem Server eine beliebige Datei abgerufen (preisgegeben) werden.
Bei Tomcat 8 ist beliebiger Code ausführbar, weil dort mehr Werte konfigurierbar sind als bei Tomcat 6. Wenn diese Werte im verwendeten Servlet-Container nicht vorhanden sind, halten sich die Probleme momentan in Grenzen.
Die Änderung von Konfigurationswerten ist nicht nur möglich, indem die Zeichenfolge als Teil der URL übergeben wird, sondern auch als verstecktes Feld einer normalen Anfrage oder sogar durch Einfügen des Werts in ein Cookie.
Aus den Zugriffsprotokollen ist nicht ersichtlich, ob ein Wert als verstecktes Feld gesetzt wurde.
Häufig werden sonntags nachts Neustarts durchgeführt. Kurz davor könnte jedoch eine Änderung der docBase und ein Dateiabruf erfolgt sein, und da anschließend der Neustart des Systems erfolgt, fällt dies für den Systemadministrator kaum auf. Wenn in jenem Zeitraum vermehrt Status 404, 500 usw. auftreten, ist es wahrscheinlich, dass einige Dateien preisgegeben wurden.
Struts 1 wird nicht mehr unterstützt (was bedeutet Support für Open Source eigentlich? – das sei dahingestellt), und es gibt keine Sicherheitspatches. Man muss selbst eine Lösung finden.
Der Ursprung des Problems liegt in BeanUtil; es muss eine Implementierung erfolgen, die bei unzulässigen Zeichenketten diese ignoriert. BeanUtil ist ein Werkzeug zum Ändern von Objektwerten (dies ist eine stark vereinfachte Beschreibung).
Ein Implementierungsbeispiel ist
com.haselab.struts.filter
web.xml
Kurz erklärt: In web.xml wird beim Systemstart ein Programm aufgerufen, das das Verhalten von BeanUtil ändert. SafeResolverListener.java wird aufgerufen, sodass BeanUtil künftig SafeResolver.java verwendet. In SafeResolver.java wird, wenn die zu analysierende Zeichenkette (unabhängig von Groß-/Kleinschreibung) 'classLoader' ist, "" zurückgegeben. Das bedeutet, dass der Wert für classLoader nicht mehr beliebig gesetzt werden kann. Dieses Verhalten wurde von https://gist.github.com/nakamura-to/11347570 übernommen. (Es ist ein kurzes Programm, daher unverändert.)
Falls die Anwendung selbst eine Änderung der Einstellung 'classLoader' benötigt, wäre dies mit dieser Methode nicht möglich, da diese Einstellung blockiert wird. In der Regel sollte jedoch keine Konfiguration namens classLoader vorhanden sein, daher ist dies vorerst unproblematisch. Bei Unsicherheit kann man über das gesamte Anwendungs-Verzeichnis grep -r -i classLoader * ausführen, um sicherzustellen, dass es nicht vorkommt.
Ich habe die Änderung der docBase getestet. Nach dem Deployment mit Maven sehen Sie sich bitte den Struts-Bereich im Browser an. Mit jedem Klick auf die Schaltfläche wird die docBase geändert und die Datei /etc/passwd angezeigt.