Code Injection: Da ist was faul! II

[joa]

Heute morgen bei der Serverwartung festgestellt, dass index.php (und viele andere, eingeschlossen) config.php meiner HP, WB 2.8, Neuinstallation von Anfang des Jahres, kein Upgrade, in der ersten Zeile einen injizierten Rattenschwanz von Code tragen. Gemeinsamkeit der - gefundenen! - befallenen Files zeigen Veraenderungsdatum 14. Februar 2010, das kann alles moegliche bedeuten oder gar nichts, aber es list zwei Tage vor dem letzten Report zur selben Attacke hier im Forum:

... php /**/ eval(base64_decode("aWYoZn ...

"FCKeditor ist 2.9.3
Designed For:    WebsiteBaker 2.7
Description:    This module allows you to edit the contents of a page using FCKeditor v2.6.5."

Ich bezweifle, das war', weil seit Lueckenmeldung FCKeditor auf neue Version geachtet. Logs von GoDaddy Security angefordert, gebeten, Augenmerk auf POST-Attacken und betroffene URLs zu haben. 24-48 Stunden sagen die, gerade veranlasst.

Interessante Gemeinsamkeit hfestgestellt: letzter vergleichbare Fall hier im Forum in 2009 erwaehnte, dass veraltete Kalendar-Software mit bekannten Sicherheitslucke eingesetzt. Das auch auf meinem befallenen Site, von "Calendar" cgi von Mevin Productions in San Francisco,  2, www.mevin.com . Ich hatte den dafuer vorgesehenen Patch eingesetzt, stellte am 23.2. und 25.2. aber dennoch fest, dass aus Jordanien (von IP-Nrn. im 86.108.xxx.xx) folgendes geschah:

Actions: [Pageview (/pages/calendar.php), Pageview (/pages/admin/add_user.php), Pageview (/admin/add_user.php)]

Zusammenhang? Das Kalendar-Verzeichnis liegt ausserhalb der WB-Installation.

Da ich verschiedene WB-Installation betreue (upgraded auf 2.8 ), ueberprueft, ob auf den anderen Sites selbe Code Injections. Fehlanzeige. Hoffe, dass nicht Trojaner/Keylogger.

Gibt es andere Updates zu diesem Angriff? Heilungschancen und Methoden?

[joa]

Wenn ich das richtig sehe, nach Lektuere der anderen Beitraege hier im Forum, dann koennte es sich um dieselbe Malware handeln, mit der auch Joomla, Moodle, Wordpress zu kaempfen hatten. Ich poste das hier nur, weil sich die Diskussion hinter dem Link erhellt, was sich da genauer abspielt:

http://74.125.155.132/search?q=cache:v9pxd4suxosJ:moodle.org/mod/forum/discuss.php%3Fd%3D111710+php+/**/+eval%28base64_decode%28%22aWYoZn&cd=2&hl=en&ct=clnk&gl=us

[doc]

Hi,

ich würde die in diesem Thread geposteten Schritte durchführen: http://www.websitebaker2.org/forum/index.php/topic,17186.msg114205.html#msg114205

Wenn möglich zuvor eine Liste der verwendeten Module (inkl. Versionsnummer) erstellen, um bei evtl. Nachfragen darauf antworten zu können.

Doc

[WebBird]

Wichtig, wie immer: Den Provider fragen, ob er etwas zum Einfallstor sagen kann. Der Provider hat Zugriff auf die Logfiles und müßte dann in der Lage sein, nähere Informationen zu liefern. Nur dann kann man das Problem einkreisen und beseitigen.

Sollte auf die Anfrage keine vernünftige Antwort kommen: Nerven, nerven, nerven! Der Provider MUSS ein Interesse daran haben, solche Analysen zu unterstützen. Immerhin werden über solche Einfallstore immer wieder die Server infiziert, im schlimmsten Fall nicht nur der Webspace eines Kunden, sondern aller Kunden auf dem gleichen Server. Hat er offenkundig dieses Interesse NICHT, ist DRINGENDST zu empfehlen, den Provider zu wechseln! Das heißt dann nämlich im Umkehrschluß, daß Deine Seiten dort nicht sicher sind. (Eben auch dann nicht, wenn andere sich eine Lücke einschleppen.)

Beispielsweise hatte ich mal eine Lücke in phpMyFAQ, die ausgenutzt wurde, da wurde mir genauestens mitgeteilt, wann über welches Script was getan wurde, daß das Script deaktiviert wurde, und was ich darüber hinaus noch unternehmen soll. DAS ist Kundenservice. Immerhin habe ich als Inhaber von einfachem Webspace selbst weder die Überwachungs- noch die Analysemöglichkeiten, die der Provider hat.

[joa]

Danke - ich habe da mit GoDaddy bisher gute Erfahrungen gemacht, die reagieren schnell, wenn man mit den richtigen Leuten spricht.

Habe denen die "Hausaufgaben" gegeben, die hier im Forum gelistet waren, und werde auch noch einmal im Sinne Deiner Antwort nachhaken, falls das offen bleibt. Werde Ergebnis (falls erhellend...) hier posten.

Werde in der Datenbank speziell mal nach Prefix/Tabellen schauen, die in dem von mir geposteten Tread erwaehnt werden. Wenn ich das richtig verstehe, legt es ja seine eigenen Tables an...

[joa]

Also, noch mehr Details: es nimmt sich alle anklickbare Bilder und Links auf dem Site, und in einer iframe-Konstruktion, nimmt einen Umweg zu einem Script, in meinem Fall auf g e o non dot net , im Verzeichnis /in
Google-Suche ergibt, dass dahinter bekannter html / iframe Trojaner. Holy cow.

[wollinche]

Also, noch mehr Details: es nimmt sich alle anklickbare Bilder und Links auf dem Site, und in einer iframe-Konstruktion, nimmt einen Umweg zu einem Script, in meinem Fall auf g e o non dot net , im Verzeichnis /in
Google-Suche ergibt, dass dahinter bekannter html / iframe Trojaner. Holy cow.

ACHTUNG, nicht anklicken:

 ht*p://geonon.net

da wird, über ein Script, automatisch ein (sogenanntes) pdf-Files geöffnet (ja nach Einstellung -> runtergeladen)

Dieses Files nutzt eine Lücke im pdf und startet ein integriertes Java-Script -> ? ? ?  (hier habe ich abgebrochen)
Andere Reader, andere als Adobe Reader, zeigen nur ein graues leeres Dokument ...

Wichtig, wie immer: Den Provider fragen, ob er etwas zum Einfallstor sagen kann

Geschenkt, das Tor ist WebsiteBaker mit dem Schlüssel FCKEditor

Auch hier: Es wurde eine c99-Shell installiert, die komplette installation sollte gelöscht werden.
Vorgehensweise wie von @doc beschrieben.

@websitebaker-Entwickler:
Der Core scheint recht unangreifbar zu sein, aber über (Fremd-)zusätze / Module  scheint es möglich zu sein auf dem Server einiges zu installieren.
Hier solltet ihr mal nachdenken was das System als ganzes sicherer macht.
Leider ist es so das, mal auf eine Lücke eingeschossen, immer wieder versucht wird diese Lücke aktiv zu nutzen.

[Waldschwein]

Hallo!

Der Core scheint recht unangreifbar zu sein, aber über (Fremd-)zusätze / Module  scheint es möglich zu sein auf dem Server einiges zu installieren.
Hier solltet ihr mal nachdenken was das System als ganzes sicherer macht.
Leider ist es so das, mal auf eine Lücke eingeschossen, immer wieder versucht wird diese Lücke aktiv zu nutzen.

Das stimmt wohl. Das Problem denke ich ist, dass Module selbst sehr viel tun dürfen, was sie wollen und WB selbst wohl zu wenige Möglichkeiten bietet, gewisse Dinge zu realisieren, sodass eben Module dann selbst das Ganze mitbringen.
Ich denke aber, das wird ein größerer Brocken sein, mehr oder weniger würde es bedeuten, den gesamten Umgang mit allen Modulen zu überdenken und neu zu programmieren.

Allerdings gibt es seit einigen Tagen vermehrt hier Meldungen zu den eval base64 Geschichten. Anscheinend haben die Hacker dahinter vermehrt Probleme bei WB festgestellt, und gehen jetzt auf viele Seiten los. Also wäre es sinnvoll, so schnell wie möglich so viele Informationen wie es nur geht zu sammeln.
Auch wäre es evtl. sinnvoll, alte WB Installationen mit den Fehlern komplett aus dem Netz zu nehmen, auch wenn es nicht mehr unterstützte Versionen sind. Ich denke hier an WB 2.7. WB 2.6x hat weniger Probleme, weil sie (logischerweise) den FCKeditor nicht benutzen.
Man bedenke: Auch wenn man eine Version nicht mehr unterstützt, Sicherheitslücken sollte man trotzdem stopfen. Das kommt allen - nicht zuletzt dem Gesamtprojekt WB - zu gute.

Gruß Michael

[doc]

Hi,

... aber über (Fremd-)zusätze / Module  scheint es möglich zu sein auf dem Server einiges zu installieren.

Wer auf seinem Webspace .htaccess Dateien nutzen kann, könnte zusätzlich den WB /admin Ordner und den FCKEditor Modulordner /modules/fckeditor mit einem .htaccess / .htpasswd Schutz versehen.

Nachteil ist doppelte Login (einmalig pro Session da im Browser gespeichert). Vorteil der Schutz vor direktem Aufruf der in den Ordner befindlichen Dateien inkl. enthaltener Unterordner.

Bei vielen Usern helfen ein paar Zeilen PHP Code, um die htaccess und htpasswd Dateien automatisch mit Daten aus der WB Userdatenbank zu generieren bzw. abzugleichen (Chron job). Geht aber auch manuell, mit nem zweiten Passwort etc.

Doc

P.S.: Bei Drittmodulen mit kritischen Funktionen (Uploads etc.), sprich FCKEditor oder Xinha bei mir Standard. Macht bei Frontendmodulen natürlich wenig Sinn (Besucher sollen ja z.B. ein Gästebuch ohne Login nutzen).

[Hans>NULL]

Sehr merkwürdig. Gerade Experimente mit der c99 u.a. haben bei unseren Installationen nie gegriffen.
Da aber nicht über Server- und PHP-Installation bekannt ist, kann man zwar berechtigt unter WB schauen, ohne Berücksichtigung anderer Faktoren ist das aus meiner Sicht zu wenig; speziell die Infos hierzu betreffend.
Gruß, Hans>NUL

[joa]

Geschenkt, das Tor ist WebsiteBaker mit dem Schlüssel FCKEditor

Auch hier: Es wurde eine c99-Shell installiert, die komplette installation sollte gelöscht werden.
Vorgehensweise wie von @doc beschrieben.

Danke, das deckt sich mit dem Moodle-Thread. Okay, wird gemacht. Was macht uns so sicher, insbesondere, da meine eine 2.8 Neuinstallation war, mit FCKeditor (module und source) auf dem neueren Stand (nach Patch), dass hier der Schluessel liegt? Wie gesagt, bemerkte manuelle Zugriffsversuche auf (vielleicht zu spaet) gepatchte, nicht oeffentlich angezeigte Kalendar-Datei ausserhalb der WB-Installation.

Wenn es anderrseits eine PDF-Luecke nutzt (und so ins System gelangt ist), dann waere ein infizierter  .pdf-upload im Medienverzeichnis ebenfalls moeglich als Einfallstor?

[DarkViper]

Bei allen WB 2.x Versionen wird uns nichts anderes übrig bleiben, als auf Ereignisse zu reagieren. WB 2.x bietet leider vom Konzept her keine Möglichkeit eine abgesicherte Modulschnittstelle ohne unverhältnismässigen Aufwand zu implementieren.
Derzeit ist WB aus Sicht der Module leider offen wie ein Scheunentor, so dass ein findiger Modulprogrammierer (also einer, der wirklich programmieren und nicht nur coden kann) ohne grosse Probleme aus dem CMS eine Waschmaschine basteln könnte.    
Erst ab der nächsten Generation (3.x) ist die Realisation eines effektiven Sicherheitskonzepte s möglich, genauso wie eindeutige Schnittstellen und Guidelines. Dadurch können dann auch Module vor Freigabe von der QS auf strikte Einhaltung der Vorgaben überprüft werden.
Bis dahin bleibt uns nur die Möglichkeit, soviele Informationen als möglich zu sammeln und noch vorhandene Sicherheitslücken zu stopfen.

Aber nicht allein wir, die Core-Entwickler sind da gefragt, sondern jeder einzelne, der Module entwickelt und der WB-Gemeinde anbietet, sollte sich seiner Verantwortung gegenüber den Anwendern in Bezug auf die Sicherheit seiner Produkte im Klaren sein und entsprechend verantwortungsbewus st handeln.
Nicht die Menge, sondern die Qualität und Sicherheit der gelieferten Funktionen macht ein gutes Modul

Werner
(Core-Dev & QS-Team)

[joa]

Gibt es einen Grund, warum das AMASP Modul Control Panel bei mir nicht mehr einsehbar ist? Es zeigt ploetzlich nicht mehr die Liste (mit Revisionsstand) der einzelnen Module an. Dh, wenn ich hier einen Ueberblick der Module geben wollte, die zum Zeitpunt des Angriffs installiert waren, muesste ich jedes von Hand ansteuern im Module-Bereich. Hat jemand eine bessere Idee?

[instantflorian]

@joa

ModuleList:
http://www.websitebaker2.org/forum/index.php/topic,17186.msg114028.html#msg114028

[joa]

Merci. Ich war gerade dabei, weil mein AMASP Control Panel nicht mehr funktionierte, das per view details von Hand durchzugehen, als ich feststellete, das jeder Zugriff auf die View Details Funktion im Hinter grund eine Verbindung zu ge o no n DOT net
When checking details, background connection to 1 news DOT her mi son DOT com (leerstellen rausnehmen und NICHT anklicken) aufbaute. Dann versuchte jemand oder etwas eine Java-App auf meinem PC zu installieren, hoffentlich erfolgreich abgeblockt. Wollte keine Zeit vergeuden und bin mit Doc's Anletung fortgefahren...

Danke fuer all die Hilfe - WebsiteBaker hat eine der besten Entwickler/User-Gemeinden, die ich kenne.

[Hans>NULL]

Jo, angekommen. Habe auch noch per PM (DarkViper) Kontakt. Ist geklärt.
Edit: War beim Verfassen des Beitrag "etwas abwesend", deshalb etwas "schräg")
Nur wenn man keine Infos zur PHP-Konfiguration von den Betroffenen bekommt, läßt sich noch nicht mal ein Tip für eine evtl. restriktive Ausführung machen. Stattdessen jagt man -anscheinend nur- der Hinterlassenschaft hinterher. Vielleicht 'nen neuen Thread "Ritt durch die Wüste" aufmachen ?  
Gruß, Hans>NUL

[joa]

Vieln Dank fuer die wirklich hilfreichen Hinweise.

Was sich mir noch nicht erschliesst, ist, da es eine 2.8 Neuinstalltion war, mit Installations-Routine sofort aus dem Netz genommen und so, FCKeditor sehr bewusst mit emphohler, nicjht veralteter Version installiert, und so weiter, ob nun ein - moeglicher - Einfallsweg - ist, oder, wahrscheinlichen (?!) .pdf-dateien. Um die fraglichen Zeit waren (wir sind ein Non-Profit) zwei PDF's hochgeladen worden, fuer die ich nicht die Hand ins Feuer legen koennte, und die im Source Script-Inhalt haben, der - kenne mich da nicht aus - aber auch Adobe/PDF-Zeugs sein koennte.

Befallen: Alle .php Dateien auf dem Server, alle mit Veraenderungsdatum 14. Feb. Was mir ausserdem nicht gefiel, ist, dass es bei Zugriff auf Backend eine Zwei-Stufen-Weiterleitung auf diese andere Domain gibt (meine letzte Mail).

[Hans>NULL]

Installiere doch mal so was einfaches wie phpsecinfo.
Somit kann man wenigstens etwas über die Grundeinstellungen erfahren.
Gruß, Hans>NUL

[joa]

wenn man keine Infos zur PHP-Konfiguration von den Betroffenen bekommt,

'tschuldigung, wird nachgeliefert:

die ini:

register_globals = off
allow_url_fopen = off

expose_php = Off
max_input_time = 60
variables_order = "EGPCS"
extension_dir = ./
upload_tmp_dir = /tmp
precision = 12
SMTP = relay-hosting.secureserver.net
url_rewriter.tags = "a=href,area=href,frame=src,input=src,form=,fieldset="

[Zend]
zend_extension=/usr/local/zo/ZendExtensionManager.so
zend_extension=/usr/local/zo/4_3/ZendOptimizer.so

Ich habe die komplette php. umgebung (angezeigt mit testing.php), soll ich sie jemandem schicken?

[BerndJM]

Ich bin ja nun weiß Gott nicht der Guru in solchen Fragen, aber ich überlege jetzt mal nur laut:

... ist es möglich, daß es gar nichts mit WB im besonderen zu tun hat ... sondern eher mit irgendeiner verqueren Serverkonfiguration - PHP-Version - Konfiguration derselben ...

... ich habe mich jetzt mal bischen mit diese "c99"-Shell befaßt, die ja hier schon öfters erwähnt wurde, die kann doch eigentlich nur funktionieren, wenn die ganze Konfiguration schon mistig ist - oder übersehe ich das was ...

... wirklich gezielt (abgesehen von den Soforthilfen) kommen wir hier doch nur weiter, wenn wir soviele Informationen von den Betroffenen sammeln wie irgend möglich ...

... dies aber möglichst nicht durch das posten von "Serverinternas" in irgendwelchen Threads ...

... hier sollte das QM-Team eine erste Anlaufstelle bieten um die Daten so umfassend wie möglich zu erfassen und auszuwerten ...

... alles andere wird sonst eine reine Rätselraterei.


Grüßle Bernd

[Hans>NULL]

Yep, so isses.
Nächste Woche gibt's für mich noch 'ne Möglichleit in einer IT-Firma WB mit Web Application Scannern zu checken. Mal gucken was dabei rauskommt (Beim letzten Mal=NIX)
Gruß, Hans>NUL

[Luisehahne]

Danke Bernd,

hatte ich auch schon gedacht. Oder andere Möglichkeit, ein befallener PC, Browser mit seinen ganzen Add-ons, wobei dann bearbeiten im Backend zugeschlagen wird.

Ich beobachte die ganze Geschichte sehr genau. Soweit ich das zurückverfolgen kann, sind alle Lücken im FCKeditor bereits 2009 geschlossen worden. Beobachte auch laufend die Einträge meiner Server Logs und konnte bisher nichtrs verdächtiges entdecken.

In meinen Hosting läuft mod_security, und ich vertraue darauf das Angriffe sofort erkannt werden. Aber man weis ja nie. Also gilt weiter höllisch aufpassen.

Dietmar

[WebBird]

Noch eine kurze Anmerkung: Es kam hier so durch, als würden gezielt WB-Installationen angegriffen. Das glaube ich nicht. (Viel zu viel Aufwand von Hacker-Seite für viel zu wenig Effekt.) Ich denke, das ist ein allgemeiner Angriff, wie manche Spamwellen, und WB hat "zufällig" eine der Lücken. (Vermutlich im FCK, aber so wie ich das sehe, wissen wir das noch nicht genau.)

Übrigens war meine WB-Installation bisher nicht betroffen, obwohl es nur eine total ungeschützte Demoseite ist. (Soll heißen, da geb ich mir keine Mühe mit irgendwelchen Sicherungen, weil ich die sowieso immer wieder zerschieße und neu aufsetzen muß. *g*) Allerdings funzt da der FCK auch nicht, wie in einem anderen Thread erwähnt... Mag ein Zusammenhang sein, muß aber nicht. (Server bei Goneo.)

[joa]

Update: Also, die Luecke in der Kalendar-SW, die ich - wie ich denke, rechtzeitig - geschlossen hatte, ist weitgehend auszuschliessen. Ich hatte heute ein Gespraech mit dem Entwickler, der damals auch zuergig eine Mail rausgeschickt hatte an User. Er bestaetigte, was soweit auch meine Einschaetzung war.

Das betr. cgi-Script lag ausserhalb der CMS-Umgebung lag, Extra-Verzeichnis, und die Luecke liess "nur zu, dass ein unautorisierter Nutzer eingetragen werden konnte, dessen Zugriffsrechte nur kontrollierte Eintraege in eine Datei zuliess, ist es relativ unwahrscheinlich, dass dies das Einfallstor war. Zumal die Script-Kids da bei ihrem ersten manuellen Zugriff (darauf lassen die Logs schliessen) einen Schmiereintrag hinterliessen - jemand der Groesseres vorhatte, wuerde wohl kaum so auf sich aufmerksam machen. Koennte es die "2. Welle" anlocken? Moeglich, aber unwahrscheinlich.

Die PDF-Variante? Bei FCKedit dachte ich als aufmerksamer Lurker in diesem Forum seit mehreren jahren., alles richtig gemacht zu haben.

Ja, ich habe die php-Details, wuerde sie aber ungern hier posten. Und auch nicht ins Dunkle - Email-Adresse bitte an die meine (mein Account hier im Forum), falls Datei gewuenscht. Bitte meine manchmal holprigen Ausfuehrungen zu entschuldigen, bin sprachlich seit langem in einem anderen Kulturkreis unterwegs.

[Waldschwein]

Yep, so isses.
Nächste Woche gibt's für mich noch 'ne Möglichleit in einer IT-Firma WB mit Web Application Scannern zu checken. Mal gucken was dabei rauskommt (Beim letzten Mal=NIX)
Gruß, Hans>NUL

Spar dir die Zeit, das habe ich (und andere) schon längst gemacht. Die Ergebnisse sind kaum zu gebrauchen, außer dass mal hier mal da eine offene XSS vorhanden ist. Acunetix und wie sie heißen, und mit Sicherheit nicht die kostenlosen Werbedemos.  Die Automatisierungssca nner sind evtl. mal ganz nett, um eine Sicherheitslücke im Vorfeld zu entdecken.

Kleine Anmerkung: Dieses ominöse Kalendermodul ist aber nicht zufällig http://slink2.no-ip.info/wbtest/pages/calendars/event-calendar.php ? Weil hier hat einer der Scanner schon im Frühjahr 2008 XSS entdeckt, vor einer Woche immer noch.

Gruß Michael