2015. november 5., csütörtök

Penetration Testing on metasploitable 2 - Automated Scanners - Nessus

Miután kézzel összegyűjtöttük a szolgáltatásokat teszteljük az elérhető szolgáltatásokat automatikus szkennerekkel. Én 3 szkennert fogok használni a vizsgálathoz. A Nessus Home verzióját, a Nexpose Community kiadását és az OpenVAS open source szkennert.

Elsőnek nézzük a Nessus-t, hogy milyen sérülékenységeket fedez fel.
A nessus konfigurálása: (Egy 6.5.2-es verziót használtam a vizsgálathoz)

Menjünk a Policy-khez és készítsünk egy új policyt (New Policy)


A következő beállításokra van szükségünk:
Assesment -> General:
Assesment -> Brute Force:
Assesment -> Web Application:

A port range alap helyzetben default, amennyiben tudjuk a konkrét portokat amit vizsgálni szeretnénk, ezt pontosan be tudjuk írni:
T:21,22,23,25,53,80,111,139,445,512,513,514,1099,1524,2049,2121,3306,3632,5432,5900,6000,6667,6697,8009,8180,8787,U:53,68,69,111,137,138,2049


A következő lépés a pluginok engedélyezése. A következő pluginokat engedélyezzük:
  • Backdoors
  • CGI abuses
  • CGI abuses:XSS
  • CISCO
  • Databases
  • Default Unix Accounts
  • Denial of Service
  • DNS
  • Firewalls
  • FTP
  • Gain a shell remotely
  • General
  • Misc.
  • Mobile devices
  • Netware
  • Peer-To-Peer File Sharing
  • Policy Compliance
  • RPC
  • Service Detection
  • Settings
  • SMTP Problems
  • SNMP
  • Web Servers
  • Windows
  • Windows:Microsoft Bulletins
  • Windows:User Management
Ha kész vagyunk mentsük el az új policyt.
Készítsünk egy új szkennelést a célgépre:

New Scan -> External Scan full + Web

Indítsuk el a vizsgálatot.

Íme az eredmény:


Készítettem egy Credentialed vizsgálatot is, amikor a Nessus egy privilégizált felhasználóval belép a gépre és helyben ellenőrzi a sérülékenységeket:

Az eredményt mentsük ki html fileba (Professional verzióban pdf-be) és tegyük el későbbi felhasználásra.

2015. november 3., kedd

Penetration Testing on metasploitable 2 - Vulnerability Analysis - port scan

A sérülékenységi elemzés első része, miután az ip címeket sikerült behatárolni minden esetben a port szkennelés kell legyen. A tapasztalat azt mutatja, hogy ezt a lépést nem célszerű teljesen automtikus eszközökre bízni. Először is meg kell állapítani, hogy az adott ip címet védi-e valamilyen port szkennelés elleni védelmi eszköz (IPS, IDS) Amennyiben van ilyen védelem, akkor azt kell detektálni és a megkerülésére valamilyen stratégiát kidolgozni. Ez egy külön téma, itt most ezt nem tárgyalom. Feltételezem, hogy a célpont előtt nincs ilyen védelem így a port szkennelés mehet mindenféle trükközések nélkül.

A TCP és az UDP portokat én külön szoktam felmérni, a kapcsolat jellege miatt.

Általános tcp syn scan:
nmap -sS -p 1-65535 -v --reason 192.168.56.102

Ez csak a nyitott portokat adja vissza és azt is megmondja, hogy miért gondolja hogy az adott port nyitott.

Itt fontos tényező, hogy az adott vizsgálat mennyi ideig fut. Ezt a lépést érdemes jól elvégezni, mert ide általában már nem tér vissza az ember és amennyiben itt valamiért elszalasztott érzékelni egy nyitott portot (pl: hálózati problémák miatt) akkor az ki fog maradni a vizsgálatból. Ha a -v kapcsolót megadjuk, akkor a program időnként életjelet ad magáról és közli, hogy mikorra várható a végeredmény illetve hogy milyen portokat talált és egyéb üzenetek:


