Ahogy ígértem, belenézünk kicsit a Hacktivtiy Hack the Vendor játékának megoldásába, mindenki okulására.

Az első szemrevételezett feladat az ingyenmenet.hu klónozott oldalán történő minél több pont megszerzése volt. Hogy a szorgoskezű kattintgatók próbálkozásainak gátat szabjanak, a szervezők adminisztrátori engedélyezéshez kötötték a pontok szerzését, így a feladat lényegében adminisztrátori jogosultság megszerzése lett.

Gyengébbek kedvéért: A cikk célja, hogy bemutasson egy hack mögött rejlő gondolatmenetet. Nem a Drupalt, vagy annak valamelyik hivatalos kiegészítő modulját törtük fel. A Drupal nem lesz kevésbé biztonságos rendszer attól, mert nyílt a forráskódja, vagy mert olyan jelszóemlékeztető funkciót használ amilyet. A probléma kulcsa egy nem megfelelően implementált "házi készítésű" modul, minden egyéb puszta körülmény, amit mellesleg egy hacker adott esetben képes a saját céljára felhasználni. Ó Uram, szabadíts meg a hülyéktől!

A célpont egy Drupal alapú oldal volt, ami egy biztonsági szempontból is igen jól megtervezett rendszer, melynek alapkomponenseiben emlékeim szerint nem fedeztek fel komolyabb sebezhetőséget az elmúlt években. Ennek tudatában a támadási felületet le lehett szűkíteni a kiegészítő modulokra, melyeket nem a hivatalos fejlesztőgárda tart kézben (gyk. nem a drupal.org-on hosztolódnak, nem látta őket a biztonsági csapat stb.).

Nem kellett sokat keresgélni: az oldalsó keresőpanel az első SQL injection próbálkozásokra kézségesen szolgáltatta vissza a teljes elszállt lekérdezéseket. Innentől kezdve gyerekjáték volt kilistázni a felhasználók tábláját, benne a jelszavakkal, melyeket azonban - mint minden jó tartalomkezelő esetében - hash-elve tárolnak. 

Miután sem a helyi gépen futtatott alap szintű brute-force, sem a GI John nem hozott rövid időn belül eredményt, más megoldáson kezdtünk gondolkozni. Aikon felvetette, hogy mi lenne, ha megpróbálnánk a jelszóemlékeztető segítségével egyszerűen mi magunk beállítani a jelszót?

Hamar kerestünk egy drupalos oldalt, ahová van regisztrált fiókunk, és kértünk egy emlékeztetőt, mire a rendszer valami ehhez hasonló linket dobott a postafiókunkba:

http://drupalsite.hu/user/reset/<a>/<b>/<c>

ahol <a> és <b> ránézésre a felhasználói azonosító és egy időbélyeg (feltehetően a kiküldés pillanatának időpontja) voltak, <c> pedig egy 32 karakter hosszú hexa érték, feltehetően egy MD5 hash. Így hát, mint az őrült elkezdtünk a hash eredete után nyomozni, de ez egy olyan összetettségű rendszer esetében, mint a Drupal nem is olyan egyszerű, vagy legalábbis egész napos sörözés, meg a BalaBites felesek után kicsit nehezebben sikerült felkutatni azt a kódrészt, amit most két perc alatt megtaláltam :)

A fenti URL-ből látható, hogy a user modul végzi a jelszóvisszaállítási feladatokat, a modul könyvtárában pedig a "reset" kifejezésre keresve azonnal feltűnik a user_pass_reset_url() függvény, amely a következő képpen néz ki:

function user_pass_reset_url($account) {
  $timestamp = time();
  return url("user/reset/$account->uid/$timestamp/". user_pass_rehash($account->pass, $timestamp, $account->login), array('absolute' => TRUE));
}

Látható, hogy sejtésünk helyes volt, vagyis az első két paraméter a felhasználónév és a emlékeztetőkérés időpontja, a keresett hash-t pedig a user_pass_rehash() függvény generálja:

function user_pass_rehash($password, $timestamp, $login) {
  return md5($timestamp . $password . $login);
}
 

Ezek után nem volt más dolgunk, mint a fenti SQL injection segítségével lekérdezni a felhasználói rekordhoz tartozó pass és login értékeket, és megkondtruálni a jelszóvisszaállító URL-t.

Azaz mégsem: a pontos timestamp még hiányzik az egyenletből, de a user_pass_reset() függvény alapján úgy látszik, hogy ezt maga a rendszer is az URL-ből szedi, és csak néhány alapvető ellenőrzést hajt végre rajta. Hogy ezt a paramétert pontosan honnan szedtük eredetileg, arra őszintén szólva már nem emlékszem, de ez jó alkalom egy kis kísérletezésre :)

Végül a fenti adatok ismeretében sikerült megtalálnunk azt a paraméterhármast, amelyet a rendszer elküldött a valódi admin e-mail címére. A reset URL-t felépítve .szépen meg is jelent az új jelszót bekérő form, ahol választottunk egy igen fantáziadús jelszót magunknak :) És itt jön a tanulság: bár az adatbázishoz csak olvasási jogunk volt, ezt sikerült végül írásira váltani, hiszen pusztán olvasási műveletekkel sikerült adminisztrátori hozzáférést szereznünk. Ha a Drupal automatikusan új jelszót generálna, amit kiküldene a megfelelő e-mail címre, ez nem lenne lehetséges.

Remélem tanulságos volt a történet, még egyszer köszönjük az ingyenmenet.hu felajánlását, folytatás következik!