[Debian] Ik ben geroot, hoe?

[Rempage0611]

Helaas is dit mij overkomen, hoe weet ik dat ik geroot ben?

Stukje uit chrootkit:
Checking `asp'... not infected
Checking `bindshell'... INFECTED (PORTS: 1524 31337)
Checking `lkm'... You have 1 process hidden for readdir command
You have 4 process hidden for ps command

De gebruikte tool is: "Fuck`it RootKit by Cyrax"
maar deze schijnt gebruik te maken van: een backdoor in SSH-1.99-OPENSSH_3.3p1.

Ik zelf draai nu : OpenSSH_3.4p1 Debian 1:3.4p1-2, SSH protocols 1.5/2.0, OpenSSL 0x0090604f

3.4p1 is toch nieuwer dan 3.3p1.. hoe kan ik dan gehacked zijn?

Kernel versie:2.4.18

De firewall laat alleen ssh verkeer door en route 2 andere poorten naar een interne machine. Hoe kan ik dan gehacked zijn? Is die ssh versie toch niet goed? Ik snap het niet.

[moto-moi]

Omdat je hiervoor wel 3.3p1 hebt gebruikt, en daarna via apt-get update; apt-get upgrade aan versie 3.4p1 bent gekomen. En toen stond die rootkit blijkbaar al op je machine

[Eijkb]

Met de tool chrootkit kan je makkelijk controleren ofdat je geinfecteerd bent? Zijn er zo nog meer tools die dat voor je kunnen doen? Op linux en/of windows? En zijn die tools geschikt voor bedrijfsomgevingen??

[blaataaps]

Eijkb schreef op 07 november 2003 @ 11:13:
Met de tool chrootkit kan je makkelijk controleren ofdat je geinfecteerd bent?

Ja, dat is het idee

Zijn er zo nog meer tools die dat voor je kunnen doen?

Ja, checkroot oid en vast ook anderen, zie ook google

Op linux en/of windows?

Virusscanners checken als het goed is op trojans en aanverwante zaken

En zijn die tools geschikt voor bedrijfsomgevingen??

oordeel zelf:

chkrootkit identifies whether the target computer is infected with a rootkit.
Please note that this is not a definitive test, it does not ensure that the
target has not been cracked. In addition to running chkrootkit, one should
perform more specific tests.

Maar voor de topicstarter is dat allemaal offtopic, ik denk inderdaad dat moto-moi gelijk kan hebben, geroot in de tijd voor het updaten van je ssh, misschien dat je ergens timestamps kunt vergelijken om te zien of dat mogelijk is? (hoeft geen definitief uitsluitsel te zijn, timestamps kunnen veranderd zijn)

[ Voor 18% gewijzigd door blaataaps op 07-11-2003 11:24 ]

[Rempage0611]

Eijkb schreef op 07 november 2003 @ 11:13:
Met de tool chrootkit kan je makkelijk controleren ofdat je geinfecteerd bent? Zijn er zo nog meer tools die dat voor je kunnen doen? Op linux en/of windows? En zijn die tools geschikt voor bedrijfsomgevingen??

Deze tool is (volgens mij) idd gewoon veilig, hij checkt als ik het goed heb gewoon of er foute bestanden bestaan en hij crc-t

Trouwens het is chKrootkit, die ene tikfout maakt veel uit

Ontopic, deze bak is 2 weken geleden gereboot en toen deed hij het nog wel, en nu gaf hij met rebooten allerlei scheldwoorden. Het is dus gebeurt met deze versie van ssh... Hoe kan dat?

[Hans]

Draai je toevallig portsentry oid? daarmee wil je nog wel es false positives krijgen met chkrootkit

[blaataaps]

Als ik wat informatie lees over de betreffende rootkit betekent het gebruik helemaal niet dat je geroot bent via de in de rootkits README genoemde versie van ssh. De rootkit is bedoeld (vandaar de naam rootkit) voor gebruik na de exploit, om je sporen te verbergen, het daadwerkelijke binnenkomen is ergens anders mee gebeurd. De "fuck it" rootkit bevat een binary van openssh, om remote toegang te bieden aan de cracker, en wel eentje van versie 3.3p1. Gebruik je wel een voor de ptrace-bug gepatchte versie van 2.4.18?

