Tweets by @buherablog
profile for buherator at IT Security Stack Exchange, Q&A for IT security professionals

A BitBetyár Blog

Túljártál a nagyokosok eszén? Küldd be a mutatványodat! (e-mail a buherator gmailkomra jöhet)

Full-Disclosure / Névjegy / Coming out


Promó

H.A.C.K.

Címkék

0day (110) adobe (87) adobe reader (21) anonymous (26) apple (60) az olvasó ír (49) blackhat (20) botnet (22) bug (200) buherablog (44) buhera sörözés (39) bukta (49) deface (38) dns (22) dos (29) esemény (82) facebook (26) firefox (64) flash (33) gondolat (31) google (59) google chrome (36) hacktivity (37) hírek (117) incidens (224) internet explorer (88) iphone (35) java (50) jog (22) kína (21) kriptográfia (68) kultúra (21) linux (24) malware (43) microsoft (142) móka (48) mozilla (23) office (26) oracle (40) os x (43) patch (197) php (20) politika (31) privacy (58) programozás (22) safari (34) sql injection (62) windows (85) xss (77) Címkefelhő

Licensz

Creative Commons Licenc

Ingyenmenet - Nem dodzsem!

2009.09.26. 13:08 | buherator | 39 komment

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!

Címkék: hacktivity drupal sql injection ingyenmenet hu

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

P1ngW1n 2009.09.26. 15:25:31

"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"

Szintén benne volt az adatbázisban, szóval ugyan úgy, ahogy a hash kikértétek ki lehetett kérni ezt a timestamp-et is :)

matx 2009.09.26. 18:00:14

thumbs up! grat, derek munka =)

gphilip · http://search-download.com 2009.09.26. 18:04:14

Szép...

Más kérdés, hogy a többi - nevesebb - szponzor mennyire díjaz egy ilyet, és ez mennyire árt a rendezvény jövőjét illetően...

Update-re nem adott lehetőséget az injection?

buherator · http://buhera.blog.hu 2009.09.26. 18:11:17

@gphilip: az amit megtaláltunk nem, egyébként nem szarakodtunk volna ennyit :)

buherator · http://buhera.blog.hu 2009.09.26. 18:12:44

@gphilip: Ja, nevesebb szponzorok közül pl. a McAffee/DNS Hungary-ról is lesz majd hasonló poszt. Ők szerintem már azt a kategóriát képviselik, ami példaként állhat a támogatók előtt.

gphilip · http://search-download.com 2009.09.26. 18:17:18

Abszolút, nem a poszttal van a gond! A megoldás is jó, bár nem túl izgi - injection... Reménykedtem egy jó kis xss-es session lopásban.

A gond az, hogy pl lehet, hogy a Microsoft jövőre nem adja a nevét egy prostikkal foglalkozó oldal mellé... :-(

buherator · http://buhera.blog.hu 2009.09.26. 18:30:38

@gphilip: Nem is az injection volt a lényeg :) XSS akkor működött volna, ha minimum van egy aktív admin jogú felhasználó, de nem erről volt szó. Amelyik gyártó meg emiatt nem adja a nevét jövőre...annak nagyon rosszul működik a PR szakosztálya!

gphilip · http://search-download.com 2009.09.26. 18:44:30

Jahm, a beharangozónál még nem tudtam, hogy egy klónt kellett törni - nem voltam Hacktitity-n sajnos. Milyen jó példa, hogy egy klón nem reprezentálja jól egy site sebezhető pontjait.

Én speciel nem hirdetnék egy ilyen tematikájú oldallal egy rendezvényen, szerintem ezt a fajta presztízskonfliktust nem szabad lebecsülni, jövőre jobban kell szűrni a támogatókat.

Sajnos nem a kisujjamból szoptam, belső MS infó, hogy ezt nem kimondottan csipázták, de szerintem a többi nagy sem... :-)

De nem gond, ennek a posztnak nem is ez volt a lényege...

P1ngW1n 2009.09.26. 20:33:33

A computerworld cikke se véletlenül említi meg az alábbit:
"Egy Hacktivity-n ugyanis követelmény a lazaság és a közvetlenség"

Forrás: computerworld.hu/hacktivity-2009.html

Tény, hogy a Hacktivity-n javallta oldottabban zajlanak az események ( pláne az esti sörözgetés ), mint egy normál öltönyös rendezvényen. És ez szerintem jól is van így.. Ha ez most a többi támogató szemét csípi, akkor nézze meg még1x, hogy hova került..

Személyes véleményem amúgy, hogy ez a fajta esti kikapcsolódás meg bőven belefért.. Jóka lel lehetett hülyülni, és közben ment a brainstorming is nem gyengén

llyes Edit (törölt) 2009.09.26. 22:50:16

"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.

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. "

Ez egy elég félrevezető leírás. Az oldalsó keresőpanelt nem egy kiegészítő modullal állították elő -- én legalábbis az utóbbi években nem láttam olyan kiegészítőt, ami nem a Drupal alapcsomag részét képező, nagyon biztonságos Form API-t használta.

Ez egy Drupal alapú oldal, amihez amatőrök nulla hozzáértéssel odatoldottak valamit. Ilyen alapon azt is lehetett volna írni, hogy feltörtünk egy PHP-alapú, vagy MySQL-alapú, vagy Apache által kiszolgált, stb. rendszert.

llyes Edit (törölt) 2009.09.26. 23:01:28

Pontosítanék: tehát a Drupal világban "kiegészítő modulnak" a drupal.org-on közzétett modulokat nevezik. Az oldalsó panelt nagy valószínűséggel nem egy ilyen modul állítja elő, hanem egy egyedi fejlesztés, amit "saját modul"-nak szoktunk nevezni, megkülönböztetendő a drupal.org-ról letölthető komponensektől.

nevergone 2009.09.26. 23:58:49

Illyés Edit: Mondjuk ez tényleg nem mindegy.

_2501 2009.09.27. 03:02:35

Kedves Edit... :)

A szöcske és a sáska elkülönítése igen könnyű feladat, mégis sokan összetévesztik őket. Az egyetlen döntő különbség az, hogy a sáska csápjai rövidek, míg a szöcskének hosszabbak mint a test fele, de gyakran még ennél is hosszabbak lehetnek. További lényeges eltérés amit érdemes megemlíteni, hogy a szöcskék között vannak ragadozó fajok, amik meglepetést okozhatnak nekünk a begyűjtés során. Életmódjuk hasonló a sáskákéhoz, ezért az ő begyűjtésük is kézzel a legcélszerűbb. A nagytestű ragadozó fajok, mint például a Zöld lombszöcske (Tettigonia viridissima) vagy a Szemölcsevő szöcske (Decticus verrucivorus) fájdalmasan megharaphatják az embert, ezért érdemes őket hátulról közvetlenül a tor felől megfogni. A másik probléma a ragadozó étrendű szöcskékkel, hogy a tároló dobozban megehetik fajtársaikat vagy más begyűjtött fajokat, ennek kiküszöbölésére érdemes ilyenkor még több növényt tenni melléjük vagy egyesével elhelyezni őket.

Tisztelettel,
_2501

llyes Edit (törölt) 2009.09.27. 09:45:08

@_2501: Na jó, de azért egy entomológistától elvárható, hogy felismerje, itt nem szöcskével hanem sáskával van dolga. :)

Elég belenézni a HTML forráskódba, azonnal látszik, hogy a kérdéses oldalsó panelt a közmondásos "szomszéd Pistike" készítette és nem egy magára valamit is adó Drupal fejlesztő.

EQ · http://rycon.hu 2009.09.27. 12:24:33

csak a felvilágításom kedvéért: vannak-e a neten olyan drupal modulok amik nem a hivatalos fejlesztőgárda termékei, viszont bárki használhat egy letöltés és patchelés után?

nevergone 2009.09.27. 12:56:30

EQ: Miért kellene patchelni őket? A drupal.org/project/modules oldalon találsz olyan modulokat, amelyek külső fejlesztők művei és letölthetőek.
A "hivatalos fejlesztőgárda" kifejezést nem értem pontosan, bárki küldhet be pl. javítást, ha az megfelelő minőségű és átmegy a tesztetek, bekerülhet a hivatalos változatba.

Szántó Gábor · http://choirs.oftheworld.club 2009.09.27. 13:00:56

@EQ: A kiegészítő modulok nagy részét nem a "hivatalos" fejlesztőgárda készíti.

_2501 2009.09.27. 13:01:36

@Edit: "Delfin vagy Eszkimó, nem mindegy? Hal-hal. " -Eric Cartman
Nem olyan nagy baj az ha nem veszünk el a részletekben.

nevergone 2009.09.27. 13:33:20

_2501: Azért fontos, hogy "elvesszünk a részletekben", mert egy olyan ponton történt a betörés, amelyet házibarkács jelleggel, különösebb hozzáértés nélkül készítettek el. A drupal.org-ról letölthető külső modulok sem mindig a legbiztonságosabbak, de ott azért van némi ellenőzés és visszajelzés, van issue-tracker rendszer, stb.
Szóval a kettő mégsem ugyanaz a kategória.

buherator · http://buhera.blog.hu 2009.09.27. 13:37:42

@Illyés Edit: Had emeljek ki néhány részt az általad idézett szövegbő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_."

Elnézést, nem vagyok olyan szinten jártas a Drupal terminológiában (főleg a magyarban nem) mint te, de ez a poszt egyrészt nem a Drupalról szól, másrészt azt hiszem mindenki számára egyértelmű, hogy itt egy "saját modulról" van szó (amely megnevezés szintén félrevezető lehet, hiszen azt a modult sem én írtam :P). Hogy véletlenül se gázoljak a Drupal közösség lelkébe, azért kiírok egy pontosítást.

llyes Edit (törölt) 2009.09.27. 14:11:04

@buherator: Azért tartottam szükségesnek a pontosítást, mert pár órán belül 2 helyen is blogmarkolták a cikket, mindkét helyen "feltörték a Drupalt" vagy hasonló szöveggel. Még a szakmabelieknek sem volt egyértelmű, miről van szó. Ez az ő hibájuk, nem a tiéd, de attól még jó tisztázni.

Kiegészítő moduloknak ezeket nevezzük: drupal.org/project/modules Ahogy nevergone írta, ezek nem "hivatalos" modulok, de általában jó színvonalúak. A webhelyen megjelenő "lyukas" űrlapot nem ezen modulok egyikével állították elő, ráadásul a fejlesztés során a Drupal űrlapkezelőjét is hanyagolták, ami nagyon alapvető hiba. Az egésznek a Drupalhoz gyakorlatilag semmi köze, bármelyik rendszerbe be lehet tolni egy olyan programot, ami sebezhetővé teszi.

EQ · http://rycon.hu 2009.09.27. 14:27:47

szerintem a "támadó" félnek illene megint elolvasni amit "támad", majd elgondolkozni és "betámadni" azokat akik szarul vették át a cikket, és ott javítani az emberi hülyeségen. És nem véletlen volt ""-ben ami benne volt.

nevergone 2009.09.27. 14:38:31

EQ: szerintem nincs itt semmiféle "támadás", csak igény arra, hogy pontosabb legyen a cikk, mert a pontatlanság tényleg komoly félreértésekre adhat okot. Szerencsére ez a pontosítás megtörtént (köszönet érte buherátornak), és így a Drupalt nem ismerők számára is érthetőbb lett a helyzet.

buherator · http://buhera.blog.hu 2009.09.27. 14:41:17

@Illyés Edit: Linkeket tudsz mutatni?

A Drupalt egy biztonsági szempontból is nagyon jó rendszernek tartom, komolyan bánnám, ha miattam esne csorba a hírnevén.

buherator · http://buhera.blog.hu 2009.09.27. 14:56:37

@Illyés Edit: Nem nevezném szakmabelinek, aki akár az eredeti cikk alapján ilyen következtetést von le :P

Megnéztem a linkeket, meg gugliztam hozzá kicsit, és azt kell mondjam, siralmas a helyzet... Beraktam egy hosszabb szájbarágót, így remélem a gyengébb képességűeknek is világos lesz miről van itt szó.

llyes Edit (törölt) 2009.09.27. 16:00:11

Köszönjük a szájbarágót. :) Annyi kiegészítés hozzá, hogy a drupal.org-on közzétett kiegészítő modulok nem "hivatalosak". Azokat is figyeli a biztonsági csoport, de ott nincs olyan típusú "garancia", mint az alapcsomag esetében. Emberileg nem is lehetne több ezer kiegészítő modul folyamatosan mozgásban lévő kódját állandó ellenőrzés alatt tartani.

Az utóbbi években nem hallottunk arról, hogy _rendesen karbantartott_ oldalt az alapcsomagon keresztül feltörtek volna. Kiegészítő modul esetében 1 spam küldésre aktívan kihasznált exploitról lehetett hallani.

Ha Drupal rendszert feltörnek, az _nagy valószínűséggel_ szakszerűtlen hozzátoldás, vagy rosszul konfigurált rendszer www.google.hu/search?hl=en&client=firefox-a&rls=org.mozilla%3Aen-US%3Aofficial&hs=pCF&q=%22You+may+post+PHP+code.+You+should+include+%3C%3Fphp+%3F%3E+tags.%22&btnG=Search vagy a titkárnő monitorjára ragasztott admin jelszó eredménye. :)

Még egyszer köszönöm a cikk kiegészítését.

llyes Edit (törölt) 2009.09.27. 16:01:14

@Illyés Edit: Bocsánat, tinyurl helyett az eredeti linket másoltam be. (Miért nincs itt a blog.hu-n előnézet?)

_2501 2009.09.27. 16:32:44

Mintha picinkét túlpörögtünk volna.

llyes Edit (törölt) 2009.09.27. 17:01:19

@_2501: Elsősorban nem neked írtam mindezt, hanem azoknak a Drupal iránt érdeklődő, többségében laikus látogatóknak, akik a jövőben a keresőkön keresztül érkeznek erre az oldalra, és esetleg félreértenék a helyzetet és emiatt átmennének a konkurenciához a Joomla táborba. ;)

De most már tényleg túl van tárgyalva a téma.

Hunger 2009.09.27. 18:07:40

@nevergone: "pontosabb legyen a cikk"

Ez nem cikk, hanem egy blogbejegyzés, HTH

Pasq 2009.09.27. 19:46:58

Amen.
Szep megoldas mindenesetre.

r@ek (törölt) 2009.09.27. 21:03:37

@never: Hi! A HIX Aréna lapja teljesen megsemmisult? Egyaltalan mennek meg a szerverek?

Regi szep telnetes idok.. ;-)

HoaxSpecialist · http://hacker.blog.hu 2009.09.27. 23:09:02

Hm, szep post, rengeteg komment : )
Igazabol nekem az kiesett az a resze az estenek hogy sikerult feltorni a democms-t, de gratu Buheranak, es akik dolgoztak vele, azt tudom hogy voltatok egy paran :)) Mi lett Cintiaval? Elvittetek egyaltalan "romantikus vacsorazni" ? :D

udv, B

nevergone 2009.09.28. 00:05:13

r@ek: sajnos onnan semmi sem üzemel már :(

gyrgyvrs 2009.10.10. 17:51:14

Jó, rendben van, de hát mégiscsak sikerült feltörni a drupal core felhasználókezelését, nem? Mert az a core része. Ha be van kapcsolva, hogy a hibajelentés jelenjen meg az oldalon is, akkor meg szerintem a core is törhető! Tényleg, egyébként nem ez volt a gond?

buherator · http://buhera.blog.hu 2009.10.10. 18:01:54

@gyrgyvrs: Nem, miért sikerült volna? A felhasználókezelés teljesen jól működik, csak ugye az nem egy normális állapot hogy a webjúzer turkál a raw adatbázisban (egy külső modulon keresztül) :P Ha nem iktatsz be egy sebezhető modult, nem tudod resetelni a jelszót, tehát a core nem hibás.

A Drupalos fejlesztőkkel egyébként azóta folyamatban van egy agyalás a Drupal 7 jelszóvisszaállító funkciójának megerősítésére (hardening != bugfix)
süti beállítások módosítása