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

 ( Stageline | 2014. április 17., csütörtök - 13:01 )

Ü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ás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

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"
áéíóöőúüű

Mint írtam is, a támadás nem állandó. A program néha fut, néha nem. Gondolom távolról cseszegetik mit támadjon éppen. Valami botnet része lehet.
Az általad leírtak mosta azt hiszem nem segítenek, vagy csak nem volt elég szájbarágós.

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

Tegyél fel egy auditd-t, mintha az tudná valamilyen szinten logolni a hálózati forgalmat is!
(Nem 100%, hogy valóban tudja :( )

# netstat -tp | grep 50862

Utolsó oszlopban ott a pid és program neve

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

Nálam az ilyen férgek a 3. próbálkozásnál iptables rule-ba kerülnek, a hálózat whois rekordjában lévő abuse email meg kap egy értesítést logrészletekkel együtt.

fail2ban forever :)
--
PtY - www.onlinedemo.hu

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

Ha már php-fpm akkor miért nem használod a chroot funkcióját? Oda csak azt rakod ami kell, nem lesznek fölös binárisok.

--
http://pyftpadmin.earthquake.hu

Nem én telepítettem ezt a szutykot.

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.

Az egy dolog, de a fenti példában is host parancsot futtatot, amit nem biztos, hogy tud chrootban. Persze ha statikusan felmásol dolgokat akkor mindegy, de ez akkor bármire igaz lehet.

--
http://pyftpadmin.earthquake.hu

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.

Nekem nem teljesen jött át miért használja a host -ot. De itt egy kód részlet hátha okosodunk.


https://gist.githubusercontent.com/anonymous/11053151/raw/166e2258c26cd9845cd7e1126286d01dcc3878c9/hack.php

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

Szép munka! (y)

?

Ajánlom a maldet alkalmazást, jó néhány ilyen feltört CMS-be rejtőzött kéretlen "alkalmazás" fogható meg vele: https://www.rfxn.com/projects/linux-malware-detect/

@mondo: köszönöm, használom, futtattam is, nem vette észre sajnos.

A maldetnél nagyságrendekkel jobb a CXS, de az $50 / server. De valamit valamiért.

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?

Bocs, félreérthető voltam.
Persze, hogy össze lehet kötni pureftpd-vel, a saját oldalukon alapból azt támogatják. Azt akartam mondani, hogy minden más hookolható cuccba is integrálható :)

cloudlinux + cpanel (pureftpd) környezetben használom

+2

subscribe