[ Voor 10% gewijzigd door blaataaps op 07-11-2003 11:33 ]

[Verwijderd]

blaataaps schreef op 07 november 2003 @ 11:31:
Gebruik je wel een voor de ptrace-bug gepatchte versie van 2.4.18?

De ptrace vulnerability kan alleen lokaal uitgebuit worden, dus tenzij het een bekende is moet een cracker toch op een andere manier toegang hebben gekregen.

Voor de TS zit er maar een ding opnieuw op. Systeem zo snel mogelijk offline halen (netwerkkabel eruit), een dd image maken via netcat als je forensics wil gaan doen en opnieuw installeren.

offtopic:
Overigens jammer dat je het systeem al hebt gereboot. Ik had graag een image van het systeem willen hebben om forensics toe te passen. Tijdens de laatste honeyney challenge genoeg inspiratie opgedaan. Zie http://honeynet.org voor de laatste challenge die over forensics ging.

[blaataaps]

Verwijderd schreef op 07 november 2003 @ 12:02:
[...]

De ptrace vulnerability kan alleen lokaal uitgebuit worden, dus tenzij het een bekende is moet een cracker toch op een andere manier toegang hebben gekregen.

Ik zie in zijn post niet dat geroot via lokale toegang uitgesloten is, alleen dat ssh naar buiten open staat, en de volgens mij verkeerde aanname dat het via de openssh 3.3p1 gegaan moet zijn

[Verwijderd]

blaataaps schreef op 07 november 2003 @ 12:06:
[...]

Ik zie in zijn post niet dat geroot via lokale toegang uitgesloten is, alleen dat ssh naar buiten open staat, en de volgens mij verkeerde aanname dat het via de openssh 3.3p1 gegaan moet zijn

Daar heb je helemaal gelijk in, maar ik ging nu even uit van de goede aard van de gebruikers op het systeem

Overigens ben ik het eens dat redenatie van de TS over openssh kort de boch is en waarschijnlijk niet klopt. Zoals ik al zei kan forensics mogelijk meer duidelijkheid geven.

[Rempage0611]

Verwijderd schreef op 07 november 2003 @ 12:14:
[...]

Daar heb je helemaal gelijk in, maar ik ging nu even uit van de goede aard van de gebruikers op het systeem

Overigens ben ik het eens dat redenatie van de TS over openssh kort de boch is en waarschijnlijk niet klopt. Zoals ik al zei kan forensics mogelijk meer duidelijkheid geven.

Hoe begin ik hiermee met forensics? Hoe pak je zoiets aan?

Ik zie trouwens ook net dat er een stuk of 5 servers, die bij allemaal andere bedrijven staan zijn besmet, allemaal geven ze andere dingen met chkrootkit. Even een paar voorbeeldjes:

Checking `syslogd'... INFECTED
Checking `lkm'... You have 1 process hidden for ps command
Warning: Possible LKM Trojan installed

Met ps /usr/bin/xsf –q gevonden, is een ssh client, deze gekilled


Checking `lkm'... You have 3 process hidden for readdir command
You have 3 process hidden for ps command
Warning: Possible LKM Trojan installed

Het is dus wel degelijk van buitenaf gekomen. Ook mede omdat de bedrijven waar deze machines staan niet echt personeel hebben die ik dit zie doen.

[Verwijderd]

Rempage0611 schreef op 07 november 2003 @ 12:20:
[...]


Hoe begin ik hiermee met forensics? Hoe pak je zoiets aan?

Dit is een vak apart en kan een hoop tijd kosten maar zie de laatste challenge op de honeynet site die ik gaf. De winnaar van de laatste challenge geeft een goede uitleg hoe dit te doen. Enige unix/security kennis is wel vereist.

Ik zie trouwens ook net dat er een stuk of 5 servers, die bij allemaal andere bedrijven staan zijn besmet, allemaal geven ze andere dingen met chkrootkit. Even een paar voorbeeldjes:

Checking `syslogd'... INFECTED
Checking `lkm'... You have 1 process hidden for ps command
Warning: Possible LKM Trojan installed

Met ps /usr/bin/xsf –q gevonden, is een ssh client, deze gekilled


Checking `lkm'... You have 3 process hidden for readdir command
You have 3 process hidden for ps command
Warning: Possible LKM Trojan installed

