Zero-Day-Alarm für viele Server mit Java

Posted on Posted in Hacker News

Gefährliche Zero-Day-Exploits für WebLogic, WebSphere, JBoss, Jenkins und OpenNMS demonstrieren nachdrücklich, dass auch Java-Anwendungen auf dem Server nicht automatisch sicher sind. Konkreter Auslöser ist die verbreitete Bibliothek Common Collections.

Die veröffentlichten Zero-Day-Exploits für WebLogic, WebSphere, JBoss, Jenkins und OpenNMS sind nur Beispiele, mit denen Stephen Breen Aufmerksamkeit auf ein lange unterschätztes Problem von Java-Anwendungen auf dem Server lenken will. Er demonstriert das mit einer akuten Sicherheitslücke in der weit verbreiteten Java-Bibliothek Common Collections. Das schlimmste daran: Obwohl die Lücke seit neun Monaten bekannt ist, gibt es immer noch keinen richtigen Fix.

Auf verwundbaren Servern können Angreifer direkt eigenen Code einschleusen und ausführen; eine vorherige Authentifizierung ist dafür nicht erforderlich. Die Zahl der anfälligen Server-Anwendungen ist derzeit nicht abzuschätzen. Common Collections kommt bei sehr vielen Java-Applikationen zum Einsatz; die aufgeführten Flaggschiffe sind lediglich Beispiele. Mit den bereitgestellten Tools und der Dokumentation lassen sich auch für andere Java-Applikationen recht einfach scharfe Exploits basteln.

Java auf dem Server

Java im Browser hat seinen Ruf als immanentes Sicherheitsproblem bereits weg und ist dort auch quasi bedeutungslos. Für Server-Anwendungen genießt die objektorientierte Programmiersprache nach wie vor einen guten Ruf – unter anderem weil ihr Einsatz die verbreiteten Pufferüberläufe verhindert. Doch bereits vor neun Monaten wiesen Gabriel Lawrence und Chris Frohoff mit ihrem Vortrag Marshalling Pickles auf eine andere große Baustelle hin, die man sich beim Einsatz von Java einhandelt: die Serialisierung.

Für die Kommunikation mit Java-Anwendungen werden Objekte in eine lineare Folge von Bytes umgewandelt, die sich abspeichern und übertragen lässt. Der Empfänger liest diese Byte-Folge ein und macht daraus wieder aktive Objekte. Obwohl diese angelieferten Objekte aus dem Netz stammen und Code enthalten können, prüfen die Java-Server-Applikationen oft gar nicht oder nur sehr flüchtig, ob sie tatsächlich vertrauenswürdig sind. Sprich: Ein Angreifer, der einer Java-Server-Applikation ein passendes Objekt senden kann, hat gute Chancen, damit Unheil anzurichten und im Extremfall sogar eigenen Code im Kontext des Servers zu aktivieren.

Konkret wiesen die Forscher dieses Problem mit fatalen Konsequenzen in der Funktion InvokerTransformer der beliebten Java-Bibliothek Common Collectionsnach. Für die gibt es noch keine aktualisierte Version, die die Lücke stopft. Doch schlimmer noch: Selbst wenn es die gäbe, wird es sehr lange dauern, bis das Problem aus der Welt geschafft ist. Denn es ist keineswegs mit einem einfachen Update-Befehl getan; Java-Applikationen wie WebLogic, Jenkins und Co bringen in der Regel ihre eigenen Bibliotheken mit und die müssen alle irgendwie aktualisiert werden.

Kein einfacher Fix in Sicht

Admins, die Server mit Java-Anwendungen betreiben, müssen somit sich auf einiges an Arbeit einrichten. Denn obwohl das Problem bereits seit neun Monaten bekannt ist, gibt es immer noch keinen richtigen Fix. Tests der eigenen Installationen und eine zumindest provisorische Absicherung des Server sind somit weitgehend Handarbeit.

Einen ersten Überblick kann sich ein verunsicherter Admin mit einem Befehl wie

