HILFE: BOT in meinem System!

T

testit

Well-Known Member
Guten Tag,

ich habe derzeit ein großes Problem: Trotz MOD-Security schafft es offenbar ein BOT sich immer wieder in meinem FreeBSD System einzunisten und spamt dann munter in der Gegend herum.

Unter/var/log cron fand ich folgenden Eintrag:

/usr/sbin/cron[3877]: (www) CMD (/tmp/.cuex/mcn/kate/y2kupdate >/dev/null 2>&1)

Im /tmp/.cuex liegt der BOT-Code.

Als ROOT mit crontab -l sehe ich o.a Crontab-Eintrag nicht. Wie kann ich den löschen?

Hat jd. sonst noch Tipps fuer mich?

Gibt es eine Möglichkeit, explizit in /tmp das Verzeichnis /.cuex zu verbieten?

Bisher habe ich die Eintrittsstelle des BOTs nicht finden können.

Danke im voraus
testit
 
Die Infektion kommt über irgendeine Webaplikation. Zu sehen daran, dass der Cronjob als www ausgeführt wird.
Folglich führt dieser Befehl zum Ziel:
crontab -u www -l
Im /tmp das Anlegen eines Verzeichnisses zu verbieten ist wohl nicht die rechte Idee.
Der Angreifer müsste einfach nur nen anderen Namen für seinen Mist nutzen, um dich auszutricksen.
Du hast verletzlichen Code auf dem System und den musst du ausfindig machen.
grep y2kupdate /var/log/httpd-access.log

Und jetzt die wirklich böse Neuigkeit - du weisst nicht, was der Pursche dir sonst noch für Eier ins Netz gelegt hat.
ls -l /tmp/.cuex/mcn/kate/y2kupdate

um zu schauen, wie lange der Krams da schon liegt.

Welche bekannten Webapps nutzt du?
 
testit schrieb:
Trotz MOD-Security schafft es offenbar ein BOT sich immer wieder in meinem FreeBSD System einzunisten und spamt dann munter in der Gegend herum.
Zum Vergrößern anklicken....

Ich wuerde als erstes mal die Webapplikation, die da offensichtlich fehlerhaft ist, abschalten oder den Bug beheben. Mod-Security ist mehr oder weniger Snake-Oil und kann allenfalls gegen bestimmte Angriffsmuster schuetzen.

Uebrigens: wenn der Bot tatsaechlich spammt, und wiederholt Dein System befallen hat, dann solltest Du wirklich ueberlegen, ob Du das System nicht erstmal komplett vom Netz nimmst. Alles andere ist asozial.

Als ROOT mit crontab -l sehe ich o.a Crontab-Eintrag nicht. Wie kann ich den löschen?
Zum Vergrößern anklicken....

Wie waere es mal mit einem Blick in die Ssytem-crontab (/etc/crontab) und wo auch immer FreeBSD noch diverse crontab-Schnippsel vorhaelt?

Hat jd. sonst noch Tipps fuer mich?
Zum Vergrößern anklicken....

Ja: lass bitte die Finger von so etwas, wenn Du keine Ahnung von Deinem System hast.

Gibt es eine Möglichkeit, explizit in /tmp das Verzeichnis /.cuex zu verbieten?
Zum Vergrößern anklicken....

Ja, Du koenntest selbst /tmp/.cuex anlegen (z.B. als root) und fuer den www-User nicht beschreibbar machen. Das ist dann aber auch nur Snakeoil. Beim naechsten Besuch nimmt der Angreifer halt einen anderen Verzeichnisnamen.


Edit: das mit der System-Crontab ist natuerlich Quark, das Ding laeuft ja nicht mit Root-Rechten; wenn es das taete, dann waere sowieso davon auszugehen, dass das komplette System kompromittiert ist.
Bitte nimm' den Server vom Netz und mach Dich dann erstmal mit Unixgrundlagen vertraut.
 
