[Linux] Rootkit / botnet y2kupdate

[Snors]

Allen,

Iets of iemand heeft op mijn Linux Ubuntu 10.04 LTS y2kupdate geinstalleerd in de crontab. Na wat research blijkt dit een rootkit en/of een file te zijn die mijn server lid maakt van een IRC botnet.

De inhoud van de cronjob is als volgt:
* * * * * /dev/shm/emech-linux-fast/y2kupdate >/dev/null 2>&1

Als ik naar /dev/shm/ ga zie ik geen emech-linux-fast. De destbetreffende user waar de cronjob op geinstalleerd stond had was geen super user. De user is inmiddels verwijderd en daarmee de cronjob ook. Ik ben van plan om de server zo snel mogelijk opnieuw te installeren maar aangezien het om een productie omgeving gaat moet ik het tot die tijd hiermee doen. Iemand enig idee of dit voldoende is?

[LnC]

Ik ben zelf niet thuis in Linux, maar wat ik hier lees denk ik dat het voldoende is wat je al gedaan hebt.

Hier en hier nog meer leesvoer. Om er zeker van te zijn, zou ik kiezen (indien mogelijk natuurlijk ) voor een nieuwe install.

[Verwijderd]

Definieer "de crontab". Heb je het over /etc/crontab, een file in /etc/cron.d of de user crontab in /var/spool/cron/<username>?
Zo te zien bedoel je het laatste. In dat geval is het onwaarschijnlijk dat de server geroot is.

Iets/iemand heeft in elk geval met die user iets kunnen doen. Enig idee wat die user aan aanvalsvectoren had? Is het een user waaronder een webapplicatie draait? FTP user? Waar was die user allemaal voor en waarmee kon een aanvaller potentieel iets met dat useraccount doen?

[Snors]

De user had toegang tot FTP maar slechts tot 3 bestanden(gelocked in home dir en symlinks aangemaakt naar de files). Deze 3 files waren PHP files maar het desbetreffende account had niet de rechten om deze uit te voeren. Enkel om ze aan te passen. Ik heb de PHP files bekeken en er staat niks verdacht in.

De rede hoe ik hierachter ben gekomen is dat mijn webserver soms enorm traag werd op willekeurige momenten. Ik heb dus de indruk dat er wel degelijk wat met mijn server is gedaan. Wat opviel was dat de CPU & Memory usage van PERL wel hoog waren tijdens dat mijn server moeite had om inkomende http requests af te handelen...

EDIT: Wat ook opmerkelijk is dat ik de user IRC in een keer in mijn passwd zie:
irc:x:39:39:ircd:/var/run/ircd:/bin/sh

/var/run/ircd bestaat niet en nogmaals de user waarmee iets of iemand toegang heeft gehad tot mijn server had absoluut geen rechten tot /etc/passwd. Is dit een standaard gebruiker die aan wordt gemaakt tijdens de install van ubuntu 10.04 LTS? Ik heb nooit iets met IRC op deze server gedaan.. Ook staat er verder geen ircd op mijn server.

EDIT2: Volgende staat in /etc/crontab:
17 * * * * root cd / && run-parts --report /etc/cron.hourly
25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )

Ik vermoed het ergste? Een domme fout is het om inderdaad een test user met SSH rechten actief te laten staan in je systeem. Lijkt erop alsof ze toch een manier hebben gevonden om root rechten te verkrijgen..

[ Voor 48% gewijzigd door Snors op 05-11-2012 13:12 ]

[photofreak]

@ M34nM4chin3

Over het algemeen zijn er 2 maniieren hoe iemand op de 'makkelijke' manier root kan worden op je systeem.

1) Zwakke wachtwoorden,maakt niet uit of het gaat over root login op ssh of over een sudo user, allebei zijn ze in staat om als root bestanden te wijzigen.

2) Local root exploit. Er worden nog wel eens lekken in de linuxkernel of in root services gevonden, deze kunnen dan door een normale gebruiker misbruikt worden met openbare exploits om root te worden.

Het lijkt me verstandig om rootlogin op ssh uit te schakelen, sterke wachtwoorden en het liefste tokens nemen, zoveel mogelijk met de minste rechten werken, je software regelmatig updaten (sudo apt-get update && apt-get upgrade) en waar mogelijk een chroot draaien.

[Snors]

photofreak schreef op maandag 05 november 2012 @ 17:49:
@ M34nM4chin3

Over het algemeen zijn er 2 maniieren hoe iemand op de 'makkelijke' manier root kan worden op je systeem.

1) Zwakke wachtwoorden,maakt niet uit of het gaat over root login op ssh of over een sudo user, allebei zijn ze in staat om als root bestanden te wijzigen.

2) Local root exploit. Er worden nog wel eens lekken in de linuxkernel of in root services gevonden, deze kunnen dan door een normale gebruiker misbruikt worden met openbare exploits om root te worden.

Het lijkt me verstandig om rootlogin op ssh uit te schakelen, sterke wachtwoorden en het liefste tokens nemen, zoveel mogelijk met de minste rechten werken, je software regelmatig updaten (sudo apt-get update && apt-get upgrade) en waar mogelijk een chroot draaien.

Gelukkig had ik inderdaad voor andere accounts wel een sterk wachtwoord... Normalitair houd ik altijd documentatie bij van test accounts(test / test123 niet bepaald best practise). Ik ga de server dit weekend her-installeren. Thanks voor de tips allen!

[Snors]

Hmm toch vraag ik me nog af of het volgende cronscript "standaard" is deze zie ik elk uur voorbij komen in de syslog en wordt uigevoerd door root. Als ik crontab -e doe of /etc/crontab bekijk zie ik hier verder geen cronjobs geconfigureerd voor het root account:

code:

[ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -th 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) -delete)

maxlifetime ziet er als volgt uit:

code:

#!/bin/sh -e

max=1440

for ini in /etc/php5/*/php.ini; do
        cur=$(sed -n -e 's/^[[:space:]]*session.gc_maxlifetime[[:space:]]*=[[:space:]]*\([0-9]\+\).*$/\1/p' $ini 2>/dev/null || true);
        [ -z "$cur" ] && cur=0
        [ "$cur" -gt "$max" ] && max=$cur
done

echo $(($max/60))

exit 0

Zelf gevonden, is normaal :--).. Topic kan dicht!

[ Voor 16% gewijzigd door Snors op 06-11-2012 13:55 ]