Penetration Testing on metasploitable 2 - Validation phase - Tcp/Udp port 53 - DNS service

A következő két port az 53-as tcp és udp port.
Nézzük, hogy a korábbi vizsgálatok mit mondanak erről a szolgáltatásról:
Nmap:
53/tcp open  domain  ISC BIND 9.4.2
53/udp open  domain  ISC BIND 9.4.2
Nessus:

OpenVAS
Az openVAS nem talált semmit erről a szolgáltatásról.
Nexpose

Cve - Details:

Itt célszerű egy verziófrissítést javasolni ahelyett, hogy az összes problémát egyesével végignézné az ember, hogy melyik milyen hatással lehet a szolgáltatásra illetve a működtető rendszerre. Működő exploit csak DoS támadáshoz található vagyis a kockázat a verzióval kapcsolatban, hogy szolgáltatás megtagadásos támadást lehet ellene kivitelezni. Távoli kódfuttatási lehetőséghez letölthető exploit nem volt.

Ami még ezzel kapcsolatban éles helyzetben lehetne vizsgálni az a zóna transzfel, illetve a különböző dns brute forcoló technikák alkalmazása de ezek nem kötődnek egy adott dns szerverhez így ezeket itt nem tárgyalom.

Penetration Testing on metasploitable 2 - Validation phase - Tcp port 23 - Telnet service - Tcp port 25 - Mail service

A telnet porttal kapcsolatban a következő észrevételek lehetnek: A port nincs titkosítva így a távoli elérés nem biztonságos. Nincs védve brute forcolás ellen, így el lehet árasztani tetszőleges belépési kísérlettel. A telnet banner érzékeny információt tartalmaz:

A login felület két érzékeny adatot is tartalmaz: az egyik egy mail cím a másik egy usernév/jelszó páros. Ezek közül a usernév/jelszó páros kritikus hiba míg az e-mail cím csak médium és információszivárgásnak minősül. Az adott információ birtokában a belépési kísérleteket le lehet szűkíteni az adott felhasználóra. A javaslat a szolgáltatás tiltása az internet irányából és ha lehetséges akkor a lokális hálózat irányából is. Ha semmiképpen nem lehet tiltani, akkor a felvetett hibák orvoslása szükséges. Brute force megakadályozása, érzékeny információk eltüntetése a bannerből, titkosítás alkalmazása valamilyen tunnelen keresztül (pl stunnel, vagy vpn)

A mail szolgáltatással kapcsolatban néhány észrevétel merül fel. Melyek ezek:

Ezt hibát a Nessus és az OpenVAS külső szkennere nem észlelte. A Nessus credentialed ellenőrző szkriptje talált egy másikat:

A hiba jellege közepes,mert helyi felhasználó szükséges a kihasználásához és privilégium emelésre alkalmas.A hiba javítása javítócsomag vagy újabb verzió telepítésével lehetséges. A hiba ellenőrzéséhez vagy kihasználásához lokális felhasználói elérés szükséges. Létezik egy harmadik hibához letölthető exploit:

A Cve details alapján a hibák összefoglalva:

Az egyik hibát megtalálta a Nexpose külső szkennere, a másikat a Nessus belső szkennere, de a legjobb, ha ellenőrizzük a cve details-on, hogy az összes hiba kibukott-e ami az oldalon lehetséges.
Mail szerver esetén meg lehet még nézni, hogy open relay-e a szerver

(nem volt az) illetve, hogy fel lehet-e  szerveren keresztül deríteni a felhasználókat.

 

fel lehetett. Ez utóbbi ellen a mail szerver konfigurálásával lehet valamennyire védekezni, de 100%-os védelem ez ellen nincs, mivel ha egy legális szerverről jön a kérés akkor azt a szerver ki fogja szolgálni és ez alapján el lehet dönteni, hogy egy adott felhasználó létezik-e a rendszerben vagy nem. Spam szűrő és vírusirtó tesztelését is el tudjuk végezni, ha küldünk egy teszt üzenetet egy kiválasztott felhasználónak:

Penetration Testing on metasploitable 2 - Validation phase - Tcp port 22 - SSH service

Nézzük a következő szolgáltatást.

Nmap:
22/tcp    open  ssh         OpenSSH 4.7p1 Debian 8ubuntu1 (protocol 2.0)
Nessus:

OpenVAS:
Az openvas nem talált semmi számottevő vagy értékelhető információt erről a szolgáltatásról.
Nexpose:

A két szkenner kritikusnak találta a dolgot. Nézzük meg közelebbről, hogy miért:

 Nexpose:

 

Ez ugyanaz a hiba, De van még más is: A 7.0 alatti verziók kritikus sérülékenységgel rendelkeznek.

A user felhasználóval be lehet távolról jelentkezni, mert a jelszava alapértelmezett, könnyen kitalálható.

Megoldás a verzió problémára:

 

Amennyiben áthatolás tesztelés a feladat, akkor a Core Impact-hoz van használható exploit hozzá. Amennyiben nincs Core Impactunk, akkor az exploit db-n is van használható kód:

Itt is három különböző probléma áll fenn: Az egyik, hogy az openssl random szám generátora rosszul működik, emiatt a kulcsok kitalálhatóak. A második probléma, hogy a 7.0  előtti openssh verzióban sok egyéb más hiba van.  A harmadik pedig, hogy a user felhasználónak kitalálható a jelszava.

Az első problémára a megoldás, hogy fel kell telepíteni egy korszerűbb openssl csomagot és újra kell generálni a kulcsokat. A második problémára a megoldás, hogy az openssh csomagot frissíteni kell a gépen.
Végül a harmadik hibát úgy lehet javítani, hogy a gyenge jelszót lecseréli a user felhasználó.

Offsec laborban volt egy gép ami ugyanezzel a hibával rendelkezett, elvileg egyszer már sikerült ezt a problémát megoldani akkor. A rend kedvéért megoldom itt is és Core Impact-al is megpróbálom kihasználni a hibát. Gyakorlásnak jó lesz.

Amit még itt is el kell végezni az a default loginok tesztelése. Ha a user felhasználó user jelszóval rendelkezett, akkor meg kell próbálni más default felhasználói fiókokat alapértelmezett jelszavakkal.
A jelszó tesztelés egy külön körben lesz, úgyhogy ezzel itt most nem foglalkozom. 
A login brute force-ot a hydrával lehet a legkényelmesebben elvégezni, a módszer ugyanaz és a usernév jelszó file is:
/usr/share/metasploit-framework/data/wordlists/unix_users.txt
/usr/share/metasploit-framework/data/wordlists/unix_passwords.txt
ez tartalmilag megegyezik ezzel:
/usr/share/wfuzz/wordlist/fuzzdb/wordlists-user-passwd/unix-os/unix_users.txt
/usr/share/wfuzz/wordlist/fuzzdb/wordlists-user-passwd/unix-os/unix_passwords.txt

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.