# grep -Rl InvokerTransformer .
./webapps/ROOT/WEB-INF/lib/commons-collections-3.2.1.jar

verschaffen. Das sollte alle jar- oder class-Dateien auflisten, die die anfällige Funktion enthalten. Wer dabei fündig wird, sollte möglichst dafür sorgen, dass die zugehörigen Dienste zumindest nicht mehr aus dem Internet zu erreichen sind. Als recht kruden Schutz empfiehlt Breen in seiner ausführlichen Zusammenfassung des Serialisierungs-Problems, die anfällige Funktion aus dem Java-Archiv zu entfernen. Da es sich dabei nur um ZIP-Dateien handelt, kann man mit einem Zip-Utility darin einfach die Datei org/apache/commons/collections/functors/InvokerTransformer.class löschen. Nur wenige Applikationen nutzen diese Funktion direkt, sodass die Chancen gut stehen, dass dabei nichts kaputt geht. Trotzdem sollte man das natürlich ausgiebig testen, bevor man es auf einem Produktionssystem macht.

Update 10.11.2015, 18:00: Red Hat stellt zusätzliche Informationen bereit, ob Red-Hat-JBoss-Produkte von dem Serialisierungs-Problem betroffen sind. Demzufolge ist insbesondere die JBoss Enterprise Application Platform ab Version 5 nicht akut betroffen, da dort eine Authentifizierung vorgeschaltet ist. Das Jenkins-Team beschreibt einen Workaround, wie man das Problem temporär entschärfen kann

Quelle: heise.de


Mitigating unauthenticated remote code execution 0-day in Jenkins CLI

Earlier today we received numerous reports about a previously undisclosed “zero day” critical remote code execution vulnerability and exploit in Jenkins core. Unfortunately the vulnerability was not disclosed to us ahead of its publication so we’re still working on more thorough fix. In the meantimehowever, we wanted to inform you of the issue and provide a workaround which will help prevent this exploit from being used against public Jenkins installations, for future reference this issue is being tracked privately as SECURITY-218 in our issue tracker.

The attack is mounted through the Jenkins CLI subsystem, so the work-around is to remove/disable the CLI support inside of the running Jenkins server.

Using the following Groovy script you can disable the attack vector in your Jenkins installations by navigating to “Manage Jenkins” and then to “Script Console”, or just go to http://your-jenkins-installation/script. This only addresses the current running Jenkins process, in order to make the workaround persist between restarts of the Jenkins server, add the script below to$JENKINS_HOME/init.groovy.d/cli-shutdown.groovy (create the directory if necessary, and the file).

import jenkins.*;
import jenkins.model.*;
import hudson.model.*;

// disabled CLI access over TCP listener (separate port)
def p = AgentProtocol.all()
p.each { x ->
  if (x.name.contains("CLI")) p.remove(x)
}

// disable CLI access over /cli URL
def removal = { lst ->
  lst.each { x -> if (x.getClass().name.contains("CLIAction")) lst.remove(x) }
}
def j = Jenkins.instance;
removal(j.getExtensionList(RootAction.class))
removal(j.actions)

in order to make the workaround persist between restarts of the Jenkins server, add the script below to $JENKINS_HOME/init.groovy.d/cli-shutdown.groovy (create the directory if necessary, and the file).

The latest version of this script can be found in this GitHub repository.

As previously announced on the jenkinsci-advisories mailing list we’re preparing a security release for this upcoming Wednesday which will include patches for both the latest and LTS lines of Jenkins core. The Jenkins Security team is working to include a fix for this previously undisclosed exploit in or before this planned security release.

If you have questions about this exploit, join us in the #jenkins channel on Freenode or ask on thejenkinsci-users@ mailing list.

For security researchers and hobbyists, if you believe you have found a security vulnerability in Jenkins, we have some disclosure guidelines on this wiki page which will help us mitigate any discovered issues as quickly and safely as possible.

Facebooktwittergoogle_plus