A remaining (fennmaradó) idő 1:34:04. Ami azt jelenti, hogy egy teljes 65535 portra kiterjedő vizsgálat a visszajelzés szerint kb másfél óra ebben az esetben. A -T kapcsolóval lehet növelni a vizsgálat agresszivitását, de ez általában csak lan környezetben illetve virtuális labor környezetben gyorsítja fel a dolgokat. Éles helyzetben általában a nagyon agresszív szkennelés ip cím kitiltását vonja maga után. Amikor az interneten keresztül történik a szkennelés és még különféle trükközéseket és lassításokat is kell alkalmaznunk, akkor ez a szkennelés több órás, akár fél napos is lehet. Célszerű stabil hálózati kapcsolattal rendelkező végpontból elindítani. (kábeles hálózat a WiFi helyett és nem terhelt hálózati szegmens)

Miután lefutott a szkennelés el tudjuk készíteni az első táblázatunkat melyben fel vannak sorolva a nyitott TCP portok:


 Nmap done: 1 IP address (1 host up) scanned in 8778.46 seconds
           Raw packets sent: 203394 (8.922MB) | Rcvd: 6864 (274.744KB)
Mint látjuk a teljes vizsgálat több mint 146 percig (két óra és 256 perc) futott vagyis több mint 2 órát.
Miután ez lefutott tudunk egy táblázatot készíteni a nyitott portokról:



A talált portokra ezután érdemes lefuttatni egy szolgáltatás feltérképező parancsot:

nmap -sV -pT:21,22,23,25,53,80,111,139,445,512,513,514,1099,1524,2049,2121,3306,3632,5432,5900,6000,6667,6697,8009,8180,8787,38752,38864,42069,57427
  --version-intensity 9 -v 192.168.56.102


Nmap done: 1 IP address (1 host up) scanned in 416.36 seconds
           Raw packets sent: 34 (1.472KB) | Rcvd: 31 (1.360KB)
Ez a vizsgálat már csak körülbelül 7 percig tartott és jóval kevesebb forgalmat generált, mint az első.
Ez után elő tudjuk állítani a kettes számú táblázatunkat, a felderített szolgáltatásokról. Ennek az inputja a korábban elkészült nyitott portokról készült táblázat és a második nmap kimenete. Amennyiben több gép lenne, akkor több vizsgálandó szolgáltatásunk lenne egymás alatt szép sorban.



Végül a feltárt portokra érdemes lefuttatni egy nmap -A parancsot is, hogy a szolgáltatások egyéb tulajdonságait is lássuk.

nmap  -A -pT:21,22,23... -v 192.168.56.102


(Több környezetben végeztem a munkát emiatt van néhol 101 máskor pedig 102 ip cím végződés)

Ez kb 3 percig futott. Ennek a kimenetét egyelőre nem használjuk, eltesszük későbbre amikor majd a szolgáltatásokon egyesével végigmegyünk.

A fenti lépéssorozatot meg kell ismételni az UDP portokra is. Itt nem célszerű mind a 65535 portot megnézni, mert az nagyon sokáig futna és a sima szkennelés nem minden esetben ad megbízható eredményt.

nmap -sU --top-ports 1000 -v --reason 192.168.56.101



Miután a nyitott/filterezett portok listája meg van megpróbáljuk a szolgáltatásokat beazonosítani:

nmap -sUV -pU:53,68,69,111,137,138,2049 --version-intensity 9 -v 192.168.56.102
Végül itt is célszerű az nmap -A futtatása a nyitott portokra:
nmap -sU -A -pU:53,68,69,111,137,138,2049 -v 192.168.56.102

A kimenetet eltesszük későbbre amikor a szolgáltatásokon egyesével végigmegyünk.

Egyes esetekben (pl: mobile stick alkalmazása esetén) az internet szolgáltató blokkolhat egyes portokat vagy proxyzhat bizonyos szolgáltatásokat és ilyen esetben előfordul, hogy bizonyos portokat nem érünk el közvetlenül más portok viszont nem élnek, csak a szolgáltatónk proxyja válaszol a kérésekre. Ezt le kell ellenőrizni mielőtt tovább mennénk.

Penetration Testing on metasploitable 2

Nemrég volt egy munkám amiben különböző gépek különböző portokon futó különféle szolgáltatásait kellett megvizsgálni és volt pár webes vizsgálat is a szkópban. Mivel kicsit döcögősen ment az eleje, elhatároztam, hogy készítek magamnak egy segéd dokumentációt, hogy ilyen esetekben milyen lépésről lépésre meghatározott feladatsort kell lefuttatni a teljeskörű hibakeresés érdekében. A programok finomhangolásához a metasploitable 2 virtuális gépet fogom felhasználni. A webes módszerek csiszolására pedig az OWASP Broken Web Application Project virtuális gépét. Mind a két virtuális gép letölthető a VulnHub-ról.

A lépések összeállításához a PTES-t az OSSTMM-et és az OWASP 4.0 testing guide-ot fogom felhasználni, illetve a Webes módszerek kicsiszolásához a  WAVSEP Web Application Scanner Benchmark 2014-t.

A hálózat felderítési lépéseket egy konkrét ismert célpontra vetítve fogom elvégezni. Az itt használatos szoftvereket azon a célponton fogom tesztelni.

A PTES szerint a vizsgálatnak a következő lépései lehetnek:
  • Pre-engagement 
  • Intelligence Gathering
  • Vulnerability Analysis
  • Exploitation
  • Post Exploitation
  • Reporting

Jelenleg a Vulnerability Analysis kérdéskört járom kicsit körbe, a többivel később kívánok foglalkozni.

A PTES szerint ennek a következő fázisai vannak:
  • Testing
  • Active
  • Passive
  • Validation
  • Research
Elsősorban az Active és a Validation pontok lesznek kivesézve.

Az Active tesztelés lehetséges lépései:
  • Automated
  • Manual Direct Connection 
Az automatikus tesztelés során alkalmazható lépések:
  • Port Scan
  • Service Detection (Bannes Grabbing)
  • Network/General Vulnerability Scanners (Nessus, Nexpose, OpenVAS)
Webes sérülékenységek felkutatására
  • Web Application Scanners
  • Directory Listing/Brute Forcing
  • Web server Version/Vulnerability Identification 
(A Webes sérülékenységi vizsgálatokra egy külön szekciót tervezek, úgyhogy itt ennél jobban nem részletezném, hogy milyen egyéb lépések vannak)

További vizsgálatok:
  • Common/default Usernames Passwords
  • Common misconfigurations
  • Backup files
 A fenti pontokat tervezem több-kevesebb részletességgel kielemezni. Mikor milyen esetekben milyen lépések elvégzése célszerű, ajánlott, lehetséges. Milyen szoftverek használatával milyen konfigurációs beállításokkal.

2015. március 27., péntek

Sebességmérés Hacking

Ma az Origón olvastam, hogy rettegni kell a sebességméréstől, mert húha.

Egy kicsit utánanéztem a dolgoknak, hogy mitől is kell annyira rettegni. Szerencsére a rendőrségen alapos munkát kell végezni és előre meg kell tervezni, hogy a szép új sebességmérő eszközök mikor hol lesznek kitéve. Egy kis olvasgatás után elég egyszerű felfedezni valami algoritmust ami alapján a rendszer működik. Miután az algoritmus ismert esetleg nem is kell annyira rettegni.
Az origós cikk:
http://www.origo.hu/auto/20150325-mar-buntetnek-az-uj-veda-traffipaxok.html
A rendőrségi tervek:
http://www.police.hu/hirek-es-informaciok/utinfo/sebessegellenorzesek
A PDF-et én itt alakítottam át szöveges állománnyá:
http://www.zamzar.com/convert/pdf-to-txt/

Mivel Bp-en élek engem elsősorban ez érdekelt, de a többi helyszínre is el lehet végezni a műveleteket.
Itt vannak a márciusi tervek:  http://pastebin.com/mS2vySLm
Itt pedig az áprilisi tervek: http://pastebin.com/kwQUkJUX

A szöveges fileokat betettem egy könyvtárba és utána elvégeztem velük pár műveletet. Először is előállt ez a lista: http://pastebin.com/YgGy8kh4 Ebben a fileban azok az utcák vannak ahova a sebességmérő egyáltalán ki lesz téve. figyelmesen átnézve rá lehet jönni, hogy egyes kerületekben nem is lesz kint a mérő semmikor sehol. Itt tehát nem kell annyira rettegni.

