iroffer Server gehackt?
SuSE 8.2, alle Updates gemacht Zuerst fiel mir auf, dass keine /var/log/messages existiert. Als ich den syslogd restarten wollte kam eine Meldung von einem Programm iroffer [1] In /dev/net gibt es ein Verzeichnis ... (also 3 punkte) in diesem sind die Verzeichnisse ibico kent personal work In kent die Dateien: ls netstat ps pstree socklist syslog.conf top ibico personal /work sind leer [2] In /usr/share gibts die Datei ... mit dem Inhalt: cd /dev/net/.../personal/iroffer chown lp.lp .* * ./kjournald -u lp a.c -b cd / exit Diese Dateien lassen sich nicht löschen! Also das Fragezeichen im Subject hätte ich mir wohl sparen können ;) Der Server wurde offensichtlich gehackt, vermutlich am 11.8.05 um 23:11. Ich konnte bisher keinerlei Hinweise auf iroffer und Linux finden Unter Windows scheint das bekannt zu sein. Ich muss also den Server neu installieren. Die Frage ist, wie wurde der Server gehackt? Der einzige nach Aussen offene port ist ssh, der einzige erlaubte user ist unprivilegiert und ist mittels keyfile abgesichert. Das Passwort ist nicht trivial ;) Die Neuinstallation werde ich wohl nutzen um auf SuSE 9.1 umzusteigen. Die Frage ist welche Teile der Konfiguration sind gehackt? Es läuft postfix, dhcp, bind9, samba-2.2.8.a, squid, apache, ssh, yp, postgres, xinetd, mysql und die sonstigen Standarddienste Wo finde ich Informationen dazu? [1] Ich habe via find nach iroffer gesucht und es gelöscht. Daher hab ich die genaue Meldung nicht mehr. [2] In diesen Verzeichnissen waren auch Dateien die ich aber gelöscht habe. Danke und Gruss Bernd
Hi, On Thu, 25 Aug 2005, Bernd Obermayr wrote:
SuSE 8.2, alle Updates gemacht
[...]
Als ich den syslogd restarten wollte kam eine Meldung von einem Programm iroffer [1]
[erster google treffer] iroffer is a software program that acts as a fileserver for IRC. It is similar to a FTP server or WEB server, but users can download files using the DCC protocol of IRC instead of a web browser.
ibico kent personal work In kent die Dateien: ls netstat ps pstree socklist syslog.conf top
d.h. auf deinem System sind jetzt Dateien eines (schlechten) rootkits installiert. Und mindestens die oben angegebenen Befehle sind kompromitiert.
In /usr/share gibts die Datei ... mit dem Inhalt:
cd /dev/net/.../personal/iroffer
chown lp.lp .* *
./kjournald -u lp a.c -b
cd /
das ist der "versteckte" Aufruf eines "Schadprogrammes". Sprich du hast einfach nur einen kjournald mehr in ps. Allerdings frage ich mich dann, wieso das rootkit ps ausgetauscht hat, wenn nachher doch noch solche seltsamen "Tricks" angewendet werden.
Diese Dateien lassen sich nicht löschen!
sehr gut. Kannst du mir die dann mal bitte per PM zuschicken? Danach sag ich dir dann auch wie du die wieder los wirst *g*
Also das Fragezeichen im Subject hätte ich mir wohl sparen können ;)
jup
Der Server wurde offensichtlich gehackt, vermutlich am 11.8.05 um 23:11.
Ich konnte bisher keinerlei Hinweise auf iroffer und Linux finden Unter Windows scheint das bekannt zu sein.
s.o.
Ich muss also den Server neu installieren.
ja definitiv. Vorher mußt du aber zuerst herausfinden wie der Angreifer auf dein System kam.
Die Frage ist, wie wurde der Server gehackt? Der einzige nach Aussen offene port ist ssh, der einzige erlaubte user ist unprivilegiert und ist mittels keyfile abgesichert. Das Passwort ist nicht trivial ;)
a) openssh hat einen noch unbekannten "bug" b) du hast uns angelogen :)
Die Neuinstallation werde ich wohl nutzen um auf SuSE 9.1 umzusteigen. Die Frage ist welche Teile der Konfiguration sind gehackt?
im Zweifelsfall alle.
Es läuft postfix, dhcp, bind9, samba-2.2.8.a, squid, apache,
da fallen mir dann doch gleich mal bind9, samba und apache sehr negativ auf ;) Wie sicher bist du, dass der Angreifer nicht über einen dieser Dienste kam?
ssh, yp, postgres, xinetd, mysql und die sonstigen Standarddienste
mysql das selbe Spiel.
Wo finde ich Informationen dazu?
Informationen wozu? Welchen Teil der cfg du weiter benutzen kannst? Im allgemeinen darfst du von einem kompromitierten Rechner nichts wiederverwenden. Die Platten müssen vor der Neuinstallation an einem anderen System komplett genullt werden (dd if=/dev/zero) Das Bios solltest du zurücksetzen bzw. mit etwas das einwandfreiem ersetzen. Allerdings hört sich deine Beschreibung nicht so an, als wäre das ein "ernstzunehmender" Hack. Sprich Scriptkiddie on Tour.
[2] In diesen Verzeichnissen waren auch Dateien die ich aber gelöscht habe.
falscher Fehler. Wenn du deine "Beweise" löschst, wie willst du dann herausfinden, wie der Angreifer in dein System kam? Greetings Daniel -- If you don't think that women are explosive then drop one.
Daniel Lord schrieb:
Hi,
On Thu, 25 Aug 2005, Bernd Obermayr wrote:
SuSE 8.2, alle Updates gemacht
[...]
Als ich den syslogd restarten wollte kam eine Meldung von einem Programm iroffer [1]
[erster google treffer] iroffer is a software program that acts as a fileserver for IRC. It is similar to a FTP server or WEB server, but users can download files using the DCC protocol of IRC instead of a web browser. Genau das hab ich auch gefunden, das klingt aber doch noch recht harmlos ;)
ibico kent personal work In kent die Dateien: ls netstat ps pstree socklist syslog.conf top
d.h. auf deinem System sind jetzt Dateien eines (schlechten) rootkits installiert. Und mindestens die oben angegebenen Befehle sind kompromitiert.
grr
In /usr/share gibts die Datei ... mit dem Inhalt:
cd /dev/net/.../personal/iroffer
chown lp.lp .* *
./kjournald -u lp a.c -b
cd /
das ist der "versteckte" Aufruf eines "Schadprogrammes". Sprich du hast einfach nur einen kjournald mehr in ps. Allerdings frage ich mich dann, wieso das rootkit ps ausgetauscht hat, wenn nachher doch noch solche seltsamen "Tricks" angewendet werden.
hm? rootkit, gut, nicht ums verrecken ist mir der Begriff eingefallen :) Nun weiss ich wieder wie das Tool hiess: chkrootkit Nützt es noch was, damit den server zu checken? Habs jetzt einfach mal installiert und probiert, hier die letzten Zeilen (vorher nur ..nothing found) Searching for Madalin rootkit default files... Possible Madalin rootkit installed Searching for Fu rootkit default files... nothing found Searching for ESRK rootkit default files... nothing found Searching for anomalies in shell history files... nothing found Checking `asp'... not infected Checking `bindshell'... INFECTED (PORTS: 4000) Checking `lkm'... You have 81 process hidden for ps command chkproc: Warning: Possible LKM Trojan installed Checking `rexedcs'... not found Checking `sniffer'... eth0: PROMISC PF_PACKET(/usr/sbin/pppd, /usr/sbin/dhcpd) eth1: PF_PACKET(/usr/sbin/pppd) ppp0: not promisc and no PF_PACKET sockets Checking `w55808'... not infected Checking `wted'... chkwtmp: nothing deleted Checking `scalper'... not infected Checking `slapper'... not infected Checking `z2'... chklastlog: nothing deleted Checking `chkutmp'... the name `ty,pid,ruser,args' is not a tty chkutmp: nothing deleted
Diese Dateien lassen sich nicht löschen!
sehr gut. Kannst du mir die dann mal bitte per PM zuschicken? Danach sag ich dir dann auch wie du die wieder los wirst *g*
Okay ;) Zum Hintergrund: Ich habe den Kunden vor 2 Mon. übernommen, der Server war offen wie ein Scheunentor. Ich habe damals die Firewall neu konfiguriert (SuSEFirewall). Habe dem Kunden empfohlen, einen DSL Router mit Firewall oder eine spezielle Firewall zu kaufen und/oder einen Security Experten zu Rate zu ziehen (Ich bin keiner) Der Kunden hielt das für zu teuer... Auch weitere Prüfungen von mir wollte er nicht: "Es ist doch jetzt schon Jahre gelaufen..." Der Server ist 80km von mir weg, ich habe das alles jetzt per ssh Login ermittelt. Vor Ort bin ich erst am Samstag.
Ich muss also den Server neu installieren.
ja definitiv. Vorher mußt du aber zuerst herausfinden wie der Angreifer auf dein System kam. Genau, deswegen frag ich ja ;)
Die Frage ist, wie wurde der Server gehackt? Der einzige nach Aussen offene port ist ssh, der einzige erlaubte user ist unprivilegiert und ist mittels keyfile abgesichert. Das Passwort ist nicht trivial ;)
a) openssh hat einen noch unbekannten "bug" b) du hast uns angelogen :) *g* a) Möglich b) Nein
Grad eben hab ich in der Ausgabe von last noch was entdeckt: service pts/8 16.204-78-194.ad Thu Aug 11 23:22 - 23:22 (00:00) service pts/7 16.204-78-194.ad Thu Aug 11 23:12 - 23:22 (00:09) service pts/6 210.119.106.76 Thu Aug 11 23:10 - 23:21 (00:10) service pts/6 81.181.206.99 Tue Aug 9 21:13 - 21:17 (00:03) service pts/6 81.181.206.99 Tue Aug 9 14:55 - 16:17 (01:21) service pts/6 tor149-99-40-226 Sun Aug 7 11:28 - 11:28 (00:00) service pts/2 81.181.206.99 Sat Jul 23 16:25 - 16:30 (00:04) service pts/1 81-223-132-210.x Sat Jul 23 16:24 - 17:27 (01:02) service pts/1 193.230.222.148 Wed Jul 6 22:26 - 22:27 (00:00) service pts/2 193.230.222.148 Wed Jul 6 21:19 - 22:23 (01:03) service pts/1 buswalnut.colora Wed Jul 6 21:15 - 21:36 (00:21) service pts/2 82.155.62.175 Tue Jun 21 07:22 - 10:42 (03:19) service pts/1 d047154.adsl.han Tue Jun 21 07:22 - 07:23 (00:01) service pts/0 218.159.70.18 Wed Apr 27 16:09 - 16:09 (00:00) service pts/0 h164-61-59-39.se Sun Apr 17 17:07 - 17:07 (00:00) Also wohl schon im April gehackt. Den User service gibt es nicht.
Die Neuinstallation werde ich wohl nutzen um auf SuSE 9.1 umzusteigen. Die Frage ist welche Teile der Konfiguration sind gehackt?
im Zweifelsfall alle.
grrrrrrrrr
Es läuft postfix, dhcp, bind9, samba-2.2.8.a, squid, apache,
da fallen mir dann doch gleich mal bind9, samba und apache sehr negativ auf ;) Wie sicher bist du, dass der Angreifer nicht über einen dieser Dienste kam?
Portscan von aussen zeigt nur ssh an. Mehr wurde nicht geprüft, der Kunde hielt das für unnötig.
ssh, yp, postgres, xinetd, mysql und die sonstigen Standarddienste
mysql das selbe Spiel.
Wo finde ich Informationen dazu?
Informationen wozu? Welchen Teil der cfg du weiter benutzen kannst? Im allgemeinen darfst du von einem kompromitierten Rechner nichts wiederverwenden. Die Platten müssen vor der Neuinstallation an einem anderen System komplett genullt werden (dd if=/dev/zero) Das Bios solltest du zurücksetzen bzw. mit etwas das einwandfreiem ersetzen. Allerdings hört sich deine Beschreibung nicht so an, als wäre das ein "ernstzunehmender" Hack. Sprich Scriptkiddie on Tour.
[2] In diesen Verzeichnissen waren auch Dateien die ich aber gelöscht habe.
falscher Fehler. Wenn du deine "Beweise" löschst, wie willst du dann herausfinden, wie der Angreifer in dein System kam?
Hm, ja. Erstens wollte ich schnell die Funktion des Hacks zerstören. Zweitens dachte ich da noch, die entsprechenden Info's wären im Netz leicht zu finden :( Drittens, /var/log/messages und warn hat er ja selber schon gekillt...
Greetings Daniel
Danke Bernd
Hi, On Thu, 25 Aug 2005, Bernd Obermayr wrote:
Daniel Lord schrieb:
[erster google treffer] iroffer is a software program that acts as a fileserver for IRC. It is similar to a FTP server or WEB server, but users can download files using the DCC protocol of IRC instead of a web browser. Genau das hab ich auch gefunden, das klingt aber doch noch recht harmlos ;)
ist es auch. Es ist nur ein Programm mit dem Warez, Pr0n oder was auch immer das "Herz begehrt" von diversen release groups auf "billige Server gestellt wird.
rootkit, gut, nicht ums verrecken ist mir der Begriff eingefallen :) Nun weiss ich wieder wie das Tool hiess: chkrootkit Nützt es noch was, damit den server zu checken?
jein, wenn du was findest gut. Wenn du nichts findest heißt das nur, dass das rootkit besser als chkrootkit oder einfach nur unbekannt ist.
Habs jetzt einfach mal installiert und probiert, hier die letzten Zeilen (vorher nur ..nothing found)
Searching for Madalin rootkit default files... Possible Madalin rootkit installed
ok, Madalin rootkit damit hat das Kind evtl. schon einen Namen.
Checking `bindshell'... INFECTED (PORTS: 4000)
auf port 4000 hast du eine weitere Möglichkeit deinen Server zu administrien wie mir scheint.
Checking `lkm'... You have 81 process hidden for ps command
IMHO versteckt SuSEs ps selber Prozesse sonst ist das auf jedenfall kein gutes Zeichen ;)
chkproc: Warning: Possible LKM Trojan installed
Aha, jetzt wird es schon interessanter. Es scheint als wäre ein spezielles Kernelmodul geladen, das dem Angreifer die Arbeit erleichtert. Allerdings wundert mich dann, dass du das rootkit gefunden hast. Ist das Modul brauchbar findest du auf einem normalen System genau gar nichts davon.
Checking `sniffer'... eth0: PROMISC PF_PACKET(/usr/sbin/pppd, /usr/sbin/dhcpd) eth1: PF_PACKET(/usr/sbin/pppd)
das ist noch normal.
Checking `chkutmp'... the name `ty,pid,ruser,args' is not a tty
da hat jemand an /var/log/utmp gespielt und was kaputt gemacht.
Diese Dateien lassen sich nicht löschen!
sehr gut. Kannst du mir die dann mal bitte per PM zuschicken? Danach sag ich dir dann auch wie du die wieder los wirst *g* Okay ;)
chattr -i <datei> rm -f <datei> aber bitte vorher sichern ;)
Zum Hintergrund: Ich habe den Kunden vor 2 Mon. übernommen, der Server war offen wie ein Scheunentor.
Damit ist dann auch klar, dass das rootkit da schon etwas länger drauf ist. Du hast nicht zufällig ein kernelupdate gemacht, oder es irgendwie anderst hinbekommen das LKM zu entladen? ;) Eine weitere wahrscheinliche Möglichkeit ist ein Angriff von innen.
Ich habe damals die Firewall neu konfiguriert (SuSEFirewall). Habe dem Kunden empfohlen, einen DSL Router mit Firewall oder eine spezielle Firewall zu kaufen und/oder einen Security Experten zu Rate zu ziehen (Ich bin keiner) Der Kunden hielt das für zu teuer... Auch weitere Prüfungen von mir wollte er nicht: "Es ist doch jetzt schon Jahre gelaufen..." Der Server ist 80km von mir weg, ich habe das alles jetzt per ssh Login ermittelt. Vor Ort bin ich erst am Samstag.
Geiz ist geil... Die DSL Flat kostet nichts und das "bischen" zusätzlicher Traffic ist zu aktzeptieren *g*
Ich muss also den Server neu installieren.
ja definitiv. Vorher mußt du aber zuerst herausfinden wie der Angreifer auf dein System kam. Genau, deswegen frag ich ja ;)
1. Herausfinden wann der Einbruch stattfand. ls -l <rootkit> /var/log/* # alles zusammensuchen was irgendwie interessant ist. ... 2. Herausfinden wie der Angreifer auf das System kam /var/log # (remote syslog oder Glück) ... In deinem Fall dürfte das Apache und Mysql Log wahrscheinlich interessant sein. 3. Angreifer beobachten. - eigenes LKM (umständlich) - tty logger - tcpdump auf einem weiteren System mitlaufen lassen. ...
Grad eben hab ich in der Ausgabe von last noch was entdeckt:
[...]
service pts/0 h164-61-59-39.se Sun Apr 17 17:07 - 17:07 (00:00)
Also wohl schon im April gehackt. Den User service gibt es nicht.
das war nicht zufällig der Account des vorherigen Admins? Wenn ja dann ist er ziemlich weit rumgekommen ;) Amiland, Korea, ...
Die Neuinstallation werde ich wohl nutzen um auf SuSE 9.1 umzusteigen. Die Frage ist welche Teile der Konfiguration sind gehackt?
im Zweifelsfall alle. grrrrrrrrr
naja, so schlimm ist das nicht. Du mußt die cfg Dateien sowieso von Hand durchgehen und an die neue SuSE anpassen. Btw. willst du nicht lieber ein Debian oder Trustix nehmen? ;)
Portscan von aussen zeigt nur ssh an. Mehr wurde nicht geprüft, der Kunde hielt das für unnötig.
portscan? nmap? Wenn nmap, dann mit welchen Optionen? Wenn der Rechner vom Angreifer wirklich benutzt und nicht nur gekapter wurde, dann kannst du den Einbruchszeitpunkt anhand des entstandenen/abgerechneten Traffics ermitteln. Ausserdem sollten sich dann auf dem Rechner noch einige wahrscheinlich recht große Dateien finden, die da nichts zu suchen haben. Greetings Daniel -- "Every living thing dies alone." -- Donnie Darko
Daniel Lord schrieb:
Hi,
On Thu, 25 Aug 2005, Bernd Obermayr wrote:
Daniel Lord schrieb:
[erster google treffer] iroffer is a software program that acts as a fileserver for IRC. It is similar to a FTP server or WEB server, but users can download files using the DCC protocol of IRC instead of a web browser.
Genau das hab ich auch gefunden, das klingt aber doch noch recht harmlos ;)
ist es auch. Es ist nur ein Programm mit dem Warez, Pr0n oder was auch immer das "Herz begehrt" von diversen release groups auf "billige Server gestellt wird. Tröstlich :-/
rootkit, gut, nicht ums verrecken ist mir der Begriff eingefallen :) Nun weiss ich wieder wie das Tool hiess: chkrootkit Nützt es noch was, damit den server zu checken?
jein, wenn du was findest gut. Wenn du nichts findest heißt das nur, dass das rootkit besser als chkrootkit oder einfach nur unbekannt ist.
Habs jetzt einfach mal installiert und probiert, hier die letzten Zeilen (vorher nur ..nothing found)
Searching for Madalin rootkit default files... Possible Madalin rootkit installed
ok, Madalin rootkit damit hat das Kind evtl. schon einen Namen.
Checking `bindshell'... INFECTED (PORTS: 4000)
auf port 4000 hast du eine weitere Möglichkeit deinen Server zu administrien wie mir scheint.
Nicht dass ich wüsste..
Checking `lkm'... You have 81 process hidden for ps command
IMHO versteckt SuSEs ps selber Prozesse sonst ist das auf jedenfall kein gutes Zeichen ;)
frx:~/bin/chkrootkit-0.45 # ./chkrootkit -x lkm ROOTDIR is `/' ### ### Output of: ./chkproc -v -v -p 1 ### [...] PID 1254: not in ps output CWD 1254: /dev/net/.../work/fedssh2 (deleted) EXE 1254: /bin/bash PID 1424: not in ps output CWD 1424: /dev/net/.../work/fedssh2 (deleted) EXE 1424: /dev/net/.../work/fedssh2/exploit (deleted) PID 2250: not in ps output CWD 2250: /dev/net/.../work/fedssh2 (deleted) EXE 2250: /dev/net/.../work/fedssh2/exploit (deleted) PID 14295: not in ps output CWD 14295: / EXE 14295: /usr/bin/smbd -D PID 14306: not in ps output CWD 14306: /tmp/.../.../parliament (deleted) [...] PID 15322: not in ps output CWD 15322: /dev/net/.../personal/iroffer (deleted) EXE 15322: /dev/net/.../personal/iroffer/kjournald (deleted) [...] PID 20473: not in ps output CWD 20473: /dev/net/.../personal/iroffer (deleted) EXE 20473: /dev/net/.../personal/iroffer/kjournald (deleted) PID 20783: not in ps output CWD 20783: /dev/net/.../personal/iroffer (deleted) EXE 20783: /dev/net/.../personal/iroffer/kjournald (deleted) usw.
chkproc: Warning: Possible LKM Trojan installed
Aha, jetzt wird es schon interessanter. Es scheint als wäre ein spezielles Kernelmodul geladen, das dem Angreifer die Arbeit erleichtert. Allerdings wundert mich dann, dass du das rootkit gefunden hast. Ist das Modul brauchbar findest du auf einem normalen System genau gar nichts davon.
Checking `sniffer'... eth0: PROMISC PF_PACKET(/usr/sbin/pppd, /usr/sbin/dhcpd) eth1: PF_PACKET(/usr/sbin/pppd)
das ist noch normal.
Checking `chkutmp'... the name `ty,pid,ruser,args' is not a tty
da hat jemand an /var/log/utmp gespielt und was kaputt gemacht.
Ja die Datei ist weg.
Diese Dateien lassen sich nicht löschen!
sehr gut. Kannst du mir die dann mal bitte per PM zuschicken? Danach sag ich dir dann auch wie du die wieder los wirst *g*
Okay ;)
chattr -i <datei> rm -f <datei>
Das hab ich schon versucht, geht nicht.. frx:/dev/net/.../kent # chattr -i ls frx:/dev/net/.../kent # mv ls ls-bad mv: cannot move `ls' to `ls-bad': Permission denied frx:/dev/net/.../kent # rm ls rm: cannot remove `ls': Permission denied frx:/dev/net/.../kent # frx:/dev/net # lsattr -R ... suS--adAc------ .../kent .../kent: --------------- .../kent/netstat --------------- .../kent/ps --------------- .../kent/ls --------------- .../kent/top --------------- .../kent/pstree --------------- .../kent/syslog.conf --------------- .../kent/socklist --------------- .../personal .../personal: --------------- .../work .../work: --------------- .../ibico
aber bitte vorher sichern ;)
Zum Hintergrund: Ich habe den Kunden vor 2 Mon. übernommen, der Server war offen wie ein Scheunentor.
Damit ist dann auch klar, dass das rootkit da schon etwas länger drauf ist. Du hast nicht zufällig ein kernelupdate gemacht, oder es
Doch uname -r 2.4.20-4GB-athlon Vorher war da glaube ich, 2.4.18-4GB
irgendwie anderst hinbekommen das LKM zu entladen? ;) Eine weitere wahrscheinliche Möglichkeit ist ein Angriff von innen. Das ist IMHO ausgeschlossen.
[...] Geiz ist geil... Die DSL Flat kostet nichts und das "bischen" zusätzlicher Traffic ist zu aktzeptieren *g*
Schön doof, naja ich hab ja was davon ;)
Ich muss also den Server neu installieren.
ja definitiv. Vorher mußt du aber zuerst herausfinden wie der Angreifer auf dein System kam.
Genau, deswegen frag ich ja ;)
1. Herausfinden wann der Einbruch stattfand. ls -l <rootkit> /var/log/* # alles zusammensuchen was irgendwie interessant ist. ...
2. Herausfinden wie der Angreifer auf das System kam /var/log # (remote syslog oder Glück)
Okay :)
...
In deinem Fall dürfte das Apache und Mysql Log wahrscheinlich interessant sein.
3. Angreifer beobachten. - eigenes LKM (umständlich) Hab grad ein Brett vorm Kopf: LKM was ist das? - tty logger - tcpdump auf einem weiteren System mitlaufen lassen. ...
[...]
Portscan von aussen zeigt nur ssh an. Mehr wurde nicht geprüft, der Kunde hielt das für unnötig.
portscan? nmap? Wenn nmap, dann mit welchen Optionen?
nmap -sT -p- -P0 Gerade eben: Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2005-08-25 21:15 CEST Interesting ports on <Adresse gelöscht> (The 65532 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 22/tcp open ssh 35721/tcp open unknown Der letzte Port war da vorher nicht :( /var/log/firewall: Aug 11 23:19:54 frx kernel: SuSE-FW-ACCEPT IN=ppp0 OUT= MAC= SRC=85.186.224.83 DST=84.150.214.196 LEN=48 TO S=0x00 PREC=0x00 TTL=120 ID=32877 DF PROTO=TCP SPT=2936 DPT=35721 WINDOW=16384 RES=0x00 SYN URGP=0 OPT (02040 5AC01010402) Aug 11 23:19:55 frx kernel: SuSE-FW-ACCEPT IN=ppp0 OUT= MAC= SRC=85.186.224.83 DST=84.150.214.196 LEN=48 TO S=0x00 PREC=0x00 TTL=120 ID=32878 DF PROTO=TCP SPT=2936 DPT=35721 WINDOW=16384 RES=0x00 SYN URGP=0 OPT (02040 5AC01010402) Aug 11 23:19:56 frx kernel: SuSE-FW-ACCEPT IN=ppp0 OUT= MAC= SRC=85.186.224.83 DST=84.150.214.196 LEN=48 TO S=0x00 PREC=0x00 TTL=120 ID=32880 DF PROTO=TCP SPT=2936 DPT=35721 WINDOW=16384 RES=0x00 SYN URGP=0 OPT (02040 5AC01010402) [...] Aug 11 23:27:53 frx kernel: eth0: Promiscuous mode enabled. Aug 11 23:27:55 frx kernel: eth0: Promiscuous mode enabled. Aug 11 23:27:55 frx kernel: Kernel logging (proc) stopped. Aug 11 23:27:55 frx kernel: Kernel log daemon terminating. Da wird man ja richtig zum Detektiv ;)
Wenn der Rechner vom Angreifer wirklich benutzt und nicht nur gekapter wurde, dann kannst du den Einbruchszeitpunkt anhand des entstandenen/abgerechneten Traffics ermitteln. Ausserdem sollten sich dann auf dem Rechner noch einige wahrscheinlich recht große Dateien finden, die da nichts zu suchen haben.
Ja die such ich mal.
Greetings Daniel
-- Gruss Bernd
Hi, On Fri, 26 Aug 2005, Bernd Obermayr wrote:
Daniel Lord schrieb:
IMHO versteckt SuSEs ps selber Prozesse sonst ist das auf jedenfall kein gutes Zeichen ;)
frx:~/bin/chkrootkit-0.45 # ./chkrootkit -x lkm ROOTDIR is `/' ### ### Output of: ./chkproc -v -v -p 1 ### [...] PID 1254: not in ps output CWD 1254: /dev/net/.../work/fedssh2 (deleted) EXE 1254: /bin/bash PID 1424: not in ps output CWD 1424: /dev/net/.../work/fedssh2 (deleted) EXE 1424: /dev/net/.../work/fedssh2/exploit (deleted) PID 2250: not in ps output CWD 2250: /dev/net/.../work/fedssh2 (deleted) EXE 2250: /dev/net/.../work/fedssh2/exploit (deleted) PID 14295: not in ps output CWD 14295: / EXE 14295: /usr/bin/smbd -D PID 14306: not in ps output CWD 14306: /tmp/.../.../parliament (deleted) [...] PID 15322: not in ps output CWD 15322: /dev/net/.../personal/iroffer (deleted) EXE 15322: /dev/net/.../personal/iroffer/kjournald (deleted) [...] PID 20473: not in ps output CWD 20473: /dev/net/.../personal/iroffer (deleted) EXE 20473: /dev/net/.../personal/iroffer/kjournald (deleted) PID 20783: not in ps output CWD 20783: /dev/net/.../personal/iroffer (deleted) EXE 20783: /dev/net/.../personal/iroffer/kjournald (deleted) usw.
ok, d.h. du hattest dann noch einen schönen zweiten SSH Zugang zu der Kiste.
chattr -i <datei> rm -f <datei> Das hab ich schon versucht, geht nicht.. frx:/dev/net/.../kent # chattr -i ls frx:/dev/net/.../kent # mv ls ls-bad mv: cannot move `ls' to `ls-bad': Permission denied frx:/dev/net/.../kent # rm ls rm: cannot remove `ls': Permission denied frx:/dev/net/.../kent #
frx:/dev/net # lsattr -R ... suS--adAc------ .../kent .../kent:
chattr -suSadAc .../kent rm -rf .../kent
3. Angreifer beobachten. - eigenes LKM (umständlich) Hab grad ein Brett vorm Kopf: LKM was ist das?
Loadable Kernel Modul d.h. einfach ein Kernelmodul, dass dir auf unterster Ebene in die Suppe spuckt. Wenn das ding richtig programmiert ist hast du am laufenden System als admin fast keine chance dagegen. Einzige Alternative (die ich kenne) ist ein monolytischer Kernel oder ein eigenes "Admin LKM" das eben alles was du nicht haben willst rauswirft. Z.B. könnte das im einfachsten Fall ein Kernelmodul sein, dass als letztes geladen wird und danach keine neuen Module mehr annimmt. In lsmod etc. darf es natürlich nicht sichtbar sein ;)
- tty logger - tcpdump auf einem weiteren System mitlaufen lassen.
tcpdump wäre bei dir jetzt ins leere gelaufen, da der Angreifer einen eigenen sshd benutzt hat. Dann kannst du den netzwerkverkehr natürlich lange sniffen, das juckt ihn nicht.
Portscan von aussen zeigt nur ssh an. Mehr wurde nicht geprüft, der Kunde hielt das für unnötig.
portscan? nmap? Wenn nmap, dann mit welchen Optionen?
nmap -sT -p- -P0
Gerade eben: Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2005-08-25 21:15 CEST Interesting ports on <Adresse gelöscht> (The 65532 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 22/tcp open ssh 35721/tcp open unknown
nmap -sV -p 35721 oder nc <ip> 35721 lsof -i TCP:35721 netstat -tulpen
Der letzte Port war da vorher nicht :(
hehe shit happens ;)
/var/log/firewall: Aug 11 23:19:54 frx kernel: SuSE-FW-ACCEPT IN=ppp0 OUT= MAC= SRC=85.186.224.83 DST=84.150.214.196 LEN=48 TO S=0x00 PREC=0x00 TTL=120 ID=32877 DF PROTO=TCP SPT=2936 DPT=35721 WINDOW=16384 RES=0x00 SYN URGP=0 OPT (02040 5AC01010402)
ok, das Packet darf also durch deine Firewall. D.h. du hast wohl highports in der Konfiguration erlaubt. Nicht gut.
Aug 11 23:19:55
hmm, auf einem server ist es wichtig immer eine genaue Uhrzeit zu haben (ntpdate oder eigene DCF77 Uhr) Sonst bist du im Fehlerfall immer am umrechnen der Zeiten.
Aug 11 23:27:53 frx kernel: eth0: Promiscuous mode enabled.
Aug 11 23:27:55 frx kernel: eth0: Promiscuous mode enabled.
Aug 11 23:27:55 frx kernel: Kernel logging (proc) stopped.
Aug 11 23:27:55 frx kernel: Kernel log daemon terminating.
Da wird man ja richtig zum Detektiv ;)
läuft da zufällig dein cron.daily? Oder ist es möglich, dass sich der Angreiffer ein Zeitfenster für seine Logins geschaffen hat? Die Rootkit Dateien habe ich mir mal näher angeschaut. bis auf top sind alles normal binaries. Normal heißt, dass es die Binaries sind die bei deiner SuSE dabei waren. Also keine Patches, Viren, Backdoors etc.. Top kann ich nicht so einfach verifizieren. Aber vielleicht hat jemand noch ne SuSE rumstehen, und kann dir sagen ob die MD5Summe zu einem "known good binary" passt. 3bc67a1772a8e5543d4459f581c1c25d top Ich habe das binary zerlegt und nichts besonderes gefunden. D.h. kein Laufzeitpacker, der gleiche Compiler, das gleiche Erstelldatum keine Sockets etc. Es fehlt mir folglich nur die richtige MD5Summe, oder irgendwann/irgendwo ist ein Bit in der Datei gekippt. Greetings Daniel -- Alle Pilze sind eßbar. Manche sogar mehrmals.
Hallo, Daniel Lord schrieb:
Top kann ich nicht so einfach verifizieren. Aber vielleicht hat jemand noch ne SuSE rumstehen, und kann dir sagen ob die MD5Summe zu einem "known good binary" passt.
3bc67a1772a8e5543d4459f581c1c25d top
die stimmt mit meinem top auf SuSE 8.2 überein... Gruß Martin
Daniel Lord schrieb:
Hi,
On Fri, 26 Aug 2005, Bernd Obermayr wrote:
Daniel Lord schrieb: [..] EXE 2250: /dev/net/.../work/fedssh2/exploit (deleted) [...]
ok, d.h. du hattest dann noch einen schönen zweiten SSH Zugang zu der Kiste.
chattr -i <datei> rm -f <datei>
Das hab ich schon versucht, geht nicht.. frx:/dev/net/.../kent # chattr -i ls frx:/dev/net/.../kent # mv ls ls-bad mv: cannot move `ls' to `ls-bad': Permission denied frx:/dev/net/.../kent # rm ls rm: cannot remove `ls': Permission denied frx:/dev/net/.../kent #
frx:/dev/net # lsattr -R ... suS--adAc------ .../kent .../kent:
chattr -suSadAc .../kent rm -rf .../kent Ok, das ging ;) Ich bin noch auf eine ganze Reihe weiterer solcher Änderungen gestossen: klogd, ls, netstat, /usr/share..
Gestern hab ich den Server neu aufgesetzt. Da die HD seltsame Geräusche von sich gab, (Klicken) und der fsck nicht durchlief hab ich gleich eine neue HD verwendet. Damit hatte ich dann das Problem mit dem Nullen der Platte auch nicht mehr ;) Der Kunde hat sich nun doch für eine externe Firewall entschieden, wenn auch nur ein DSL Router mit Firewall aber immerhin ;) Nachwievor ist unklar wie die Angreifer in das System kamen. Um den Server vor weiteren Attacken zu schützen müsste ich mich wohl mehr mit Intrusion detection etc. befassen. Da mir das nicht bezahlt wird, fehlt mir die Zeit dazu ;) Habe den Kunden nochmal aufgefordert, einen Spezialisten einzuschalten...
3. Angreifer beobachten. - eigenes LKM (umständlich)
Hab grad ein Brett vorm Kopf: LKM was ist das?
Loadable Kernel Modul d.h. einfach ein Kernelmodul, dass dir auf
hmmm, rot werd, naja war ja schon spät :))
unterster Ebene in die Suppe spuckt. Wenn das ding richtig programmiert ist hast du am laufenden System als admin fast keine chance dagegen. Einzige Alternative (die ich kenne) ist ein monolytischer Kernel oder ein eigenes "Admin LKM" das eben alles was du nicht haben willst rauswirft. Z.B. könnte das im einfachsten Fall ein Kernelmodul sein, dass als letztes geladen wird und danach keine neuen Module mehr annimmt. In lsmod etc. darf es natürlich nicht sichtbar sein ;) [...]
nmap -sV -p 35721 oder nc <ip> 35721 lsof -i TCP:35721 netstat -tulpen netstat und lsof waren auch betroffen nc kannte ich noch garnicht.
Der letzte Port war da vorher nicht :(
hehe shit happens ;)
/var/log/firewall: Aug 11 23:19:54 frx kernel: SuSE-FW-ACCEPT IN=ppp0 OUT= MAC= SRC=85.186.224.83 DST=84.150.214.196 LEN=48 TO S=0x00 PREC=0x00 TTL=120 ID=32877 DF PROTO=TCP SPT=2936 DPT=35721 WINDOW=16384 RES=0x00 SYN URGP=0 OPT (02040 5AC01010402)
ok, das Packet darf also durch deine Firewall. D.h. du hast wohl highports in der Konfiguration erlaubt. Nicht gut.
Ja das war so :( Wie ich aus einem Vergleich mit dem Backup ersehen konnte habe ich das nicht aktiviert. Offenbar hat das rootkit sich so die Tür offengehalten. In /etc/init.d/syslog war die Zeile eingefügt: source /usr/share/... Deswegen liess sich syslog nicht restarten. Am Anfang meiner Suche habe ich diese Zeile übersehen. Diese Meldung von iroffer, siehe erste Mail, mein erster Gedanke war, im Startscript nachzusehen...
Aug 11 23:19:55
hmm, auf einem server ist es wichtig immer eine genaue Uhrzeit zu haben (ntpdate oder eigene DCF77 Uhr) Sonst bist du im Fehlerfall immer am umrechnen der Zeiten.
Es lief ntp Aber warum erwähnst Du das?
Aug 11 23:27:53 frx kernel: eth0: Promiscuous mode enabled.
Aug 11 23:27:55 frx kernel: eth0: Promiscuous mode enabled.
Aug 11 23:27:55 frx kernel: Kernel logging (proc) stopped.
Aug 11 23:27:55 frx kernel: Kernel log daemon terminating.
Da wird man ja richtig zum Detektiv ;)
läuft da zufällig dein cron.daily? Oder ist es möglich, dass sich der Angreiffer ein Zeitfenster für seine Logins geschaffen hat?
Da hab ich jetzt gar nicht mehr nachgesehen.
Die Rootkit Dateien habe ich mir mal näher angeschaut. bis auf top sind alles normal binaries. Normal heißt, dass es die Binaries sind die bei deiner SuSE dabei waren. Also keine Patches, Viren, Backdoors etc..
Fein :-/ Was offensichtlich verändert wurde, ist mindestens klogd wahrscheinlich auch syslogd und ...
Top kann ich nicht so einfach verifizieren. Aber vielleicht hat jemand noch ne SuSE rumstehen, und kann dir sagen ob die MD5Summe zu einem "known good binary" passt.
3bc67a1772a8e5543d4459f581c1c25d top
Laut Hans-Martin Flesch ist das auch in Ordnung (Danke!)
Jedenfalls Danke für Deine ausführlichen Antworten, Du hast mir sehr geholfen ;)) -- Gruss Bernd
Hi, On Sun, 28 Aug 2005, Bernd Obermayr wrote:
Daniel Lord schrieb:
Bernd Obermayr wrote:
Aug 11 23:19:55
hmm, auf einem server ist es wichtig immer eine genaue Uhrzeit zu haben (ntpdate oder eigene DCF77 Uhr) Sonst bist du im Fehlerfall immer am umrechnen der Zeiten.
Es lief ntp Aber warum erwähnst Du das?
Weil die Logauszüge IMHO aus der Vergangenheit kamen. Zumindest war deine Mail mit dem Portscan vom 26 Aug 2005, und die dazugehörigen Logs vom 11 Aug ;) Schade, dass sich nicht mehr (einfach) klären läst wie der Angreifer auf das System kam. Wenn es denn wirklich ein sshd 0day ist fände ich das schon wichtig zu wissen ;) Greetings Daniel -- Man hat jetzt die Lösung gefunden und sucht noch nach dem Problem.
participants (3)
-
Bernd Obermayr -
Daniel Lord -
Hans-Martin Flesch