Het is dus wel degelijk van buitenaf gekomen. Ook mede omdat de bedrijven waar deze machines staan niet echt personeel hebben die ik dit zie doen.

Hoewel dit niet best klinkt geeft chkrootkit soms nog wel eens een false positive. Zeker als je chkrookit niet met trusted binaries draait. Je moet dus ook nooit de binaries (zoals ifconfig, ls, ps, ed....) vertrouwen op een gehackt systeem.

Ik neem aan dat die machines niet regelmatig up to date werden gehouden?

[ Voor 5% gewijzigd door Verwijderd op 07-11-2003 12:28 ]

[Rempage0611]

Verwijderd schreef op 07 november 2003 @ 12:26:
[...]

Dit is een vak apart en kan een hoop tijd kosten maar zie de laatste challenge op de honeynet site die ik gaf. De winnaar van de laatste challenge geeft een goede uitleg hoe dit te doen. Enige unix/security kennis is wel vereist.


[...]

Hoewel dit niet best klinkt geeft chkrootkit soms nog wel eens een false positive. Zeker als je chkrookit niet met trusted binaries draait. Je moet dus ook nooit de binaries (zoals ifconfig, ls, ps, ed....) vertrouwen op een gehackt systeem.

Ik neem aan dat die machines niet regelmatig up to date werden gehouden?

Nee helaas niet, je kent het wel, het valse gevoel van veilighied.

Je zegt dat je graag forensics wilde doen, ik heb nog wel een machine die niet gereboot is, neem even contact met me op via mail/msn/icq.

[Confusion]

Hmmm... ik krijg ook

code:

Checking `lkm'... You have     4 process hidden for ps command
Warning: Possible LKM Trojan installed

maar ik update mijn Debian Testing toch vrijwel dagelijks. Verder heb ik niets raars gezien, in termen van schijfgebruik en netwerkstatistiek, dus ik maak me eigenlijk geen zorgen.... or should I?

[Rempage0611]

Confusion schreef op 07 november 2003 @ 13:28:
Hmmm... ik krijg ook

code:

Checking `lkm'... You have     4 process hidden for ps command
Warning: Possible LKM Trojan installed

maar ik update mijn Debian Testing toch vrijwel dagelijks. Verder heb ik niets raars gezien, in termen van schijfgebruik en netwerkstatistiek, dus ik maak me eigenlijk geen zorgen.... or should I?

Heb je dit? /dev/proc/fuckit/fk.tgz
Die had ik nml op 1 van m`n servers die dezelfe melding gaf.

[ Voor 7% gewijzigd door Rempage0611 op 07-11-2003 13:39 ]

[Verwijderd]

Rempage0611 schreef op 07 november 2003 @ 12:47:
[...]
Je zegt dat je graag forensics wilde doen, ik heb nog wel een machine die niet gereboot is, neem even contact met me op via mail/msn/icq.

Ik ben op zich wel geinteresseerd om forensics te doen ja, zit alleen nu op mijn werk. Het wordt wel de eerste keer voor mij na wat te hebben gespeeld met die iso van de honeyney challenge, dus geen garantie.

Alvast wat tips:

Haal vast de netwerkkabel uit je systeem en laat het systeem nog even aan staan. Onder geen beding een shutdown geven, want in die runlevel scripts kunnen allerlei nare dingen zitten.

Verder moet je niet teveel op het systeem rondneuzen, want dan veranderd de access time van veel files en dat maakt de forensics weer moeilijker. Je kijkt namelijk vooral naar access time ed. van bestanden en probeert zo een tijdlijn op te zetten.

Ik neem waarschijnlijk vanavond contact met je op om te kijken hoe ik kan helpen.

[usr-local-dick]

Als je de boel weer clean hebt, dan zou ik je aanraden om op al je servers dit in je crontab te zetten:

code:

apt-get -qq update && apt-get -dqq upgrade && apt-get -sqq upgrade

Eigenlijk geef ik je hierbij BEVEL om dit te doen, het is nl. de beste manier om dit soort perikelen te voorkomen

[Confusion]

Rempage0611 schreef op 07 november 2003 @ 13:38:
Heb je dit? /dev/proc/fuckit/fk.tgz
Die had ik nml op 1 van m`n servers die dezelfe melding gaf.

