Von einem JBoss Virus und einer ignorierten Sicherheitslücke

Wer kennt sie nicht die regelmäßigen Sicherheitsmeldungen der CVE , wonach in einer Software wieder einmal eine Sicherheitslücke entdeckt wurde. Diejenigen Unternehmen unter uns, die gerne Open Source für die eine oder andere Problemstellung einsetzen, ignorieren gerne im Alltag die notwendigen Sicherheitspatches, da sie meistens selbst kompiliert und deployed werden müssen. Wobei die Tests und Prozedere zur Softwareverteilung meistens aufwendiger sind als der Patch selbst.

Nur so ist zu erklären, warum eine Sicherheitslücke im JBoss Application Server zwar schon seit einem Jahr bekannt  ist und vorbildlich von RedHat entsprechende Patches veröffentlicht wurden, ein listiger Virus diese Sicherheitslücke aber noch immer im großen Stil ausnützen kann. Offensichtlich findet er genügend Futter in den Unternehmen. Details zum Virus sind folgendem JBoss Posting zu entnehmen.

Anscheinend gibt es noch immer genügend alte Versionen des JBoss AS im Unternehmenseinsatz, die nie einen Patch gesehen haben und in jungfräulicher Unschuld der Dinge harren. Offensichtlich sind manche Betreiber derart überzeugt, dass ihnen nichts passiert, dass sie nicht einmal die von JBoss empfohlenen Sicherungsmaßnahmen konfigurieren. Ist halt einfacher so. Da hat ein findiger Virenschreiber leichtes Spiel.

So, kurz zum eigentlichen Problem. Die Sicherheitslücke ist schnell erklärt. Ein JBoss mit aktivierter JMX Console ist die Schwachstelle. Über eine veränderte HTTP URL können beliebige Shell-Commands auf dem Server im Usercontext des JBoss durchgeführt werden. Wer seine JMX Console nach den Vorgaben von RedHat gesichert hat, dürfte anscheinend bei JBoss AS 6 & 7 nicht betroffen sein. Bei älteren JBoss Versionen ist nach ersten Gerüchten selbst dass nicht ausreichend, auch wenn korrekt gepacht wurde. Da hilft es nur die JMX Console zu deaktivieren!

Der Virus besitzt nach letzten Meldungen noch keine Schadroutinen, d.h. er löscht z.B. keine Daten auf dem Server. Aber was nicht ist, kann ja noch werden Smiley Zur Verbreitung lädt er sich in der derzeitigen Variante Schadcode aus dem Internet auf den Server und führt selbst ein Deployment auf dem JBoss durch. Dadurch ist es auch recht leicht den Virus zu erkennen und zu stoppen, sofern noch kein Patch eingespielt wurde:

  • Blockieren der URL “http://magicstick.dyndns-remote.com/kisses.tar.gz” sowie Alarmierung des Network Operation Center
  • JMX Consolen deaktivieren sofern möglich, speziell auf den Entwickler Arbeitsplätzen die gerne lokale JBoss Installationen verwenden
  • das Programm “wget” am Server entfernen sofern möglich
  • Den Zugriff auf das Internet vom Server über einen Proxy nutzen und die HTTP_PROXY Variable nur temporär für Arbeiten setzen falls möglich

Was lernen wir aus der ganzen Geschichte. Open Source darf nicht mit “Free Beer” verwechselt werden, einfach zum bekommen und konsumieren. Vielmehr bedeutet es im Sinne der GNU Foundation “Free Speech”, d.h. jeder kann mitmachen muss aber verantwortungsvoll damit umgehen. In unserer Welt heißt das patchen, patchen, patchen.

You can leave a response, or trackback from your own site.

One Response to “Von einem JBoss Virus und einer ignorierten Sicherheitslücke”

  1. Daniel Kohl says:

    Hallo,

    wir hatten solch einen Angriff auf einer alten “vergessenen” Demo-Maschine. Unsere Ressourcen wurden dann für http://www.paldf.net genutzt. Auch aljazeera.net spielt eine Rolle.

    Grüße

Leave a Reply

Subscribe to RSS Feed Follow me on Twitter!