Inhaltsverzeichnis

Dieser Artikel ist älter als ein Jahr und könnte daher Informationen enthalten, die nicht mehr auf einem aktuellen Stand sind.

In der letzten Zeit gab es vermehrt Meldungen über Hackerangriffe auf Shopsysteme. Beim Betrieb eines Onlineshops hat man nicht nur wegen dem Schutz von Kundendaten auf die Sicherheit zu achten, sondern auch aus eigenen wirtschaftlichen Interessen. Denn die Einbindung von Schadcode (Malware) in die Shopseiten kann dazu führen, dass man aufgrund von Warnungen oder Sperren durch die Suchmaschinen kurz- oder auch langfristig deutlich weniger Besucher erhält.

Verantwortlichkeiten

Der folgende Absatz richtet sich hauptsächlich an Shopbetreiber, die ein Open Source Shopsystem einsetzen. Es geht darum, auf die Notwendigkeit von Updates hinzuweisen und Ratschläge zu geben, wie man die Beschaffung von Informationen über potentielle Sicherheitsprobleme organisieren kann. Außerdem werden beispielhaft zwei aktuelle Hackerangriffe auf die Open Source Shopsysteme PrestaShop und osCommerce geschildert.

Ist Open Source unsicher?

Sicher nicht. Open Source Software hat viele Vorteile. Transparenz und Anpassungsfreiheit sind zwei wichtige Pluspunkte. Es gibt aber auch Nachteile. Ein Nachteil aus Sicht des Shopbetreibers könnte sein, dass man die Verantwortung für die Sicherheit und den einwandfreien Betrieb der Anwendung nicht auf den Entwickler einer Open Source Software abwälzen kann. Es gibt mittlerweile “kommerzielle Open Source Software”, bei der individuelle Lizenzen eventuell andere Regelungen bieten. Aber grundsätzlich kann man sagen, dass man beim Einsatz von Open Source Software ein hohes Maß an Eigenverantwortung erbringen muss.

Aktualisierungen sind Pflicht!

Insbesondere bei Anwendungen, die im Internet für Zugriffe öffentlich erreichbar sind, sind Aktualisierungen ein notwendiges Pflichtprogramm. Es gibt häufig die Vorstellung, dass sich ein Hacker die Zeit nimmt, eine bestimmte Website anzugreifen. Und warum sollte meine Domain das Ziel sein, wenn es Millionen anderer Domains gibt, mag sich manch einer denken. In der Regel ist es jedoch so, dass durch entsprechende Tools tausende Domains in kurzer Zeit automatisiert nach Schwachstellen gescannt und gefundene Schwachstellen dann auch automatisiert ausgenutzt werden. Entsprechende Zugriffe findet nahezu jeder Domainbesitzer nahezu täglich in den Logfiles des Webservers/Hosters, wenn man beispielsweise nach der Zeichenfolge 404 (Seite nicht gefunden) sucht.

Klarheit bei den Verantwortlichkeiten

Ein Onlineshop wird häufig so erstellt, dass ein Dienstleister das Shopsystem installiert und anpasst und der Shop nach Fertigstellung dann in den Verantwortungsbereich des Shopbetreibers übergeht. Dies birgt die Gefahr, dass der Shopbetreiber aus fehlender Kenntnis oder aus mangelnder Einsicht notwendige Updates unterlässt.

Die Verantwortlichkeiten für Software-Updates sollten klar regelt sein. Sofern es keinen Servicevertrag mit einem Shopdienstleister oder einer Webagentur gibt, muss sich der Shopbetreiber darüber klar sein, dass er täglich Zeit zu investieren hat, um von möglichen Problemen zu erfahren und notwendige Anpassungen vorzunehmen. Wer als Shopbetreiber einen Onlineshop einfach dauerhaft ohne Updates laufen lässt, handelt grob fahrlässig, was den Umgang mit Kundendaten angeht und wirtschaftlich unvernünftig, wenn man die Folgen von Datenklau und Schadcode bedenkt.