A másik, hogy vannak egyéb dolgok is amit ki lehet olvasni a rendszerből. Ha adott egy útvonal amerre az ember szokott járni, akkor nincs más dolga, mint az útvonalat végig ellenőrizni, hogy melyik szakaszon melyik napokon és milyen napszakban tervezik kitenni a mérőket.

Ez persze nem jelenti azt, hogy a terveket később ne változtatnák meg, de mvel egy ilyen terv kidolgozása nem kis logisztikai feladat ezért valószínű, hogy havonta nem fogják ezeket újra tervezni, inkább csak finomítások várhatóak. Mivel amikor egy mérés az adott helyen befejeződött át kell menni az új helyszínre és ezt azért meg kell tervezni, hogy optimális legyen az eszközök kihasználtsága. Ha ezt egyszer kidolgozták akkor egy darabig biztos nem fogják teljesen átdolgozni a rendszert.

Nézzünk egy példát: Néha szoktam az Albertirsai úton menni, tehát rákerestem, hogy itt mikor várható a mérők kihelyezése:

Az látszik, hogy itt csak reggel 7 és 8:30 között várható mérés. Ha tovább nézzük, akkor azt látjuk, hogy Március 10-> kedd, 13-> péntek, 24-> kedd, 27-> péntek, április 7-> kedd, 24-> péntek.

Elmondható, hogy az Albertirsai úton leginkább kedden és pénteken 7 és 8:30 között kell odafigyelni, hogy az ember ne lépje túl a sebességet, legyen bekötve az öve és ne mobilozzon, illetve más szabálysértést se nagyon kövessen el. (Záróvonalon előzés, stb)

Az Albertirsai út egy tipikusan olyan hely, ahol általában nem figyelnek oda annyira az emberek, könnyen 70 fölé mehet az ember, mivel nincs forgalom és ha nincs valami rendezvény a Hungexpon akkor eléggé kihalt a terület. Tehát lehet tempósabban haladni mint általában a városban ahol amúgy egyébként is dugó van sok helyen majdnem egész nap.

Ez persze nem garancia semmire, de legalább akkor mikor számítani lehet a mérésre jobban oda lehet figyelni, hogy az ember mit csinál. A rendőrség évi több tízmilliárdos bevételre számít és azt a szabálytalanságon kapott állampolgároktól tudják csak beszedni. Ha nincs szabálytalanság, bírság sincs.

Érdemes egyszer végigpásztázni azt az útvonalat amerre az ember járni szokott és rögzíteni, hogy mikor lehet tervezetten mérésre számítani. Így legalább az elkerülhető, hogy akkor ne büntessenek meg amikor tudni lehet, hogy számítani kell rá. Természetesen szabályosan kell közlekedni, a szabályokat betartva, de ha tudjuk, hogy számítani lehet a mérőeszközre, akkor még körültekintőbbek tudunk lenni.

Azt is meg lehet nézni, hogy milyen útszakaszokon mérnek reggel (mikor siet az ember a munkába) és hol mérnek este, amikor a gyérebb forgalom miatt hajlamosabb az ember kicsit jobban nyomni a pedált. Ha valaki kiszújra, hogy hol állítják fel a mérőt, akkor pedig legközelebb már eleve tudja, hogy hol, melyik útszakaszon kell jobban odafigyelni. (Általában a mérés helyszínét sem szokták nagyon változtatni, mert nem mindegy, hogy honnan mérnek. Mennyire kiszúrható messziről a mérő. Általában próbálják úgy felállítani, hogy ne lehessen kilóméterekről észrevenni. És egy útszakaszon behatárolt helyek jöhetnek csak szóba ahonnan érdemes mérni.)

Nézzünk azért még egy példát. A Mogyoródi út. Erre is szoktam járni, úgyhogy ez is érdekel, hogy itt mikor méregetnek (Asszem tegnap pont láttam hogy hol mérnek, mondjuk tegnap bringával jöttem :)