Ik heb geen /dev/proc en in mijn /proc staat niets van dien aard.

[Verwijderd]

euh, ik denk aan de hand van dit topic laat ik 's ff kijken en ja hoor:

Checking `lkm'... You have 1 process hidden for readdir command
You have 1 process hidden for ps command
Warning: Possible LKM Trojan installed

hmmmz

[fetcher]

Confusion schreef op 07 november 2003 @ 13:28:
Hmmm... ik krijg ook

code:

Checking `lkm'... You have     4 process hidden for ps command
Warning: Possible LKM Trojan installed

maar ik update mijn Debian Testing toch vrijwel dagelijks. Verder heb ik niets raars gezien, in termen van schijfgebruik en netwerkstatistiek, dus ik maak me eigenlijk geen zorgen.... or should I?

/ignore
Dat is sinds kernel 2.4 het geval en normaal.

[ Voor 49% gewijzigd door fetcher op 07-11-2003 16:00 ]

[Rataplan]

usr-local-dick schreef op 07 november 2003 @ 15:47:

code:

apt-get -qq update && apt-get -dqq upgrade && apt-get -sqq upgrade

Eigenlijk geef ik je hierbij BEVEL om dit te doen, het is nl. de beste manier om dit soort perikelen te voorkomen

man apt-get:

Note that quiet level 2 implies -y, you should never use -qq without a no-action modifier such as -d (...) as APT may decide to do something you did not expect.

Niet dat ik het met je oneens ben, maar dit moet je er dan wel ff bij vermelden

[igmar]

