[Warning] Kritische Schwachstelle im Umgang mit der Java "Commons Collection" - betrifft uA WebSphere, JBoss, WebLogic

Robert Waldner waldner at cert.at
Tue Nov 10 12:15:02 CET 2015


10. November 2015

Beschreibung

   Laut einem Blog-Post von Fox Glove Security (s.u.) 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



-- 
// CERT Austria - Robert Waldner <waldner at cert.at>
// http://www.cert.at/ - T: +43 1 5056416 78
// Eine Initiative der nic.at GmbH
// http://www.nic.at/ - Firmenbuchnummer 172568b, LG Salzburg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cert.at/cgi-bin/mailman/private/warning/attachments/20151110/495f0f43/attachment.sig>


More information about the Warning mailing list