Liebe Leute,
nochmal was zum Angriff. Der Angreifer war so dreist, es noch zweimal zu probieren, so dass ich ihn dann auch online erwischt habe. Das offene Scheunentor war samba aus der testing-Distribution. Das ist ärgerlich, weil die Versionen aus stable und unstable neuer und vor allem sicher sind. Interessant ist, dass er zu Scannen nicht zufällige IP-Adressen gewählt hat, sondern inkrementell durch A-, B- bzw. C-Netze gegangen ist. Die Chance ist also groß, dass es noch mehr Rechner unter 141.30.*.* erwischt hat. Natürlich hat die TUD kein Warnsystem für Administratoren...
Außerdem hatte er seine Werkzeuge von 3 Accounts auf xoom.it heruntergeladen, was ich dann natürlich auch gemacht habe. Meine Email an abuse@xoom.it blieb aber unbeantwortet. Ziel des Ganzen war übrigens eine DDOS-Atacke basierend auf dem stacheldraht-Code. Gibt es security-Adressen, wo ich die Programme sinnvollerweise mal hinschicken kann?
Jetzt bleibt nur die Frage, wie ich zuverlässig herausfinden kann, ob in den Benutzerverzeichnissen irgendwelche Ostereier zurück geblieben sind. 72 GB manuell durchzugucken ist sicher kein gangbarer Weg.
Torsten
P. S.: Bevor ich zum Schämen in die Ecke gegangen bin, habe ich das verlorengegangene iptables-Skript reaktiviert und 'hosts deny all except ...' in die smb.conf eingetragen, peinlich peinlich...
Am Fre den 09 Mai 2003 um 10:41:13 +0200 schrieb Torsten Werner:
Liebe Leute,
nochmal was zum Angriff. Der Angreifer war so dreist, es noch zweimal zu probieren, so dass ich ihn dann auch online erwischt habe. Das offene
Du meinst, das hat jemand echt händisch gemacht? Findet chkrootkit das kit? Eigentlich sollte aber unsere Firewall mich vor sowas bewahren.
Scheunentor war samba aus der testing-Distribution. Das ist ärgerlich, weil die Versionen aus stable und unstable neuer und vor allem sicher sind. Interessant ist, dass er zu Scannen nicht zufällige IP-Adressen gewählt hat, sondern inkrementell durch A-, B- bzw. C-Netze gegangen ist. Die Chance ist also groß, dass es noch mehr Rechner unter 141.30.*.* erwischt hat. Natürlich hat die TUD kein Warnsystem für Administratoren...
Eigentlich wundert es doch, daß das URZ nicht hier die gleiche Holz- hammermethode wie bei SMTP verwendet, sprich, den Router alles droppen zu lassen, was auf solche Ports geht.
Außerdem hatte er seine Werkzeuge von 3 Accounts auf xoom.it heruntergeladen, was ich dann natürlich auch gemacht habe. Meine Email an abuse@xoom.it blieb aber unbeantwortet. Ziel des Ganzen war übrigens eine DDOS-Atacke basierend auf dem stacheldraht-Code. Gibt es security-Adressen, wo ich die Programme sinnvollerweise mal hinschicken kann?
Auf securityfocus gab es AFAIK eine Datenbank von bekannten Kits.
Jetzt bleibt nur die Frage, wie ich zuverlässig herausfinden kann, ob in den Benutzerverzeichnissen irgendwelche Ostereier zurück geblieben sind. 72 GB manuell durchzugucken ist sicher kein gangbarer Weg.
Auf jeden Fall solltest du mal cronjobs überprüfen, falls das noch nicht geschehen ist. @reboot ist ja super zum starten von beliebigen Sachen. Die .bashrc's und .bash_profiles sind sicherlich auch gut für sowas. Oder vielleicht auch mal über mount mit noexec nachdenken.
P. S.: Bevor ich zum Schämen in die Ecke gegangen bin, habe ich das verlorengegangene iptables-Skript reaktiviert und 'hosts deny all except ...' in die smb.conf eingetragen, peinlich peinlich...
Unsere Sambakiste ist zum Glück multihomed, daher ist das Abschotten etwas einfacher. Wenn man ganz paranoid ist, kann man auch mit dem user Modul von iptables Regeln definieren, was root oder andere Leute dürfen. Allerdings sollte man dann auch das iptables Binary umbenennen. Das kit, was ich mir mal eingehandelt habe, hat vorher explizit versucht, die backdoors mit ipchains zu öffnen.
Tschau,
andre
Hi Andre,
Am 09. Mai 2003 schrieb Andre Schulze:
Oder vielleicht auch mal über mount mit noexec nachdenken.
Zwei Punkte sprechen dagegen:
1. Es wird bei uns Software entwickelt.
2. noexec ist unter Linux sinnlos, weil ein '/lib/ld-linux.so.2 datei' immer funktioniert.
Torsten
Hallo Torsten!
Am 2003-05-10 14:53 +0200 schrieb Torsten Werner:
Am 09. Mai 2003 schrieb Andre Schulze:
Oder vielleicht auch mal über mount mit noexec nachdenken.
[...]
- noexec ist unter Linux sinnlos, weil ein '/lib/ld-linux.so.2 datei' immer funktioniert.
Das ist ja gruselig! Bei mir funzt es zwar nicht, weil grsecurity das abblockt, aber wenn man es ausschaltet, geht es schon. Da zeigt sich mal wieder der Vorteil von MAC, was aber sicher auf den allermeisten Rechnern heutzutage nicht zu finden ist.
IMHO ist das ja eher ein Bug als ein Feature von ld-linux.so.2. Oder hat es irgendeinen legitimen Sinn?
Was gibt es eigentlich für einen Grund, eine Datei die ".so" heißt (also eine Bibliothek sein sollte) ausführbar zu machen? IMHO ist das ein äußerst schweres Sicherheitsrisiko, weil es die strikte Trennung von durch den Benutzer schreibbaren und ausführbaren Dateien untergräbt.
Einen schönen Sonntag wünscht
Martin
[...]
Jetzt bleibt nur die Frage, wie ich zuverlässig herausfinden kann, ob in den Benutzerverzeichnissen irgendwelche Ostereier zurück geblieben sind. 72 GB manuell durchzugucken ist sicher kein gangbarer Weg.
Reicht es nicht sich nur mal alle ausführbare Dateien anzuschauen? Ansonsten kannst du ja auch die Dateirechte recursiv ändern. Wenn das System und der Kernel wieder vertrauenswürdig sind, dann werden keine Programme / Dateien mit r--r--r-- gestartet.
Jens Weiße
Am 09. Mai 2003 schrieb Jens Weiße:
Reicht es nicht sich nur mal alle ausführbare Dateien anzuschauen?
Nein, z. B. sind die folgenden Dateien nicht ausführbar und trotzdem verwundbar:
.bashrc .vimrc .mutt/muttrc .ssh/authorized_keys
und wahrscheinlich viele andere auch.
Torsten
Am Freitag, 9. Mai 2003 12:49 schrieb Torsten Werner:
Am 09. Mai 2003 schrieb Jens Weiße:
Reicht es nicht sich nur mal alle ausführbare Dateien anzuschauen?
Nein, z. B. sind die folgenden Dateien nicht ausführbar und trotzdem verwundbar:
.bashrc .vimrc .mutt/muttrc .ssh/authorized_keys
und wahrscheinlich viele andere auch.
Das wahrscheinlich ist sogar höchst wahrscheinlich. Eigentlich könnte in jeder Datei eine Zeitbombe schlummern. Wie google gerade meldet, können selbst mp3's zu Buffer Overflows führen (siehe http://www.securityfocus.com/bid/6593/info/).
Jens Weiße
Jetzt bleibt nur die Frage, wie ich zuverlässig herausfinden kann, ob in den Benutzerverzeichnissen irgendwelche Ostereier zurück geblieben sind. 72 GB manuell durchzugucken ist sicher kein gangbarer Weg.
debsum (oder so ähnlich). Und dann die übrigbleibenden Files manuell?
Heiko
Am 09. Mai 2003 schrieb Heiko Schlittermann:
debsum (oder so ähnlich). Und dann die übrigbleibenden Files manuell?
# cd / # cat /var/lib/dpkg/info/*.md5sums > /root/tmp0 # md5sum -c /root/tmp0
Das habe ich gemacht, aber unter /home/ liegen 72 Gb, die man theoretisch auch überprüfen müsste...
# find /home/ -perm +7000
habe ich natürlich schon gemacht, aber das kann nicht alles sein.
Torsten
lug-dd@mailman.schlittermann.de
-
Andre Schulze -
Heiko Schlittermann -
Jens Weiße -
Martin Pitt -
Torsten Werner