fetcher schreef op 07 november 2003 @ 15:59:
[Dat is sinds kernel 2.4 het geval en normaal.

Da's dan wel distro specifiek, op geen enkel systeem hier kan ik dat namelijk reproduceren.

[imdos]

Of je hebt een grsec kernel of een andere gemodificeerde kernel! Ik heb dit nl. ook met mijn bak ... en ik ben vrij zeker dat deze niet geroot is!

[Confusion]

fetcher schreef op 07 november 2003 @ 15:59:
/ignore
Dat is sinds kernel 2.4 het geval en normaal.

Zo rondsurfend over het web krijg ik sterk de indruk dat je gelijk hebt.

Ter verdere informatie: ik ben even gaan zoeken en het betreft processen 3, 4, 5 en 6. Hun directories in /proc zien er als volgt uit:

code:

confusion:/proc/4# ls -l
ls: cannot read symbolic link exe: No such file or directory
total 0
-r--r--r--    1 root     root            0 Nov  7 16:26 cmdline
lrwxrwxrwx    1 root     root            0 Nov  7 16:26 cwd -> /
-r--------    1 root     root            0 Nov  7 16:26 environ
lrwxrwxrwx    1 root     root            0 Nov  7 16:26 exe
dr-x------    2 root     root            0 Nov  7 16:26 fd
-r--r--r--    1 root     root            0 Nov  7 16:26 maps
-rw-------    1 root     root            0 Nov  7 16:26 mem
-r--r--r--    1 root     root            0 Nov  7 16:26 mounts
lrwxrwxrwx    1 root     root            0 Nov  7 16:26 root -> /
-r--r--r--    1 root     root            0 Nov  7 16:26 stat
-r--r--r--    1 root     root            0 Nov  7 16:26 statm
-r--r--r--    1 root     root            0 Nov  7 16:26 status

Er is weinig bijzonders te zien. Het enige opvallende is dat 'mounts' een lijstje met mounts bevat, die met 1 verschilt van de mounts die het commando 'mount' laat zien:
rootfs / rootfs rw 0 0.

update
Ah, het begint logischer te worden. De 'status' in die directories bevat precies de namen van de volgende processen in de output van 'ps':

code:

    0 ?        SWN    0:00 [ksoftirqd_CPU0]
    0 ?        SW     0:01 [kswapd]
    0 ?        SW     0:00 [bdflush]
    0 ?        SW     0:00 [kupdated]

Kortom: er is gewoon een mismatch in de aanduiding van de kernel en ps in de PIDs. Ik weet niet waarom, maar het lijkt me niet zorgelijk.

igmar schreef op 07 november 2003 @ 16:12:
Da's dan wel distro specifiek, op geen enkel systeem hier kan ik dat namelijk reproduceren.

Systeemspecifiek en afhankelijk van de processen die je draait. Misschien dat mensen die bijvoorbeelde multi-threaded java applicaties draaien nog wel van veel meer verloren PIDs last hebben...

[ Voor 27% gewijzigd door Confusion op 07-11-2003 16:31 ]

[fetcher]

igmar schreef op 07 november 2003 @ 16:12:
[...]


Da's dan wel distro specifiek, op geen enkel systeem hier kan ik dat namelijk reproduceren.

Ow

Ik gebruik alleen maar Debian en daar heb ik het overal op
Ik heb het inderdaad niet getest met andere distro's

[Zwerver]

usr-local-dick schreef op 07 november 2003 @ 15:47:
Als je de boel weer clean hebt, dan zou ik je aanraden om op al je servers dit in je crontab te zetten:

code:

apt-get -qq update && apt-get -dqq upgrade && apt-get -sqq upgrade

Eigenlijk geef ik je hierbij BEVEL om dit te doen, het is nl. de beste manier om dit soort perikelen te voorkomen

uhmz, snap ik het nu niet?

apt-get -qq update <-- updates halen
apt-get -dqq <-- Download only - do NOT install or unpack archives
apt-get -sqq <-- No-act. Perform ordering simulation

-qq is voor geen output behalve errors, maar er wordt hier nu niet geupgrade of wel? Wel gedl'ed en gesimuleerd, maar wezenlijk geupdate zie ik hier nix worden... of snap ik het gewoon niet....

[usr-local-dick]

Zwerver schreef op 07 november 2003 @ 17:33:
[...]


uhmz, snap ik het nu niet?

apt-get -qq update <-- updates halen
apt-get -dqq <-- Download only - do NOT install or unpack archives
apt-get -sqq <-- No-act. Perform ordering simulation

-qq is voor geen output behalve errors, maar er wordt hier nu niet geupgrade of wel? Wel gedl'ed en gesimuleerd, maar wezenlijk geupdate zie ik hier nix worden... of snap ik het gewoon niet....

Voor de duidelijkheid

1. updates binnenhalen
2. download packages als dat nodig is
3. simuleer een install

De laatste stap is de magic trick! Als dit vanuit cron gedaan wordt en er zijn GEEN updates, is er totaal geen output van de cronjob.
Als er WEL updates zijn (vaak zijn dit security related updates, aangezien het nieuwste pakket in debian/stable ongeveer uit 1998 komt ) dan geeft de laatste stap wel output, en krijg je mail en je ziet wat er geinstalleerd ZOU worden. Hij doet dus nog niks!
Dus je krijgt mail van de servers die updates nodig hebben, je logt in en je doet MET DE HAND de update.

Ik zou zeggen probeer het gewoon en zie wat er gebeurt (ik kreeg vanochtend dus mail van 2 servers waar PostgreSQL op draait - van de tig andere server kreeg ik geen mail).


Ik beheer een behoorlijk aantal stable debian servers en dan moet je het jezelf makkelijk maken vindt ik

BTW ik heb een (goed gebackupte) devserver met deze crontab en die update zichzelf

code:

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11; apt-get -qq update && apt-get -dqq upgrade && apt-get -yqq upgrade

Niet aan te raden maar bij mij draait dit al bijna een jaar zonder gedoe....

[ Voor 5% gewijzigd door usr-local-dick op 07-11-2003 17:53 ]

[Zwerver]

usr-local-dick schreef op 07 november 2003 @ 17:48:
[...]


Voor de duidelijkheid

1. updates binnenhalen
2. download packages als dat nodig is
3. simuleer een install

De laatste stap is de magic trick! Als dit vanuit cron gedaan wordt en er zijn GEEN updates, is er totaal geen output van de cronjob.
Als er WEL updates zijn (vaak zijn dit security related updates, aangezien het nieuwste pakket in debian/stable ongeveer uit 1998 komt ) dan geeft de laatste stap wel output, en krijg je mail en je ziet wat er geinstalleerd ZOU worden. Hij doet dus nog niks!
Dus je krijgt mail van de servers die updates nodig hebben, je logt in en je doet MET DE HAND de update.

Ik zou zeggen probeer het gewoon en zie wat er gebeurt (ik kreeg vanochtend dus mail van 2 servers waar PostgreSQL op draait - van de tig andere server kreeg ik geen mail).


Ik beheer een behoorlijk aantal stable debian servers en dan moet je het jezelf makkelijk maken vindt ik

BTW ik heb een (goed gebackupte) devserver met deze crontab en die update zichzelf

code:

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11; apt-get -qq update && apt-get -dqq upgrade && apt-get -yqq upgrade

Niet aan te raden maar bij mij draait dit al bijna een jaar zonder gedoe....

Hmm, oke, dan pas ik mijn cron maar ff aan want:

0 * * * * /usr/bin/apt-get update &>/dev/null
0 * * * * /usr/bin/apt-get -qq -y upgrade &>/dev/null

dat staat er bij mij in

[blaataaps]

Is elk uur updaten niet een beetje veel van het goede?

[Leon]

apt-cache show cron-apt

Dit draai ik ook elke dag, hij stuurt gewoon een mailtje met hoe alles is gegaan en wat er moet worden geupdate.

Commando's die cron-apt draait kun je instellen in /etc/cron-apt/* inclusief commando's die gedraaidt moeten worden en event. extra header/footer

[ Voor 84% gewijzigd door Leon op 07-11-2003 18:32 ]

[Zwerver]

blaataaps schreef op 07 november 2003 @ 18:25:
Is elk uur updaten niet een beetje veel van het goede?

Uch... waar kwam die hoge traffic load elk uur ook al weer vandaan.... Nee hoor, gewoon foutje met C&P-en.... hij draait snachts om 0 uur alleen

[deadinspace]

code:

Checking `lkm'... You have     4 process hidden for ps command
Warning: Possible LKM Trojan installed

Die krijg ik ook op elke Debian Unstable bak die recent is geupdate (procps = 3.1.14-1) ook. Op een Debian Unstable bak die langere tijd niet is geupdate (procps = 3.1.11-2) krijg ik het niet.

Zie ook http://lists.insecure.org...basics/2003/Jul/0361.html.

[Rempage0611]

Nog even een update: openSSL was van een oude versie, nessus is af en toe toch wel eens handig om te draaien.

Nou heb ik nog een vraagje, als ik

apt-get -qq update && apt-get -dqq upgrade && apt-get -sqq upgrade && apt-get -dqq dist-upgrade && apt-get -sqq dist-upgrade

draai update ik dus ook m`n dist. Is dit ook nodig of is het niet aan te raden. Verder wordt een versie van openSSL die wel compleet dicht is niet geinstalleerd als ik mijn config op stable laat staan. Wat is dan wijsheid, alles updaten met testing sources???? Of apart deze update installeren via source??

[terrapin]

Debian patched voor stable vaak oudere releases van bijv. SSH en Apache, die daardoor een kwetsbaar versienummer lijken te hebben, maar wel gepatched zijn tegen de bekende exploits.

Dus waatschijnlijk is er geen enkel probleem, lees anders de changelog's e.d. van SSH..

[Verwijderd]

Je bent helemaal niet gehackt.
Chkrootkit is niet bepaald 100% correct met die dingen, ik heb ongeveer dezelfde meldingen van een LKM als jij, en ik krijg dit op elke box die ik probeer :-)

