2015. november 6., péntek

Penetration Testing on metasploitable 2 - Validation phase - Tcp port 21 - FTP service

A táblázatunkban az első vizsgálandó szervíz a 21-es porton futó ftp szolgáltatás. Mielőtt belemerülénénk a vizsgálódásba nézzük meg, hogy az egyes eszközök segítségével milyen információhoz jutottunk:

Nmap:
21/tcp    open  ftp         vsftpd 2.3.4
Nessus:

OpenVAS:

Nexpose:
Igazából három különböző kockázatot érzékeltek a szkennerek. (A nessust fogom mindig alapként használni, mert áttekinthetőbb a riport amit készít, és a másik két szkennernél csak azokat a jelzéseket hozom fel, ami bővebben kifejti a hibát illetve más hibát fed fel.)

Az első és a legkritikusabb kockázat, hogy van egy hátsó ajtó a rendszerben. Ezt a Nexpose nem ismerte fel(...) viszont a nessus és az openvas igen.

Nmap-al is ellenőrizhetjük:
A nessushoz tartozó plugint is ráengedhetjük kézzel is:
Metasploitban is ban hozzá használható modul:
Ezen a ponton célszerűnek látszik a shadow file kidumpolása:
Erre le kell futtatni egy john-the-rippert, hátha talál a felhasználói nevekhez jelszavakat.

Exploitdb-n is rá tudunk keresni a problémára, ha az előzőek nem hoztak volna eredményt:
Securityfocus is egy jó hely a keresésre:
Kali linuxon a searchsploit is egy kereső amivel próbálkozhatunk:
A CVE Details adatbázisban is rákerestem, de ott nincs fent a hiba...

Talán  ezért nem találta meg a Nexpose, holott a metasploitban még modul is van hozzá.
Mindegy, ez egy Validált (nem false pozitív) létező hiba. Elérhető exploit csak a metasploitban van rá, illetve a nessus nasl szkriptjével lehetne még esetleg szórakozni vele.
A hiba kihasználhásával nem kell itt különösebben foglalkozni, elég ha azt meg tudjuk állapítani, hogy a hiba valós és elérhető hozzá exploit. Így a hiba a nagyon súlyos kategóriába esik, mivel a gépen a támadó azonnal root jogot képes szerezni. Ez a hiba mindenképpen javítandó és minél sürgősebben.

A második probléma(?) hogy az anonymous elérés engedélyezve van. Ez nem biztos, hogy valós probléma, mert lehet, hogy ez egy anonymous ftp szerver és pont ez a cél. Mindenesetre, hogy ez false pozitívnak számít-e azt az alkalmazás dönti el. Az, hogy mi célból funkcionál a szolgáltatás.

A harmadik probléma, hogy cleartext-ben mennek az adatok. Ha ez csak egy anonym ftp szerver és senki nem lép fel rá a neten keresztül (az adat feltőltés biztonságos csatornán történik) és publikus adatok vannak rajta publikálva, akkor ez is false pozitív. Amennyiben bármilyen érzékeny adat (pl jelszó) közlekedik a hálózaton, akkro ez az adattól függően vagy közepesen súlyos vagy súlyos probléma is lehet akár. Ez az adott adat érzékenységétől függ.

Azt meg kell még nézni, hogy írás joga van-e az anonymous ftp usernek. Illetve, hogy mihez van olvasási joga. (Valószínűleg, ha ez exploitálható lenne akkor azt már rég észlelték volna, de egy ellenőrzést megér)

A táblázatban ezt a szolgáltatást Unsafe-re állítjuk (nem biztonságos) és a kockázatot a legmagasabbra vesszük. Súlyos vagy kritikus és piros színnel jelöljük, hogy a menedzserek is lássák, hogy itt valami nagyon nem jó. És a kritikus kockázat mellett a másik két problémát is fel kell tüntetni.

A kritikus probléma megoldására a javasolt megoldás a teljes verzió csere. Patch nincs a problémára és work-around megoldások sem. A szolgáltatást azonnal le kell állítani és egy másik verziójú ftp daemont kell feltelepíteni a gépre. A másik két észrevétel alkalmazás függő. Ha szükséges az anonymous elérést le kell tiltani, illetve ha érzékeny adatok közlekednek a hálózaton, akkro az egész szolgáltatást le kell cserélni olyanra ami rejtjelezi a csatornát. (scp, sftp, stb)

Ha a feladat áthatolás tesztelés, akkor a hiba segítségével további (belső hálózaton lévő) gépek támadása válik lehetségessé. A fertőzött gépre telepíteni kell egy saját hátsó ajtót és utána mehet a belső hálózat feltérképezése és további célpontok utáni kutatás. (Amennyiben ez szkópja a vizsgálatnak)

Mivel az ftp user ftp jelszóval működik, célszerű lehet más default felhasználók és default jelszavak tesztelése az ftp protokoll alatt. A loginok tesztelését egy későbbi fázisban fogom elvégezni, egyben a többi login teszteléssel (ssh, telnet, stb) 
ftp login tesztelése metasploittal:

Ez egy kicsit lassan fut, úgyhogy hydrával csináltam meg inkább:
Ennél a szolgáltatásnál van még egy probléma: Lehetséges a login brute forcolás, vagyis tömeges belépési kísérletekkel lehet elérasztani a rendszert. Ez ellen lehet lokálisan fail2ban-al, vagy globálisabb szinten IDS,IPS rendszer működtetésével védekezni.

Penetration Testing on metasploitable 2 - Automated Scanners - Nexpose

A következő sérülékenység vizsgáló eszköz a Nexpose. első lépésben hozzunk létre egy site bejegyzést:


Állítsuk be a Sitehoz az ip címet:
Állítsuk be a Template-nél a Full audit-ot és mentsük el.
Ha a Save & Scan-t választjuk, akkor el is indul a vizsgálat:
A sor végén találunk egy download log gombot,:
Ha rákattintunk felajánlja hogy elmentsük a fájlt vagy megnyissuk:
A logban meg tudjuk nézni, hogy hol tart a folyamat. Azt is meg tudjuk nézni, hogy a nexpose milyen nmap parancsot használt a felderítéshez:
Ha lefut a scan a státuszban láthatjuk, hogy Completed successfully:
Miután lefutott készítsünk egy reportot a talált hibákról:
Válasszuk ki az elsőt: Audit report.
Válasszuk ki a megfelelő site-ot (Select site gomb alul)
Ezután válasszuk ki a vizsgálatot (szkennelést):
Adjunk meg egy nevet a reportnak:
Mentsük el a Save & Run reporttal:
A reportot meg tudjuk nézni a View reports fülön:
A Vulnerabilities menüben meg tudjuk nézni a sérülékenységeket tételesen:
A program azt is meg tudja állapítani, hogy a sérülékenységhez létezik-e exploit illetve hogy a metasploitba integrált exploit létezik-e.
A keletkezett riportot mentsük el később még használni fogjuk.
Ok, a szkennelésnek ezzel a részével végeztünk. (A nexpose-nál nem minden portot derített fel a program. Ezzel csak akkor érdemes foglalkozni, ha az adott porton a másik két szkennerrel és egyéb módon se találtunk problémát, akkor meg lehet nézni, hogy ha a nexpose port listájába felvesszük és megint lefuttatjuk a vizsgálatot, akkor találunk-e valamit.

A szkennerek vizsgálatai nem 100%-osak. Nessus és OpenVAS esetén a nasl szkripteket kézzel is le tudjuk futtatni, ha kézzel akarjuk ellenőrizni egy-egy probléma meglétét.

A Nexpose olyan hibákat is kimutatott amire az egyes komponensekből következtetett. Nem a port szkennelése alapján, hanem pl az operációs rendszer verziószáma alapján is felsorol hibákat. El kell dönteni, hogy ezzel foglalkozunk-e szkópja-e ez a vizsgálatnak. Amennyiben csak a külső portok vizsgálata a szkóp, akkor ezzel nem foglalkozunk, csak megjegyezzük, hogy egyébként érdemes lenne egy credentialed ellenőrzést is lefuttatni a hostra mert lehetnek rajta egyéb hibák amiket külső szkenneléssel nem lehet detektálni. 

A következő lépés, hogy a szolgáltatásokon egyesével végigmegyünk és meghatározzuk a kockázati szintjét illetve adunk egy javaslatot, hogy az adott hibát hogyan lehet kiküszöbölni. Kummuláljuk a hibákat és a végső riportban csak azokat tüntetjük fel, ami releváns és a legsúlyosabb problémát okozza.

A szolgáltatásokon a port szeknneléskor készített táblázat alapján megyünk egyesével végig és megnézzük, hogy az adott szolgáltatás mennyire biztonságos, hány különféle probléma van vele és milyen javításokat javasolunk a hiba elhárítására.

Penetration Testing on metasploitable 2 - Automated Scanners - OpenVAS

A következő automata szkenner amit meg fogok nézni az az OpenVAS. Én a Kali 2.0-s telepítést használtam, de le lehet tölteni virtuális gépet is (OpenVAS- Demo-8) Azzal is hasonló eredményt lehet elérni.

Első lépésben a szkennelés paramétereit kell beállítani. Vegyünk fel egy új port listát:
Configuration -> Port List, a csillag jellel tudunk új listát felvenni:

Írjuk be a portok listáját a Nessus-nál használt szintaktikával: T:21,22,23,...U:53,68,69,...
Nyomjuk meg a Create Portlist gombot így elmentettük az új listánkat.

Ez után készítsünk egy új szkennelő konfigurációt (pluginok listája)
Configuration -> Scan Configs: Csillag (New Scan Config)
Mentsük el, majd a villáskulcs ikon kiválasztásával editáljuk a pluginek listáját:
Még nem teljesen világos, hogy pontosan melyik plugin mit csinál, de később majd pontosítom ezt az információt. Mivel ez a Nessus-ból lett forkolva, alég hasonlóak a pluginok.
Vegyünk fel egy új targetet. Configuration -> Targets csillag jel (New Target)



 Amikor ez is kész van készítsünk egy új taskot. Scan Management -> Tasks. Csillag jel (New Task)
Scan targets opciónál válasszuk ki az általunk készített targetet és a Scan Config-nál is azt a konfigot amit erre a feladatra készítettünk. Amennyiben az általunk készített konfig nagyon lassú lenne, akkor válasszuk helyette a Full and very deep beállítást.
 Indítsuk el a szkennelést. A Scan Management -> Reports alatt tudjuk nézni, hogy hány sebezhetőséget talált a program és hány százaléknál jár a szkennelés.

Ha rákattintunk a Date oszlopban lébő elemre részletesen meg tudjuk nézni, hogy a szkenner éppen mit csinál.

Egy Full and very deep konfigurációval is sikerült jónéhány hibát megtalálni:
 
A kimenetet mentsük el későbbi felhasználásra.

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.