Drupalgeddon - Back Door Exploit

HAL 9000 képe

Sziasztok!

Egy olyan támadásba futottam bele, amiről nehéz elhinnem, hogy igaz, annak óriási méretei miatt (100 000-800 000 oldal).

Leírom amit eddig megtudtam, mert talán Titeket is érint:

A hátsó ajtós támadás nagyon súlyos és nem csak az érintett oldalak nagy száma miatt, hanem azért is mert a támadás következtében a támadó adminisztrátori hozzáféréssel bármilyen PHP kódot futtathat, jelszavakhoz hozzáfér, fájlokat adhat a files könyvtárhoz, sorokat adhat a menu_router táblához, új admin user-eket és jogokat hozhat létre, PHP futtatására alkalmas blokkokat hozhat létre, stb..
A támadás nevet is kapott: Drupageddon vagy Druplageddon („L”-el)

    Azok az oldalak lehetnek érintettek melyek Drupal
  • 6-osok és a DBTNG modult használják,
  • 7.32-esnél vagy
  • 8 beta2-nél
  • kisebb verziószámúak voltak 2014 Október 15-én és a biztonsági figyelmeztetés bejelentését követő órákban nem frissítettek.

Azért írom ezeket a sorokat, hogy felhívjam a figyelmet a veszélyre, leírjam a gyanús jeleket, elmondjam, hogy milyen lehetőségeket ajánlanak az orvoslásra, milyen tanulsága van az esetnek és végül, de nem utolsó sorban várom a véleményeteket, tapasztalatotokat a probléma kezelésével kapcsolatban.

Gyanús jelek:
Ha a felhasználók között találsz drupaldev, system vagy configure nevűt, megauser joggal akkor fertőzött vagy! Arról nincs infóm, hogy ha nincsenek ott a fenti userek akkor tiszta-e az oldal.

Én egy drupaldev nevűt találtam , megauser joggal és formailag érvénytelen email címmel, aki aktív státuszú volt (csak én aktiválhatok) és 44 éve regisztrált! (44 éve 1970-volt)

Lehetőségek:
  • Állítsd vissza a Október 15 előtti utolsó mentésből az oldalt és azonnal frissíts.
  • Újból építsd fel az oldalt.

Fertőzött oldalnál az upgrade vagy patch nem oldja meg a problémát!

A lehetséges lépésekről itt található egy szép hosszú folyamatábra.

Tanulság:
  • Gyakori mentés
  • Azonnali frissítés
  • Verzió kontrol (GIT)
Melyik modulhoz, modulokhoz kapcsolódik a téma?: 
Fórum: 
szt képe

Azon gondolkoztam, hogy ha csak uid=1 felhasználó van, akkor is lehet-e fertőzött az oldal? A fentiek szerint: igen...

0
0
tamoca képe

Igen én nekem is 1970-es felhasználó admin vigyorog az oldalaimban.
Index.php-t átírta, egy uj sminket is feltett, stb. Tiszta agyrém. Az indexnek ezt tették be:

Azt értem, hogy frissíteni kell stb. de ennyire ajtó kapu nem volt eddig Drupal rendszer. A Kickstart2 -es oldalaimat mind feltörték...Miért pont ezeket nem tudom.
A mentést visszateszem és utána frissítek, jó kis húsvét lesz.

A fertőzött kódrészt kitöröltem, kérlek ne publikáld újra. - NeverGone -

0
0

tamoca

nevergone képe

Azért azt tegyük hozzá, hogy ez a hiba nem most került elő, hanem október közepén. Szóval ha azóta nem frissítetted az oldalaidat, akkor olyan biztonsági réseket hagyhattál nyitva, ami alapján végig kellene gondolnod az általad üzemeltett honlapok karbantartási folyamatát.

0
0
szantog képe

Miért meglepő? Évtizedeken át bevált, használt, megbízható rendszerekről derülnek ki triviálisan kihasználható biztonsági hibák.
Emberek készítik? Igen. Hibáznak? Igen. Megfelelően volt kezelve? Igen.

Egy darab feltört drupal nem volt a security release előtt az adott sechole-ra vonatkozóan!

Én amint jeleztem, hogy ilyen gáz van (ok, kis hendikepp, néhány órával a sec rls előtt), és gyorsan kijavítanám, egy rendszergazda azonnal összedobott egy scriptet, ami mind a 10+ oldalt frissítette. Hogy miért? Mert ott van bazi pirossal, hogy Highly Critical.

Neked fél évig nem volt rá időd, hogy egy szénné publikált, minden oldalról kifilézett sec hole-t befoltozz, arról nem is beszélve, hogy mekkora fail kickstartot éles oldalon alkalmazni.
Jah, és van ám update notification is drupalban, csak nem kellett volna kikapcsolni telepítéskor és/vagy ignorálni.

Szóval nehogy már a drupal hibája legyen, hogy szép kis húsvétod lesz..

4
0

----
Rájöttem, miért kérdezek olyan ritkán a drupal.hu-n. Amíg szedem össze az infokat a kérdéshez, mindig rájövök a megoldásra.