Fórumok
Sziasztok!
Nem újdonság, hogy próbálják feltörni a weboldalunkat, de a tegnapi Logwatch üzenet egy kicsit elgondolkodtatott:
--------------------- httpd Begin ------------------------
A total of 1 possible successful probes were detected (the following URLs
contain strings that match one or more of a listing of strings that
indicate a possible exploit):
/index.php?option=com_b2jcontact&view=loader&type=uploader&owner=component&bid=1&qqfile=/../../../Raiz0WorM_1620790849.php HTTP Response 200
---------------------- httpd End ------------------------- PHP log:
- - 12/May/2021:05:43:29 +0200 "POST ?option=com_b2jcontact&view=loader&type=uploader&owner=component&bid=1&qqfile=/../../../Raiz0WorM_1620790849.php" 200 /var/www/drupal/index.php 414.896 18432 69.90% - - 12/May/2021:05:43:59 +0200 "POST ?option=com_jce&task=plugin&plugin=imgmanager&file=imgmanager&method=form%22" 200 /var/www/drupal/index.php 469.983 14336 68.09%
Webszerver log:
20.98.105.13 - - [12/May/2021:05:43:29 +0200] "POST /index.php?option=com_b2jcontact&view=loader&type=uploader&owner=component&bid=1&qqfile=/../../../Raiz0WorM_1620790849.php HTTP/1.1" 200 8002 "-" "python-requests/2.25.1"
Webszerver log az érintett IP-ről: https://pastebin.com/fDgi4Mb2
Az érintett rendszer: Debian 10 + Drupal 9.1, kezdjek aggódni?
Vagy ez a támadás egy sérülékeny WP esetén lenne hatásos?
Hozzászólások
Ezek Joomla URL-nek tűnnek, se a Drupalt, se egy WP-t nem fog megtörni :)
BlackY
"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)
+1, https://vulmon.com/exploitdetails?qidtp=packetstorm_exploits&qid=915f6015abd37845cc04ff226131d726
Oldschool Computer - http://oscomp.hu
Köszönöm a linket.
Nm.
Oldschool Computer - http://oscomp.hu
Köszönöm a megnyugtató választ, én is ebben reménykedtem :)
ugy tunik fel akarja tolteni a wormot majd lefuttatni
annyit megtehetsz hogy csak annyi idore engeded a webszervert irni a documentroot ala mig frissitesz, egyebkent r/o
mondjuk ez az ellen nem ved ha a barhol mashol eltett feltoltott fajlt gondolkozas nelkul lefuttatja az engine
neked aztan fura humorod van...
Igen ezt sejtettem. Csak a 72. sorban nem értem miért 200-as a HTTP response. A 73. sorban látom, hogy próbálta meghívni, és arra már 404 a HTTP response.
Természetesen a webszerver, PHP-FastCGI és a documentroot-ban lévő fájlok, mappák mind eltérő felhasználóhoz vannak rendelve, read/write jogosultságok elvileg jól be vannak állítva. De attól féltem, hogy a Drupal adatbázisába injektálnak valamit.
Mert van index.php, nem?
https://iotguru.cloud
Egy Drupal oldalon nyilván van index.php oldal.
Nem ismerem a webszerverek működését ilyen mélységekben, de ezek szerint ha az index.php-nak POST-tal küldenek valamit, akkor az 200-as HTTP response választ küld vissza akkor is, ha nem várt POST kérést kap?
Nagyrészt igen, persze, miért ne válaszolna 200-at, ha kap egy csomó olyan paramétert, amire nem figyel? Visszaadja azt a tartalmat, amit az index.php előállít.
https://iotguru.cloud
Ok, értem.
Teljesen automatikus támadások jönnek ezrével, amelyek egy csomó szoftver ismert hibáit próbálják kihasználni. Ha mindegyiket egyenként meg akarod nézni, akkor meg fogsz őszülni. Tartsd naprakészen a rendszereidet és engedd el, hogy mennyien "támadják".
https://iotguru.cloud
Természetesen a rendszer naprakész, de ilyen üzenetet korábban nem küldött a logwatch, ezért foglalkoztam vele.
vagy okosítsd a detektáló rendszeredet, és correláld bele a szervereid vulnetrability scan eredményeit...
Azután csak akkor riaszt, ha a támadás ismert sérülékénységgel rendelkező szervert irányozna meg.
Persze ehhez kell asset DB, meg vulnerability scan is... De ez az út egy 'mature' (értsd: a gyakorlatban is működő) SOC-hoz
szerintem.
zrubi.hu
Nem azt mondom, hogy egy webszerver védelméhez elég, de a mostani helyzetben első lépésnek egy
és némi beállítás kapásból megfogja. Pl. a CRS a ../ vagy a /.. mintákat bármilyen argumentumban (GET, POST) már PL1-en blokkolja. Ha enkódolva van, akkor is.
És ez jó Nginx-hez is?
Ez, amit írtam (mármint az előre lefordított modul), nem :).
A mod_security eredetileg Apache-hoz készült, ezt a modult pár évvel ezelőtt megpróbálták Nginx-re is portolni, nem túl sok sikerrel. Úgy tudom, most a Microsoft vette "támogatása alá" a projektet. Pár éve kipróbáltam, az egész Nginx-et újra kell fordítani (sajnos ez Nginx "feature"), a modul fordítása meglehetősen körülményes, az eredmény pedig messze elmarad az Apache-nál definiált funkcióktól.
Közben pár éve elkezdték a libmodsecurity3 fejlesztését, ami - ahogy a neve is mutatja - egy WAF library, ami mod_security kompatibilis próbál lenni. Ehhez a libhez konnektorokon keresztül kapcsolódhatnak az egyes alkalmazások. Teljes értékű és stabil támogatása jelenleg csak az Nginx-nek van, ami elérhető (van HAProxy-hoz is, de az fizetős, ill LiteSpeed-hez is, ennek van opensource kiadása).
Sajnos itt is él az előző állítás: ha kell a konnektor (Nginx modul), az egészet újra kell fordítanod. A Debian-nak nincs hivatalos konnektor modulja (az Nginx karbantartót képtelenség elérni). Ha nem parázól, ezt a repository-t használhatod: modsecurity.digitalwave.hu. Amúgy az Nginx egy-az-egyben a Denian-ban (vagy Ubuntuban) levő csomag újrafordítva, csak a konnektor van hozzáadva. Minden más az aktuális master branch a Github-ról. A többi Debian/Ubuntu csomagot is részben én csinálom (mármint ami a Debianban/Ubuntuban van) :).
Szerk: a libmodsecurity3-at én nem használnám, ha nem muszáj, vagy nagyon megnézném, hová teszem. Elég sok a bug benne, nagyrészt tervezési hibák. A régi, Apache-hoz írt mod_security2-vel nem teljesen kompatibilis: sok funkció hiányzik, de van, ami ebben benne van, és nincs benne a régiben. Viszont a régi (az Apache-hoz írt) elég stabil, ez a CRS referencia rendszere.
Az Nginx-el alapvetően az a bajom, hogy nagyon fasza addig a pontig, amíg egyszerű dolgokat kell megoldani, de amint egy kicsit is komplexebb igényed van, akkor vért hugyozol és akkor se lesz teljesen jó.
https://iotguru.cloud
ha figyelembe vesszuk, hogy az nginx eredetileg proxynak irodott, es nem webszervernek, akkor ez nem is annyira meglepo :)
ugy remlik az volt a koncepcio mogotte, hogy a statikus tartalmat kiszolgalja maga sendfile-al hogy gyors legyen, minden mast meg proxyzik egy webszrevernek vagy fastcgi-nek... emiatt nem is tud tul sok mindent.
Értem, csak mindig meg kell küzdenem a dologgal, hogy párba állítják és odatesznek egy sokkalnagyobb jelet az Nginx felé, hogy az Apache szar. Nem szar az, jóval többet tud, sok dolgot egyszerűbben, de ennek ára van a teljesítmény kapcsán. És paradox módon sokszor a proxy tudás rugalmasabb az Apache esetén, leginkább a modulok miatt.
https://iotguru.cloud
szerintem az nginx hype meg abbol az idobol ered, amikor az apache mod_php-vel bohockodott, es minden statikus file kiszolgalasahoz is forkolt egy php interpretert foloslegesen, sok memoriaval. ezzel szemben az nginx csak a php fileokhoz hivott cgi-t, statikushoz meg sendfile() syscall azt jovan, onnantol a kernel intezte egyedul...
a masik ok meg a C10K problema lehet, amire az apache eleg keson reagalt, de nyilvan bonyolultsaga miatt nem is lehetett ott egyszeruen megoldani:
http://highscalability.com/blog/2013/5/13/the-secret-to-10-million-conc…
amugy ez is erdekes lehet:
http://www.eterna.com.au/bozohttpd/
meg konfig fileja sincs :)
PDF mellékleteket töltök fel a weboldalra, és észrevettem két érdekességet:
Ha pedig kitörlöm a korábban feltöltött, de a webes felületen letörölt PDF fájlt, és utána u.a. a néven megpróbálom feltölteni, akkor ezt kapom hibaüzenetben:
Egy vagy több fájlt nem lehet feltölteni.
Tehát annak ellenére, hogy nem kérem a korábbi verzió megőrzését, valahol adatbázis szinten mégis elmenti, hogy milyen nevű fájl volt feltöltve egy oldalon, és később nem enged ugyanolyan nevű fájlt feltölteni?