1-Klick-Installation beim Hoster

Wenn man ein Webspace-Paket bei einem Hoster hat, sind die Verantwortlichkeiten zumeist klar definiert. In der Regel ist es so, dass man als Hostingkunde die Serversoftware (z.B. Webserver, Datenbankserver) nicht aktualisieren muss (und auch nicht kann). Dies liegt im Verantwortungsbereich des Hosters. Verantwortlich wird man allerdings dann, wenn man Software (z.B. ein Shopsystem) im Hostingpaket einrichtet.

Eine Besonderheit ist es, wenn der Hoster dem Kunden die Möglichkeit gibt, per “1-Klick-Installation” Open Source Software in das Hostingpaket zu installieren. Dies bieten mittlerweile viele Hoster an. Hier entsteht häufig eine Gefahr, da viele Hoster die durch den Kunden installierte Anwendungen nicht aktualisieren. Sofern man “1-Klick-Installation” beim Hoster in Anspruch nimmt, sollte unbedingt geklärt werden, wer für Aktualisierungen dieser Anwendungen verantwortlich ist.

Beispiel 1: PrestaShop und gestohlene Zugangsdaten

Am 23.08.11 kamen die ersten Meldungen auf, dass ein Hackerskript innerhalb einer PrestaShop-Installation sensible Daten (Zugangsdaten des Backoffice und der Datenbank) per E-Mail verschickt. Außerdem wurde bei diesem Vorgang eine Shopdatei so verändert, dass auf allen Shopseiten Schadcode (Malware) eingebunden wird. Das Ziel beim Einfügen von Malware sind in der Regel die Computer der Shopbesucher, die zum Beispiel mit Trojanern infiziert werden sollen.

Ursache

Die Ursache war, dass der Server prestashop.com gehackt wurde und dass über die Benachrichtungsfunktion Dateien in den eigenen Onlineshop geladen wurden. Die Benachrichtungsfunktion dient normalerweise dazu, dass Inhalte von prestashop.com in das Backoffice der Shops eingebunden werden, damit die Shopbetreiber aktuelle Meldungen rund um PrestaShop sehen können. Man konnte in diesem Fall also kaum den unbefugten Eingriff in das eigene Shopsystem verhindern, sondern war zufällig dann betroffen, wenn man in der entsprechenden Zeit am 23/24.08.11 das eigene Backoffice aufgerufen hat. Bei mehr als 85.000 Installationen (laut PrestaShop) dürften von dem Problem zahlreiche Shops betroffen gewesen sein.

Lösung

Die Lösung bestand vor allem darin, dass das PrestaShop-Team das Problem auf prestashop.com lösen musste. Außerdem waren die betroffenen Shops möglichst schnell zu informieren und die Shopbetreiber mussten die veränderte Datei anpassen. Desweiteren bestand für betroffene Shopbetreiber die Notwendigkeit, die Zugangsdaten zu ändern. Eine komplette Lösung wird im PrestaShop-Blog geschildert.

Dass prestashop.com gehackt wurde wirkt zwar nicht sonderlich vorteilhaft für das Team von PrestaShop. Allerdings muss man das Krisenmanagement des PrestaShops-Teams sehr loben. Bei dem Vorgang wurden die Vorteile von Open Source in Form von Offenheit und Gemeinschaft deutlich.

PrestaShop Dashboard
PrestaShop Dashboard

In einer anschließenden Diskussion wurde gefordert, dass es keine Einbindung von Elementen von externen Domains (also auch von prestashop.com) geben dürfte, da die einzelnen Shopbetreiber keine Kontrolle über diese Domain haben. Allerdings wird bei dem Vorschlag offenbar übersehen, dass eine zeitnahe Information bei Sicherheitslücken bei vielen Shopbetreibern vermutlich nur durch eine direkte Einbindung realisieren werden kann. Zumindest ist diese Art der Benachrichtung wohl am effektivsten.

Beispiel 2: osCommerce und der Massenexploit