Zuletzt bearbeitet:
@kili
Lass doch bitte den bösen Unterton weg. Es ist noch nirgends ein Meister vom Himmel gefallen. testit beschäftigt sich seit Jahren mit BSDs und ist hier im Forum aktiv. Viele (Hobby-)Admins merken nicht einmal, wenn sie sich einen Spam-Bot eingefangen haben. testit hat's gemerkt und begonnnen, dagegen vorzugehen. Und es ist völlig richtig, dass er hier in diesem Forum um weitere Hilfe nachfragt.

@testit
Viel Erfolg mit der weiteren Analyse und Schadensbeseitigung.

SolarCatcher
 
Hallo,

erstmal herzlichen Dank für Eure Hinweis. Zumindest jene, die keine "Allgemeinplätze" darstellen.

Bspw. teile ich keinesfalls die Meinung von Kili über MOD Security. Das fortwährende Patchen der üblichen Verdächtigen wie phpBB, Joomla usw und so fort war auch nicht immer ein Erfolgsgarant, zumal mit diversen Patches wieder neue Einfallmöglichkeiten geschaffen wurden.

Ich hatte mit MOD Security und den passenden Regeln in meinem System seit Jahren "Ruhe". Vor einigen Tagen tauchte dieser BOT auf, der sich übrigens immer mit dem gleichen Verzeichnisnamen im /tmp verewigt und massenhaft SPAM über den Server mailt.

Die Exploit-Variante zu finden, ist nicht mal en passant gemacht, da ich zig LogFiles durchgehen muss. Schließlich ist nicht bekannt, über welche Domain und entsprechendes LogFile der Einfall erfolgte.

Da ich seit Jahren das Exploit-Problem nicht mehr hatte, verdächtige ich momentan WordPress, da dies die einzige neu installierte WebApp ist. Einem Freund zuliebe, der es mal testen wollte.

Sobald ich raus habe, wie das Einfallstor aussieht, melde ich mich hier nochmal.

Schönend Abend noch
testit
 
Ich hoffe du hast den bot noch?

Mach doch mal Folgendes:
Lade dir das Ding auf deinen lokalen Rechner. In ne Jail, oder sonstwas. Ziemlich sicher kannst du sogar ne lifecd dafür nehmen. Lass auf einer Konsole tcpdump laufen und starte den bot.

Der Bot sollte jetzt Kontakt mit seinem Herrn und Meister aufnehmen, um Anweisungen zu erhalten. Die Adresse des Herrn und Meisters siehst du jetzt mit tcpdump. Die Adresse sperre mit nem Paketfilter auf der prod-Kiste. Und durchforste den Bot(ich geh davon aus, dass es eine Scriptesammlung ist) nach der IP des Meisters. Es kann sein, dass ne ganze Liste existiert.

Das Vorgehen sollte die zumindest für eine kurze Zeit den Rücken freihalten, um herrauszufinden, wie das Dingen reingekommen ist. Der nächste Exploitversuch wird sicher nicht lange auf sich warten lassen...

Viel Erfolg!
 
Noch ne Info, y2kupdate ist nur der Starter für psybnc, einen IRC-Bouncer. Das Ding ist nur für die Kommunikation von Anweisungen zuständig. Der Schädling selbst sitzt an anderer Stelle.
Es ist ein Server, der auf den Interfaces der Maschine lauert. Such mal mit sockstat. Sperr den Port via ipfw, um die Kommunikation zu unterbinden und dir Zeit zu verschaffen.

Du scheinst ein ernstes Problem zu haben. Beeil dich besser. :-(
 
Hallo Troll,

vielen Dank für Deine Tipps! Das siehst Du natürlich völlig richtig.

Entgegen der Annahme von Kili kenne ich mein System eigentlich ganz gut und habe selbstverständlich sofort den "Listener" platt gemacht. War als httpd Prozess getarnt.

Mein größtes Problem ist nach wie vor die Eintrittsstelle zu finden, da jeder Webauftritt auf dem Server sein eigenes LogFile hat. Und die sind bei mir nicht gerade klein.

Nette Grüße und Dank für Deine wertvollen Hinweise!
testit
 
Kannst du das Durchsuchen nicht scripten?
Also angenommen die Domains liegen unter /usr/local/www/domain01 /usr/local/www/domain02,...
Und die Logfiles ähnlich strukturiert unter /var/log/www/domain01/access.log, /var/log/www/domain02/access.log

for domain in `find /var/log/www/ - type d`; do grep y2kupdate $domain/access.log; done

Etwas in der Art. Wenn du schreibst, wie die Struktur mit den Logfiles aussieht, kann dir sicher schnell jemand ein passendes Script zum durchforsten zusammenfrickeln.
 
Hi,

sicher ginge das, aber kannst Du mir sagen, wieso in den Apache LOGs zwingend ein "y2kupdate" auftauchen sollte?

Nette Grüße
testit
 
Hallo,

dass die Infiltration von Exploits über URLs gang und gebe ist, lässt sich schnell an den LOGs von Security-MOD feststellen und genau der Grund, warum ich dieses Modul im Apache eingebunden habe.

Klar werde ich mal nach y2kupdate in den LOGs ausschauen, aber ich halte es für sehr unwahrscheinlich, einen solchen Request zu finden. Denn die ganzen Scripte des Exploits befanden sich ja auf meinem Server, darunter auch in einem Unterverzeichnis y2kupdate.

Der Aufruf von y2kupdate ist EINE Sache, aber die Frage, wie ein Script auf dem Server eingeschleust werden konnte, das UNTER ANDEREM y2kupdate enthält, eine andere. Oftmals wird beim eigentlichen Einschleusvorgang via URL erst einmal ein gepacktes File von irgendwoher geladen usw.

Momentan nutze ich in erster Linie die LOGS von MOD-Security, in denen sämtliche Requests - übrigens auch POSTs - und deren "Behandlung" abgespeichert sind, um weitere Infos zu gewinnen. Bspw. konnte ich auf diese Weise eine Datei namens modsurl.php ausfindig machen, mit deren Hilfe fremder Code in das System eingeschleust werden konnte. Nur ergibt sich daraus die Anschlussfrage, wie modsurl.php auf den Servr kam?

Wofür hat man Sonntage? :cool:
 
testit schrieb:
Nur ergibt sich daraus die Anschlussfrage, wie modsurl.php auf den Servr kam?
Zum Vergrößern anklicken....

Nun, durch URL-Spoofing. Wenns kein Fehler im Apache ist, der ausgenutzt wurde, sondern ein Fehler in einer Webapp(sehr wahrscheinlich) dann muss es auf solch einem Weg passiert sein. Ein anderer Weg ist ein angreifbarer Dateiupload - in beiden Fällen müsste es in den Logs zu finden sein.
Falls du ftp nutzt, solltest du auch diese logs durchforsten. Ich glaube aber nicht wirklich daran, weil der Angreifer dann seinen Krams auch direkt hätte hochladen können.
Der nächste Schritt ist also nach modsurl zu greppen. So ist die Schnitzeljagt einfach...

P.S. ich ignoriere nicht, dass du mod_sec nutzt. Es ist in meinen Augen aber ein Fehler sich darauf zu verlassen, dass ein Modul, dass sehr umstritten ist einen Angriffsweg dicht macht. Das kann es nicht. Ansonsten wären nur html-Dateien auf dem Rechner möglich.
Das Selbe gilt für mich für die Vermutung, dass WordPress die Angriffsstelle sein könnte. Es ist nur eine Vermutung, die sogar sehr unscharweinlich ist.
Die Nähe zwischen Installationszeitpunkt einer App und einem Crack steht in keinem Zusammenhang. Die höchste Wahrscheinlichkeit ist einfach in weit verbreiteten Scripten, die unschön geschrieben sind. Und da gibt es nun mal weit schlimmeres als WordPress.
 
Zuletzt bearbeitet:
Hi,

das, was ich zu y2kupdate ausgeführt habe, gilt auch für modsurl.php: Das Script kann durch ein gepacktes File in einem Request auf den Server gelangt und erst dort entpackt worden sein, so dass in diesem Fall auch eine Suche in den LOGs nach modsurl.php nicht weiterhelfen wird, wenn es um die Suche der EINTRITTSTELLE geht.

Allerdings ist modsurl.php später sicherlich auch "genutzt" worden, was sich durch die LOGS auch bestätigt. Immerhin liegt ein zeitlicher Zusammenhang zwischen der Nutzung von modsurl.php und dem Einschleusen nahe, der helfen kann, die Such einzuschränken. Es sei denn, der Angreifer hätte anschließend erst einmal ein paar Tage/Wochen gewartet.

Nette Grüße
testit
 
Vielleicht würdest Du mal temporär /tmp noexec mounten und auch einmal nach Benutzereinträgen in passwd schauen. Dieser Bot scheint auch Benutzerauccounts anzulegen. Außerdem wird er (Berichten zu Folge) den apache-Benutzer benutzen, um einen cron-Eintrag zu machen. Schau mal in Deine Crontabellen rein.
Code: 
ls -l /var/cron/tabs/

Du kannst den Zeitpunkt vielleicht ganz gut eingrenzen, anhand des Datums der Modifikation der Cron-Tabelle, oder Datum des Botstarters in /tmp. Dann such in der Nähe in den httpd-access.log Dateien nach verdächtigen Zugriffen.

Nachtrag:
An Deiner Stelle würde ich den Rechner vom Netz nehmen und neu installieren. Wer weiß wo sich der Scheiß überall eingenistet hat. Die Berichte sind schon haarsträubend.
 
Zuletzt bearbeitet:
Hallo,

danke Dir für Deinen Beitrag.

Weiter oben siehst Du, dass ich bereits CRON im Visier hatte und auch anschließend den Eintrag sofort gelöscht habe. Sicherheitshalber habe ich noch eine DENY-Datei angelegt und nur ROOT für Cron zugelassen.

Und Du hast auch recht, was die Ausführung als Apache-Benutzer angeht. Man erkennt die Sache allerdings recht gut daran, dass er sich mittels
./proc "/usr/local/apache/bin/httpd -DSSL" httpd JaM5
startet.

/tmp als nicht ausführbar zu definieren hatte ich bereits schon einmal vor Jahren gemacht, aber dann leider dadurch anderweitige Probleme.

Nette Grüße
testit
 
testit schrieb:
das, was ich zu y2kupdate ausgeführt habe, gilt auch für modsurl.php: Das Script kann durch ein gepacktes File in einem Request auf den Server gelangt und erst dort entpackt worden sein, so dass in diesem Fall auch eine Suche in den LOGs nach modsurl.php nicht weiterhelfen wird, wenn es um die Suche der EINTRITTSTELLE geht.
Zum Vergrößern anklicken....

Das ist alles viel zu theoretisch. Wenn der Knabe das php-Script irgendwie auf den Server bekommen hat, dann wird er es auch aufgerufen haben->logfiles.
Zudem hab ich auch die typischen Patterns schon geschrieben - unter anderem tar.
Warum alles durch diskutieren, anstatt einfach mal Butter bei die Fische zu geben und die Logfiles zu durchwühlen. Der Thread hier entgleist in ein Theoriegespräch, über den Vorgang einen Rechner zu kompromittieren. Das ist alles überhaupt nicht mehr zielführend, oder ansatzweise praxisbezogen. Wir haben ausser der Information, dass dein Server befallen ist und zwei Dateinamen keinerlei Information. Wir wissen nicht, was du gemachts hast, wonach du schon gesucht hast - irgendetwas.
Sorry für die harten Worte, aber so kann man nicht helfen.
 
Hallo Troll,

ich gehöre zu den Menschen, die - wenn sie Hilfe bekommen - auch auf die Hilfeversuche eingehen und sich bedanken. Vielleicht ist deswegen bei Dir ein falscher Eindruck entstanden.

Überdies hast Du womöglich übersehen, dass ich längst in einem vorangegangenen Beitrag geschrieben hatte:

"Allerdings ist modsurl.php später sicherlich auch "genutzt" worden, was sich durch die LOGS auch bestätigt."

Damit hat sich auch Deine Annahme "dann wird er es auch aufgerufen haben->logfiles" bestätigt bzw. erledigt. ;)

Im übrigen hatte ich hier bereits kurz nach meinem Ausgangsposting die Hinweise, die ich mir erhofft hatte. Den Rest konnte ich selbst abwickeln, wollte aber weitere nette Denkanstöße nicht einfach ohne Reaktion stehen lassen.

Schönen Abend noch!

testit
 
testit schrieb:
Bspw. teile ich keinesfalls die Meinung von Kili über MOD Security. Das fortwährende Patchen der üblichen Verdächtigen wie phpBB, Joomla usw und so fort war auch nicht immer ein Erfolgsgarant, zumal mit diversen Patches wieder neue Einfallmöglichkeiten geschaffen wurden.
Zum Vergrößern anklicken....

Und mod_security hat letztlich das gleiche Probllem. Sobald jemand einen Weg findet, die Checks in mod_security zu umgehen, hat Dein Server die Hosen runter, bis eine neue Version von mod_security zur Verfuegung steht.

Ich hatte mit MOD Security und den passenden Regeln in meinem System seit Jahren "Ruhe". Vor einigen Tagen tauchte dieser BOT auf, der sich übrigens immer mit dem gleichen Verzeichnisnamen im /tmp verewigt und massenhaft SPAM über den Server mailt.
Zum Vergrößern anklicken....

Die Spammer und Botbetreiber passen Ihre Software an, wenn die "Trefferquote" zu gering wird. Wenn die Leute anfangen, dieses eine Verzeichnis fuer www nicht schreibbar zu machen, dann kommt in ein paar Wochen eine Version des Bots, die ein anderes Verzeichnis bzw. ein mehr oder weniger zufaelliges Verzeichnis verwendet.

Da ich seit Jahren das Exploit-Problem nicht mehr hatte, verdächtige ich momentan WordPress, da dies die einzige neu installierte WebApp ist. Einem Freund zuliebe, der es mal testen wollte.
Zum Vergrößern anklicken....

Hast Du Backups von dem System, moeglichst vor dem Befall? Falls ja: einfach mal ein Backup mit dem jetzigen Inhalt des Systems vergleichen und vor allem (aber nicht nur) auf geaenderte .php Files achten. Speziell bei WordPress soll es meines Wissens auch moeglich sein (oder gewesen sein), pgp-Scripte in irgendwelchen fuer Bilder vorgesehenen Verzeichnissen abzulegen und diese dann als WordPress-Extension zu registrieren. Da koennte eine Kombo von find(1). xargs(1) und file(1) weiterhelfen -- ein php-Script namens foo.png waere z.B. einigermassen verdaechtig.
 
@Kili:

Danke Dir für Deine Hinweise!

Kurze Anmerkung zu Deiner Aussage:

"Und mod_security hat letztlich das gleiche Probllem. Sobald jemand einen Weg findet, die Checks in mod_security zu umgehen, hat Dein Server die Hosen runter, bis eine neue Version von mod_security zur Verfuegung steht."

Nein, Du musst NICHT warten, bis eine neue Version Version von mod_Security zur Verfügung steht. Du kannst Dir Deine Regeln selbst definieren.

Der große Vorteil des Einsatzes von mod_security ist, dass teilweise auch Sicherheitslücken abgedeckt werden, die noch gar nicht konkret bekannt sind, während das fortwährende Patchen - bspw. von phpBB, Joomla etc. in der Tat voraussetzt, dass die Lücke erkannt und beseitigt ist.

mod_security macht selbstverständlich das regelmäßige Updaten von WebApps nicht überflüssig, hilft aber in vielen Fällen, weiteren Schaden fernzuhalten. Und zur Analyse der http Requests ist mod_security ohnehin gold wert, da bspw. auch post-requests dokumentiert werden.

Nette Grüße
testit
 
Guten Tag,

ich hatte das im Ausgangsposting beschriebene Problem bereits relativ zeitnah gelöst, aber noch keine Zeit gehabt, es hier weiter zu erörtern.

Kurzum:

