Es trifft mich wie ein Blitz …

Java-Logo
… heute früh meldete Heise Security einen seit ca. neun Monaten bekannten Exploit, der sich als besonders kritisch einstuft.
Zu diesem Zeitpunkt war ich gerade in einem Meeting mit Bernd und bin fast aus allen Wolken gefallen, als Sebastian mit dieser Nachricht in der Tür stand.
Ich bot an dieser Meldung genauer auf den Grund zu gehen, da ich selber begeisterter Java Entwickler bin und mich wie vermutlich auch viele von euch direkt oder eben auch indirekt mit Java und dem erweiterten Stack tagtäglich beschäftige.
Im Netz kursiert seit dem 6. November der folgende Artikel, dessen Autor Herr Stephen Breen, sehr genau, fast schon spielerisch beschreibt, wie dieser Exploit denn genau funktioniert.
Er schreibt dort im wesentlichen über die in Java schon seit Version 1.1 verfügbare ‘Serializable’ Schnittstelle, die es dem Programmierer ermöglicht fertig instanziierte Java Objekte über das Netzwerk zu senden oder auch von Festspeichern zu lesen. Diese Klasse ist allerdings nur der kleinere Teil des Übels, genauer gesagt ist es die Methode “InvokerTransformer” der “Apache CommonCollections API” die hier über die “Java Reflections API” es einem möglichen Angreifer hier Kinderleicht macht seinen Schadcode auf dem Zielsystem zur Ausführung zu bringen.
Nun könnte man fast meinen das einen das ja nicht wirklich betrifft, da muss ich euch leider enttäuschen und das sogar berechtigterweise.
Folgende Szenarien um das Problem im wesentlichen zu konkretisieren:

  • Servlet Container sowie Application Server verwenden diese API, wie im Artikel zu lesen ist, auch um Cookies und HTTP Header zu lesen. Das ist im ersten Moment noch nicht so kritisch, nur werden heutzutage auch viele Cross-Site-Request-Forgery und andere Angriffe dazu verwendet die Systeme der Wahl erfolgreich zu attackieren.
    Ein Angreifer könnte versuchen über entsprechende HTTP Header mit Cookie Payload ein bösartiges Objekt seiner Wahl einzubetten, das wiederum wenn auf dem Ziel System einmal angekommen, im ersten Moment Zugriff auf die der dort laufenden Anwendung zu Verfügung stehenden Klassen nutzen kann. Hier ist es dann bereits ein leichtes dem Application Server bzw. ServletContainer einen separaten URL Context ( zum Beispiel unter http://application.yourdomain.com/nasty-little-exploit ) mit anderen Funktionen unterzujubeln. Et Voila der Schaden wäre bereits immens.
    Auch ein simpler Download als Injected Java Objekt könnte hier den Rest des Ziel Systems mit entsprechenden Schadcode über eine Art Bootstrap Job infizieren.
    Um dem vorher gehenden Beispiel noch einmal etwas Würze zu verleihen, einen bereits bestehenden URL Context einer großen Bank könnte so manipuliert werden, um Kundendaten abzugreifen. Auch hier wäre der Schaden nicht zu ermessen.
  • Die Software von Drittanbietern ist davon mit unter auch betroffen. Vor allem wenn sie die oben genannte Schnittstelle verwendet oder sogar muss. Hier sollte man schnell Handeln aber auf keinen Fall das Problem ignorieren. Allein anzunehmen das hier ja bereits verschlüsselte Kommunikation stattfindet, schütz vor diesem Exploit nicht.
  • Ich schlage ihnen daher vor, den Rat des Autors zu beherzigen und diese Schnittstelle aus der Apache CommonCollections API zu verbannen, allein die Nutzung der Application einzustellen um anschließend ein komplettes Refacturing der Anwendungen vorzunehmen verursacht vermutlich sehr hohe Kosten und ist hier mit der Gefahr verbunden sich einem weiteren Exploit zu schaffen, jedoch recht schnell geschehen. Schnelle Änderungen schaffen immer wieder neue Bugs und vermutlich auch neue noch unbekannte ZeroDay Vectoren.

Dem einen oder anderen von euch stellen sich hier vermutlich schon die Nackenhaare auf, daher wollen wir nun lieber über die Deeskalation bzw. möglichen Lösungen kümmern, was gilt es nun zu tun!?

  • Evaluieren ob die Apache CommonCollections API auf dem eigenen Systemen existiert.
  • Prüfen ob die eingesetzte Java Software von dieser Gebrauch macht.
    • Wenn dem so ist, sollte die Anwendung aus der DMZ entfernt werden, das blockieren der von außerhalb erreichbaren Ports genügt im ersten Moment bereits.
    • Wenn dem nicht so ist, dann Schwein gehabt.
  • Sofern die betroffenen Anwendungen ermittelt werden konnten, sollten folgende Punkte abgearbeitet werden.
    • Test der Anwendung in isolierter Umgebung ( Docker kann hierbei recht hilfreich sein ) mit der Apache CommonCollections API. Wobei vor Beginn die org/apache/commons/collections/functors/InvokerTransformer.class bereits aus der API entfernt sein sollte.
      Wenn es hier nichts zu beanstanden gibt und die Application auch ohne diese Schnittstelle zu laufen scheint, kann diese wieder in den Betrieb überführt werden.
    • Sollte die Anwendung nicht korrekt funktionieren, wird empfohlen diese unter Vorbehalt nur den eig. Mitarbeitern zur Verfügung zu stellen, sollte es sich bei der Anwendung allerdings, um eine des Kunden handeln, sieht es da schon etwas schwieriger aus, wobei sich vmtl. kein Kunde den damit einhergehenden Gefahren gerne ausgesetzt sieht.
      Hier sollte dem Kunden angeraten werden, die Application bis zu einem erfolgreichen Security Audit vom Netz zu nehmen.

Weitere Lösungsansätze sind derzeit noch nicht bekannt, wir versuchen euch aber entsprechend auf dem Laufenden zu halten.
Nützliche Links:

Link Inhalt
http://www.heise.de/security/meldung/Zero-Day-Alarm-fuer-viele-Server-mit-Java-2913605.html Heise Security Artikel
http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/ der Exploit im Detail
https://commons.apache.org/proper/commons-collections/javadocs/api-release/org/apache/commons/collections4/functors/InvokerTransformer.html Javadoc zum betroffenen Interface
https://github.com/frohoff/ysoserial das daraus entwickelte Framework für Penetration Tests
https://www.cvedetails.com/vulnerability-list/vendor_id-93/product_id-19117/Oracle-JRE.html Java CVE – Übersicht

Weekly Snap: InGraph, Google Analytics for Prestashop, LDAP & Distributed Shell

weekly snap26 – 30 November ended the month with mini guides on Distributed Shell and LDAP, Google Analytics and Prestashop, alongside some familiar hardware, InGraph and news from Down Under.
Eric gave a sneak preview to features planned for coming releases of InGraph, concluding The Ultimate Guide to InGraph.
Stefan fiddled with batch mode clusters via ssh using Distributed Shell dsh, while Lennart showed how to use LDAP filters for authorisation settings in recursive groups.
Georg then showed how to make the most of Google Analytics in Prestashop and introduced one of his best sellers, the HWg-STE network thermometer.
On sabbatical, Birger got settled into Sydney and reflected on a successful Movember 2012 as Bernd shared his thoughts on Africa’s internet landscape.

Happy Birthday Smiley

Neben dem Talk Like A Pirate Day, ist der heutige Tag noch aus einem anderen Grund denkwürdig: Der Smiley hat Geburtstag. Die beiden Grundformen : – ) und : – ( wurden am 19. September 1982 vom späteren Informatik-Professor Scott E. Fahlman zum ersten Mal vorgeschlagen. Damit gilt er als Erfinder der Smileys und das heutige Datum als ihr offizieller Geburtstag. Damit herzlichen Glückwunsch zum sechsundzwanzigsten.

Julian Hein
Julian Hein
Executive Chairman

Julian ist Gründer und Eigentümer der NETWAYS Gruppe und kümmert sich um die strategische Ausrichtung des Unternehmens. Neben seinem technischen und betriebswirtschaftlichen Background ist Julian häufig auch kreativer Kopf und Namensgeber, beispielsweise auch für Icinga. Darüber hinaus ist er als CPO (Chief Plugin Officer) auch für die konzernweite Pluginstrategie verantwortlich und stösst regelmässig auf technische Herausforderungen, die sonst noch kein Mensch zuvor gesehen hat.

Firefox 3 & Download Day

Heute erscheint (endlich) die finale Version von Firefox 3 und gleichzeitig hat Mozilla den Download Day ausgerufen. Es soll versucht werden innerhalb von 24 Stunden einen Weltrekord für die meisten Downloads aufzustellen. Da Sie den neuen Firefox ja sowieso herunterladen werden, können Sie es dann auch gleich heute machen und so mithelfen, dass der Rekordversuch möglichst gut gelingt. Wobei, gelingen wird er auf jeden Fall, denn so wie ich die Website verstanden habe, gibt es noch gar keinen alten Rekord, den es zu schlagen gilt. Es geht nur darum mit einer möglichst imposanten Anzahl an Downloads in Guinness Buch der Rekorde zu kommen. Das neue Release soll ab 10:00 Uhr (US Westküste) verfügbar sein; bei uns entspricht dass dann 19:00 Uhr.

Julian Hein
Julian Hein
Executive Chairman

Julian ist Gründer und Eigentümer der NETWAYS Gruppe und kümmert sich um die strategische Ausrichtung des Unternehmens. Neben seinem technischen und betriebswirtschaftlichen Background ist Julian häufig auch kreativer Kopf und Namensgeber, beispielsweise auch für Icinga. Darüber hinaus ist er als CPO (Chief Plugin Officer) auch für die konzernweite Pluginstrategie verantwortlich und stösst regelmässig auf technische Herausforderungen, die sonst noch kein Mensch zuvor gesehen hat.

www

Normalerweise ist die Website einer Firma ja unter der Adresse www.meinefirma.de zu erreichen. Also Domainname plus Subdomain “www”. Trotzdem hat man früher seinen DNS aber eigentlich immer so konfiguriert, dass auch die Domain alleine funktioniert, also nur meinefirma.de. In letzter Zeit fallen mir aber immer mehr Firmen auf, bei denen das nicht geht und zwar, wenn ich eine eMail bekomme und den Domainnamen per Cut’n’Paste in den Browser kopiere. Ist das pure Nachlässigkeit bei der Konfiguration der Zonenfiles oder gibt es einen Grund warum das nicht mehr geht?
Ich habe das bei uns so eingerichtet, dass man sich sogar vertippen kann und auch http://ww.netways.de oder http://wwww.netways.de eingerichtet. Und natürlich zeigt auch http://netways.de und sogar http://www-netways.de auf unsere Website. Damit Google aber keinen Double Content erkennt wird das alles per redirect auf die eigentliche Website weitergeleitet.

Julian Hein
Julian Hein
Executive Chairman

Julian ist Gründer und Eigentümer der NETWAYS Gruppe und kümmert sich um die strategische Ausrichtung des Unternehmens. Neben seinem technischen und betriebswirtschaftlichen Background ist Julian häufig auch kreativer Kopf und Namensgeber, beispielsweise auch für Icinga. Darüber hinaus ist er als CPO (Chief Plugin Officer) auch für die konzernweite Pluginstrategie verantwortlich und stösst regelmässig auf technische Herausforderungen, die sonst noch kein Mensch zuvor gesehen hat.