Exploit? Perl Prozess SSH env SPAM aus /tmp

O

orion

New Member
Liebe Community,

ich habe seit einigen Tagen folgendes Problem:

Ein Angreifer führt auf meinem Debian V-Server einen Perl Prozeß aus, der mit Hilfe von temporäten Dateien, die in /tmp abgelegt werden SPAM versendet. Irgendwie bekommt das Script SSH Zugriff auf das System. Im env werden jeweils entsprechende Variablen gesetzt (SSH_CLIENT, SSH_CONNECTION), die der jeweiligen IP Zugriff gewähren.

Distribution:
Linux version 2.6.18-028stab093.2 (root@rhel5-build-x64) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-46))

Habe bereits folgendes getan:
- Postfix gestoppt
- Sämtliche Updates (OPENSSH, Perl...) durchgeführt
- Alle Zugriffsrechte auf Dateien und Verzeichnisse geprüft
- Root Zugriffe von extern unterbunden und alle Kennwörter erneuert
- denyhosts installiert

Ich weiß jetzt nicht mehr weiter und wäre für jede Hilfe dankbar, wo ich denn nach dem Einstieg suchen könnte. Gibt es hier vielleicht eine bekannte Sicherheitslücke?

Obwohl ich Postfix deaktiviert habe, werden die SSH-Environment Variablen nach dem löschen wieder neu gesetzt und in /tmp ständig neue Mail-Packages aufgespielt.

Vielen Dank im voraus!
 
Welchem benutzer gehören die Daten in /tmp? Läuft außer dem Postfix noch ein anderer Dienst auf dem V-Server, welcher öffentlich erreichbar ist? Welches Betriebssystem in welcher Version läuft auf dem System?
 
- Die Dateien in /tmp gehören root
- tulpen
Code: 
tcp        0      0 0.0.0.0:3306            0.0.0.0:*               LISTEN      107        1071646042  13675/mysqld
tcp        0      0 127.0.0.1:783           0.0.0.0:*               LISTEN      0          293543938   1937/spamd.pid
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      0          1071668675  9947/apache2
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      0          1156407778  11445/sshd
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      0          1071668677  9947/apache2
tcp        0      0 127.0.0.1:60000         0.0.0.0:*               LISTEN      0          1071674964  14292/postgrey.pid
tcp6       0      0 :::110                  :::*                    LISTEN      0          293499626   1532/couriertcpd
tcp6       0      0 :::143                  :::*                    LISTEN      0          293499591   1521/couriertcpd
tcp6       0      0 :::22                   :::*                    LISTEN      0          1156407776  11445/sshd
- Debian GNU/Linux 5.0
 
Der wird dann wohl vollen Root Zugriff haben.
Checke mal alle System Benutzer vieleicht ist jemand dabei von dem du nichts weisst.
Überprüfe ob der jenige ssh keys angelegt hat.
Und poste mal das Script hier.
 
Nimm den Server so schnell wie möglich vom Netz um weiteren Schaden zu verhindern. Du kannst deinen Server ja in den Rescue-Modus hochfahren. Dann ist dieser sauber und du kannst ganz in Ruhe deine Platte mounten und nachsehen.
 
orion said:
Ich weiß jetzt nicht mehr weiter und wäre für jede Hilfe dankbar, wo ich denn nach dem Einstieg suchen könnte. Gibt es hier vielleicht eine bekannte Sicherheitslücke?
Click to expand...
Klingt verdächtig nach einem Symlink-Exploit, schau dir mal das dazu an...
 
Vielen Dank für eure Hinweise!

Habe folgenden Artikel gefunden:
http://www.linuxquestions.org/questions/linux-security-4/server-compromised-exim-headers-837856/

die Symptome entsprechen genau meinen:
- Perl Prozess
- SSH env
- Ausführung von Mail Packages aus /tmp

Allerdings habe ich kein Exim. Würde jedoch gerne die SSH binaries wie in der Lösung beschrieben neu aufspielen. Wie kann ich denn das bewerkstelligen, ohne mich selbst vom Server auszusperren?

Upgrade habe ich bereits durchgeführt.
 
Ich kann meinen Vorrednern nur zustimmen.

Sofern der Eintrittspunkt nicht vollständig analysiert worden ist und die damit verbundenen Konsequenzen würde ich den Server auch vom Netz (rescue-modus) nehmen.