Fout van chkrootkit dus, niet om je zorgen over te maken.

[Rempage0611]

Verwijderd schreef op 10 november 2003 @ 11:37:
Je bent helemaal niet gehackt.
Chkrootkit is niet bepaald 100% correct met die dingen, ik heb ongeveer dezelfde meldingen van een LKM als jij, en ik krijg dit op elke box die ik probeer :-)

Fout van chkrootkit dus, niet om je zorgen over te maken.

Nou... als je met ps axf een proces [Hax0r] ziet, en fuckit mappen hebt in ene, er een 2e ssh server draait, je root ww is gewijzigt zegt dat wel genoeg denk ik.

[Ryceck]

Rempage0611 schreef op 10 november 2003 @ 11:43:
[...]


Nou... als je met ps axf een proces [Hax0r] ziet, en fuckit mappen hebt in ene, er een 2e ssh server draait, je root ww is gewijzigt zegt dat wel genoeg denk ik.

En toch is chkrootkit niet secuur

[igmar]

Confusion schreef op 07 november 2003 @ 16:25:
Zo rondsurfend over het web krijg ik sterk de indruk dat je gelijk hebt.

Het is een Debian specifiek probleem, ik kan het op systemen met een vanilla 2.4 en 2.4-grsec op 5 distro's niet reproduceren.

