Sicherheitslücke in OS Comerce

Hallo Martin,

ja mir würde es auch interressieren, scheint rafiniert zu sein.
Im allg. werden solche eploit durch xss mittels iframe injection gemacht...vielleicht lässt auch einer der Formulare etwas duchsicken.
Ich glaube nicht an einer SQL injection, da sonst eher DB tabelle geklaut wären...

Aber an unsere stelle würde ich JETZT SOFORT einen Backup machen und die Seite beobachten...
Nicht vergessen...http://www.plus.de war über 10 Tage offline wegen so eine Geschichte...

Julien.

Hallo Martin,

Hmm..ich bin kein Anwalt aber ich denke mir dass als "für den Inhalt Verantwortlichen" und "Inhaber" im Sinne des Gesetz eine Haftung von der Seite des Shopsbetreiber entsteht.
Weil im Umkehrschluss Du eine Malwareseite bauen könntest, die Leute mit attraktive Angeboten locken könntest und dafür nicht haftbar wärest?
Das glaube ich nicht.

Da der Shop unter GPL steht und wenn man die Lizenz liest steht da irgendwie dass für nichts garantiert wird auch nicht die Funktionalität, glaube ich dass die Jungs aus der Haftung raus sind.
Als Service Partner und im Geschäftsinn sollte aber eine Hilfe deren Seite sicher nicht fehlen.

Jetzt aber zum Thema Sicherheit von SEO, auch da bin ich kein Expert (leider) aber innerhalb weniger Minuten sind mir schon XSS Lücken aufgefallen (warum habe ich nie davor geforscht?? keine Ahnung.)

Aber einer der Schwachstellen mMn ist die xtc_update_whos_online.inc.php
Es werden die Variablen

$wo_referer = $_SERVER['HTTP_REFERER'];
$useragent_referer = $_SERVER['HTTP_USER_AGENT'];

Direkt in der DB geschrieben ohne wenn und aber...und das ist nicht good.

EInschleusen von JS code durch HTTP referer:
In FF folgende Plugin downloaden und installieren: Modify Headers v0.7.0.2
Dann den referer in zB.

'"()&%1<ScRiPt >prompt(928833)</ScRiPt>

ändern,
dann auf zB. die 404.php Seite deines Shop gehen und dann..siehst Du wie hier den JS Code "injektiert" wurde.
Es ist mir klar dass dies ein harmlose Code ist und dass man sicher damit nichts anstellen kann..(nur wenn man will vielleicht..)
ABER

es wird auch ein SQL Fehler ausgespuckt und dann könnte man es als Angriffmöglichkeit nehmen um weitere Unfug zu betreiben.

Es ist sicher nicht die einziege Möglichkeit einzusteigen und wenn man die steigende Zahl der Infirzierte Shops seiten sieht..können wir auf einem baldigen Fix hoffen.

Übrigens so wie ich gelesen habe sind auch die domains die die Schadcode geschickt haben gesperrt worden...also ein bisschen ruhe bis zum nächsten Mirror haben wir noch.

Julien.

Hallo,

noch mehr Info:

habe glaube ich die 2 von oben schliessen können (bitte aber testen)

if($aktuelle_datei)
		$wo_last_page_url = $aktuelle_datei;
	else
    	$wo_last_page_url = addslashes(getenv('REQUEST_URI'));

	$wo_referer = $_SERVER['HTTP_REFERER'];
	$useragent_referer = $_SERVER['HTTP_USER_AGENT'];

mit

// FIX XSS SCRIPTING ATTACKING REFERER & USER AGENT
if($aktuelle_datei)
		$wo_last_page_url = $aktuelle_datei;
	else
$wo_last_page_url = addslashes(fix_xss_attack(getenv('REQUEST_URI')));


$wo_referer = fix_xss_attack($_SERVER['HTTP_REFERER']);
$useragent_referer = fix_xss_attack($_SERVER['HTTP_USER_AGENT']);

Dann unten eine Funktion addieren:

function fix_xss_attack ($url){
  $urlregex = "^(https?|ftp)\:\/\/([a-z0-9+!*(),;?&=\$_.-]+(\:[a-z0-9+!*(),;?&=\$_.-]+)?@)?[a-z0-9+\$_-]+(\.[a-z0-9+\$_-]+)*(\:[0-9]{2,5})?(\/([a-z0-9+\$_-]\.?)+)*\/?(\?[a-z+&\$_.-][a-z0-9;:@/&%=+\$_.-]*)?(#[a-z_.-][a-z0-9+\$_.-]*)?\$";
  $url_fix = eregi($urlregex, $url);
    if ($url!=$url_fix){
    $url_fix = "ALERT-POSSIBLE-XSS-ATTACK";
    }
  return $url_fix;
}