Während es über das PrestaShop-Problem kaum Meldungen gab, wurde über die Masseninfektion von osCommerce-Shops Ende Juli 2011 sehr umfassend berichtet. Neben Heise, Gulli, t3n verwies auch das Bundesamt für Sicherheit in der Informationstechnik (BSI) in einer Stellungnahme auf das Problem.

Allerdings ist der Eindruck, der dort vermittelt wird, meiner Ansicht nach nicht ganz richtig. Es gab eine nachvollziehbare Masseninfektion nach einem bestimmten Muster, die als Ziel offenbar die Shopbesucher hatte. Diese Masseninfektion konnte von dem Security-Blog Amorize eindrucksvoll präsentiert werden, da die betroffenden Shops aufgrund des geänderten Seitentitels gut erkennbar waren. Aber tausende gehackte osCommerce-Shops gab es auch schon Monate vorher, da die Lücke schon sehr lange bestand und automatisiert ausgenutzt wurde.

Meiner Einschätzung nach liegt die Anzahl der Ende Juli betroffenden osCommerce-Shops im oberen vierstelligen Bereich. Eventuell auch im fünfstelligen Bereich.Dass jedoch Millionen osCommerce-Shopsysteme gehackt wurden, wie nicht wenige Blogs in den letzten Tagen behaupteten, kann man als Fehleinschätzung oder Panikmache einstufen. Vielleicht ist auch nicht jedem der Unterschied zwischen Seiten und Domains geläufig.

Ursache

Das grundsätzliche Problem war, dass man allein durch den Aufruf einer bestimmten URL den Zugangsschutz des osCommerce-Adminbereichs umgehen konnte. Dies ermöglichte das Auslesen von Daten oder auch das Hochladen von Schadcode. Beispielsweise kann man mit dem Aufruf /admin/file_manager.php/login.php direkt auf den Dateimanager zugreifen. Ob die Ursache für dieses Problem bei osCommerce oder PHP liegt, kann man diskutieren.

Seit 2009 war diese Lücke bekannt und wurde auch in entsprechenden Exploit-Datenbanken veröffentlicht. Seit mindestens Oktober 2009 wird mit Schwachstellen-Scannern automatisiert nach dieser osCommerce-Lücke gesucht. Seit dem konnte man wöchentlich oder bei manchen Domains sogar täglich entsprechende Hackversuche in den Webserver-Logfiles sehen.

1 access.log.33:00.000.000.0 - - [18/Aug/2011:21:07:52 +0200] "GET /admin/file_manager.php/login.php?action=download&filename=/includes/configure.php HTTP/1.1" 404 2689 "-" "Mozilla/5.0 (compatible; Nmap Scripting Engine; http://nmap.org/book/nse.html)"

Solche automatisierten Aufrufe findet man nicht erst seit kurzem, sondern seit langer Zeit bei jeder halbwegs bekannten Domain. Somit ist davon auszugehen, dass ungesicherte osCommerce-Shops nicht erst Ende Juli 2011 gehackt wurden.

Lösung

Im deutschsprachigem osCommerce-Forum wurde die Lücke und Gegenmaßnahmen im Juli 2009 veröffentlicht. Dieser Hinweis ist seit damals als gepinnter Beitrag ganz oben im entsprechendem Forum. Auch im englischsprachigem Forum gab es einen Hinweis. Es hat sich jedoch gezeigt, dass diese Hinweise nicht ausreichten. Selbst einige osCommerce-Dienstleister haben im Jahr 2011 nichts von dieser Lücke nichts gewusst. Da kann man sicherlich darüber diskutieren, ob eine bessere Kommunikation notwendig gewesen wäre.

Ab der osCommerce-Version 2.3x, die Ende 2010 veröffentlicht wurde, ist neben der Verbesserung der Sicherheit eine Update-Benachrichtung vorhanden, die Shopbetreiber beim Erscheinen einer neuen osCommerce-Version im Adminbereich benachrichtigt. Sofern man es als Shopbetreiber nicht übersieht.

