2013. május 25., szombat

A GitSCB verseny élménybeszámolója + megoldás videók.

Elöljáróban annyit, hogy köszönet a szervezőknek, mert egy nagyon élvezetes játékot sikerült összehozniuk. Én a magam részéről nagyon élveztem a dolgot.

Annyit el kell mondani, hogy nekem személy szerint nem a verseny megnyerése volt a célom, hanem a penteszteléses módszereim tökéletesítése és a tanulás. Megtalálom-e vajon a hibát egyedül? Ez volt számomra a kérdés nem az, hogy hány pontot sikerül összegyűjteni. Emiatt a feladatot nem is csináltam meg végig. Miután bent voltam a szerveren és interaktívan is be tudtam lépni a privilégium eszkalálással már nem bajlódtam. Találtam rá nyomokat, amin el lehetett volna indulni, de az első része jobban érdekelt. (Így az scb-vel nem is kezdtem el bűvészkedni. Emiatt csak az első két pályára jutottam be. A 3-as és a 4-eshez kellett volna az scb-t jobban ismerni, de most nem akartam vele sokat foglalkozni.

Azt is el kell mondani, hogy mivel egyszerre többen dolgoztunk a problémán, már rég bent voltam a szerveren és már le is mentettem .bash_history fileokat és más config állományokat, mikor még fogalmam sem volt arról, hogy milyen hibán keresztül lehetne egyáltalán bejutni a gépre. Ennek oka igen egyszerű: mások bejutottak és az ő hibáikon keresztül be tudtam lépni a gépre. Sok ember sokféle módon közelítette meg a kérdést és volt aki c99.php shellt használt. Én meg megtaláltam és azon keresztül belépve gyakorlatilag már nem is lett volna szükségem rá, hogy a megoldásra rájöjjek.

Ez egyébként egy security hole volt a játékban, amit meg is említettem a szervezőknek és úgy vettem észre, hogy a .bash_history fileokat el is tűntették, hogy ne lehessen így a megoldásokhoz jutni.(legalábbis az első gépen)

Az időm nagy részét a bejutási lehetőség keresésével töltöttem. Hiába volt már meg a szükséges jelszó engem az érdekelt, hogy ha nem sikerült volna a php shellen bemenni, akkor hogyan jutnék be. Megpróbáltam megvizsgálni a lehetséges hibákat és sokat eltököltem az információ gyűjtéssel és a google és az exploit leírások olvasgatásával. Megpróbáltam penteszteléses feladatnak értelmezni a feladványt.

Végül két hibát találtam - ebben nagy szerepe volt az irc-n elhangzó beszélgetéseknek is. Az egyik egy ottfelejtett file volt, amiben benne volt a phpmyadmin jelszó és annak ismeretében már nem volt probléma behekkelni magam a rendszerbe. A másik hiba egy sql injection hiba volt, amin keresztül eljutottam az adminisztrátori usernév+hash párosig.

De az eredeti hash-t feltörni nem sikerült. (Igaz, sokat nem is vesződtem vele) Azt végül nem tudtam meg, hogy másoknak vajon sikerült-e. Mivel legtöbben - ha nem mindenki - a verseny feladványok megoldásán agyalt - nekik mindegy volt, hogy hogy jutottak be a gépre a lényeg, hogy bent voltak.

A dolog szépségét fokozta, hogy a játékosok folyamatosan változtatgatták a gépen a dolgokat. Jelszavak cserélődtek, fájlok keletkeztek, majd tűntek el váratlanul. Ennek voltak előnyei és hátrányai is. Rengeteg ötletet lehetett ellopni másoktól. Viszont olyan is előfordult, hogy egymás munkáját elrontották a játékosok. Ez benne volt a pakliban.

A legnagyöbb derültséget a törökök akciója okozta, akik már deface-olták a gépet, mielőtt még bárki be tudott volna rá jutni :) (Mindenki arra volt a leginkább kíváncsi, hogy hogy csinálták - de ezt a szervezőktől végül nem tudtuk meg)

Sok ember elbukott az ssh kérdésen. Hiába szereztek jogosultságot a gépre php-n keresztül nem tudták, hogy mi módon lehetne azt kihasználni és hogy lehetne egy interaktív shellt csinálni. Pedig ez azért nem volt olyan nehéz.

Gyakorlatilag - ha jól emlékszem még a verseny kezdete után órák múlva is üres volt az eredményjelző, pedig sokan már 10-20 perc után találtak rést a falon - de nem igazán tudtak vele mit kezdeni. Az járt jól aki folyamatosan pásztázta a szervert - így nagyon sok információhoz hozzá lehetett jutni. Néhányszor ki lettek zárva a játékosok bizonyos file jogosultságok elállításával. Nem derült ki, hogy ezt valaki szándékosan vagy pedig véletlenül csinálta-e.

Itt volt egyébként a következő security hole a játékban: aki bejutott az ssh-val és nem tűntette el  egyből a nyomait arra olyanok is rá tudtak bukkani egy sima nikto-val akik még be sem jutottak a gépre. Mivel sok játékos sokféleképpen próbálkozott gyakorlatilag el lehet mondani, hogy "egymás hátán" egymás megoldásait felhasználva gyorsan lehetett előre haladni. Az egyik megoldotta az egyik problémát, a másik meg a következőt, és így tovább.

A tisztánlátás kedvéért megpróbáltam belépni a gépre a második vagy a harmadik nap hajnali 5-kor és az a meglepetés fogadott, hogy a szerver nem is hasonlított arra mint amin addig dolgoztam :) Jóformán egy széthekkelt szerverrel találkoztam egész napközben :) Így elég gyorsan lehetett előre haladni. Most viszont, a "tiszta" gépen nekem kellett a különböző hekkeléseket megcsinálni. Ha valaki későn jött, neki sokkal nehezebb dolga volt, ez biztos. Mivel nem tudott mások hibáit kihasználva bejutni.

Az elején például volt tegy jelszó-hash csere. Valaki lecserélte az admin userhez tartozó jelszó hash-t a phpmyadmin felületen (vagy máshogy) Aki ezen a könnyített jelszón keresztül be tudott jutni az admin felületre az utána már az eredeti hash megtörése nélkül is be tudott lépni. Vagyis az történt, hogy a megoldás tudta nélkül kikerülte az első akadályt :) Nagyon sokan jártunk így :) Csak az szívta meg aki később jött. Ők ugyanis nem a széthekkelt géppel találkoztak, hanem az eredetivel.

Volt egy file amit meg lehetett elvileg találni, de szerintem azt csak nagyon kevesen találták meg.

Az mindenesetre kiderült számomra, hogy az automata eszközök nagyon sokat tudnak segíteni egy ilyen feladat megoldásában, de nem lehet csak rájuk hagyatkozni. Kézzel/szemmel is ellenőrizni kell a dolgokat. Volt olyan, hogy az automata hibát jelzett, de nem volt hiba és olyan is volt, hogy nem jelzett pedig lukas volt a szoftver. A teszteléshez egy külön saját webhostra feltelepítettem egy joomlát és eg qdPM-et is. Hibakeresésnél nagyon haszos lehet az ilyesmi.

Arra is rájöttem, hogy a módszer amit használtam tökéletlen volt. Sok apróságra nem figyeltem fel első nekifutásra amik fontosak voltak vagy azok lehettek volna.

Készítettem két videót - de inkább pentesztelési szempontokat vettem figyelembe. Sok a vágás, mert néha bénáztam és ezeket kivágtam a filmből. Meg volt, hogy mások felülcsaptak közbe dolgokat miközbe vettem fel az anyagot. Ami maradt az nagyjából demonstrációs anyagnak jó. Azért nagyjából látni lehet, hogy mit csináltak a játékosok vagy, hogy mit kellett volna csinálniuk. A root jog megszerzésére nem maradt idő - így arról sajnos nem készült videó.

Az első videó végén van egy .bash_history részlet, amit letöltöttem az egyik szerverről, abban vannak próbálkozások a játékosok részéről.

Lett volna még ötletem, hogy mit csináljak a gépen, csak időm nem maradt már rá. Egy dmesg | grep -i virtual paranccsal megtudtam, hogy egy vmware virtuális gépről van szó, és 32 bites módban fut  gép. Próbáltam feltenni más virtuális gép detektáló cuccokat is a feltört gépre, de végül hagytam a dolgot :)

(A virtuális gép hibáján keresztül a valós szerverig is meg lehetett volna próbálni eljutni - persze versenyen kívül, de erre nem maradt időm)

íme a két videó :





2013. május 14., kedd

Ghost in the Shell Control Box

http://gitscb.silentsignal.hu/

Megcsináltam az első két szinten az ssh shell elérését. de a türelmem, kedvem, időm elfogyott.

Majd még visszanézek oda később, de egyelőre elég volt a gép törögetésből/megkerülésből.

Ha vége a versenynek és elérhető lesz a megoldás esetleg megírom itt, hogy mivel próbálkoztam - és mi vezetett eredményre. Root jogot nem sikerült szerezni, de annyi időm nincs, hogy exploitokkal kísérletezzek, vagy átnézzem a gépet privilégium eszkalációs lehetőségek után kutatva.


2013. május 6., hétfő

DVWA File Inclusion Test

Ezen a Videón a File Inclusion tesztelését fogom bemutatni. Banális beállítások esetén működik a Remote File Inclusion vagy más néven RFI ami, ha van egy jó php shellünk, akkor nagyon kényelmessé teszi a szerver elfoglalását. Ha a távoli file inclusion nem működik, akkor lehet próbálkozni helyi inclusionokkal, amikkel szintén elég sok információt ki lehet szedni a gépből. (configokat kilistázni, satöbbi...)


Ez a téma persze ennél sokkal bővebb, de minden részletét nem lehetett itt bemutatni, mert ahhoz módosítanom kellett volna a php forrást. Például bevitellel lehet terminálni a stringet így ha a program hozzátenné a file-hoz a kiterjesztést, akkor ezt a védelmet meg lehet így kerülni. Ezek bagatell programozói hibák, de mégis aki nem tudja, hogy ezen keresztül milyen sérülékenységet tud okozni egy szervernek könnyen így felejti a kódot - hisz működik és a fejlesztőknek ez általában már elég szokott lenni. Tehát érdemes ilyen hibák után kutatni, mert régiek ugyan de annál jobban kihasználhatóak.