Dann hat man Zeit, den Angriff (vollständig) zu analysieren und Backups zu fahren. Damit die Re-Initialisierung dann um so schneller geht.
 
- Systemnutzer sind OK
- ssh_keys wurden keine angelegt
- Anscheinend wurde folgendes Script verwendet: http://pastebin.com/8Z6rWN80

Prozeß läuft als:
root 5472 0.0 0.0 5216 3408 ? S 11:18 0:00 perl

Suche immer noch den Einstiegspunkt.
- Alle Passwörter sind sicher / Root Passwort wurde geändert
- Keine ssh_keys
- Keine offen cgi-bin Verzeichnisse

Karl34 said:
Der wird dann wohl vollen Root Zugriff haben.
Checke mal alle System Benutzer vieleicht ist jemand dabei von dem du nichts weisst.
Überprüfe ob der jenige ssh keys angelegt hat.
Und poste mal das Script hier.
Click to expand...
 
Prozeß läuft als:
root 5472 0.0 0.0 5216 3408 ? S 11:18 0:00 perl
Click to expand...

Das deutet darauf hin, dass das Skript mit Root-Rechten ausgeführt worden ist und nicht als "$WebUser".

Bitte überprüfe auch die Access-Log Dateien, nach möglichen Eintrittspunkten (sqli,rfi,etc) Über ein CMS könnte der Angreifer rein gekommen sein und dann ein lokales Root-Exploit ausgeführt haben.
 
Da der OP höchstwahrscheinlich keinen externen Loghost betreibt, wie soll er dann die Integrität der Logs sicherstellen? Das Säubern der lokalen Logs gehört heutzutage selbst bei den Scriptkiddies zum Standardvorgehen, wenn sie root sind.

Es ist dem gesamten System inklusive Logs, Nutzdaten und automatisierten Backups nicht mehr zu trauen! Daher bleibt einzig der kompromisslose Neuanfang...
 
Da der OP höchstwahrscheinlich keinen externen Loghost betreibt, wie soll er dann die Integrität der Logs sicherstellen? Das Säubern der lokalen Logs gehört heutzutage selbst bei den Scriptkiddies zum Standardvorgehen, wenn sie root sind.

Es ist dem gesamten System inklusive Logs, Nutzdaten und automatisierten Backups nicht mehr zu trauen! Daher bleibt einzig der kompromisslose Neuanfang...
Click to expand...

Kann dir nur zustimmen.
Dennoch kann es nicht schaden, den Angriff weiter zu analysieren, damit man diesen Fehler in Zukunft nicht nochmal macht.
 
its said:
Kann dir nur zustimmen.
Dennoch kann es nicht schaden, den Angriff weiter zu analysieren, damit man diesen Fehler in Zukunft nicht nochmal macht.
Click to expand...

Stimme dir auch zu. Es gibt ja viele "dunkle Foren", in denen alle Tools für die Automatisierung eines Einbruchs über Exploit bereitgestellt werden.

Bin gerade dabei, das System parallel neu aufzusetzen. Ich möchte das Problem jedoch mit eurer Hilfe bis zum Ende analysieren, damit andere Nutzer mit vergleichbaren Symptomen hier einen hilfreichen Thread vorfinden.

Aktueller Stand:
Nach aufspielen der neuen Debian Patches per http://www.debian.org/security wurden auch einige Sicherheitslecks in Perl und OpenSSH behoben. Seither hat der Angreifer anscheinend keinen Dateizugriff mehr.

Dennoch wird das eingeschleuste Perl Script (s.o.) mehrmals am Tag gestartet. In der Offline-Mailqueue landen dann Initialisierungsmails an "serverpoplavock@gmail.com" (Defaulteinstellung des Perl Scripts!).

Ich würde gerne feststellen, wo sich das Script befindet und wie es ausgeführt wird, um auch einen möglichen Einstiegspunkt zu identifizieren.

In den Cronjobs für Root und User ist alles sauber. Eine Suche nach kürzlich ausgeführten Perl Scripts im System mit "find / -atime -1 -name '*.pl'" (Dateien, die in <24h angefasst wurden) führt zu keinem Ergebnis.

Wie soll ich weiter vorgehen?
 
