Schwere Sicherheitslücke im Onlineshop XT-Commerce 3.0.4 SP 2.1
Tags: Exploit | Sicherheit | Software | XT CommerceEine türkische Hacker-Gruppe ist derzeit extrem aktiv. Neben verschiedenen Software-Installationen ist eines der Ziele der Onlineshop XT-Commerce Version 3.0.4. Die aktuelle Version ist die SP 2.1 aber Vorsicht: Die „Servicepack Version 2.1“ gibt es unglückseligerweise in zwei Versionen – eine Version mit und eine ohne Security-Patch! Beide Versionen weisen sich nach außen hin gleich aus – als Version 3.0.4 SP 2.1 ….
Die Version ohne Security-Patch bietet den Hackern bei aktivierten SEO Urls und aktivierten magic_quotes folgende Möglichkeit:
- Über Google wird nach dem Pfad-Segment „/shop_content.php/coID/“ gesucht
- Dank eines Exploit gelangen die Hacker via SQL-Injection in den Admin-Bereich.
- Über die Upload-Funktion wird nun ein angebliches Bild hoch geladen, nur das die Software gar nicht prüft, ob es sich um ein Bild handelt, tatsächlich lässt sich ein PHP-Script hoch laden!
Nach erfolgreichem Upload der PHP-Shell (C99Shell.B) haben die Hacker umfassenden Zugriff auf die Webseite und „Defacen“ in der Regel die Index-Seite, was dann so aussieht:
Wollen Sie das für Ihren XT-Commerce-Shop vermeiden, dann haben sie mehrer Optionen:
1. Den Security-Patch installieren, um die SQL-Injection abzufangen -> PFLICHT!
Hier gibt es den Patch: Security-Patch für XT-Commerce 3.0.4 SP 2.1
2. Die Ausführung von PHP-Scripten in allen Upload-Verzeichnissen mittels .htaccess unterbinden (um das Problem mit der mangelhaften Upload-Überprüfung auch zukünftig zu verhindern) -> auch PFLICHT!
Order deny,allow
Deny from All
3. Bei Zugang mit einer statischen IP biete sich die Möglichkeit, das ganze admin-Verzeichnis für alle IPs bis auf die eigene zu sperren, bei Zugang mit dynamischer IP kommt zumindest ein zusätzlicher Verzeichnis-Schutz mit Passwort in Frage.
4. Wenn Punkt 3 nicht möglich ist (z.B. wegen Zugang zum Internet via dynamischer IP), dann sollte das Admin-Verzeichnis unbedingt zusätzlich per .htaccess mit einem Verzeichnisschutz versehen werden!
Die .htaccess sieht dafür so aus:
AuthType Basic
AuthUserFile /...absoluter...pfad...zur...datei.../.passwd
AuthName "Zugangsberechtigung"
order deny,allow
allow from all
require valid-userDie Password-Datei ist etwas kniffliger zu erstellen, wenden Sie sich hierzu an einen Administrator Ihres Vertrauens. Sie benötigen hierzu das Programm htpasswd, dies ist in den Dateien für Apache enthalten und existiert dementsprechend in Varianten für alle Betriebssysteme, für die auch eine Apache-Version existiert. Alternativ bieten Systeme wie Plesk auch die Möglichkeit an, den Verzeichnisschutz komplett via Dashboard zu erstellen.
Was tun, wenn Ihr Shop bereits gehackt wurde?
Kontrollieren Sie alle Upload-Verzeichnis, PHP-Scripte haben dort NICHTS zu suchen!
Freitag, 06.02.2009 um 1:05 Uhr
Hi Stephan,
nochmals vielen Dank für den tel. Hinweis und die ausführliche Doku hier im Blog!
Ich habe tatsächlich einen Kunden, der genau diese Version 3.0.4 ohne Security-Patch fährt.
Freitag, 06.02.2009 um 22:42 Uhr
Dann weißt Du ja, was zu tun ist. Wir haben uns übrigens bei dem Security-Meeting heute Mittag mit Felix Kronlage und Bernd Ahlers von der Firma Bytemine dazu entschlossen, grundsätzlich jeden Admin- / Backend-Bereich via Version 3 zusätzlich abzusichern: Wer per statischer IP (habe gehört, sowas gibt es sogar in Oering? ;-)) kommt, hat freien Zugang, alle anderen müssen sich zusätzlich zum Backend-Login immer per AuthUser Zugang verschaffen…
Mittwoch, 11.02.2009 um 15:19 Uhr
Vielen Dank für die Doku dieses xt:Commerce Exploits und die Tipps zur Problemlösung.
Dienstag, 17.02.2009 um 22:17 Uhr
Vielen Dank für diese hilfreiche Information mit den dazugehörigen Tipps zur Problemlösung. Noch mal Danke
Sonntag, 08.03.2009 um 13:55 Uhr
Hallo Leute,
wollte mir gerade den Patch laden, doch der kann leider nicht entpackt werden. Was nu?
Wie finde ich heraus, ob ich evtl. den Patch schon habe?
Wie geht das mit dem AuthUser Zugang?
Montag, 09.03.2009 um 20:48 Uhr
Das Problem mit dem Zip ist, das es nur mit einer neuen WinZip-Version ausgepackt werden kann. XT-Commerce verpackt neuerdings mit einer Version / Einstellung, die eine neue WinZip-Version zwingend notwendig macht …
Mittwoch, 20.05.2009 um 6:35 Uhr
@Thoby: Setzte dich einmal mit htaccess auseinander.
Ich finde der Admin bereich sollte immer mit einem Auth Login gesichert werden. Wenn aber die Hacker schon auf dem Server sind durch eventuelle Sicherheitslücken des Serverbetreibers bringt dies leider auch nichts mehr.
Freitag, 05.06.2009 um 18:22 Uhr
Sehr hilfreicher Beitrag!
Vielen Dank!
Samstag, 27.06.2009 um 10:39 Uhr
Woran erkenne ich denn, ob die XT Commerce Version die ich einsetze, die „gepatchte“ Version ist.
Grundsätzlich regen mich diese „Hacker“ wirklich auf. Ich meine haben diese nichts besseres zu tun als anderen Leuten Schaden zuzufügen. Ich hasse sowas!!!
Montag, 29.06.2009 um 0:59 Uhr
Vielen Dank für die Infos!
WÜrde auch gerne wissen wie ich es erkennen kann, ob mein Shop schon diesen Patch hat oder nicht
Montag, 29.06.2009 um 10:23 Uhr
Im Zweifelsfall würde ich noch einmal Patchen … lieber einmal zuviel als einmal zu wenig. Ansonsten könnte ein Vergleich der Patch-Dateien mit den eigenen Dateien helfen. Ich habe die alten Files nicht mehr, kann daher keinen Compare mehr machen, um entsprechende Änderungen aufzeigen zu können.
Dienstag, 30.06.2009 um 23:51 Uhr
Hi Stephan,
nochmals vielen Dank für den tel. Hinweis und die ausführliche Doku hier im Blog!
Ich habe tatsächlich einen Kunden, der genau diese Version 3.0.4 ohne Security-Patch fährt.
Mittwoch, 01.07.2009 um 0:22 Uhr
Lieber „Thorsten“ alias „Luise“ alias „Thorsten“, mein Freund Thorsten bekommt tatsächlich Hinweise via Telefon, einen Absender, der zudem die Firma „Homepage Hoster“ als Absender angeben könnte, kenne ich nicht und habe ich auch noch nie angerufen, um ihn über irgendwelche Bugs zu unterrichten! Euer Spaming ist nicht nur flach und offensichtlich, sondern geht mir langsam auf den Nerv!Hiermit erkläre ich ausdrücklich, das weiter Spam-Kommentare mit Verlinkung der Firma Homepage Hoster unerwünscht sind und als das verfolgt werden, was sie sind: Spam.
Nachtrag vom 20.9.2009: Herr Thomas P., Geschäftsführer der von www-homepage-hoster.de, erklärt mir gegenüber in einer eMail glaubwürdig, dass die Kommentare nicht in seinem Auftrag angelegt wurden!
Nachtrag vom 12.7.2021: Herr Thomas P., Betreiber von www-homepage-hoster.de (so steht es dort im Impressum), erklärt mir gegenüber, dass www-homepage-hoster-de nicht existieren würde (ups, da hat wohl jemand vergessen, eine Domain zu löschen?) und verlangt die Löschung seines Namens aus diesem Beitrag. Dem komme ich hiermit schmunzelnd nach – wohl wissend, dass ein Vor- und Nachnamen-Kombination ja noch keine persönlichen Daten darstellen, insbesondere dann nicht, wenn sie dank der Impressumspflicht im Internet frei zugänglich sind … @Thomas P.: Das Recht, auf welches Sie sich berufen, basiert übrigens auf der DSGVO, nicht auf der „DVSGO“. 😉
Freitag, 17.07.2009 um 18:26 Uhr
lieber einmal zuviel als einmal zu wenig. Ansonsten könnte ein Vergleich der Patch-Dateien mit den eigenen Dateien helfen. Ich habe die alten.
Samstag, 25.07.2009 um 17:25 Uhr
Danke für diesen Tipp, will mir ja auch gerade XTC zulegen.
Sonntag, 23.08.2009 um 15:50 Uhr
Die Lücke liegt nicht beim Shopsystem selber sondern wird durch einen nicht richtig konfigurierten Server hervorgerufen. Das ganze ist eher Panikmache als alles andere, man sollte sich diesbezüglich lieber auf die Aussagen des Herstellers verlassen als auf irgendwelche dubiosen Forennnews.
Sonntag, 23.08.2009 um 22:46 Uhr
Wo wurden hier „dubios Forennews“ zitiert?
Wobei der Hersteller vor allem sein Forum – im Support-Bereich, welcher bezahlt werden muss – nutzt, um derartige News zu publizieren.
Montag, 24.08.2009 um 14:09 Uhr
Lieber Herr Hertz … wo bitte wurde im Hersteller Forum diese News pupliziert ? Ich glaube da liegen Sie falsch, das ganze kommt aus einem freien Forum , sonst nichts. Trotz alle dem handelt es sich hier nicht um eine „schwere Sicherheitslücke“ des Shopsystems sondern schlichtweg um schlecht konfigurierte Server.
Dienstag, 25.08.2009 um 0:55 Uhr
Liebe Frau Rühle,
woher diese News kommt? Die kommt nicht aus irgend einem Forum, das ist ein Erfahrungsbericht!
Und es handelt sich schlicht weg um ein miserables Versions-Management seitens XTC, da die letzten Security-Patches alle samt die Versionsnummer SP2.1 tragen bzw. die Versionsnummer nicht ändern!
Wegen der angeblich schlecht konfigurierten Server lassen Sie sich bitte von jemandem, der sein Geld nicht mit XTC verdienen muss, sagen: Eine Lücke für SQL-Injections ist kein Konfigurationsproblem sondern ist eine unzureichend programmierte Software – und Lücken für SQL-Injections sind schwere Sicherheitslücken!
Samstag, 29.08.2009 um 1:50 Uhr
Hallo Herr Hertz,
danke für die Zusammenfassung. Ich habe gerade noch einen Kunden mit einem XTC-Shop, der offenbar nicht gepatcht ist – und schon mehrfach angegriffen wurde. Ich bin da ganz auf Ihrer Linie: das ist einfach schlampig programmiert. Wer sich schon mal intensiver den Quellcode des alten XTC angesehen hat, wundert sich nicht. Ich wünsche den Veyton Usern, dass die dort sicherer sind. 😉
Samstag, 05.09.2009 um 19:49 Uhr
Ich habe die alten Files nicht mehr, kann daher keinen Compare mehr machen, um entsprechende Änderungen aufzeigen
Montag, 28.09.2009 um 17:57 Uhr
Danke für den tollen und hilfreichen Beitrag.
Montag, 21.12.2009 um 22:39 Uhr
Ich bin aufgrund dieser Sicherheitslücken zu einer Weiterentwicklung von XTC gewechselt und bin ganz zufrieden. Dort erhält man sofort ein Update. Ist mir lieber als einen Shop aufgrund eines Hackerangriffs zu verlieren. Das ist mir leider in der Vergangenheit passiert. Aus Schaden wird man klug.
Dienstag, 22.12.2009 um 23:07 Uhr
Meinst Du eine Entiwcklung von Gambio?
greetz
Freitag, 25.12.2009 um 7:34 Uhr
Nein, er wird eher VEYTON meinen – beide Lösungen sind aber nicht wirklich zufriedenstellend, da Gambio auf einem veralteten System aufsetzt und VEYTON keinen Zugriff mehr auf den Sourcecode erlaubt…
Freitag, 12.03.2010 um 18:35 Uhr
Hallo Stephan,
auch von mir vielen Dank für deine Tipps! Nachdem gestern einer meiner 3 XT Shops gehackt wurde
(R57 shell) bin ich jetzt alle Installationen durchgegangen und habe die patches raufgespielt.
Was echt super wäre, wenn du noch einmal alle Upload Ordner auflisten könntest, in die die
htaccess Datei rein muss (die php Dateien verbietet). Ich habe diese jetzt mal in die Ordner gepackt,
in die die Produktbilder reingeladen werden, bin aber nicht sicher ob da noch welche übrig sind,
die ich nicht auf dem Plan habe.
Viele Grüße – Kalle
Freitag, 14.05.2010 um 15:12 Uhr
Eine kurze Frage hierzu,
ich habe meinen Shop artoflion.de ebenfalls unter der besagten Lizenz laufen sp2.1. Die Patches habe ich eingepflegt und zusätzlich die Möglichkeit genutzt, von meinem Provider die Dateien ab /admin/ mit einem Passwortschutz zu versehen.
Ist das das gleiche wie weiter oben beschrieben wird, indem eine .htaccess und eine passwortdatei eingefügt werden?
Vielen Dank für eure Antwort, vielleicht an thomas@hannoverlokal.de
Schönes Wochenende noch
Montag, 17.05.2010 um 18:29 Uhr
Es wundert uns, dass es anscheinend immer noch Shopbetreiber gibt, die diese Sicherheitslücke nicht geschlossen haben. Anders kann man diese rege Diskussion in diesem Blog nicht verstehen. Dabei ist die Sicherheitslücke doch bereits über 6 Monate alt….
Donnerstag, 20.05.2010 um 2:16 Uhr
Lieber „xt:Commerce Profi“, der ursprüngliche Beitrag von mir wurde am 04.02.2009 um 23:51 Uhr veröffentlicht (ist also weit über ein Jahr alt!) und ist offensichtlich bis heute aktuell – sollte uns das nicht zu denken geben?
Mittwoch, 15.09.2010 um 14:11 Uhr
Hallo,
auch ich danke schon mal für die vielen nützlichen Tips an dieser Stelle.
ich möchte auch noch einmal nachfragen, was der User KALLE wissen wollte:
Was echt super wäre, wenn du noch einmal alle Upload Ordner auflisten könntest, in die die
htaccess Datei rein muss (die php Dateien verbietet).
Oder reicht es den Schnippsel:
Order deny,allow
Deny from All
nur in die .htaccess im root-Verzeichnis zu kopieren???
… und wie realisiert man Punkt3)
3. Bei Zugang mit einer statischen IP biete sich die Möglichkeit, das ganze admin-Verzeichnis für alle IPs bis auf die eigene zu sperren …..
Würde mich über eine zeitnahe Antwort sehr freuen, danke schon mal
Mittwoch, 15.09.2010 um 14:46 Uhr
Noch eine 2. Frage:
Wie können wir verhindern, dass in den Ordner templates_c schafhafte *.php-Dateien geschrieben werden? So was hatten wir neulich.
Mit
Order deny,allow
Deny from All
klappt das ja nicht , bzw. da werden dann auch die „guten“ geblockt
Sonntag, 10.10.2010 um 23:59 Uhr
Zu der 2. Frage: Dort gibt es nur Schadcode, wenn an andere Stelle etwas schief läuft…
Zur ersten Frage – beide Teile gebe ich im Laufe der nächsten Tage eine Antwort, bin gerade erst nach Hause gekommen und eigentlich noch im Urlaub…
Mittwoch, 13.10.2010 um 19:05 Uhr
Herzlichen Dank für die Doku dieses xt:Commerce Exploits und die Tipps zur Problemlösung.
Samstag, 06.11.2010 um 0:28 Uhr
Wieso kann man hier nicht einfach ganze IP-Ranges aus dem Ausland sperren die für solche Hackerangriffe bekannt sind?
Ich hatte noch nie einen Kunden aus der Türkei, Russland oder Bulgarien.
LG
Silke
Donnerstag, 25.11.2010 um 0:02 Uhr
@Silke: Wenn Du nur in Deutschland verkaufen willst, dann geht das natürlich – wir haben aber auch Kunden aus China, Indien, Russland, usw. …
Dienstag, 15.03.2011 um 12:56 Uhr
Bei einem von mir betreuten Shop tritt das Problem auf, das andauernd die Zahlungsmethoden geändert werden, kann das auch hiermit zu tun haben?
Zuerst wurde ständig die Kreditkarte Aktiviert, nachdem ich diese ganz aus dem System gelöscht habe, wurde jetzt eine der 2 verbliebenen Zahlungsoptionen gelöscht.
3.0.4 SP 2.1 ist installiert, auch der Patch ist drauf, trotzdem scheint jemand Zugriff zu bekommen um die Änderungen zu machen.
Vielen Dank für einen Ratschlag
Torsten
Samstag, 07.05.2011 um 14:43 Uhr
Vielen Dank für die Veröffentlichung dieses Beitrages. Wir wurden heute Nacht gehackt. Ich habe alle Upload Verzeichnisse kontrolliert und dort im Ordner Banner und Categories die Dateien 1337.php und 100.php gefunden, die ich dann sofort gelöscht habe.
Die Schritte 1-3 habe ich selbstverständlich auch ausgeführt. Allerdings muss ich mir jemanden suchen der Schritt 4 ausführt.
Nocheinmal DANKE !
Sonntag, 08.05.2011 um 15:02 Uhr
Ganz so einfach war es nun leider doch nicht. Ich habe in der Datenbank eine Tabelle stuff gefunden und war mir sicher dass diese dort nichts zu suchen hat. Nach dem Löschen dieser Tabelle hatte ich jedoch keinen Zugang mehr zum Admin Bereich ?
Freitag, 13.05.2011 um 21:06 Uhr
@Nicole: In der Tat gehört eine Tabelle „stuff“ in der DB nicht zu XTC. Um eine Aussage machen zu können, wo das Problem mit dem Zugang ist, müsste man die beiden PHP-Scripte näher untersuchen und versuchen, zu rekonstruieren, was die Hacker genau gemacht haben.
Möglicherweise gibt es weitere Manipulationen an den Dateien? Spielen Sie mal ein File-Backup (kein Datenbank-Backup, dann verlieren Sie Kunden- / Bestell-Daten!!!) ein, eventuell lösen sich Ihre Probleme damit bereits.
Sonntag, 04.09.2011 um 2:27 Uhr
Danke! Ich benutze self-commerce, das hat denselben Fehler (habe ich getestet). Ich habe die vorgeschlagenen Änderungen durchgeführt, das sollte helfen. Grüße, Peter
Samstag, 25.02.2012 um 2:15 Uhr
Eine türkische Hackergruppe ist derzeit…….
HAHAAAA
Ich kenn auch einen:
Steht ein Manta vor der Realschule……..
türkische Hackergruppe, man man du haust die Dinger hier raus alter
Sonntag, 11.03.2012 um 11:17 Uhr
Sie teilen sich Tonnen von interessanten Informationen, sauber und exzellentes Design Sie hier habe. Es ist sicherlich eine der informativsten Zeug zu diesem Thema, die ich je gelesen habe.