Hogyan törjünk fel weblapokat?

LakatMa egy igen kényes témát szeretnék bemutatni. Kényes mert a biztonsági tanácsok egyben ötletek másoknak arra, hogy hogyan tudnak ténylegesen feltörni oldalakat. Egy webalkalmazás biztonsági tesztelése praktikusan nem jelent mást mint, hogy a webalkalmazás fejlesztője / tesztelője egy rövid időre a támadó bőrébe bújik. Rászántam a hétvégét és egy dologra jöttem rá, egy weblap feltöréséhez egyetlen dolog szükséges: IDŐ.

A betörő szett

Amint azt írtam a betöréshez egyetlen dologra lesz szükségünk, időre. Na jó kell egy kis háttér ismeret a web általános működéséről valamint türelemre és egy kis szerencsére. Álkulcs, spájszer is kell majd, jobban mondva ezek online változatára. Amit meg kell értenünk, hogy a támadók másképpen gondolkoznak és mindent másképpen akarnak használni mint ahogy azt mi eredetileg terveztük volna.

A bűnözésben egy egyszerű kis Clevo laptop segített a maga 2 GHz-es procijával és 2 GB memóriával. Szóval nem mondhatnám, hogy egy különlegesen kifinomult és bikaerős társam lett volna.

A célpont

A célpont egy nemrégiben lecserélt webáruház volt. Fogtam és feltettem az egész cuccot a laptopra és megpróbáltam elérni a következőket:

  • megszerezni a vásárlók adatait – ugye ez jól jöhet a konkurenciának, illetve más hasznos infókat is szerezhetünk ezek alapján
  • perzisztens XSS-t
  • vagy tartalom módosítást produkálni
  • a szervert felhasználni saját cáljainkra – spam, stb

Előkészületek

Mivel abszolút nem vagyok otthon a témában fogtam egy webes biztonsági kérdéseket feszegető könyvet és átolvastam. Az egyik a

Hacking Exposed Web Applications, 2nd Ed. (Hacking Exposed)

a másik pedig a

How to Break Web Software: Functional and Security Testing of Web Applications and Web Services. Book & CD

Mindkettő nagyon hasznos volt több szempontból is. Az egyik, hogy bemutatták azokat a fő technikákat amelyeket a betörők használnak, a másik pedig az, hogy rájöttem, hogy a biztonsági kérdések mennyire elhanyagoltak a weben. A hanyagság abból adódik, hogy sokan nem gondolják, hogy bármiféle támadás célpontjaivá válhatnak, másrészt pedig azért mert egy megrendelőt maximum a funkcionalitás, a működőképesség érdekli. A biztonság már csak akkor kerül szóba ha már valaki leverte a lakatot.

A könyveket kb egy délután alatt átpörgettem aztán feltelepítettem a szükséges programokat, amely a normál fejlesztői környezetemen felül 2-3 Firefox kiterjesztést jelentett csupán.

A betörés

A betörés alatt végig tartottam magam ahhoz, hogy habár a saját gépemen volt az alkalmazás úgy csináltam mindent mintha nem férnék hozzá a szerver oldalhoz.

A szerver oldal

Előszőr próbáltam megállapítani, hogy milyen szerver oldali alkalmazásokat használ a webáruház. Ehhez csupán annyit kellett tennem, hogy az url végére odatettem egy ?error=jo_hosszu_string karakterláncot, ahol a jo_hosszu_string kb 800 karaktert tartalmazott. Ez persze dobott nekem egy hibaüzenetet amiből megtudtam, hogy Apache/2.2.11 (Ubuntu) webszerver és PHP/5.2.6 fut a szerveren. Ebből megsaccoltam, hogy MySQL lesz az adatbázis szerver. Mondjuk ezzel az információval nem mentem túl sokra de első körben pozitívan értékeltem, hogy legalább sikerült valami olyan információt megszerezni amit nem kötnek mindenki orrára.

Ha értenék egy kicsit a webszerverek és egyéb szerver oldali cuccok birizgálásához akkor biztosan nekiálltam volna ismert biztonsági réseket keresni, de mivel ehhez egyáltalán nem értek, így ezt az utat kihagytam.

Azért emelett lefuttatam egy Nikto-t is hátha talál valami érdekeset, de nem találtam semmi használhatót.

HTML megjegyzések

Következő lépésként megnéztem a különböző oldalak HTML forrását és a HTML megjegyzésekben keresgéltem nem odaillő részleteket, mint SQL utasítások, jelszavak vagy bármi más használható információt. A rendszer ebből a szempontból jól vizsgázott nem találtam semmit.

Könyvtárak és fájlok

Ezután próbáltam keresni olyan fájlokat és könyvtárakat amelyek hasznosak lehetnek. Keresgéltem config.inc ás más hasonló nyalánkságok után, de csak a /admin URL-en sikerült megtalálnom az adminisztrátorok beléptetésére szolgáló oldalt.

Inputok

Az adatbevitel legfontosabb eszközei az inputok, legyenek akár sima szövegesek, hiddenek, selectek vagy mások. Tekertem őket mindenfelé de semmit sem tudtam kihozni belőlük. Úgy néz ki, hogy a webshop jól kezelte a nem valid értékeket, XSS támadásokat és egyebeket. Szóval ez a megközelítés is zsákutca volt.

Get paraméterek

Néhány helyen használt az alkamazás get paramétereket. Ezeket is próbáltam átalakítgatni szintén eredménytelenül. Próbálgattam a ?admin=1, ?debug=1 paramétereket hátha találok valami kiskaput, de nem találtam.

SQL beoltás

A következő nekifutásom az SQL beoltásokkal való kísérletezés volt. A '-- és hasonló stringekkel való játék sikertelennek bizonyult, ezen a vonalon sem tudtam bejutni.

Usernevek és jelszavak

Bárki szabadon regisztrálhatott a webshopba. Megpróbáltam mindenféle ügyes usernevekkel beregisztrálni, mint a '--, a <script>alert('XSS');</script> és más hasonlóak de nem vezettek eredményre.

Új felhasználó beregisztrálásakor annyi kiderült, hogy próbálgatással pár usernévre visszajött hibaüzenetként, hogy az adott user már létezik, de mivel nem volt értelme más bőrébe bújni nem mentem tovább ezen a vonalon.

Jelszóként a mindenféle speciális karakterekkel ellátott jelszókra azt a hibaüzenetet kaptam, hogy a jelszó csak betűket és számokat tartalmazhat.

Ezen a ponton kezdtem feladni, mivel úgy nézett ki, hogy a klasszikus betörési módszerekkel nem mentem semmire.

Ekkor megpróbálkoztam tipikus adminisztrátori felhasználónevekkel és jelszavakkal (mint az admin / admin, admin / 1234, stb) behatolni az admin felületre. Nem sikerült ez sem, viszont itt már felbukkant valami érdekes. Az érdekesség az volt, hogy úgy nézett ki, hogy az admin felület tetszőleges számú bejelentkezési kísérletet engedélyez, azaz nem tilt le pár sikertelen próbálkozás után.

Jelszótörés

A fenti információk jegyében megpróbáltam 1-2 jelszó feltörő scriptet amit le lehet tölteni könnyedén internetről. Habár hidegrázásom van a wines programoktól még a Brutus nevű alkalmazást is kipróbáltam, de mivel nem ismertem egy admin felhasználónevet nem sokra jutottam vele.

Ezért végül előszedtem a php-t és a curl-t és összeraktam egy kb 50 soros is programocskát. A kis programocska annyit tett, hogy fogta a normál linux telepítésben megtalálható myspell magyar szótár fájlt és egy megadott felhasználói névvel végigpróbálgatta azokat. Találomra bepróbálkoztam pár gyakori magyar férfinévvel, mint józsi, sanyi, stb de nem jártam sikerrel. A szótárban több mint 95.000 szó volt és habár nem sikerült bejutnom bebizonyosodott, hogy a webshop nem tiltakozik ha pár százezerszer megpróbálunk behatolni. Egy-egy ilyen próbálkozás a kis laptopon kb 35-40 percig tartott.

Aztán fogtam a magyar utóneveket és szépen egyesével végigmentem rajtuk is, ismét eredménytelenül.

Mivel ezzel sem jutottam semmire arra gondoltam, hogy hátha van olyan adminisztrátor aki felhasználónévként ugyanazt használta mint jelszóként. Ebből a feltételezésből kiindulva írtam egy másik 50 soros php scriptet ami végigpróbálgatja az összes elképzelhető kis és nagybetű, valamint szám kombinációt ami előfordulhat.

Az egy karakteres brute force (nyers erő) próbálkozás 1 perc alatt lefutott de nem volt eredménye. A két karakteres kb 5-8 percig tartott szintén eredménytelenül zárt. A 3 karakteres próbálkozás 35 perc kísérletezgetés után kidobta a zig nevezetű usert. Szerencsémre zig kellőképpen óvatlan volt és jelszóként a zig-et használta.

3 karakter ami kis és nagybetű illetve számokat tartalmazhat 512 ezer variációt jelent. 5 karakterhosszon már 3,2 milliárd lehetséges variációt jelent. Percenként kb 10 ezer jelszót tudott a kis laptopocska kipróbálni, azaz 5 karakter hosszúságú felhasználó / jelszó esetében több mint 200 napra lenne szüksége megfejteni és a karakterlánc hosszával hatványosan nő. Ezek alapján könnyen megsaccolható, hogy egy több ezer gépből álló botnetnek mennyi idő kellhet egy jelszó visszafejtéséhez.

Eredmények

Zig jelszavával beléptem az admin felületre. Itt megtalálható volt a teljes user lista, a saját tartalomkezelő segítségével pedig játsznyi könnyedtséggel tudtam perzisztens XSS-t és tetszőleges tartalommódosítást létrehozni. Mivel a webshopnak volt hírlevélküldő szolgáltatása amelyben volt fájlfeltöltő szolgáltatás is tetszőleges fájlt tudtam feltölteni és futtatni a szerveren. Küldetés teljesítve.

Tanulságok

A weblapok feltöréséhez nincs másra szükségünk mint időre. Fogadjuk el, hogy egy kellőképpen eltökélt támadó akár még különösebb támadási ismeretek nélkül is idővel találni fog valami behatolási pontot. A biztonsági kérdéseket fontosnak kell tartanunk és a fejlesztés közben folyamatosan figyelni kell rájuk.

Akarjuk vagy sem webalkalmazásunk könnyedén célponttá vállhat. Lehetnek adataink amelyek mások számára kívánatosak, vagy az alkalmazásunkon keresztül behatolva a szerverre értékes erőforrásokat szerezhetnek meg a támadók.

A hibaüzenetek értékes információkat adhatnak támadóinknak. Próbáljunk kellőképpen informatív, de egy támadó számára értéktelen hibaüzeneteket adni. A tipikus példa erre, hogy ragaszkodjunk a “Rossz név vagy jelszó” hibaüzenethez bejelentkezéskor és ne adjuk a támadó tudtára, hogy melyiket sikerült neki kitalálni.

Próbáljuk rákényszeríteni a felhasználókat erős jelszavak használatára.

További lépések

A hírlevélnél használatos fájlfeltöltő segítségével sikeresen letöltöttem magamnak a teljes adatbázist. Itt fény derült valamire amit eddig nem teljesen értettem meg, hogy miért is kell az adatbázisban titkosítva tárolni a jelszavakat. Persze mindig úgy tároltam őket de most bebizonyosodott a haszna. A kezemben volt a teljes adatbázis de a jelszavakat még fel kellett törni. Mivel a saját gépemen volt itt már nyugodtan dolgozhattak a jelszótörők, hogy megfejtsék azokat. Mire kell ez egy támadónak? Jó eséllyel találunk olyan felhasználót aki ugyanazt a jelszót használja a levelezésében mint a webshopunkban. A levelezésben pedig érdekes dolgok lapulhatnak, mint újabb jelszavak és más hasznosságok.

Statisztikák

A webshopnak 8.000 felhasználója volt. Ebből 400-nak, 5%-nak ugyanaz volt a jelszava mint a felhasználóneve. 40 felhasználó a usernevét után írt 1-4 számmal toldotta meg és azt használta jelszóként. Ezt a két tesztet kb 2 perc alatt futtattam le, hozzájutva ezzel majd 450 ember jelszavához.

Az 123-at jelszóként 3 felhasználó választotta magának, 1234-et 388-an, 12345-t szintén 3-an, 123456-ot pedig 26-an, és még 2-2 felhasználó választotta magának az előző jelszót megtoldva 7-8-9-cel. Ez újabb 426 jelszót jelentett.

A legnépszerűbb jelszavak az 1234 (388 user), a asd123 (38), a 123456 (26), a video (24 – video webshopról volt szó), az avi (20). Ezeken felül volt még másik 5 jelszó amit 15-25 user használt, de nem volt energiám visszafejteni őket.

Összesen 5.941 jelszót használt a 8.000 user. Kb 60 olyan jelszó volt amelyet több mint 8 user használt.

Ezután némi türelemmel praktikusan minden felhasználói jelszóhoz hozzá lehet jutni és mivel a rendszer a userek email címét is tartalmazza ott lebegett előttem a lehetőség, hogy feltörjem 8.000 ember levelezését. Jelenleg nem vonz túlságosan a bűnözői pálya, így ennek nem fogtam neki.

33 thoughts on “Hogyan törjünk fel weblapokat?

  1. a verzió megszerzés, hát ott azért rendesen felkonfigurált szerveren nem tudnál meg semmit. Esetleg annyit, hogy apacs.

    Én még egy nmapot is toltam volna, hátha abból (TCP csomagokból) kiderül milyen OS fut a gépen (persze ez se 100%-os)

  2. ö, a jelszó egy normális alkalmazásban nem titkosítva tárolódik, hanem csak egy jelszó hasht (md5, crypt, stb.) tárolódik. Azért a két dolog nem ugyanaz (titkosításból vissza lehet fejteni adatot, míg a hash csak egyirányú). Legalábbis ilyen értelemben szokták magyarban használni.

  3. Ő is a jelszó hash-re gondolt, látszik a leírásból.
    De legalább az megvolt.
    Egyébként egy admin felületet ilyen elérhetővé tenni… hááááát.
    No meg hogy a feltöltött fájlokat futtatni lehet, háááát…

  4. és mindez egy gyenge admin jelszó miatt.
    nem csoda, hogy a jobb helyeken megkövetelik a bonyolult admin jelszót.

    egyébként egyszer egy linux disztrót telepítettem próbaképpen, aminek a telepítője közölte velem, hogy a kívánt root jelszó nem biztonságos, mert szerepel valami dictionary-ban. pedig arról a jelszóról azt hittem, hogy csak én találhatok ki ilyen marhaságot… 🙂

  5. Jó kis cikk. A “Töréstesztet” idő hiányában mindenki elmismásolja. Pedig ez egy fontos lépése a fejlesztésnek.

    Sajnos hiába minden titkosítás és szűrés meg tesztelés, ha az oldal gazdája nem elég körültekintő. Nem is hinnénk mekkora bajt tud okozni egy segítőkészségből lemásolt hordozható Total Commander, vagy bármilyen FTP program. A TC-nél elég megszerezni a wcx_ftp.ini fájlt és már benn is vannak az adott weboldal tárhelyén. Ott aztán lehet szabadon garázdálkodni. Ha TC Password ripper-rel visszafejtik belőle a jelszót akkor azzal már másutt is tudnak próbálkozni.

  6. Pingback: HTML Info » Jelszavakról és biztonságról

  7. Nagyon jó cikk, köszönöm, hogy megosztottad velem / velünk!

    Még annyit tennék hozzá, hogy nem csak az idő miatt tudtad feltörni a lapot, hanem a sokat emlegetett felhasználói/emberi hiba megléte miatt.

    Köszi még egyszer a leírást!

    Üdv, DarkLight

    • @fabrik Azt felejtette el lekorlátozni a fejlesztő, hogy mennyi sikertelen bejelentkezési próbálkozást tesz lehetővé. Ez nyitott utat egy brute force támadásnak. De valójában tényleg nincs feltörhetetlen rendszer. A mi dolgunk, hogy minél jobban megnehezítsük a támadók dolgát.

  8. Ajánlanám ezt a blogot: http://secblog.stratis.hu/ Illetve van egy ilyen könyv is (Hogyan törjünk fel webhelyeket, azt hiszem ez a címe.

    Egyébként a twittert is így törték fel nemrégiben, ráadásul, mivel a user a gmail-hez is ugyanazt használta, ugye azt is.

    Persze rengeteg dolog van, a legfontosabb, hogy egy esetleges törést minél előbb felfedezzünk, és minél előbb visszaállítsuk a megelőző állapotot. A feltörhetetlen webhely olyan mint az örökmozgó. Nem létezik.

  9. Nagyon jó és rendkívül aktuális is, a napokban zúzták meg a szolgáltatóm, szerverét, de “csak” átirányítottak az ő oldalukra.

    Akkor dobtam egy hátast amikor tegnap egyik nagynevű könyvesbolt lánc egyik üzletében láttam a “Hogyan Törjünk fel weboldalakat” vagy valami hasonló című művet… Valszeg a fentebb általad említett könyv magyar változata.

    Freelance71

  10. Tényleg jó a cikk.
    2009-et írunk és rengeteg olyan webes alkalmazással találkozhatunk ahol 0 a biztonság, illetve a klienes oldali JS validátornál kimerül a felhasználóktól érkező adatok ellenőrzése. Viszont ezzel szemben kellő figyelemmel a hiba üzenetek kiírása is be van kapcsolva, és a $_REQUEST tömb is orrvérzésig mindenre használva van (tényleg nehéz megkülönböztetni a _POST és _GET tömböket)…

    Vannak Firefox bővítmények amik az efféle biztonsági dolgok tesztelésére hivatottak.

  11. rrd: tegyük fel, hogy 3-5 próbálkozás után letiltja a rendszser az aktuális account-ot. A tiltásnál mit érdemes csináli? Tilt 30-60 percre, vagy teljes blokkolás, azaz csak admin felhasználó tudja feloldani a lock-ot?

    Az én ötletem:
    a, publikus felhasználói fióknál elég lehet mondjuk 3 hibás jelszó, majd 30-60 perc lock
    b, admin fiók esetében mindenképpen teljes lock-olás 3 hibás próbálkozás után

    • @Max Logan igen, valami ilyesmi. Vagy mint a google kiad egy captcha-t 3 hibás próbálkozás után. Az már más kérdés, hogy a captchak a userek 40-50%-át sem engedik át…

  12. Ha már webáruház, azért az se rossz megoldás, ha a felhasználó fiókja nem az idők végezetéig érvényes. Legalább a jelszó járjon le egy idő után. Akkor lehet e-mailben értesíteni, hogy cserélje ki. Ha ezt nem teszi meg akkor törlés.

    Engem a Szabadúszó által említett Hogyan törjünk fel webhelyeket című könyvből tanítottak a suliban. Sajnos ez is olyan mint a többi szakkönyv évekkel lemaradva követi a valóságot. Egy haszna azért van, kapsz egy csomó kulcsszót amire rákereshetsz a Google-en

  13. @zsgyuris,

    OK!

    Aki ilyen vizeken akar evezni az úgy is megtalálja, sőt ingyen is, aki véletlenül téved oda…

    De amikor neves offline Pcs havilapban leközlik, hogyn ágyazhatsz be, makrót egy null pixeles .jpg fáljba, hogyan nyithatsz meg titkosítatlan doksit, hogy nézhetsz be egy jelszóval nem védett, hálózati webcamba… Sőt, hogy a hálózati nyomtatók, memóriájából, hogyan szedheted ki az utolsó, nyomtatás vagy szkennelés emlékét…

    Szal oda akarok, kilyukadni, hogy aki bombát akar gyártani freebe megtalál mindent ami kell, de azért ne osztogassunk “modellkészletet recpttel!”

    Freelance71

    ui.: bocsi a kicsit offba mentem! 😉

  14. egyegyszerű ff kiterjesztéssel (live http headers) is meg tudom mondani hogy pl a webmania.cc mögött Apache/1.3.41 (Unix) PHP/5.2.10 mod_ssl/2.8.31 OpenSSL/0.9.7a van. 😉

  15. @Szabadúszó

    Maximálisan egyetértek veled. Aki ilyesmivel akar foglalkozni az mindent megtalál a net-en ami kell. Az már más kérdés, hogy milyen nagy árat fizet érte később.

    Valóban sok mindent leközölnek újságok és weblapok is ebben a témában. A tapasztalatom mégis az, hogy ezek ellenére sem foglalkoznak eleget a témával. Annak ellenére, hogy gyakran hamarabb talál az ember jelszófeltörőt, mint egy normális PHP bemenet szűrő osztályt.

    A lényeg az, hogy kezdőknek senki nem mondja meg, hogy mire figyeljenek oda. Az ilyen jó című könyvek mint a Hogyan törjünk fel webhelyeket meg csak olaj a tűzre. Ad egyfajta hamis biztonságérzetet.

  16. Jó és egyben érdekes is volt a cikk. Na meg tanulságos is! Most a zig-et lehetne okolni azért, mert elszabadult a pokol, de vérezhetett volna más sebből is.
    Most megyek lecserélem az egyik jelszavam 😀

  17. Nem olvastam még egyikötöktől sem a nem fogadott, visszaküldött tartalmakról. Értékes információt szolgáltat a küldő IP-címe,számsora.Erre magamtól jöttem rá, nem fogadott tartalmak kapcsán. Tehát védekezésül nem szerencsés semmit visszaküldeni, elutasítani, hanem olvasatlanul törölni kell.

  18. Én múltkorában találtam egy állami hivatal oldalán egy weboldalt. A webcímekből kiderült, php-t használnak. site.hu/admin oldalra rápróbálva bejött egy beléptető form. Sqlinjectionra googlizás, 3-4. találatban volt egy olyan kifejezés, amivel beléptem az admin oldalra. Mondjuk tudtam volna törölni az összes felhasználót, híreket manipulálni, pályázati kiírást átirni… Írtam a cégnek, azóta semmi visszajelzés. Ja ez augusztusban volt, azóta is benne van a kérdéses hiba (legutóbb 1 hónapja néztem)

  19. Nagyon tetszett a cikk. Tanulságos. Habár a felhasználó gyenge láncszem, talán mégis lehetne valamit tenni. Az időt nyújtani. Eleve az egy IP címről történő, azonos böngészőparaméterekkel indított bejelentkezéseket lehet korlátozni, vagy ami durvább – a konkrét felhasználónévhez behúzni a féket, IP-től függetlenül. Három – öt rossz jelszó után félóra szünet az adott felhasználónévnek. Illetve a login szkriptbe behúzni egy 2-5 másodperces várakozást. Egy felhasználó ezt ki tudja várni, talán még azt is hiszi, hogy a program ilyen sebességgel jelentkeztet be. De 3 karakternél az 512 ezer variációnál már kínos ez a fix sleep érték. Ja és a session. A bejelentkezést eleve már csak egy friss munkamenetből lehessen indítani. Ha ezeket optimálisan kombináljuk, a feladat nehézsége és a kecsegtető haszon mérlege már egy-két hekkert elrettenthet.

  20. Ez csak ízelítő, lehet még más módon is hekkerkedni.Csinálom pár éve le nem buktam pedig jó pár szerveren tettem látogatást.Jó az írás, csak így tovább!

  21. “Ekkor megpróbálkoztam tipikus adminisztrátori felhasználónevekkel és jelszavakkal (mint az admin / admin, admin / 1234, stb)”, “hátha van olyan adminisztrátor aki felhasználónévként ugyanazt használta mint jelszóként”.
    Mind a két hiba meglepően gyakori. A 17 éves fiam egyszer vasárnap délután 5 perc alatt bent volt a cég MS-SQL Server adatbázisában (pénzügyi cég, 12 GB-os adatbázis). A pénzügyi rendszer távoli asztalon ment, tehát bárhonnan elérhető. Windows név: megegyezik a cég nevével, jelszó: 123. Az adatbázis (SQL hitelesítést használt) neve: megegyezik a cég nevével, jelszó: megegyezik a névvel. Sajnos, sok ilyen rendszergazda garázdálkodik a nagyvilágban.
    A cikk nagyon tanulságos, gratulálok.

Vélemény, hozzászólás?

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöljük.