3. Update: Kritische Schwachstelle im Umgang mit der Java "Commons Collection" - betrifft uA WebSphere, JBoss, WebLogic

10. November 2015

Update 11. November 2015, 09:15h
Update 12. November 2015, 07:00h
Update 16. November 2015, 15:15h

Beschreibung

Laut einem Blog-Post von Fox Glove Security existiert in (bzw. im Umgang mit) der weit verbreiteten Java Commons Collection ein Sicherheitsproblem.

CVSS Score (laut Fox Glove Security): 10.0

Details

Ein Angreifer kann eine Applikation, die ungeprüfte und entsprechend präparierte serialisierte Objekte akzeptiert, und die Commons Collection im Java Class Path hat, dazu bringen beliebigen Code mit den Rechten der Anwendung auszuführen. Je nach Konfiguration kann die Commons Collection auch durch andere Software in den Class Path eingefügt worden sein.

Auswirkungen

Da der Angreifer nach einem erfolgreichen Angriff prinzipiell beliebigen Code mit den Rechten der Java Applikation (meist der User des Webservers, etwa www-data oder apache) auf den betroffenen Systemen ausführen kann, sind alle Daten auf diesen Systemen, sowie potenziell alle durch diese erreichbaren (etwa durch ausspionierte Zugangsdaten, Datenbanken, VPN, Fileshares, etc.) Daten und anderen Systeme gefährdet.

Da der Exploit nun breit öffentlich bekannt geworden und auch relativ einfach auszunutzen ist, ist davon auszugehen, dass sich diverse Akteure nun darauf konzentrieren werden, diesen auszunutzen.

Betroffene Systeme

Laut Fox Glove Security sind unter anderem die folgenden, weit verbreiteten Applikationen/Frameworks betroffen:

• WebSphere Application Server
• JBoss Application Server
• Jenkins
• WebLogic Application Server
• OpenNMS (via RMI)

Welche anderen Applikationen noch betroffen sein könnten, ist nicht bekannt.

Abhilfe

Da das Problem nicht in der "Commons Collection" selbst liegt, sondern darin, wie diese oft eingesetzt wird, sowie dem Umstand, dass Java-Applikationen oft ihren eigenen Satz an Libraries mitbringen (und nicht auf die vom Betriebssystem oder dem Application Server zentral zur Verfügung gestellten zurückgreifen) gibt es hier keine einfache zentrale Update-Möglichkeit wie bei üblichen Sicherheitsproblemen in Software-Libraries. Betreiber von anfälligen Systemen sind daher darauf angewiesen, hier selbst tätig zu werden (Lösungsvorschläge/Ansätze dazu im Blog-Post von Fox Glove Security) - zumindest bis Updates der jeweiligen Software-Hersteller vorliegen.

• Für WebSphere könnte dieses Problem bereits behoben worden sein, siehe IBM Security Bulletin 1883573: http://www-01.ibm.com/support/docview.wss?uid=swg21883573
• Jenkins hat einen Post bezüglich Mitigation dieses Problems veröffentlicht: https://jenkins-ci.org/content/mitigating-unauthenticated-remote-code-execution-0-day-jenkins-cli
• OpenNMS hat auch eine Anleitung zur Mitigation (Firewall-Rules): http://www.adventuresinoss.com/2015/11/09/opennms-rmi-exploit/

Die Apache Software Foundation hat auch einen Fix/Workaround dazu entwickelt, der das Default-Verhalten der betroffenen Funktion so verändert, dass diese nicht mehr ohne explizite Konfiguration (de)serialisierbar ist, siehe https://issues.apache.org/jira/browse/COLLECTIONS-580.

Sollten wir zu einem späteren Zeitpunkt über mehr Informationen verfügen, werden wir diese Warnung entsprechend updaten - die aktuelle Version ist immer via https://cert.at/ abrufbar.

Empfehlungen

Die meisten Applikationen akzeptieren serialisierte Objekte nur auf Management-Interfaces. Wenn dafür Sorge getragen wird, dass diese nur eingeschränkt erreichbar sind, ist ein Teil des Problembereichs abgedeckt - dennoch sollte auch in internen Netzen möglichst auf weitere Einschränkungen gesetzt werden (etwa nur authentisierten+authorisierten Sessions Zugriff auf derartige Interfaces zu geben).

Hinweis

Generell empfiehlt CERT.at, wo möglich die "automatisches Update"-Features von Software zu nutzen, parallel Firewall-Software aktiv und den Virenschutz aktuell zu halten.

---

Informationsquelle(n):

Blog-Post von Fox Glove Security (englisch)
http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/
Artikel dazu bei Slashdot (englisch), mit tw. hilfreichen Kommentaren
http://developers.slashdot.org/story/15/11/08/0346258/vulnerability-in-java-commons-library-leads-to-hundreds-of-insecure-applications
Eintrag dazu beim Apache Bugtracker (englisch), inkludiert einen möglichen Library-seitigen Fix/Workaround
https://issues.apache.org/jira/browse/COLLECTIONS-580
Blog-Post dazu von SANS ISC (englisch)
https://isc.sans.edu/forums/diary/ICYMI+Widespread+Unserialize+Vulnerability+in+Java/20353/
Hintergrund zu Java J2EE Pentesting (Marc Schoenefeld, 2006, PDF, englisch)
https://dl.packetstormsecurity.net/hitb06/DAY_1_-_Marc_Schoenefeld_-_Pentesting_Java_J2EE.pdf
Oracle Secure Coding Guidelines for Java SE, Kapitel 8 "Serialization and Deserialization" (englisch)
http://www.oracle.com/technetwork/java/seccodeguide-139067.html#8
Artikel zum Thema bei Security Week (englisch)
http://www.securityweek.com/remote-code-execution-flaw-found-java-app-servers