Kimenő HTTP POST brute force támadás wp-login.php

Fórumok

Üdv szakik!

Több ügyfelünk szerveréről változó időpontokban kifelé HTTP POST kérésekkel bombáznak különböző wp oldalakat.
A szerverről tehát kifelé mennek jelszó próbálkozások xy.com/wp-login.php címekre. Ezeket csak úgy látom, ha tcpdump-al
figyelem a kimenő hálózati forgalmat.

Kérdésem az lenne, hogy miként lehetne megtalálni azt a programot a szerveren, amely ezeket a támadásokat végrehajtja?
Nem valószínű hogy php-vel csinálják, mert a php.ini beállításaiban letiltottam az socket nyitást meg a távoli url hívásokat.
Nem lehet tehát php-vel ilyen brute force támadásokat csinálni szerintem. Valami korábbi betöréskor a szerverre másolt
program fut le időnként. Apache log ilyenkor felejtős, mert ugye POST.

Ötlet? Tapasztalat?

Hozzászólások

A crontab -ban találtam egy bejegyzést ami percenként lefuttatja a /lib/java/.../update útvonalat a /lib/java mappában találtam egy fájlt aminek a neve 0.

A programot futtatva ezt kaptam, talán valamilyen log törölgető cucc lehet.


root@xxxx:/lib/java# ./0

[~] 0x333shadow => hide your tracks version 0.1
[~] coded by nsn of outsiders ~ 0x333 Security Labs www.0x333.org [~]

Usage: ./0 [action] -i [string] -l [secs] -m [ dir1/file1 ] [ dir2/file2 ] [ ... ]

where action have to be:

-a clean all default dirs (recursive scan) you can use even -m. (include option -s, -b).
-b clean only binary (utmp, wtmp, utmpx, wtmpx, lastlog) files.

other options:

-l clean after n secs, any system can log to logout, so you exit, and it try will clean (bg mode).
-m specify more dirs or text files (if you don't specify -a, -b, -s, default dirs and logs will be skipped ...
so only dirs/files specified will be cleaned).
-i string by search, choose it with sense ;)
-s enable research other logs watching in syslogd newsyslog confs.
-h show this help.

other auto actions: read the DOCUMENTATION.
this tool watch in these directory by default:

/var/log
/var/adm
/usr/adm
/var/mail

correct use various example:

./0 -a -i string
./0 -b -i string -s
./0 -b -i string
./0 -a -i string -l 60
./0 -i string -m /var/log/messages

Egyelőre még mindig nem vagyok nagyon előrébb, kiszedtem így talán a logban is lesz végre valami info.

Ha megvan a socket, akkor netstat megmondja az usert es a pidet, ha pedig a pid is megvan a procfsbol kideritheto a programtol kezdve minden, ha ezek nincsenek elrejtve

---
Apple iMac 27"
áéíóöőúüű

Ismétlődik, vagy mindig új dolgokat próbálnak?

Amikor egy támadás zajlik, mennyi ideig tart?

Én készítenék egy scriptet, ami lementi ezeket a dolgokat, amiket figyelni próbálsz, és aztán vagy futtatod rendszeresen, pár másodpercenként vagy percenként, a támadás jellemző időtartamától függően úgy, hogy lehetőleg beleessék.

Eredményt kiírod fájlba. Futtatás gyakoriságától függően időnként (pl. logrotate-tel) betömöríted és újat kezdesz.

Amikor bekövetkezett a támadás legközelebb, akkor visszanézed a logjaidban, hogy mit látsz. Kapcsolatot, pid-et, adott piddel futó program nevét.

Vagy ha elég hosszú, akkor figyelsz, és amikor látod, akkor kézzel futtatod az információk lementését.

Van egy ilyenem, ebből hogyan lehetne megállapítani, melyik program indította a kimenő forgalmat?