Mit Hilfe von mod_securiy habe ich einfach jeglichen http-Request geloggt und konnte dadurch ziemlich schnell den Übeltäter finden, der sich über eine Schwachstelle des PHP-Skriptes ADVANCED POLL eingeschleust hatte. An dieses Voting-Script hatte ich die letzten Jahre überhaupt nicht mehr gedacht.

Der große Vorteil von mod-security war, dass in EINEM LOG alle Requests geloggt werden konnten und ich so nicht alle LOGs für zahlreiche virtuelle Hosts durchgehen musste.

Freundliche Grüße
testit
 
Hi!

Das Problem dürfte ja gelöst worden sein.

Ich möcht aber nochmal ein wenig auf modsecurity eingehen:
Hat schon mal jemand das whitelisting von modsec versucht, also ModProfiler?

Testit, welche Rules verwendest du? "Nur" jene von modsecurity.org oder auch eigene bzw. andere. Auf gotroot.com gibts ja auch viele nützliche die aktuell gehalten werden.
Natürlich is so ne WAF auch ein Aufwand - false positives gibts bei Zeiten auch mal.

Aber das modsec Schlangenöl ist möchte ich stark anzweifeln. Weil anders als bei signaturbasierten Lösungen hast du hier aufgrund des Rulesets eine breite angesetzte Verteidigung gegen viele der Angriffe. Is natürlich keine Garantie, aber viel lästiges Zeuch wird schon mal verhindert! Ne gesunde Paranoia sollte trotz implementierter Sicherheitsmaßnahmen immer noch da sein :ugly:
Ich darf zitieren:
"Unlike intrusion detection and prevention systems, which rely on signatures specific to known vulnerabilities, the CRS is based on generic rules which focus on attack payload identification in order to provide protection from zero day and unknown vulnerabilities often found in web applications, which are in most cases custom coded."

Ich für meinen Teil verbiete es den Webservern auch noch (auf der Perimeter Firewall), dass sie von intern nach extern eine Verbindung aufbauen und kommunizieren können!
Dank stateful ist das ja kein Problem mehr dass sie trotzdem auf Anfragen von extern reagieren ;-)
Aber so kann ein evtl. IRC Bot, sollte er sich doch irgendwie einnisten, wenigstens nicht nach Hause telefonieren! Und ich sehs sofort im Firewall-Log wenn da was ungewöhnliches ins Freie möchte aber geblockt wird. Hat sich bewährt! :cool:

BTW: ossec sorgt bei mir dafür, dass nach dem 10ten durch modsec erkannten Angriff die "böse" Source IP für x Minuten gesperrt wird. DOS wär somit potentiell schon möglich, also dass das System munter alle möglichen IP's sperrt, passiert ists bisweilen noch nicht!
 
worel schrieb:
Ich für meinen Teil verbiete es den Webservern auch noch (auf der Perimeter Firewall), dass sie von intern nach extern eine Verbindung aufbauen und kommunizieren können!
Dank stateful ist das ja kein Problem mehr dass sie trotzdem auf Anfragen von extern reagieren ;-)
Aber so kann ein evtl. IRC Bot, sollte er sich doch irgendwie einnisten, wenigstens nicht nach Hause telefonieren! Und ich sehs sofort im Firewall-Log wenn da was ungewöhnliches ins Freie möchte aber geblockt wird. Hat sich bewährt! :cool:
Zum Vergrößern anklicken....
Aber nur, solange auf Deinen Servern kein interaktives Web-2.0 Zeugs rennt. Schon bei einer Blog-Software (Stichwort: Trackback) wäre Schluss mit lustig (und die Whitelists dafür wären definitv zu umfangreich). Ansich spricht nichts gegen Outbound-Filterung als Second-Level Defence, aber die sollte IMHO mit Augenmaß und auf die jeweilige Situation passend geschneidert werden.
 
Volle Zustimmung.

Das sicherste wär wohl das Lankabel zu ziehen ;-)
Mist, dann hab ich noch immer das Problem der physikalischen Sicherheit...

Es hört einfach nicht auf! :D
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben