Fórumok
Egy új wordpress támadás van mostanában, aminek nem találom a behatolási módját, hogy blokkolhassam.
A betörés onnan vehető észre egyértelműen, hogy létrejön egy wpsuadmin wordpress felhasználó, valami random előtagos gmail e-mail címmel.
A betörés nem egy konkrét WP verziót érint csak. Sajnos a legfrissebb WP verzióba is képes bejutni, akkor is, ha Wordfence telepítve van.
A kérdés az lenne, tud-e valaki többet erről a betörésről? Hogyan lehetne blokkolni? Milyen módon jut be a wordpressekbe?
Hozzászólások
Ez nem egy bővítményen át jön? Ami még előfordulhat, hogy korábbi hackekből ottmarad file-t találnak meg, és azzal intézkednek. Miután a wp-config.php -ban ott van az adatbázis file, ezért igen egyszerű egy felhasználó beszúrása.
Sikerült találnom egy olyan behatolást, ahol annyira nem használták az oldalt, hogy teljesen üres a naplófájl. És oda is bejutott.
Sajnos az apache webszervernek - tudtommal - van egy olyan hibája, hogy a naplóbejegyzéseket csak a kérelem lezárulta után helyezi el a logban, így ha sikerül hibásan eltermináltatni egy kérelmet, elérhető, hogy nem kerüljön a naplóba.
Találtál valami hasznáhatót?
Egyelőre sajnos nem. De mivel WP, gondolom többen is belefutottak innen. Nem tűnik hátrahagyott vagy le nem pucolt vírusnak sem. Ahhoz túlságosan sokféle oldalt támadott meg egyszerre. Reméltem, másnak is van tapasztalata.
ha nincs httpd log előzménye akkor én elkezdenék gyanakodni hogy valami olyan db usert szereztek meg ami hozzáfért az adatbázisához több wp oldalnak és úgy hozták létre a usereket. szerintem nincs olyan httpd req mód ami semennyi idővel később se kerül bele a logba (még ha nem is zárja le, el kell timeoutoljon)
Az adatbázisoknak nincs távoli hozzáférése, csak localhost-on van nyitva.
Amúgy szinte ugyanazon a napon nyomták fel mindet. Olyan, mintha egy adott sérülékenységgel bepróbálkoztak volna mindenhol.
Egyelőre tippem sincs, mi lehetett a módszer.
Az apache kérelemre pedig emlékem van, hogy létezik olyan, ami nem kerül naplózásra. Egyszer belefutottam, bár igaz, pár éve volt. Akár javíthatták is azóta.
A WP hackek nem ilyen kifinomultak, pláne nem, hogy ha nagyüzemi. Szerintem jó eséllyel egy friss sebezhetőséget találtak, és használtak vagy a WP-ben, vagy egy elterjedt pluginben. Az access logot átnézted? Különös tekintettel a POST kérésekre, gyanús user agentekre, illletve még mindíg lehet régen bekerült hack bármelyik php file-ba.
Mint fentebb írtam, az access log üres. Mivel php-fpm fut, a php kérelmeknek is van külön naplója. Az érdekes az, hogy az is üres.
Biztosan oda naplózik a vhost, meg azaz ftpm? Tényleg nem ekkora májerek ezek a tömeghekkek. A másik tipp, hogy nem minden oldalt törtek meg, hanem van valamilyen közös pontjuk, akár a default vhost, amin keresztül végigjárták PHP-val a filerendszert, legalábbis amit az adott felhasználó elér.
+1 én is ezt értettem ez alatt, hogy pl ami wp-ben be volt állitva mysql hozzáférés az mindenhez hozzáfért és tudtak kódot futtatni amivel az összes db-t átvizsgálták hogy van-e még olyan tábla amibe akarnak irni valamit
bitninja.io ?
Nemrég örököltem egy WP-t, minél több mindent ismerek meg benne annál inkább elborzaszt ami a marketing máz alatt van.
Zajlik már a fejlesztés amivel pár hónap múlva ki tudom dobni az egész francot woocommerce-estül, divi templétestül, 50+ telepített pluginostul ahova való, addig is kényszerből sub ezekre a szálakra...
Mivel tudod kiváltani?
Természetes drupal-al, hiszen a HUP is azon fut
Ebben a konkrét esetben - felmérve az igényeket - symfony alapra fog kerülni.
Ha azon esetleg elmarad a folyamatos frissítés és karbantartás mennyire válik sebezhetővé? Illetve jóval munkásabbnak tűnik a karbantartása, hiszen csak a keretrendszert kapod, az appot még össze kell hozni benne.
nagyságrendekkel kevéssé, mint egy wp. a keretrendszer adott, ha azt rendesen használod, akkor csak a business logicban tudsz hülyeségeket csinálni. ez ellen pedig semmi nem véd.
4 és fél éve csak vim-et használok. elsősorban azért, mert még nem jöttem rá, hogy kell kilépni belőle.
sebezhetőség: kb ahogy a fórumtárs fentebb írta
Az app összerakás és a későbbi karbantartás nem probléma, nem peremfeltétel hogy bárki, egyszerűen, könnyen, gyorsan, valódi tudás nélkül, csak néhány egyszerű kérdésre válaszolva, pár klikkeléssel, stb, stb összedobja. Sőt.
Cserébe működni fog. A jelenlegi megoldás napi szinten hátráltatja a megrendelő munkáját. Nem tudom, hogy minden telepített WP példány ilyen-e vagy csak ezt sikerült alapos akarattal így elcseszni. Bár a WP belsejét nézegetve nehéz elképzelni hogy bármi hatékony összerakható lenne ezekre az alapokra.
A frissítés azért nem árt, elnézve a changelogot: https://github.com/symfony/symfony/blob/5.4/CHANGELOG-5.4.md
Jóval több WP-t látok, igazából az elhanyagoltságuk miatt problémások, de volt már symfony-val is issue. Ha a megrendelő kifizeti a Symfonyval a többletmunkát, akkor rendben van persze.
Katt-katt és kész a csili-csálé, a szerver meg lerohad alatta, legyen az egy 1 lapos landing page, akkor is olyan CPU terhelést generál, csak pistlog az üzemeltető. Nem értem hogy lehet ennyire elcseszni valamit, de minden WP pistikének sikerül. Főleg ahogy hallom ez a divi a templatek között is a rosszabbik fajta, wp pistikék naná, hogy ezt szeretik.
Egy joomlát már átraktam Publii alá, a következő egy wp lesz. Szerencsére wp-ből közvetlenül tud importálni a Publii. Majd kiderül, hogy milyen eredménnyel.
Egy hup fórumtársunk bemutatója a témában: https://hup.hu/node/168172
Azóta fejlődött még, nagyon testre szabható és egy feltörhetetlen, atom gyors oldalt kapsz, naná: full html az egész.
Saját drupal oldalamat is Publii-ra fogom cserélni. Teljesen felesleges ritkán változó tartalmakhoz dinamikus CMS, hogy aztán a verzió frissítési görcs és a bloatware velejáróival szívjon az ember. Teljesen elég oda egy static generátor is, mint pl. a Publii
ahol tudom en is statikus html-re alakitom a wp-t.
mondjuk en wget-et hasznaltam hozza, de meg fogom nezni ezt is.
neked aztan fura humorod van...
Az Elementor is pont most vásárolt fel egy WP statikusra konveráló SW-vel foglalkozó céget, meg van még pár alternatíva ilyesmire. WP vonalon is látják azért páran, hogy ahol nincs semmi igazán dinamikus tartalomgenerálás (csak akkor változik, mikor az oldal menedzsere változtat), akkor érdemesebb statikussá alakítani, és egyszerre növekszik a biztonság és a sebesség.
sub
zrubi.hu
nincs semmi mas elerheto a szerveren? pma? cpanel?
neked aztan fura humorod van...
Ha CPanel van, akkor az egy CPanel hoszting szerver, nem csak úgy fentvan. :) A CPanel önmagában általában a kisebb probléma, sokkal inkább a mindenféle felpakolt CMS-t támadják, illetve mentett jelszóvakat malware-rel kihámozva belépnek, de ez ellen csak a 2FA véd.
Pma van, cpanel nincs. Én is arra tippeltem, hogy a pma lehetne a ludas, de azzal sokra nem mennek, ha nem ismerik az adatbázis hozzáféréseket. Azt, hogy pma-n keresztül egy wp adatbázisába bejutnak, még el tudom képzelni, de hogy tömegesen, azt már nehezen.
Azt kellene megkérdezni, hogy az előző üzemeltetőtől békességben váltak-e meg.
Még 2009-2010 tájékán squid-et raktam reverse proxy módban a webszervereink elé. Meg nem állította amikor bejöttek 0-day -el, viszont azt láttuk az access.log -ban hogy hogyan, így a plugineket ki tudtuk gyomlálni.
Ha van rá mód/keret rakj valami normális WAF szolgáltatást az oldal elé, később is jól fog jönni.
Köszönöm, az ötlet jó. Bár most hasonló céllal a mod_security modul fut, ami minden POST kérelmet naplóz, az adataival együtt. Csak ugye a baj, hogy az egyik oldalnál semmilyen apache kérelem nincs, így félő, ez esetben a proxy sem nyújtana segítséget.
Egy halvány remény, hogy úgy tűnik, ez a most log nélkül feltört oldalt már régebben is feltörték. Lehet, hogy az történt, hogy valaki begyűjtött mysql hozzáféréseket a wordpresszekből, és most hozzáfért egy oldalon keresztül a mysql-hez, és így összes hozzáféréssel létrehozott felhasználókat. Sajna nincs binlogom mysqlből, így ez marad teória egyelőre. De az is igaz, hogy wp feltörés után nem szoktak változtatni az adatbázis jelszaván, ami így nézve elég nagy baj.
Hiába változtatnak, hogy ha include('wp-config.php') -val ott lesz megint. Elég ha egy eldugott wp-content könyvtárban vagy egy pluginnél ott lesz egy file, akár úgy, hogy a file elején maradt ott az "ajándék". Nagyon el tudják rejteni ezeket a cuccokat.
A szerveren a kifelé menő kapcsolatok ugye le vannak tiltva, és csak a szükségesek engedélyezettek? Az allow_url_include -ra allow_url_fopen -re ugyanez vonatkozik. Ezeket fejlesztőék rendszerint bekapcsolják, mert nekik nagyonfontos és instant működő megoldások kellenek, hiszen semmire sincs idejük, cserébe tésztaszűrőt generálnak tetszőleges szerverből.
én hasonló okból használom a fent említett bitninja.io -t
Nálam Cloudflare van, ránézésre ez hasonló lehet. Vagy tévedek?
fixme, de a cloudflare egy proxy.
ez a cucc pedig a szerveren fut, és figyeli gyanús PHP kódok futását, ismert threat-ek mintáját letölti a központról, van benne IP black/whitelist, gyanús forrás esetén captcha, etc
nem utolsó sorban magyar fejlesztés
Jahha... az úgy más. Na, ezt pont nem találtam meg így felületes áttekerés után.
Persze most így utólag már egyértelmű :) "First of all, we check the number of system and non-system users by UID_MIN, MAX, SYS_UID_MIN/MAX, it can be defined in /etc/login.defs. Moreover, we count different users’ various folders in /home, /var/www, /var/www/vhosts"
ha apache-al szolgalsz ki, akkor van apparmor modulja, erdemes lehet beizzitani, vhostonkent lehet profilet allitani, aztan ha az adott vhostnak nemkell perl/python/bash/stb futtatas, akkor azokat szepen meg lehet fogni. persze a php scriptekre nemjo, de mivel az okossag is apparmorban fut, igy a kenyes etc/usr/var nemfer hozza. nyilvan a mysqlben turkalast nem fogja meg ez.
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Köszi, ez hasznosnak tűnik!