14:10:49.452514 IP xxxxxxx.50862 > ns3002507.ip-37-59-5.eu.www: Flags [P.], seq 3429426485:3429426598, ack 989856173, win 46, options [nop,nop,TS val 778794191 ecr 152856443], length 113
E.....@.@.ey.q>.%;.C...P.h.5;.......Cw.....
.kt. .g{POST /the-henner/hennesystuff.php HTTP/1.0
Host: hennersy.com
Pragma: 1337
Content-Length: 13

P,0,0,0,0,47

Megoldódott.

Szóval az egyik wp oldalt törték fel a szerveren, valamilyen módon az upload mappába korábban feltöltöttek egy rakás php srciprtet ami irkált a crontab-be és használta brute force támadásra a /usr/bin/host programot.


www-data 32073 0.0 0.0 100120 2020 ? Ss 13:22 0:00 /usr/bin/host

Ami vicces hogy nem volt elég a php, php5-fpm leállítása, apache2 leállítása a hálózati forgalomban ugyan úgy ott voltak a támadások. Szóval tovább mentem és ps aux -al megnéztem mik futnak. Gyanús volt hogy folyamatosan megy a /usr/bin/host és nyomtam a PID -re egy lsof-ot ami az alábbi eredményt hozta:


host 32073 www-data cwd DIR 8,2 4096 15646785 /var/www/clients/client0/web6/web/wp-content/uploads
host 32073 www-data rtd DIR 8,2 4096 2 /
host 32073 www-data txt REG 8,2 120328 17285492 /usr/bin/host
host 32073 www-data mem REG 8,2 22928 10887277 /lib/libnss_dns-2.11.1.so
host 32073 www-data mem REG 8,2 51712 10887287 /lib/libnss_files-2.11.1.so
host 32073 www-data DEL REG 8,2 4177923 /var/www/clients/client0/web6/web/wp-content/uploads/.sd0
host 32073 www-data mem REG 8,2 534832 10887322 /lib/libm-2.11.1.so
host 32073 www-data mem REG 8,2 18704 10887979 /lib/libattr.so.1.1.0
host 32073 www-data mem REG 8,2 30840 10485840 /usr/lib/libisccc.so.60.0.0
host 32073 www-data mem REG 8,2 92752 10887906 /lib/libz.so.1.2.3.3
host 32073 www-data mem REG 8,2 93000 10887269 /lib/libresolv-2.11.1.so
host 32073 www-data mem REG 8,2 10224 10887885 /lib/libkeyutils-1.2.so
host 32073 www-data mem REG 8,2 14696 10887291 /lib/libdl-2.11.1.so
host 32073 www-data mem REG 8,2 31168 10485871 /usr/lib/libkrb5support.so.0.1
host 32073 www-data mem REG 8,2 14584 10887928 /lib/libcom_err.so.2.1
host 32073 www-data mem REG 8,2 154048 10485781 /usr/lib/libk5crypto.so.3.1
host 32073 www-data mem REG 8,2 803192 10485868 /usr/lib/libkrb5.so.3.3
host 32073 www-data mem REG 8,2 209272 17369297 /usr/lib/libGeoIP.so.1.4.6
host 32073 www-data mem REG 8,2 1588616 10887305 /lib/libc-2.11.1.so
host 32073 www-data mem REG 8,2 1372344 17368201 /usr/lib/libxml2.so.2.7.6
host 32073 www-data mem REG 8,2 135745 10887283 /lib/libpthread-2.11.1.so
host 32073 www-data mem REG 8,2 18888 10887280 /lib/libcap.so.2.17
host 32073 www-data mem REG 8,2 339464 10485864 /usr/lib/libisc.so.60.1.4
host 32073 www-data mem REG 8,2 120640 10485842 /usr/lib/libisccfg.so.60.0.2
host 32073 www-data mem REG 8,2 47048 10485848 /usr/lib/libbind9.so.60.0.1
host 32073 www-data mem REG 8,2 1626400 10887289 /lib/libcrypto.so.0.9.8
host 32073 www-data mem REG 8,2 213784 10485866 /usr/lib/libgssapi_krb5.so.2.2
host 32073 www-data mem REG 8,2 1538568 10485846 /usr/lib/libdns.so.64.1.0
host 32073 www-data mem REG 8,2 71752 10485844 /usr/lib/liblwres.so.60.0.0
host 32073 www-data DEL REG 8,2 15646921 /var/www/clients/client0/web6/web/wp-content/uploads/libworker.so
host 32073 www-data mem REG 8,2 136936 10887292 /lib/ld-2.11.1.so
host 32073 www-data 0r CHR 1,3 0t0 1364 /dev/null
host 32073 www-data 1r CHR 1,3 0t0 1364 /dev/null
host 32073 www-data 2r CHR 1,3 0t0 1364 /dev/null
host 32073 www-data 3r CHR 1,3 0t0 1364 /dev/null

Nem bírtam kinyomni killall -9 -el a 32073 folyamatot, ezért rebootoltam. A programokat lementettem és letöröltem a gépről. Érdekes, szeretnék én is annyi IQ-t mint amennyi annak van aki ezt a programot megírta így ebben a formában :-)

Miért ne lehetne? PHP hívhat külső binárist is, arra meg nem hat a php.ini.
Inkább eltávolítani kéne az ártó kódot a szerverről, és megakadályozni, hogy újra bejusson a támadó.

update update update

Aztán megfelelő védelmi beállítások.
--
PtY - www.onlinedemo.hu

Még annyit hozzátennék, hogy én hiába tiltottam le utólag a php.ini-ben a system, exec stb.. függvények használatát, ez a szar már akkor is futott és mivel nem php processzként ment hiába is indítgattam újra a php -t meg az apache-t. :D

@PtY ez így kb. pont ki is üti a javaslatod mert ezen a szerveren fut fail2ban

Sajnos egyre több az "önmódosító" szarkupac php program, ami elvárja, hogy saját magát tudja frissíteni (ergó nem lehet elszeparálni a végrehajtható és az írható könyvtárakat). A lájtosabb cms rendszerek csak "melegen ajánlják", hogy adjál nekik írásjogot saját magukra, de vannak olyanok, amik konkrétan nem is telepíthetőek adminként, cli-ből, hanem ragaszkodnak az elbaszott kis megoldásukhoz.
Na innentől kezdve chrootolhatod, ahová akarod, felmásol magának mindent a betörő php-ban, és azt csinál, amit akar.

A host parancs használata csak a balfasz programozó miatt van. Simán tudná ugyanazt php-ból natívan is csinálni, még fel sem kell másolni binárist. Az se működik, hogy letiltogatod a megfelelő php függvényeket, mert ugyanúgy nem fognak menni azok a programok, amik a netről szeretnék magukat frissíteni, mintha nem kapnának írásjogot.

Az egész önmódosító php-s koncepció alapvetően van elbaszva.

A fail2ban arra való, hogy azokat a próbálkozásokat, amik a gépedről mennek kifelé, a túloldal megfogja.
Az meg nagyon nem mindegy, milyen filtert csinálsz a fail2ban-re. Alapbeállításokkal nem fog ilyesmit megfogni, ahhoz elég jó rule-t kell összerakni, hogy minden ilyen jellegű támadásra ugorjon.
Szóval az eszköz önmagában kevés...

Hogy egy hasonlattal éljek: lehet fogni nyulat egy darab dróttal is, de ha csak leteszed a drótot az erdőszélen, ahogy a boltban vetted, akkor sosem fogsz nyulat.
--
PtY - www.onlinedemo.hu

Leggyakrabban ezek ugy nonek oda, hogy a PHP-bol elindit egy Perl programot pl exec-kel es az csinalja a csunyasagokat. Alaposan nezd vegig a processlistadat.

Plusz eso utan koponyeg, de ezt majd kergesd vegig a PHP-don, nezd meg mit mond a biztonsagi beallitasokra. (Disclaimer: az en munkam)

@janoszen: szép munka, megnézegettem. Nálam ez annyira nem játszik, mert mint fentebb írtam ezt a gépet nem én telepítettem, én mindig csak a szart lapátolom mások után. Természetesen az első amikor jelezték a szolgáltatók a támadást az én szolgáltatómnak (ügyfél szolgáltatójának) azonnal letiltogattam azokat amiket a te scripted is aján letiltani. De ekkor már futott sajnos nem apache és nem is php processzként ez az attack script (/var/www/clients/client0/web6/web/wp-content/uploads/.sd0). Ezért találtam érdekesnek az egészet. Gyk. hülyét csinált belőlem :D

Te használod? Mit lehet tudni róla? Mit takar a "nagyságrendekkel jobb" kifejezés? Komolyan kérdem, átolvasva a főoldalt, feltűnt, hogy talán gondom lehet vele Debian alatt, valamint Proftpd-t sem ír, csak Pure-FTP-t. Használunk maldetet pár olyan szerveren, ahova simán megengedhető lehet ez a kb. 12e Ft-os kiadás, csak nem "jön át" ez a nagy különbség, így a kérdés komoly: miben tud ez többet/jobbat, mint a Maldet?

Igen, használom.

Szerintem simán besorolható a bevált kategóriába. Korrektül testreszabható hogy miket ellenőrízzen és miért szóljon, saját patterneket könnyű hozzáadni és commitolni, stb.

Az a tapasztalat, hogy a maldet csomó mindent nem ismert fel amit a cxs igen, és ahogy elnézem normálisan karbantartott, frissentartott a db-je.

A pure-ftp-n kívül mindenbe "be lehet tenni" amiben hookolható a feltöltés.

Ha kell, akár azért is tud szólni, ha régi egy CMS verzió, stb.
Elvileg kezel Inotify-t, de ezzel kapcsolatban nincs személyes tapasztalatom.

Össze lehet kapcsolni a pure-ftp -vel is.


# If your pure-ftpd has been compiled with pure-uploadscript support,
# this will make pure-ftpd write info about new uploads to
# /var/run/pure-ftpd.upload.pipe so pure-uploadscript can read it and
# spawn a script to handle the upload.
# Don't enable this option if you don't actually use pure-uploadscript.

CallUploadScript yes

Milyen környezetben használod a cxs-t?