Ingebroken op server

[jurp5]

Vandaag kwam ik erachter dat er ingebroken was op een webserver die ik beheer.
Er draaiden een aantal vreemde processen svwar.py (https://code.google.com/p/sipvicious/wiki/Svwarusage)
en er was een map aangemaakt in /tmp en 5 tgz bestanden.



code:

drwxr-xr-x  3 www-data www-data    4096 2011-02-06 19:03 aloha
-rw-r--r--  1 www-data www-data 1668079 2011-01-29 05:24 test.tgz
-rw-r--r--  1 www-data www-data 1668079 2011-01-30 15:41 test.tgz.1
-rw-r--r--  1 www-data www-data 1668079 2011-01-30 15:41 test.tgz.2
-rw-r--r--  1 www-data www-data 1668079 2011-01-30 15:41 test.tgz.3
-rw-r--r--  1 www-data www-data 1668079 2011-01-30 15:41 test.tgz.4

Inhoud van de map aloha:

code:

-rwxr-xr-x 1 www-data www-data     4834 2008-08-10 09:20 Changelog
-rwxr-xr-x 1 www-data www-data      553 2010-07-30 15:19 doit.sh
-rwxr-xr-x 1 www-data www-data       46 2010-07-30 16:03 end.sh
-rwxr-xr-x 1 www-data www-data    12175 2008-08-10 09:20 fphelper.py
-rwxr-xr-x 1 www-data www-data    12452 2009-08-20 22:54 fphelper.pyc
-rw-r--r-- 1 www-data www-data  1050898 2010-07-02 10:01 GeoIP.dat
-rwxr-xr-x 1 www-data www-data      117 2010-07-30 14:44 geoip.pl
-rwxr-xr-x 1 www-data www-data    12288 2008-08-20 17:36 groupdb
-rwxr-xr-x 1 www-data www-data    35886 2008-08-10 09:20 helper.py
-rwxr-xr-x 1 www-data www-data    35300 2009-08-20 22:54 helper.pyc
-rw-r--r-- 1 www-data www-data    94993 2010-12-02 18:33 inc.txt
-rwxr-xr-x 1 www-data www-data      660 2010-07-30 17:23 ip.sh
-rwxr-xr-x 1 www-data www-data      337 2010-07-30 17:23 ip.sh~
-rwxr-xr-x 1 www-data www-data        2 2008-08-20 13:18 log
-rwxr-xr-x 1 www-data www-data      424 2010-07-30 17:23 mail_test.sh
-rwxr-xr-x 1 www-data www-data      420 2010-07-30 17:23 mail_test.sh~
-rw-r--r-- 1 www-data www-data       21 2010-08-31 22:16 mail_to.txt
-rw-r--r-- 1 www-data www-data   925540 2010-12-02 18:42 parole.txt
-rwxr-xr-x 1 www-data www-data     4298 2008-08-10 09:20 pptable.py
-rwxr-xr-x 1 www-data www-data     4960 2009-08-20 23:31 pptable.pyc
-rwxr-xr-x 1 www-data www-data    14052 2010-07-30 13:52 pygeoip.py
-rw-r--r-- 1 www-data www-data    14117 2010-07-30 13:52 pygeoip.pyc
-rwxr-xr-x 1 www-data www-data     1361 2008-08-10 09:20 README
-rwxr-xr-x 1 www-data www-data     4229 2008-08-10 09:20 regen.py
-rwxr-xr-x 1 www-data www-data     4068 2009-08-20 22:54 regen.pyc
-rw-r--r-- 1 www-data www-data    17982 2011-02-07 00:58 results.txt
-rwxr-xr-x 1 www-data www-data   249980 2009-12-07 20:12 screen
-rw-r--r-- 1 www-data www-data 83914752 2011-02-07 01:13 .sipviciousrandomtmp
-rw-r--r-- 1 www-data www-data       29 2011-02-06 19:03 srand
-rwxr-xr-x 1 www-data www-data   110592 2011-02-06 19:03 staticfull
-rwxr-xr-x 1 www-data www-data   282624 2011-02-06 19:03 staticheaders
-rwxr-xr-x 1 www-data www-data    21834 2010-07-30 14:28 svcrack.py
-rwxr-xr-x 1 www-data www-data     9159 2008-08-10 09:20 svlearnfp.py
-rwxr-xr-x 1 www-data www-data    22045 2008-08-20 13:28 svmap.py
drwxr-xr-x 6 www-data www-data     4096 2008-08-10 09:20 .svn
-rwxr-xr-x 1 www-data www-data     8285 2008-08-10 09:20 svreport.py
-rwxr-xr-x 1 www-data www-data    24458 2008-08-19 20:21 svwar.py
-rwxr-xr-x 1 www-data www-data      749 2008-08-10 09:20 sv.xsl
-rwxr-xr-x 1 www-data www-data      308 2008-08-10 09:20 THANKS
-rwxr-xr-x 1 www-data www-data       80 2008-08-10 09:20 TODO
-rwxr-xr-x 1 www-data www-data    45056 2008-08-20 17:37 totag
-rwxr-xr-x 1 www-data www-data      216 2010-07-30 13:52 t.py
-rw-r--r-- 1 www-data www-data   925540 2010-12-02 18:39 users.txt

Het lijkt erop dat er ergens een lek script op de webserver staat..

Alleen het rare is dat ik nergens precies terug kan halen hoe ze de server binnengekomen zijn.

Mijn grootste vermoeden is phpmyadmin, omdat ik een aantal keren in het error log een wget voorbij zie komen, en enkele seconden ervoor er een get/post naar /phpmyadmin/scripts/setup.php wordt gedaan.

Voorbeeld:
access log:

code:

*knip*:94.63.246.3 - - [23/Jan/2011:21:26:05 -0800] "GET /phpmyadmin/scripts/setup.php HTTP/1.1" 200 15224 "http://www.*knip*/phpmyadmin/scripts/setup.php" "Opera"
*knip*:94.63.246.3 - - [23/Jan/2011:21:26:06 -0800] "POST /phpmyadmin/scripts/setup.php HTTP/1.1" 200 486 "http://www.*knip*/phpmyadmin/scripts/setup.php" "Opera"

error.log:

code:

[Sun Jan 23 19:51:30 2011] [error] [client 208.80.194.29] request failed: error reading the headers
--21:26:08--  http://vt.pen.go.kr/webEdit/data/CVS/a.txt
           => `a.txt'
Resolving vt.pen.go.kr... 211.182.237.130
Connecting to vt.pen.go.kr|211.182.237.130|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 9,204 (9.0K) [text/plain]
a.txt: Permission denied

Cannot write to `a.txt' (Permission denied).
mv: cannot stat `a.txt': No such file or directory
[Sun Jan 23 22:30:52 2011] [error] [client 67.205.93.21] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)

Ditzelfde patroon heb ik al een aantal keren kunnen herkennen (wget in errorlog, 2 sec ervoor post in phpmyadmin)

Het vervelende is ook dat het hier om een server met Plesk gaat, de accesslog komt van een vhost vandaan, en de wget stond in de 'algemene' error.log, maakt het niet echt duidelijker.

Het rare is dat het om phpMyAdmin 2.9.0.2 gaat en ik nergens een exploit kan vinden die tot php/shellcode execution in staat is..

Wat denken jullie hiervan?

[Freezerator]

Welke software pakketten draai je nog meer?

Maak in het vervolg je tmp directory zonder excute rechten. De get/post zou normaal nog een extra stuk code moeten bevatten waarmee ze de daadwerkelijke aanval uitvoeren. Dit kan je vaak ook afvangen met mod_security.

[jurp5]

Freezerator schreef op maandag 07 februari 2011 @ 12:34:
Welke software pakketten draai je nog meer?

Maak in het vervolg je tmp directory zonder excute rechten. De get/post zou normaal nog een extra stuk code moeten bevatten waarmee ze de daadwerkelijke aanval uitvoeren. Dit kan je vaak ook afvangen met mod_security.

Plesk 8.4.0
Php 5.2.0 (ik weet dat die ook vrij outdated is)
Apache/2.2.3
Courier Imap

Maar zo te zien in de logs zijn ze binnengekomen via apache.

Ik denk dat die execute rechten niet zoveel uitmaken, omdat ik zag dat de scripts gewoon via de python interpreter gestart werden, ook wget en bashscripts hoe je hier dus niet mee tegen.

De inhoud van postrequests wordt niet gelogged. Ik denk dat de get request vooraf alleen een controle was/het ophalen van een sessiecookie?

[Freezerator]

Ik bedoelde welke pakketjes zoals een joomla, phpbb en dergelijke. Vaak zijn dat de pakketjes die als 1e gekraakt worden. Als je niet uit de access log al de aanval kan filteren wordt het lastig. Beste is imo een complete reinstall ivm eventuele backdoors.

Het noexec maken van je /tmp dir is een simpele maatregel tegen de geautomatiseerde scriptjes.

[jurp5]

Freezerator schreef op maandag 07 februari 2011 @ 13:15:
Ik bedoelde welke pakketjes zoals een joomla, phpbb en dergelijke. Vaak zijn dat de pakketjes die als 1e gekraakt worden. Als je niet uit de access log al de aanval kan filteren wordt het lastig. Beste is imo een complete reinstall ivm eventuele backdoors.

Het noexec maken van je /tmp dir is een simpele maatregel tegen de geautomatiseerde scriptjes.

Het enige wat er op draait qua pakketjes is phpmyadmin..

Ik denk inderdaad dat een reinstall het beste is, maar zou graag erachter willen komen wat de precieze oorzaak is..

[Verwijderd]

Kun je niet een log inschakelen op je poort 80? Zodat hij alle inkomende/uitkomende connecties in een log-bestand plaatst. ( Ik meen dat die standaard ingeschakeld staat ).

Maargoed, een reinstall is niet nodig. Verwijder die bestanden, en sluit even uit hoe hij erin is gekomen. En update je systeem evt. voor de zekerheid

[ Voor 46% gewijzigd door Verwijderd op 07-02-2011 13:48 ]

[daft_dutch]

jurp5 schreef op maandag 07 februari 2011 @ 12:30:
Het rare is dat het om phpMyAdmin 2.9.0.2 gaat en ik nergens een exploit kan vinden die tot php/shellcode execution in staat is..

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5718

[Thralas]

@ Hierboven: Moet je wel de juiste advisory linken, ipv. een stokoude XSS(!) vulnerability in phpMyAdmin.

TS, je hebt al het 'bewijs' gevonden, maar durft de conclusie niet te trekken. Dat is toch echt de manier waarop ze zijn binnengekomen, via een lekke setup.php van phpMyAdmin.

Juiste exploit: http://www.exploit-db.com/exploits/8921/

Zo te zien hebben ze een SIP scanner gedownload. Lijkt mij een redelijk specifieke payload, mogelijk was dat alles. Mag je zelf even afwegen of je wilt reinstallen (immers, iedere compromise betekent dat je in theorie ook een rootkit te pakken zou kunnen hebben)...

[daft_dutch]

Thralas schreef op woensdag 09 februari 2011 @ 00:27:
@ Hierboven: Moet je wel de juiste advisory linken, ipv. een stokoude XSS(!) vulnerability in phpMyAdmin.

Het is een exploit in de versie van phpmyadmin die de TS heeft. Als er dan een nieuwe versie wordt gemaakt en aangeraden wordt te upgraden. Kan men begrijpen dat er voor de reeds onveilige versie geen nieuwe vulnerabilities worden gerapporteerd. Dan kan je blijven rapporteren en maak je de ontwikkelaars niet echt blij mee.

Het is dus een reactie op zijn statement dat er geen vulnerability voor zijn versie kon vinden. Niet dat dit de expliciete exploit was die gebruikt is.