admin, bitee testen aber es sollte funktionieren.

Dann bleibt nur noch das parsen von $_GET values in den String und XSS sollte mMn geschlossen sein.

Julien

Hallo,

leichter Kommando zurück es hilft zwar aber es bleiben noch viele Aufrufe von $_SERVER['REQUEST_URI'] und $_GET die gepacht weden müssen.

Am besten ist es sicherhttp://phpids.org/ zu integrieren...aber dafür fehlt mir die Zeit.

admin, ihr seid jetzt dran.

Hmm..so viel ich sehen kann, sind diese Lücken im core des Shops, also weit von der Templates entfernt..
Aber ich glaube wirklich gelesen zu haben in den AGBs dass der Shop as-is angeboten wird, lediglich für den SupportForum-Zugang, also nicht den Support! ein Geldbetrag gefragt wird. Aber ich bin kein Anwalt und das durchLesen 1000 Software AGB ist nicht bei mir wirklich synonym für Spass

Wieso ich darauf komme...weil ich eine Genie bin?

Nein, weil ich auf meine Lokale Umgebung dieses Tool laufen gelassen habe.
Acunetix Web Vulnerability Scanner in der Free Edition (checkt nur die XSS Exploits)

Und der nach dem ersten durchgang ca. 130 Lücken entdeckt hat: $_SERVER['REQUEST_URI'], $_SERVER['HTTP_REFERER'],$_SERVER['HTTP_USER_AGENT'].
Dann habe ich selbst getestet..und festgestellt dass es stimmt..
Nach der Anpassung der xtc_update_whos_online.inc.php sind es leider nur noch 60...

Aber immerhin die Tür steht nicht ganz weit offen.

Letzter Login des Admin ist 28.07...vielleicht sind sie alle in Urlaub.
Ab heute ich auch.

julien.

Hallo ihr beiden, ich muß euch absolut recht geben. Überhaupt keine Reaktion auf dieses Brisante Thema geht auch über meinen Horizont.

Juergen

HAllo Julien

ALERT-POSSIBLE-XSS-ATTACK kommt dan in statistik beim den IP's

Wir haben das Thema schon im Blick und arbeiten an der Lösung. Wobei anzumerken ist, die betroffenen Shop basieren auf osCommerce! die Lücke wurde im November schon von osCommerce geschlossen! Das xt:Commerce 3 Shops betroffen sind und deren Ableger ist bisher NICHT bekannt!

Statement:
Nach nochmaliger Analyse des ganzen Vorfalles hier noch einmal eine Zusammenfassung aus unserer Sicht:

1. osCommerce ist über eine Schwachstelle angreifbar, die bereits seit 2 jahren gefixt ist. (letztes update war November 2010!) Das Problem liegt im ungeschützten Adminbereich. Die Problematik stellt sich bei commerce:SEO + xt:Commerce 3 nicht! Hier ist der Adminbereich geschützt. Bei xt:Commerce 3 gab es diverse Schwachstellen, die ALLE in commerce:SEO bereits seit langen behoben sind.
2. commerce:SEO Schutz eingebaut: in der application_top.php werden potenzielle SQL Injections abgefangen. Wir haben das mit dem Header manipulieren nachstellen können, allerdings werden hier keine Daten in die DB geschrieben. Die Auswirkungen bleiben also lokal auf den Rechner beschränkt.
3. Acunetix Web Vulnerability Scanner 7 Test. Ja da kommen auch Meldungen, allerdings bleiben die auch, ebenso wie die Modifikation des Headers, lokal auf den Rechner beschränkt.

Was kann man tun:

Erweiterung der .htaccess
Suche: RewriteEngine On

füge danach folgendes ein:

## Begin - Rewrite rules to block out some common exploits.
# If you experience problems on your site block out the operations listed below
# This attempts to block the most common type of exploit `attempts` to Joomla!
#
# Block out any script trying to base64_encode data within the URL.
RewriteCond %{QUERY_STRING} base64_encode[^(]*\([^)]*\) [OR]
# Block out any script that includes a <script> tag in URL.
RewriteCond %{QUERY_STRING} (<|%3C)([^s]*s)+cript.*(>|%3E) [NC,OR]
# Block out any script trying to set a PHP GLOBALS variable via URL.
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
# Block out any script trying to modify a _REQUEST variable via URL.
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
# Return 403 Forbidden header and show the content of the root homepage
RewriteRule .* index.php [F]
#
## End - Rewrite rules to block out some common exploits.

Das kommt zwar von Joomla, ist aber allgemein ein wirksamer Grundschutz vor Scripten.

Die SQL Fehlermeldung, die dabei kommt, kann (sollte?) man eventuell reduzieren, damit keine weitere Angriffsfläche entsteht:

Suche Datei: xtc_db_error.inc.php

Suche darin folgenden Code:

// handling an sql error
            echo "<b>SQL Fehler</b> [$errno] " . SQLMESSAGE . "<br /><br />\n\n";
            echo "<b>Query:</b> " . SQLQUERY . "<br /><br />\n\n";
            echo "Beim Aufruf der Datei <em>" . SQLERRORFILE . "</em> ";
            echo ", PHP " . PHP_VERSION . " (" . PHP_OS . ")<br /><br />\n\n";

Ändere in:

// handling an sql error
            if ($_SESSION['customers_status']['customers_status_id'] == 0) {
                echo "<b>SQL Fehler</b> [$errno] " . SQLMESSAGE . "<br /><br />\n\n";
                echo "<b>Query:</b> " . SQLQUERY . "<br /><br />\n\n";
                echo "Beim Aufruf der Datei <em>" . SQLERRORFILE . "</em> ";
                echo ", PHP " . PHP_VERSION . " (" . PHP_OS . ")<br /><br />\n\n";
            }

und:

echo "<b>My ERROR</b> [$errno] $errstr<br />\n";
                echo "  Fatal error on line $errline in file $errfile";
                echo ", PHP " . PHP_VERSION . " (" . PHP_OS . ")<br />\n";

gegen:

if ($_SESSION['customers_status']['customers_status_id'] == 0) {
                echo "<b>My ERROR</b> [$errno] $errstr<br />\n";
                echo "  Fatal error on line $errline in file $errfile";
                echo ", PHP " . PHP_VERSION . " (" . PHP_OS . ")<br />\n";
            }

Somit wird nur noch der Admin berechtigt, SQL Fehlermeldungen zu sehen. Ich halte diese Variante für sinnvoll, zumal der Admin trotzdem in der Lage ist, Fehler zu analysieren.

Grundlegend verfalle ich nicht sofort in Panik bei solchen Vorkommnissen und behalte einen kühlen Kopf. Da ich regelmäßig heise lese, bin ich stets über aktuelle IT-Ereignisse im Bilde.
Ich halte nicht viel davon, Sofort Panik zu verbreiten, die sich im Nachgang oft als reine luftblase raus stellt (wie damals oft bei ecomb...). Das verunsichert die Leute und verleitet viele zu Schnellschussreaktionen.
commerce:SEO v2.1 wurde mit diversen Security Scannern mehrfach beackert und hierbei keine relevanten Probleme fest gestellt. Wir werden aber am Ball bleiben und Bei Bedarf Fixes liefern.

Die aufgeführten Fixes sind im QF3 bereits enthalten. ACHTUNG, dabei wird die .htaccess mitgeliefert!!! Wer da schon Änderungen gemacht hat, bitte VORHER vergleichen!!! Es wurde der Sec-Fix eingebaut, aber auch das Caching noch etwas verbessert.

Danke.
Und jetzt also wider Ruhe

OK - Aber man darf doch mal unruhig werden.

Trotzdem vielen Dank für die Info!

Yep abber besser nicht zu unruhig.

Gesundheit geht doch vor

Und in Forum gibt es dann schnell Panik.
( ist naturlich nicht gut )
Dass teil von Julien ist teils dafür einer lösung aber dann wirkt also den Statistik nicht . ( bei uns in jedenfalls sehe post oben)

Hallo lasermodelle, mit Luftblase meine ich nicht diesen thread hier. Ich meine das bezogen auf andere Foren, die gerne mal die Leute in Panik versetzen und dann bricht das Große hektische Treiben aus und es gehen mehr Shops dabei kaputt, als überhaupt jemand gehackt wird
Wie mann aber fast jeden Tag bei heise nachlesen kann, werden trotz alledem genügen Webseiten zur Zeit gehackt und das Thema ist auch für uns ein hoch brisanntes.
Das kommt natürlich auch immer kurz vorm Urlaub, wo eh schon die Luft brennt.
Ich teste noch ein wenig am QF3 und weitere potenzielle Verbesserungen, so dass das QF3 noch heute Abend kommen wird.
Auch im Urlaub werde ich einen Blick auf alles haben, allerdings können Antworten, die nicht wirklich eine hohe Prio haben, etwas auf sich warten lassen.
Ich habe im letzten halben Jahr den Shop fast komlett umgekrempelt und von vielen vielen Fehlern befreit, die noch in der Vorgänger Version drin waren. Jetzt brauche ich aber auch mal eine Pause um wieder Energie zu tanken :-))
Euch erst mal eine schöne Zeit. In 14 Tagen sind wir dann auch wieder im Dienst.