Auf manchen Internetseiten wurde empfohlen, auf osCommerce 3.0.2 zu aktualisieren. Dazu muss man allerdings wissen, dass osCommerce 3.x eigentlich noch nicht produktiv einsetzbar ist, da noch einige Funktionalitäten fehlen.

Fazit

Als Shopbetreiber kann man folgende Lehren aus den geschilderten Hackerangriffen ziehen.

Updatefähigkeit des Shopsystems berücksichtigen

Bei der Wahl des passenden Shopsystems sollte darauf geachtet werden, dass Software-Updates möglichst einfach durchgeführt werden können. PrestaShop bietet seit der Version 1.4.4 ein One Click Upgrade, welches sich noch im Beta-Status befindet. Auch osCommerce bietet ab Version 3.x ein Core Update, das den Aktualisierungsvorgang zukünftig deutlich vereinfachen soll. Außerdem ist es sinnvoll, wenn man im Backend des Shops auf mögliche Sicherheitsprobleme und Updates hingewiesen wird. Dies bieten mittlerweile sowohl PrestaShop als auch osCommerce in den aktuellen Versionen.

Informationen sammeln und schnell reagieren

Der Shopbeteiber muss sicherstellen, dass er zeitnah Informationen über mögliche Probleme erhält und entsprechende Aktualisierungen durchführt oder durchführen lässt.

Informationsbeschaffung

Es ist sehr wichtig, dass man die tägliche Informationsflut kanalisiert. Hinweise über mögliche Sicherheitsprobleme sollten möglichst separat abgerufen werden, damit diese nicht im Strom der sonstigen Meldungen untergehen. Für die Informationsbeschaffung gibt es verschiedene Möglichkeiten. Einige werden nachfolgend aufgelistet.

Twitter

Auch wenn es im Einzelfall anders sein kann, aber grundsätzlich kann man sicherlich sagen, dass Twitter der schnellste Informationskanal ist. Man kann bei Twitter zwischen der Begriffsüberwachung und dem Folgen bestimmter Twitter-Konten unterscheiden.

Begriffsüberwachung

Es ist zu empfehlen, dass man das Auftauchen entsprechender Begriffe in Twitter täglich verfolgt. Sofern man das Shopsysstem PrestaShop einsetzt, wäre “PrestaShop” logischweise der passende Begriff. Man kann zur Überwachung die Twitter-Suche, Dienste wie Hootsuite oder sonstige Twitter-Clients nutzen.

Twitterkonten

Nahezu jede populäre Open Source Software ist auch bei Twitter vertreten. Es empfiehlt sich, derartige Twitter-Konten zu abonnieren. Bei PrestaShop und osCommerce wären dies beispielsweise:

Communities

Populäre Open Source Anwendungen haben in der Regel mehr oder weniger aktive Community-Foren. Sowohl bei PrestaShop als auch bei osCommerce gibt es sogar Forenrubriken, die sich speziell mit Sicherheitsthemen befassen. Auch dort gilt es, die Diskussionen zu verfolgen.

Websites

Es gibt zahlreiche Websites, die über Sicherheitsprobleme berichten. Viele dieser Internetauftritte bieten auch RSS-Feeds an, so dass man beim Einsatz eines Feed-Readers darauf verzichten kann, diese Websites jedesmal alle einzeln zu besuchen.

Benachrichtigungsservice

Ein sinnvoller Benachrichtigungsservice ist Google Alert. Man kann sich dort regelmäßige Benachrichtungen per E-Mail zusenden lassen, wenn Google neue Internetseiten zu bestimmten Stichwörtern findet.

Sollte jemand weitere Tipps parat haben, wie und wo man Informationen über Sicherheitslücken bekommt, können diese Hinweise gerne in den Kommentaren angegeben werden.

Kommentare
  1. Danke für den ausführlichen Artikel zum Thema. Ich hoffe das OSCommerce nicht all zuviel Angriffsfläche bietet.
Kommentar hinzufügen

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

Bitte keine HTML-Tags einfügen.