Donnerstag, 12. Mai 2016 – ImageMagick Exploit Shop 4

Na eigentlich wollte ich nicht über die JTL-Wawi und den Shop 4 mehr schreiben. Aber wenn man mich so lieb bittet. Gerne, dann hauen wir mal in die Tasten. Dann zerlegen wir mal ein paar Dinge in ihre Einzelheiten. Es geht um eine Sicherheitslücke in ImageMagick, die auch den JTL-Shop 4 betrifft. Bei Shop 3 bin ich mir jetzt nicht so zu 100% Sicher, ob dieser davon auch betroffen ist, weil ich mir nicht die Mühe gemacht habe, das entsprechende Skript dafür herunterzuladen. Aber gehen wir das mal der Reihe nach durch.

Ausgangslage:

Wir haben einen schönen JTL-Shop 4 auf dem Webspace unseres Internet Service Providers installiert. Wir haben jetzt keine Ahnung ob überhaupt dort ImageMagick, sowie die Extension php5-imagick installiert ist. Wir haben eine Sicherheitslücke in ImageMagick die aktuell sogar schon ausgenutzt wird. Wir stehen jetzt ziemlich ratlos dar und wissen nicht so recht was zu tun ist.

Warum wird von JTL-Shop 4 ImageMagick unterstützt?

Die Frage ist ganz einfach zu beantworten: „Die Installation von ImageMagick sowie der Extension php5-imagick beschleunigt den Bilderabgleich bei der Shop-Wawi-Synchronisation.“

2016-05-12 17_26_10-shop4-Systemcheck

Schritt 1

Ist ImageMagick mit der php-Erweiterung php5-imagick auf meinem Webspace installiert? Die Frage ist sehr schnell zu beantworten. Einfach folgendes Script in eine Datei mit dem Namen phpinfo.php kopieren auf den Webserver laden und per http://[meineDomain]/phpinfo.php aufrufen.

[codesyntax lang=“text“]

[/codesyntax]

Steht gleich oben links Array() unter darunter erst die PHP Version, kann man sich entspannt zurück lehnen. Steht da oben etwas und die Suche auf der Seite nach „imagick“ war erfolgreich, wird auf dem Webserver dieses Tool bereitgestellt – schlecht.

*Im Guide zu JTL-Shop kann man sich auch ein Skript herunterladen, mit dem überprüft wird, ob alle Voraussetzungen für den JTL-Shop 4 erfüllt sind. Ist hinter ImageMagick-Unterstützung ein gelbes Symbol, ist die Welt auch in Ordnung.

Schritt 2

War das Ergebnis in Schritt 1 positiv sollte man sich mit seinem Internet Service Provider in Verbindung setzen, so fern man nicht selbst Administrator des Servers ist, und höflich fragen, ob die aktuellen Patches zu ImageMagick installiert sind und ob diese Sicherheitslücke von diesem geschlossen wurde. Wenn man selbst der Administrator des Servers ist, sollte man ganz schnell sein Linux System und PHP-Erweiterung php5-imagick auf den neuesten Stand bringen. Entsprechende Sicherheitspatches sind schon vorhanden. Vielleicht noch besser ist, beides gleich vom Server zu verbannen.

Warum ist das ganze so kritisch?

Mit der neuen Wawi lassen sich Bilder ganz einfach mit der Maus von irgendeiner Webseite in die Wawi kopieren. Links die Wawi, rechts die Internetseite vom Lieferanten und schon werden die Bilder von dort in die Wawi kopiert. Nur kann ich bei diesem Vorgang nicht feststellen, ob jemand mir dort ein kompromittiertes Bild untergejubelt hat. Die Bilder werden schön brav in der Wawi gespeichert. Jetzt mache ich meinen Shop-Abgleich oder der Worker macht dies automatisch für mich und schon hat ein Angreifer die Kontrolle über meinen Webshop übernommen.

2016-05-12 12_38_29-_W2K12_ auf _MICHAEL-PC_ - Verbindung mit virtuellen Computern

Panik?

Nein, definitiv keine. Aber man sollte auf solche Sicherheitslücken reagieren und sich vergewissern, ob seine Systeme „safe“ sind. Und wie ich die Tage festgestellt habe, läuft der Abgleich zwischen Wawi und Shop auch ohne php5-imagick ganz ordentlich. Also kann man auch auf ImageMagick verzichten und diese Erweiterung vom System verbannen.

Warum der Blog-Beitrag heute?

Schön wäre es natürlich gewesen, wenn Marc Völker recht hätte mit seinen Äußerungen. Er hat leider nicht bis zum Ende gedacht. Eine kompromittierte Bilddatei bringt die Wawi eben nicht zum Absturz. In einem hat er recht, ich weiß nicht, ob JTL auf diese Sicherheitslücke in ImageMagic mit dem neuen Update regiert hat. Das man sie ausnutzen kann, konnte ich feststellen. Wer jetzt mit Panik mache daher kommt, versucht nur zu beschwichtigen, weil er Angst hat, dass ihm die Kunden davon laufen.

Zu guter Letzt

Ich habe an dieser Stelle keinen Grund hämisch auf andere zu zeigen. Das hier verwendete WordPress hat auch so seine Sicherheitslücken und auch WordPress unterstützt ImageMagick, sofern auf dem Webspace vorhanden ist. Hier wird es im Backend-Bereich für den Upload von Medien-Dateien verwendet. Und auch in WordPress gab es eine XSS-Sicherheitslücke, welche mit der aktuellen Version behoben sein soll. Wichtig ist, dass man seine Systeme Zeitnah aktualisiert, wenn solche Sicherheitslücken bekannt sind und von den Entwicklern geschlossen wurden. Eine Mail zu versenden, in der so getan wird, als hätte ein umfangreiches Security-Audit stattgefunden und dabei wäre eine Sicherheitslücke entdeckt worden, kommt bei mir gerade nicht so besonders gut an.

WordPress 4.5.2 Sicherheits-Release

8 Gedanken zu „Donnerstag, 12. Mai 2016 – ImageMagick Exploit Shop 4“

  1. Lieber Gerd,

    beide Blogbeiträge sind gut. Wer Lesen kann ist klar im Vorteil. Ich werfe in diesem Beitrag gar nichts durcheinander. Aber vielleicht sollte Dir jemand mal die Deutsche Sprache erklären.

    Ich habe heute nicht ein Shop-Problem mit der ImageMagick Sicherheitslücke durcheinander geworfen. Der Shop 4 unterstützt ImageMagick, wie du dem Screenshot oben entnehmen kannst. Und da gibt es ein Problem.

    So und jetzt? Antworten darauf? Nein keine, Fehlanzeige. Platte Sprüche und mehr nicht. Kenne ich von der AfD auch. Bringt aber keine Lösungen.

    Und wenn jemand ein Security-Audit über seine Software fährt und diese Lücke sollte immer noch offen sein, oder die Kunden werden nicht informiert, dass es da eine Lücke gibt, dann muss ich Dir als Fachmann nicht sagen, was davon zu halten ist. Wie man in solchen Fällen zu verfahren hat, kannst du dir Bei WordPress durchlesen.

    Also kein Süppchen gekocht. Gelesen, analysiert, ausprobiert und aufgeschrieben. Ein Blog halt eben, auch wenn manche Äußerungen anderen nicht passen.

    Gruß Michael

  2. Also ein bisschen muss ich doch lachen.
    Leider kann ich hier nicht ganz so ruhig wie Gerd bleiben.

    Fangen wir mal vorne an, Schritt 1, ist defakto bei einer Negativ Meldung kein Anzeichen, dass hier keine Sicherheitslücke vorliegt. So Gaugelt man dem Leser dann nur vor. Hab ich gemacht, kamm nix zurück alles okay.

    Fakt ist, dass du die Funktion exec ausführen kannst, ist bereits eine Sicherheitslücke. Bei nem Ordentlich konfigurierten System geht das nicht. Sprich ein leeres Array() oder die anzeige von nix sagt dir erst mal nicht wirklich was. Da solltest du die ausgabe von der phpinfo() eher betrachten, da die Extension php5-imagick dort normalerweise angegeben ist.

    Nun gut, Anwender findet heraus, ja wir haben ImageMagick, dann sollte die erste Reaktion einfach nur den Hoster zu Kontaktieren sein, alternativ ist mal selbst der Administrator kannst du das Problem meistens schon mit zwei ganz einfachen befehlen fixen (z.B. unter Debian)

    apt-get update
    apt-get upgrade

    dann ist das auch geupdatet.

    Hier sollte nochmal ganz klar gestellt werden, nur das System z.B. WordPress oder den Jtl Shop und hier ist egal ob 1 oder 2 oder 3 oder 4. Sofern die ImageMagick fürs Rendering nutzen betrifft es einfach jede Webanwendung (im übrigen jede Anwendung die irgendwo mit ImageMagick arbeitet) upzudaten.
    Das einzige was hier was bringt, ist das Updaten der Installierten ImageMagick.

    Ob man nun ImageMagick brauch oder nicht, stelle ich mal nicht zur Diskussion. Ich kann dir nur aus erfahrung sagen, es macht sich schon recht schnell bemerkbar ob es da ist oder nicht.

    So nun kommen wir zum Nächsten Teil.
    Alleine das Beispiel du ziehst ein Bild vom Server deines Lieferanten runter. Und spielst es ein unterstellt schonmal das der Lieferant selbst die Exploits verteilt. Halte ich doch für recht unwarscheinlich, aber okay ist möglich.
    Das die Wawi das nicht mit einer Exception bedankt, naja gut, wenn irgendwo im Exploit noch genug Bild Daten zur Visialisierung vorhanden ist, dann wird sie es nehmen.

    Schlussendlich kann man nur einen Ratschlag machen, guckt dass ihr Bilder aus Vertrauensvollen Quellen nehmt.
    Was jedoch im bezug auf JTL ausgeschlossen ist, dass ein Angreifer selber einen JTL Shop Kompromitieren kann, dies geht in diesem Fall dann wirklich nur durch eigenes zu tun. Da man selber erst mal ein Kompromentiertes Bild in die Wawi laden muss.

    1. Hallo Marc,

      1:0 für Dich. Deine Schritte wie Du sie aufgeführt hast, sind völlig richtig und diesmal richtig gut, ruhig und sachlich geschrieben!

      Nur so zur Info, bei WordPress reicht es schon aus, wenn ein Bild über eine URL der Medienbibliothek hinzugefügt wird. Ich nutze diese Funktion zwar nur im äußersten Notfall, aber alleine dies würde schon ausreichen, um über die hier beschriebene Sicherheitslücke in mein System zu kommen. Also das Bild muss noch nicht mal auf meinem Server gespeichert sein, es reicht aus, wenn ImageMagick genutzt wird (sehr einfach ausgedrückt!).

      Gruß Michael

  3. Es mag natürlich stimmen, dass die entsprechende Webanwendung einfach durch Features, die an sich dann auch nicht geschützt sind. Es halt eben Potenziellen Angreifern möglich macht, durch diese Sicherheits lücke ins System einzudringen.

    Nur der Springende Punkt ist halt hier, es gibt für die Software JTL Shop ein gewisses Risiko, was aber im vergleich zu anderer Software hier doch nicht ganz so Gravierend ist.

    Damit soll nicht gesagt sein, man sollte nicht reagieren. Reagieren ist auf jeden fall Pflicht. Nur im bezug auf das folgende Problem könnte JTL nur eins machen, und zwar die Verwendung unterbinden. Was jedoch nicht umbedingt die Idealste form ist.

    Mal grundsätzlich zu den JTl Sicherheits Updates von dieser Woche, diese sollte auf jeden fall für jeden Kunden Pflicht Programm sein. Da durch diese Updates doch sehr massive Sicherheitslücken gefixt werden.

    1. Gerd,

      ich liebe Trolle! Kardinalfehler von Dir. Wenn Du Marcs Kommentar lesen könntest, dann gibt er mir sogar ungewollt recht. Und ich muss jetzt nicht hier runterschreiben, was in der Praxis gemacht wird. Und um es dir hier mal auch zu sagen, in JTL-Shop 3 und 4 gab es wie in fast allen MySQL-Server basierenden CMS oder Shop-Systemen eine XSS-Sicherheitslücke mit der über Formulare Schadcode eingeschleusst werden kann. Hintergrund sind Datenbankfelder die als Text hinterlegt sind. Wenn dort ein überlanger Text eingefügt wird, führt dies zu einer Exeption die ein Angreifer ausnutzen kann. Hat auch Magento, WordPress und andere Systeme betroffen. Die Sicherheitslücke hat aber kaum JTL in einem umfangreichen Security-Audit gefunden und ist auch schon länger bekannt. Siehe Link am Ende des Beitrags.

      Für dich zum Nachlesen: Ein Security-Audit ist eine Überprüfung einer Software auf Schwachstellen und Sicherheitslücken und wird in der Regel auch von externen Sicherheitspezialisten durchgeführt. Wenn ich mich über etwas echauffiere, dann über solche netten Sätze in E-Mails. Das habe ich getan. Du kannst Dich gerne weiter Verarschen lassen, aber ich sehe es mittlerweile wie manche Kunden von JTL. Und auf eine Lösung seinen geschäftlichen Erfolg aufzubauen, bei der es hinten und vorne zur Zeit ganz gewaltig hapert, ist keine Gute Idee.

      Im übrigen kopiert die halbe JTL Servicepartner Welt meine Anleitungen hier in diesem Blog und war dankbar für jede Anleitung die ich geschrieben habe. Damit war ich so erfolgreich, das mittlerweile JTL mein Format gnadenlos kopiert hat. Also so schlecht, wie Du behauptest ist der Blog definitiv nicht. Musst ihn ja nicht lesen.

      Gruß Michael

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.