Er is weinig bijzonders te zien. Het enige opvallende is dat 'mounts' een lijstje met mounts bevat, die met 1 verschilt van de mounts die het commando 'mount' laat zien:
rootfs / rootfs rw 0 0.

Da's wel normaal.

Systeemspecifiek en afhankelijk van de processen die je draait. Misschien dat mensen die bijvoorbeelde multi-threaded java applicaties draaien nog wel van veel meer verloren PIDs last hebben...

Ik had er dan op dit systeem zeker last van moeten hebben. Dit is een devel bak die het altijd wel vrij druk heeft. Misschien een Debian specifieke kernel patch ? Ik kan weinig anders bedenken.

[igmar]

Confusion schreef op 07 november 2003 @ 16:25:
Zo rondsurfend over het web krijg ik sterk de indruk dat je gelijk hebt.

Ik denk dat het in de versie van fileutils / coreutils ligt. Ik draai coreutils 5.0, ivm de ACL's die op alle systemen actief zijn. Sinds 2.4.21 is de uitvoer wat gewijzigd, er staan bij de meeste processen geen commandlines meer bij. Dat zou wel eens de verschillen in uitvoer kunnen verklaren, aangezien chkrootkit de uitvoer van ps gebruikt.

[deadinspace]

igmar schreef op 10 november 2003 @ 14:42:
Misschien een Debian specifieke kernel patch ?

Nope, ik draai vanilla kernels (althans, meestal).

igmar schreef op 10 november 2003 @ 14:47:
Ik denk dat het in de versie van fileutils / coreutils ligt.

Nee, het is procps, zoals ik al schreef

[sphere]

usr-local-dick schreef op 07 november 2003 @ 17:48:
Voor de duidelijkheid

1. updates binnenhalen
2. download packages als dat nodig is
3. simuleer een install

De laatste stap is de magic trick! Als dit vanuit cron gedaan wordt en er zijn GEEN updates, is er totaal geen output van de cronjob.
Als er WEL updates zijn (vaak zijn dit security related updates, aangezien het nieuwste pakket in debian/stable ongeveer uit 1998 komt ) dan geeft de laatste stap wel output, en krijg je mail en je ziet wat er geinstalleerd ZOU worden. Hij doet dus nog niks!
Dus je krijgt mail van de servers die updates nodig hebben, je logt in en je doet MET DE HAND de update.

Hrm, beetje een omweg? Bovendien is het voor mensen die ook zo'n cron job willen draaien vast handiger om ook MAILTO te gebruiken, zodat ze niet per se mail hoeven te lezen op die bak zelf.

code:

      1 # /etc/cron.d/apt: crontab fragment for apt
      2 MAILTO=[e-mail]
      3 # Run every night at 0400 ZULU
      4 0 4     * * *     root  apt-get update > /dev/null && apt-get -yd upgrade | grep http

Cron Daemon <[e-mail]>
Date: Tue, 11 Nov 2003 04:01:17 +0100
From: Cron Daemon <[e-mail]>
To: [e-mail]
Subject: Cron <root@xxxx> apt-get update > /dev/null && apt-get -yd upgrade | grep http

Get:1 http://security.debian.org stable/updates/main epic4 1:1.1.2.20020219-2.2 [357kB]

[Verwijderd]

deadinspace schreef op 07 november 2003 @ 21:39:

code:

Checking `lkm'... You have     4 process hidden for ps command
Warning: Possible LKM Trojan installed

Die krijg ik ook op elke Debian Unstable bak die recent is geupdate (procps = 3.1.14-1) ook. Op een Debian Unstable bak die langere tijd niet is geupdate (procps = 3.1.11-2) krijg ik het niet.

Zie ook http://lists.insecure.org...basics/2003/Jul/0361.html.

Few... Ik schrok vandaag even toen ik deze melding kreeg. Toen bedaarde ik, ik dacht, dat kan niet! Ik update die bak elke dag En toen las ik dit topic... Wat mn dag weer goed maakt. Ook debian unstable.