Joe User said:
Für den ganz primitiven Anfang:
Code: 
ls -alh /tmp
grep -rn perl /tmp
Click to expand...

Vielen Dank. In /tmp werden seit den Securityupdates keine Dateien mehr abgelegt. Allerdings taucht in der Postfix-Mailqueue regelmässig eine Mail auf. Diese ist wohl gedacht, um die "Funktionsfähigkeit" des Versands zu testen und danach eine Versandwelle zu starten.

Das perl Script war nach killen des Prozesses einige Stunden später wieder in der Prozeßliste. eine Suche nach verschiedenen Strings, die im Script vorkommen können, führte nicht zum Erfolg.

Kann ich denn bei einem gestarteten Prozeß die Quelle des ausführenden Pfades, z.B. in /proc/<PNR> ausfindig machen?
 
Du solltest erstmal deine Binarys prüfen. Vermutlich sind die nicht mehr Original. Ein komprimitiertes "ps" oder "lsof" zeigt nunmal keine daemons an die es nicht anzeigen soll ;-)

chrootkit sollte hier zumindest zeigen das was installiert ist.
 
- Die Binaries sind im Originalzustand
- chkrootkit und rkhuter zeigen keine Auffälligkeiten
- Mit find keine weiteren Spren gefunden
- core Dumps werden keine mehr erzeugt

Konnte aber den perl Prozeß abfangen:

Code: 
lsof -p 20255
COMMAND   PID USER   FD   TYPE DEVICE    SIZE      NODE NAME
perl    20255 root  cwd    DIR  0,217   36864 123733739 /tmp
perl    20255 root  rtd    DIR  0,217    4096 123699272 /
perl    20255 root  txt    REG  0,217 1254244 123737362 /usr/bin/perl
perl    20255 root  mem    REG  0,217   63312 123699763 /lib/libresolv-2.7.so
perl    20255 root  mem    REG  0,217   17880 123714493 /lib/libnss_dns-2.7.so
perl    20255 root  mem    REG  0,217   38408 123699759 /lib/libnss_files-2.7.so
perl    20255 root  mem    REG  0,217   34348 123714491 /lib/libnss_nis-2.7.so
perl    20255 root  mem    REG  0,217   79608 123699758 /lib/libnsl-2.7.so
perl    20255 root  mem    REG  0,217   30436 123699764 /lib/libnss_compat-2.7.so
perl    20255 root  mem    REG  0,217  217016 123837807 /var/cache/nscd/passwd
perl    20255 root  mem    REG  0,217   38296 123699716 /lib/libcrypt-2.7.so
perl    20255 root  mem    REG  0,217 1294572 123714483 /lib/libc-2.7.so
perl    20255 root  mem    REG  0,217  112012 123714492 /lib/libpthread-2.7.so
perl    20255 root  mem    REG  0,217  149328 123699760 /lib/libm-2.7.so
perl    20255 root  mem    REG  0,217    9680 123714485 /lib/libdl-2.7.so
perl    20255 root  mem    REG  0,217   19816 123734039 /usr/lib/perl/5.10.0/auto/Socket/Socket.so
perl    20255 root  mem    REG  0,217  113248 123714472 /lib/ld-2.7.so
perl    20255 root    0r   CHR    1,3         123699816 /dev/null
perl    20255 root    1w   CHR    1,3         123699816 /dev/null
perl    20255 root    2w   CHR    1,3         123699816 /dev/null
perl    20255 root    3r   REG  0,217   14507 259391556 (deleted) /tmp/

In /tmp existiert bessagtes Script jedoch nicht. Bash Historys geben keine Hinweise. Irgendwelche Ideen?
 
Ich würd mal tippen, dass das Perl-Script nicht aus /tmp gestartet wird.
Da gibt es echt sehr viele Möglichkeiten. Unter anderem könnte es ein cronjob oder usercronjob sein (crontab -l) oder ein .bashrc, .profile, .bashprofile oder vielleicht ein initscript, welches geändert worden ist. Vielleicht eine geänderte .screenrc. Verstecken kann man wirklich an sehr vielen Orten. Vielleicht hat er den Kernel oder Kernelmodule geändert. Wobei man da aber sicherlich nicht perl einsetzen würde.
 
You must log in or register to reply here.
Back
Top