Itt mi az algoritmus? Általában hónap elején és végén mérnek.Mondjuk a hónap második hetében és a negyedik héten. Mikor? Kedden, szerdán, csütörtökön, szombaton és vasárnap. Hétfőn és pénteken nincs mérés a tervek szerint. Időben mikor? Gyakorlatilag reggel 7:30-tól 18:30-ig. Szinte egész nap. Kivéve hét végén, mert akkor szombaton csak 10:30-tól vasárnap pedig csak 14:30-tól.
A Mogyoródi út elég hosszú, de mivel nagyon sokszor mérnek többször el lehet menni, hogy az ember rögzítse a fejében, hogy hol, melyik szakaszom mérnek és merre. El is lehet kerülni az egészet, ha az ember az Egressy úton vagy a Fogarasi úton megy. Ott nincs tervezett mérési pont.

Arra is rá lehet keresni, hogy este felé és hajnalban hol mérnek:
findstr "20.00" brfk*sajtonak2.txt
findstr "19:30" brfk*sajtonak2.txt

Ami engem érint, az a Csömöri út vagy a Fogarasi út. Mikor mérnek itt? Úgy látom, hogy csak márciusban, áprilisra ide nem terveztek mérést. Márciusban egyébként hétfő és péntek volt kitűzve 20-tól 21:30-ig.  Reggel vagy délután, illetve késő éjszaka "tiszta" az útvonal. A Késmárk utcában pedig márciusban csak szombat reggel-délelőtt illetve áprilisban hétfő reggel-délelőtt volt tervezett mérés. Tehát este felé itt valószínűleg nem mérnek (amikor én erre járok általában)

A hajnali órákra is rá lehet keresni:
findstr "02:00" brfk*sajtonak2.txt
findstr "03:00" brfk*sajtonak2.txt

Ebből ami engem érdekelhet, az a Dózsa György út, itt általában kedden, pénteken és szombaton mérnek éjjel 2-től  hajnal 5-ig.

A fentiek természetesen nem azt jelentik, hogy máshol (pl járőröző autóból) nem mérhetnek, csak azt, hogy a fenti időpontokban és helyeken számíthatunk rá tehát nem ér váratlanul. A mozgó járőr autók pedig elég jól felismerhetőek távolról úgyhogy ha abból mérnek az se lehet váratlan egy figyelmes sofőr részére.

A fenti módszer egyfajta bypassing technika, amivel a tervezett ellenőrzés megkerülhető. Ha ismertek a helyszínek és az időpontok, akkor lehet kerülő utakat készíteni ami elkerüli az adott ellenőrző pontokat vagy pedig lehet fókuszálni az ellenőrző pontok környékére így a szabályszegés kerülhető el.

A gondolatmenetet tetszés szerint lehet tovább finomítani. Esetleg folyamatosan figyelni a publikált terveket és azok alapján kiigazítani a korábbi algoritmusokat.

Egyébként pedig széles utat és gumi fákat és szabálytalanság mentes közlekedést kívánok mindenkinek :-)

2015. március 20., péntek

OSCP vizsga

Tegnapelőtt sikeresen megcsináltam az OSCP vizsgát. Szerdán 12:00-kor kezdődött. Az első fél órát eltököltem a doksi olvasgatásával, meg a gépemen windows frissítést csináltam, hogy később ez ne zavarjon.

Utána végig portszkenneltem a gépeket és nagyjából kitaláltam egy sorrendet, hogy hogy fogok haladni. Elsőnek megcsináltam egy 25 pontos gépet (maximum 100 pontot lehetett elérni és 70 kellett a sikeres vizsgához). Utána jött egy 20 pontos, majd egy 25 pontos gép. Ekkor már meg is volt a szükséges pontszám. Utána volt egy 10 pontos gép még annak is nekiálltam. Az egyik gépet ráadásul kétszer is meg kellett csinálnom, mert volt egy lehetőség amit csak egyszer lehetett felhasználni és egy másik gépre kellett ellőni úgyhogy azt a gépet kétszer törtem fel :) két különböző módon. Ekkor már meg volt 4 gép és még csak este 8 volt. Összesen 8 óra kellett a 4 gép megszerzéséhez.

Ekkor kicsit belazultam, mert innentől kezdve már nem volt kérdés, hogy meg lesz-e a vizsga vagy nem. Elmentem a barátnőmért, megvacsoráztunk, leültem kicsit TV-t nézni. Így el is ment egy kis idő.

Mivel még nem voltam álmos gondoltam nekiállok az 5-ik gépnek is. Ez olyan este 10 körül volt. Teljesen rossz uirányba indultam el és kb hajnal 4-ig köszködtem így, mikor kicsit megálltam megint pihenni és újra elkezdtem előről nézegetni a gépet. Találtam egy olyan lehetőséget amit először nem vettem észre és ez új löketet adott. Ezen a nyomon elindulva ez a gép is meg volt 2 óra alatt. (összesen vagy 8 órát eltöltöttem vele, annyit mint a másik 4 gépre együtt).

Körülbelül reggel 6 és fél 7 körül lettem kész. Összesen olyan kb 18 óra kellett a gépek feltöréséhez (ebben benne van, hogy közben TV-zgettem/vacsoráztam)  Összességében elégedett vagyok a teljesítményemmel. A laborban feltörtem majdnem 40 rendszert és még ezt az ötöt a vizsgán. Jól sikerült a felkészülés és minden tudást meg tudtam szerezni ami a vizsga teljesítéséghez kellett.

Októbertől márciusig 5 hónap volt a teljes felkészülési idő, de már korábban is készülgettem különféle feladványok megoldásával. A CEH után lett még egy trófeám. Ráadásul a vizsgán 100%-osan teljesítettem. Fel is tettem magamnak a kérdést: "Örülünk Vincent?" És igen. Most örülök. Remek volt a tanfolyam és a vizsga is. Most egy kis pihenő következik. :)

A VulnHub-os gépekkel való tökölés megérte. Volt egy gép amit úgy sikerült feltörnöm, hogy egy ottani gép megoldásának a leírásból szedtem. Ha nem ismerem ezt a módszert nem sikerült volna megoldani azt a feladatot.

Tegnap elkészítettem a doksit is. Szép színes szagos pdf lett belőle. Beköttetem és elteszem a polcra. Ha kell majd mennem állásinterjúra viszem magammal mint referencia munka. Elég sok féle módszer be van mutatva benne :)

2015. február 27., péntek

SkyTower VulnHub challenge

Jó rég írtam már ide. (Pedig lenne bőven míröl, csak lusta vagyok rá)

Legutóbbi feladvány amivel foglalkoztam a VulnHubos SkyTower. Íme képekben:
nikto:
dirb és dirbuster semmi eredményre nem vezetett, így azok dokumentálását mellőzöm.
A login oldalon találtam egy sql hibát:

Mivel az sqlmap nem mutatott ki semmit megnéztem Burppal, hogy mi a helyzet:
filterezés van. de ez nem jelenthet akadályt:

ssh direktben nem ment, de a squid-en keresztül 127.0.0.1-re igen:
login után egyből ki is lépett, emiatt a .bashrc-ből ki kellett venni a végéről az exit-et.
mivel egyebet nem találtam megnéztem, hogy a mysql-al mit lehet kezdeni:

Így könnyen be lehetett lépni:
Megnéztem SkyTech-ben van-e valami érdekes és igen:
utána megpróbáltam sara userrel is belépni:
innen már nem volt messze a vége:
Pedig találtam exploitot is, csak épp nem volt a lemezen hely , hogy fel tudjam másolni:
 A legtöbbet az sql waf bypasszolással tököltem, de a squiden keresztüli ssh se volt annyira triviális, ott is olvasgatnom kellett, hogy hogyan.  Mindenesetre nagyon jól szórakoztam és megint tanultam pár dolgot. Jöhet a következő feladvány.

2014. március 16., vasárnap

irisscon 2012 CTF challenges

A hét végén ezzel szórakoztam:

http://damienoreilly.org/ctf/index.php

Ennyire futotta egyelőre:











A Wechallon feljöttem a 11 helyre :)






Elkezdtem reverse engineeringgel foglalatoskodni és már a szimpla feladványokat meg tudom oldani ezzel a kevéske tudással :)


A HackTisSite.org-on vannak nagyon jó kis feladványok :






Meg a ThisIs Legal.com-on is lejutottan egy darabig:


Egyenlőre ennyi.