Sicherheitspatch für alle Shopversionen (security_fix_2015_10_06.zip)

[Tomcraft]

Liebe Community,

wir haben eine Sicherheitslücke gefunden, die alle veröffentlichten Shopversionen von modified eCommerce betrifft.

Es ist jedem zu raten diese mittels angehängtem Patch zu schliessen.

Es muss nur die Datei ausgetauscht werden.

Download des Fixes: Klick mich

Wir wünschen euch weiterhin gute Geschäfte und viel Spass mit unserer Shopsoftware.

Euer modified eCommerce Shopsoftware Team

Linkback: https://www.modified-shop.org/forum/index.php?topic=33736.0

[karsta.de]

Vielen Dank!

[Viol]

[webald]

Erst mal danke für wieder ein geschlossenen Lücke.

Ich hätte dazu aber mal ein, zwei Anmerkungen:
Warum wird die Rev.-Nr. in der Datei nicht mehr gepflegt?
Ich meine diese Zeile:

Code: PHP  [Auswählen]

   $Id: xtc_get_countries.inc.php 899 2005-04-29 02:40:57Z hhgag $  

Wir sind doch schließlich schon weit über 8.000 und irgendwann wird es unübersichtlich zu sehen ob eine Datei aktuell oder überholt ist.

Die Lücke könnte in dieser Art ja noch häufiger im Code sein bzw. der Code könnte auf die gleiche Weise sicherer gemacht werden. Notwendig?

[thomas57]

[Bonner]

Dem schliesse ich mich an!

Bonner

[cayuco]

Auch von mir ein Danke!

[Fakrae]

[longchuan]

Danke

[jaorn]

1000 dank!

[innuXTC]

merci!

[JZ_Aqua]

Danke für die Bereitstellung des Sicherheitspatches.

[Haustier-Laden]

auch von mir ein dickes Danke.

[Jürgen]

[MarcoMG]

[BiDoubleU]

Einfach 

[noRiddle (revilonetz)]

Interessant was so alles noch auftaucht wo nie einer bewußt reingeschaut hat...

Merci.

Gruß,
noRiddle

[Alex23]

[pq]

Interessant was so alles noch auftaucht wo nie einer bewußt reingeschaut hat...

Ich hab mich schon oft gefragt, ob es da kein Tool gibt, das die Sourcen eines Projektes nach Schwachstellen scannen kann.

[Tomcraft]

[...]
Warum wird die Rev.-Nr. in der Datei nicht mehr gepflegt?
[...]

Lange Geschichte, aber es wird wieder gepflegt werden!

Grüße

Torsten

[ReiniB]

Vielen Dank!

[golferteddy]

Frage:
Welcher Art war die Sicherheitslücke die mit dem FIX geschlossen wurde ?
Was hätte passieren könnnen ?

Danke

Gruss

[Hetfield]

Durch die Sicherheitslücke konnte die Datenbank manipuliert werden (SQL-Injection). Wir haben einen Hacker live dabei erwischt und haben sofort reagiert. Eine Anleitung, wo und wie diese SQL-Injection möglich ist, wird es hier allerdings nicht geben, da ja noch sehr viele Shops ohne Patch im Netz sind.

MfG Hetfield 

[golferteddy]

Danke

[versand-richter]

Vielen Dank auch von mir. 

Wir haben zwei Shops, in beiden wurde die Datei eingefügt. Der "ältere" Shop läuft damit ganz normal.

Beim Shop mit der Version  v1.06 rev 4642 SP2 kommt jetzt, wenn man ein neues Kundenkonto anlegen will oder etwas in den Warenkorb legen will, immer nur eine weiße Seite ?

[HHGAG]

Überprüfe die Dateirechte.

[ChristianRothe]

Vielleicht sollte man statt derartige Sicherheits-Patches tröpfchenweise zu veröffentlichen, einfach mal konsequent den gesamten Programmcode durchforsten und jedes SQL-Statement darauf abklopfen, ob Parameter ohne "Sanitizing" in die SQL-Queries einfließen. Wenn einfach konsequent immer und überall "xtc_db_input()" verwendet wird, dann ist das Risiko von SQL-Injections eigentlich komplett gebannt.

[versand-richter]

@ HHGAG: Wie sollten denn die Dateirechte sein ? Schreiben , Lesen ?

Habe in den "älteren " Shop geschaut, wo alles ohne Probleme läuft, dort sind die Rechte bei dieser Datei: Chmod 755 und so auch in dem anderen Shop, wo jetzt die weißen Seiten angezeigt werden

[p3e]

Sind beide xtc_get_countries.inc.php wirklich identisch?
Sonst vergleiche mal aus beiden Shops die ursprünglichen xtc_get_countries.inc.php (Back-up) mit einem Programm wie WinMerge. Eventuell ist der eine Shop doch älter.

[HHGAG]

Setze die Rechte auf 644 (bei hohen Rechten verweigern einige Server übrigens auch den Dienst ^^) wenn das nicht reicht, müsstest Du die Fehlermeldungen aktivieren, sprich:
eine leere Datei Namens:

_error_reporting.shop

im Verzeichnis:

export/

Wenn Du den Fehler reproduziert hast, kannst Du die Datei löschen und den Fehler hier her posten.

[versand-richter]

@ HHGAG:  Es lag an den Rechten, jetzt ist wieder alles okay ... also vielen lieben Dank für den Tipp.   

Wobei ich es nicht verstehe, denn der "ältere Shop" läuft auch mit Chmod 755, aber egal ... ich bin immer wieder einfach nur froh, wenn alles fehlerfrei läuft.

[HHGAG]

kein Problem =)

[golferteddy]

Durch die Sicherheitslücke konnte die Datenbank manipuliert werden (SQL-Injection). Wir haben einen Hacker live dabei erwischt und haben sofort reagiert.

Frage: Ja aber .... Wie reagiert man in so einen Fall richtig. Ich muss ihn ja irgendwie blockieren aber wie ?

[HHGAG]

Solange kein eigener Server vorhanden ist kann man nur per

.htaccess

den jeweiligen per IP bannen.

[golferteddy]

Danke ....

aber geht das nicht auch ein bisschen genauer.
Erst einmal muss ich ja die IP ermitteln und
zweiten dann WAS in die .htaccess eintragen

[HHGAG]

Order Deny,Allow
Deny from 192.168.0.1

wobei die IP zu ersetzen gilt. Die IP wäre u.a. über das "Wer ist Online" ermittelbar, aber sowas wird ein Laie nur schwer erkennen können, deshalb sollte jede Sicherheitslücke schnellstmöglich geschlossen werden.

[pdfil12]

Ihr solltet die Security Patches in die aktuelle Version die man bei euch downloaden kann, einpflegen.
Alles andere ist zu fahrlässig. Und da es eh nur Dateiänderungen sind, sehe ich da auch keine Probleme. Damit kann der Hinweis:

Die folgenden Korrekturen sind in Shopversion 1.06 rev 4642 SP2 noch nicht enthalten und müssen nachträglich installiert werden:

entfallen. Wirkt sonst nicht so richtig professionell und kann auch schnell übersehen werden. Ist auch eine generelle frage, weshalb man als Hauptdownload eine angreifbare Version anbietet...

[webald]

Na ja, es gibt ja andere Programme, die machen das genauso: Windows, Office, Suse, ....

[pdfil12]

Diese Programme/Betriebsysteme haben Autoupdater, welches bei modified Commerce fehlt.
Ich wollte nur darauf hinweisen. Es wäre besser für alle und der Aufwand dafür ist gering.

[Gulliver72]

Mal als Laie eine Frage zum Code

Derzeit wird die Variable typisiert. Soweit okay.
Allerdings kann jetzt eine DB-Abfrage einen Fehler werfen. Nämlich, wenn die Variable nicht Integer ist.
Um auch das zu vermeiden , sollte meiner Meinung nach die Zeile 20 ergänzt werden.

Code: PHP  [Auswählen]

    if (xtc_not_null($countries_id) && is_int($countries_id)) {

Ist mein Gedanke soweit richtig? 

[webald]

Das steht doch schon da.

Code: PHP  [Auswählen]

function xtc_get_countriesList($countries_id = '', $with_iso_codes = false) {
        $countries_array = array();
        if (xtc_not_null($countries_id)) {....

[Gulliver72]

Wenn ich das richtig lese, eben nicht.
Was passiert, wenn $countries_id not_null und nicht Zahl ist ? Bedenke, warum gefixt wurde. 
So wie der Code jetzt ist, kommt ein Fehler sobald $countries_id not_null aber keine Zahl ist. Das Array bleibt leer.
Mit meiner Codeerweiterung schicke ich das Programm direkt in die else Bedingung ohne $countries_id.

Oder liege ich falsch?

[Jürgen H.]

Hallo Gulliver72,

mit deine Erweiterung liegst du falsch. "is_int" Funktion prüft nicht nur nach Zahl nach, sondern auch nach Datentype "integer", was in dem Fall ein String (z.B. "81") ignorieren wird. Wenn du nach Zahl abfragen möchtest, benutze lieber "is_numeric" (Nachteil davon ist aber: dies erlaubt dezimal Zahlen).

Gruß,
Jürgen H.

[Hetfield]

Die Variable $countries_id kann auch ein String sein, der erst in ein Integer umgewandelt werden muss.
Hier wird ein String an die Funktion übergeben:

Code: PHP  [Auswählen]

xtc_get_countriesList('81');

Hier wird ein Integer an die Funktion übergeben:

Code: PHP  [Auswählen]

xtc_get_countriesList(81);

Bei der ersten Variante wird deine Abfrage mit is_int() nicht mehr funktionieren. Der Patch macht ja auf jeden Fall einen Integer aus der übergebenen Variable.

MfG Hetfield 

[webald]

So wie der Code jetzt ist, kommt ein Fehler sobald $countries_id not_null aber keine Zahl ist.

Hast du das getestet?

Code: PHP  [Auswählen]

$id='a';
$result = (int)$id;
echo "result(".$id."): " . $result;

$result wird im Falle eines Wertes der kein Integer ist zu 0, also einer Integer-Zahl. Das Array bleibt leer, weil es keine coutries_id=0 gibt.

Lustig ist das Verhalten bei Dezimalwerten als Parameter.

Code: PHP  [Auswählen]

$id='2.5';
$result = (int)$id;
echo "result(".$id."): " . $result;

Das ergibt als $result 2, obwohl die Eingabe kein Integerwert ist.

[web0null]

Lustig ist das Verhalten bei Dezimalwerten als Parameter.

Warum ist das "Lustig", das ist ein korrektes verhalten.

[...] obwohl die Eingabe kein Integerwert ist.

Es hat auch nichts damit zu tun welcher Type übergeben wird,
"(int)" z.B. ist eben dafür da, in einen Integer zu Konvertieren, egal was reinkommt.

Gruß

[webald]

Du hast ja recht. Ich wollte damit nur zum Ausdruck bringen, dass nicht wirklich auf Integer geprüft wird und dass damit auch ein falsches Ergebnis suggerierit werden kann. Man sucht nach "3.144545799" und bekommt das Ergebnis für "3" angezeigt und nicht dbnull.

[Gulliver72]

Wieder was dazu gelernt 

[Rosco]

Gern schließe ich mich allen Danksagern an. 

[gabto]

Danke schön..

[borkumer]