-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hallo,
wie würde sich der benutzte Kernel-Hack auswirken, wenn die Benutzerkonten in einer UML-Umgebung laufen würden? (Die ihrerseits von einem defekten Kernel gestartet wird.)
Könnte man es sich dann sparen, die Server runterzufahren?
Bernhard
On Tuesday 02 December 2003 19:08, Bernhard Schiffner wrote:
wie würde sich der benutzte Kernel-Hack auswirken, wenn die Benutzerkonten in einer UML-Umgebung laufen würden? (Die ihrerseits von einem defekten Kernel gestartet wird.)
Könnte man es sich dann sparen, die Server runterzufahren?
Man sollte dazusagen: es ist ein lokaler Exploit. Also muss der Angreifer erstmal auf den Rechner kommen (z.B. durch eine Lücke im Apache oder ein unsicheres/gesnifftes Passwort (letzteres war es bei Debian)).
Konrad
On 02.12.03 Bernhard Schiffner (bernhard@schiffner-limbach.de) wrote:
Moin,
wie würde sich der benutzte Kernel-Hack auswirken, wenn die Benutzerkonten in einer UML-Umgebung laufen würden? (Die ihrerseits von einem defekten Kernel gestartet wird.)
Was willst Du wissen? Ob UML-2.4.x (x <= 22) auch vulnerable war? Was heißt die Benutzerkonten laufen in einer UML-Umgebung? Wenn ich etwas verändern können soll brauche ich das COW-File, was nach dem Angriff auch verseucht ist. Wenn ich nix verändern können will, könnte ich auch mein nichtvirtuelles System auf CD vorhalten und UML hat keinen Vorteil.
Könnte man es sich dann sparen, die Server runterzufahren?
Das wurde ja nur getan, damit der Attacker keinen weiteren Schaden anrichten kann. Ob ich eine reale Maschine runterfahre oder virtuelle (wenn ich diese unbedingt brauche) sollte fast egal sein.
H.
Hi,
Nu isses passiert(Debian Testing):
# chkrootkit -q Possible t0rn v8 (or variation) rootkit installed Possible RH-Sharpe's rootkit installed
Weiß nun jemand, wie chkrootkit auf diese Idee kommt? Einige Tips, t0rn aufzuspüren, habe ich ohne Erfolg probiert. Ein nmap vom Rechner nebenan bringt: Port State Service 9/tcp open discard 13/tcp open daytime 21/tcp open ftp 22/tcp open ssh 25/tcp open smtp 37/tcp open time 80/tcp open http 110/tcp open pop-3 111/tcp open sunrpc 113/tcp open auth 139/tcp open netbios-ssn 199/tcp open smux ???? 389/tcp open ldap 445/tcp open microsoft-ds 631/tcp open cups 873/tcp open rsync 924/tcp open unknown rpc.statd 955/tcp open unknown rpc.mount 2049/tcp open nfs 2988/tcp open unknown ??? wird von lsof -i ign. 3306/tcp open mysql 5432/tcp open postgres 5556/tcp open unknown rplayd 5901/tcp open vnc-http-1 6001/tcp open X11:1 8888/tcp open sun-answerbook 10000/tcp open snet-sensor-mgmt 55556/tcp open unknown rplayd
Na ja, über den Firewall ist nur ssh und www sichtbar, (hoffe ich)? Wer prüfen will: riedel.dynup.net ist der Patient
Komisch ist weiterhin:
You have 4 process hidden for ps command Warning: Possible LKM Trojan installed
Die 4 Prozesse sind neuerdings mit PID 0 dargestellt PID TTY STAT TIME COMMAND 1 ? S 0:00 init [2] 2 ? SW 0:00 [keventd] 0 ? SWN 0:00 [ksoftirqd_CPU0] 0 ? SW 0:23 [kswapd] 0 ? SW 0:00 [bdflush] 0 ? SW 0:00 [kupdated] 120 ? SW 0:00 [kapmd] 129 ? SW< 0:00 [mdrecoveryd]
Ja, ich habe ein Backup....
Mit besorgten Grüßen Konrad Riedel
Hi Konrad,
Weiß nun jemand, wie chkrootkit auf diese Idee kommt? Einige Tips, t0rn aufzuspüren, habe ich ohne Erfolg probiert.
Das scheint ein Bug in chkrootkit zu sein. Siehe unten.
Na ja, über den Firewall ist nur ssh und www sichtbar, (hoffe ich)? Wer prüfen will: riedel.dynup.net ist der Patient
Da ist mehr als nur Port 22 und 80 offen.
<-------------- schnipp -------------------> jens:# nmap riedel.dynup.net
Starting nmap V. 3.00 ( www.insecure.org/nmap/ ) Interesting ports on pD9E1F78A.dip.t-dialin.net (217.225.247.138): (The 1590 ports scanned but not shown below are in state: closed) Port State Service 22/tcp open ssh 24/tcp open priv-mail 25/tcp open smtp 37/tcp open time 53/tcp open domain 80/tcp open http 137/tcp filtered netbios-ns 138/tcp filtered netbios-dgm 139/tcp filtered netbios-ssn 199/tcp open smux 5901/tcp open vnc-1
Nmap run completed -- 1 IP address (1 host up) scanned in 15 seconds <-------------- schnapp ------------------->
Komisch ist weiterhin:
You have 4 process hidden for ps command Warning: Possible LKM Trojan installed
Die 4 Prozesse sind neuerdings mit PID 0 dargestellt PID TTY STAT TIME COMMAND 1 ? S 0:00 init [2] 2 ? SW 0:00 [keventd] 0 ? SWN 0:00 [ksoftirqd_CPU0] 0 ? SW 0:23 [kswapd] 0 ? SW 0:00 [bdflush] 0 ? SW 0:00 [kupdated] 120 ? SW 0:00 [kapmd] 129 ? SW< 0:00 [mdrecoveryd]
Dieses Problem wurde auf der Debian-Security-Maillingliste vor kurzem diskutiert. Das scheint ein bekanntes Problem mit Kernel-Threads zu sein. Chkrootkit behandelt diese Threds irgendwie falsch. Da ich nicht weis ob du die Liste liest, hier mal auszugsweise die Antworten auf die Anfrage "chkrootkit and lkm" (Message-Id: 20031125121835.4f5f4a4f.graumann@its.caltech.edu)
<---------------------- zitiert ----------------------------> it is a ps/kernel bug, try top. ---------------- I do not think that it is a problem due to the compromised servers, because I noticed this on machines, which had been not updated since these serverhacks. I think this is a bug in the chkrootkit-package, although it has not been reported on the buglist.
But please be carefull, it is only my opinion, I will not guarantee that the hack is not the cause of the problem ;) ------------------- It's nothing at all to do with the compromise, and everything to do with URL:http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=217525 (`ps shows incorrect pid value') and URL:http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=217278 (`chkrootkit: doesn't work too well with kernel threads').
(FWIW, the bugs were filed 31 and 33 days ago, against procps and chkrootkit respectively, and URL:http://bugs.debian.org/{procps,chkrootkit} is currently operational, although lacking a record of activity since late last week.)
Your machine is behaving no more strangely than thousands of other sarge/sid boxes. :-) ----------------------- This is known bug in chkrootkit, it does not understand processes with pid '0' (kernel threads) which are not listed under /proc and emits this "alert".
As a matter of fact it was reported previous to the compromise. Please check the following bugs for more information:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=217278 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=217278 <------------------- nicht mehr zitiert ------------------->
Ja, ich habe ein Backup....
Vorbildlich. Prinzipiell nicht schädlich, hier anscheinend nicht nötig.
Jens Weiße
On Wednesday 03 December 2003 08:39, Jens Weisse wrote:
jens:# nmap riedel.dynup.net
Diese Syntax zeigt nicht alle offenen Ports an, sondern laut Manpage nur die registrierten. Diese wiederum sind aber selbst von denen in /etc/services nur eine Teilmenge, denn nmap hat eine eigene services-Datei, was ich persönlich für eher unklug halte, da diese potentiell veraltet ist.
nmap -p 1-65535 oder so wäre denke ich eine Minimumlösung für das lokale Netz, dauert ca. eine Minute.
Josef
Am Mittwoch, 3. Dezember 2003 09:09 schrieb Josef Spillner:
On Wednesday 03 December 2003 08:39, Jens Weisse wrote:
jens:# nmap riedel.dynup.net
Diese Syntax zeigt nicht alle offenen Ports an, sondern laut Manpage nur die registrierten. Diese wiederum sind aber selbst von denen in /etc/services nur eine Teilmenge, denn nmap hat eine eigene services-Datei, was ich persönlich für eher unklug halte, da diese potentiell veraltet ist.
Danke für den Hinweis. Man sollte sich wirklich immer erst die Dokumentationen durchlesen.
nmap -p 1-65535 oder so wäre denke ich eine Minimumlösung für das lokale Netz, dauert ca. eine Minute.
Momentan nmap'e ich alle lokalen Rechner. Mit deiner Version tauchen wirklich noch zusätzliche Ports auf. Dem muss ich mal nachgehen.
Jens
Josef Spillner josef@ggzgamingzone.org wrote:
On Wednesday 03 December 2003 08:39, Jens Weisse wrote: nmap -p 1-65535 oder so wäre denke ich eine Minimumlösung für das lokale Netz, dauert ca. eine Minute.
Und nur TCP/IP. Um auch TCP/UDP zu erfassen: nmap -sU ... Um die Sache zu beschleunigen: -T insane
mfg, Fabian
lug-dd@mailman.schlittermann.de