Penetration Testing on metasploitable 2 - Validation phase - Tcp 2121 - ProFTPD service

A követkető port a sorban a tcp 2121-es. Nézzük mit mondanak erről a szkennerek:
nmap:
2121/tcp  open  ftp         ProFTPD 1.3.1
Nessus:

OpenVAS:

Nexpose:
A nexpose port listájában vagy nem volt benne ez a port vagy nem talált róla semmit. (Inkább az előbbire gyanakszom)

Kihasználható exploitot nem találtam ehhez a verzióhoz. Viszont mivel ez egy ftp szerver olyan, mint a 21-es porton futó szolgáltatás vagyis azokat a vizsgálatokat és megállapításokat itt is el lehet végezni, meg lehet tenni.
Az anonym hozzáférés le van tiltva, úgyhogy ez nem jelent problémát.
Ami problémát jelent, hogy a szolgáltatás brute force-olható és az érzékeny adatok titkosítatlan csatornán közlekednek a hálózaton.
A probléma megoldására verzió frissítés javasolt,vagy ftp helyett sftp használata, ha nincs szükség a szolgáltatásra, akkor a teljes letiltása. Erre több szót nem érdemes vesztegetni.

Penetration Testing on metasploitable 2 - Validation phase - Tcp 1524 és tcp/udp 2049 - remote root shell és nfs service

A következő két port a 1524 és a 2049. Nézzük először a 1524-et.

Nmap:
1524/tcp  open  shell       Metasploitable root shell
Nessus:

OpenVAS:

Nexpose:

Kézi tesztelés eredménye:

A szolgáltatás kritikus, mivel azonnal root jogokat eredményez a felhasználó számára a kapcsolódás. Se jelszót se felhasználói nevet nem kell tudni a kihasználásához. Ez egy igen súlyos hiba a rendszerben. Megoldási javaslat: aszolgáltatás elérhetetlenné tétele, letiltása.

2049 tcp/udp port:
nmap:
2049/tcp  open  nfs         2-4 (RPC #100003)
Nessus:

OpenVAS:

Nexpose:

Az nfs-en keresztűl a root "/" könyvtár mountolható írásra, olvasásra távolról.
A hiba kritikus, mivel így elérhetővé válnak az operációs rendszer fájljai írásra és olvasásra távolról.

 Megoldási javaslat, szerkeszteni a /etc/exports fájlt és a megfelelő jogosultságokat beállítani, hogy bárki ne tudja mountolni írásra, olvasásra a gyökér könyvtárat.

Penetration Testing on metasploitable 2 - Validation phase - Tcp 1099 - Rmi regirtry service

A következő port a 1099 tcp port.
Nmap:
 1099/tcp  open  rmiregistry GNU Classpath grmiregistry
|_rmi-dumpregistry: Registry listing failed (No return data received from server)
Nessus:

OpenVAS:

Nexpose:
A Nexpose nem találta meg ezt a szolgáltatást mivel ez a port hiányzott a feltérképezendő szolgáltatások listájából.

Ezt kézzel kell megvizsgálni, mivel az automata eszközök nem sok mindent tudtak kideríteni a szolgáltatással kapcsolatban.
 Rákeresünk az nmap nse scriptjei illetve a metasploit moduljai között:

 

A szolgáltatás kritikus kockázatot jelent. Könnyűszerrel lehet root jogosultságot szerezni a hiba által.

Penetration Testing on metasploitable 2 - Validation phase - Tcp 512, 513 és 512 - rexecd, rlogin és rsh service

Folytassuk a metasploitable-2 sérülékenységi vizsgálatát az 512,513 és 514-es tcp portokkal.

Nézzük, hogy mit mondanak a szkennerek azekről a portokról:
nmap:
512/tcp   open  exec        netkit-rsh rexecd
513/tcp   open  login?
514/tcp   open  shell       Netkit rshd
Nessus:

OpenVAS:

Nexpose:

Ami mindegyik szolgáltatásnál probléma, hogy a csatorna nincs titkosítva így érzékeny adatk utazhatnak a hálózaton keresztül. A megoldás, hogy a szolgáltatást le kell tiltani és helyette ssh-t kell alkalmazni a kapcsolatok lebonyolítására. Amennyiben nem lehet a szolgáltatást letiltani,akkor szükséges tovább vizsgálódni az egyéb veszélyek tekintetében.

Ha telepítve van az rsh-client akkor megpróbálhatunk belépni a gépre root felhasználóval.

 

 Más felhasználóval is megpróbálhatunk belépni:

Mindhárom szolgáltatást lehet brute force-olni hydra-val vagy medusa-val. ezen kívül a metasploitban beépített brute force lehetőség van az rlogin szolgáltatáshoz:
auxiliary/scanner/rservices/rlogin_login
nmap-hoz is van rlogin-brute nse szkript (bár jelen esetben nem működött teljesen hibátlanul)
Ezeket a szolgáltatásokat szinte senki nem használja már napjainkban, úgyhogy nem érdemes vele többet foglalkozni. Ha van ilyen nyitott port valahol, a legjobb, ha kikapcsolják a szolgáltatást és helyette ssh-t használnak vagy más alternatív megoldást.

Rábukkantam pár hasznos linkre a témáról:

• https://community.rapid7.com/docs/DOC-1875
• http://www.0daysecurity.com/penetration-testing/enumeration.html
• http://www.vulnerabilityassessment.co.uk/Penetration%20Test.html
• http://www.adeptus-mechanicus.com/codex/metamod/metamod.php

Penetration Testing on metasploitable 2 - Validation phase - Tcp 139 és 445 - Samba service

A 80-as portot a webes vizsgálatoknál tárgyalom a 111-es porttal pedig túl sok mindent nem tudok kezdeni így azzal nem is foglalkoztam. A következő szolgáltatás a Samba.
Nézzük a szkennerek mit találtak ezzel kapcsolatban:
Nmap:

Nessus:

Credentialed check:

OpenVAS:

Nexpose:

Itt volt még egy pár nem kritikus hiba, azok felsorolásától most eltekintek.
Ez a verzió nagyon sok súlyos hibát tartalmaz létezik rá letölthető exploit és metasploitba épített modul is. Itt mindenképpen verziót kell váltani.

Penetration Testing on metasploitable 2 - Validation phase - Udp port 68,69 - DHCP és TFTP service

A következő két port a 68 és a 69-es udp port. A 68 a DHCP és a 69 a TFTP portja szokott lenni.

Nézzük a szkennerek mit találtak erről a két portról:
nmap:
68/udp open|filtered dhcpc
69/udp open|filtered tftp
Nessus:

Credentialed check:

OpenVAS:

Nexpose:

Ebből annyit tudtunk meg, hogy a tftp szolgáltatás elvileg működik (szoftver neve, verzió száma nem ismert) és hogy a dhcp kiens sérülékeny verziójú.
A dhcp hibára létezik elérhető exploit:

Viszont egy ilyen hiba feltehetőleg csak LAN elérésnél használható ki, távolról valószínűleg nem. Hacsak nem az internetes címet dhcp-n keresztül kapja a gép.(Ez nem valószínű, de lehetséges)
Ilyen esetben is azonban ezt a hibát csak a szolgáltató tudja kihasználni, akitől az ip címet kapja a gép. Ezt a hibát kritikusnak kell venni ettől függetlenül mivel létezik rá működő exploit.
Kihasználásához el kell érni, hogy a gép újból lekérje az ip címet a dhcp szervertől. (reboot után, pl)
Más módszert nem tudok erre most hirtelen, ami távolról működhet.
A megoldás, hogy frissíteni kell az alkalmazást olyan verzióra ami nem sérülékeny. Célszerűen a legfrissebbre.
Térjünk át most a tftp szerverre. Kezdjük egy nmap nse szkripttel az ellenőrzést:

metasploittal nem sikerült semmilyen érdekes fle-t találni:

Az /etc/passwd file-t sem sikerült letölteni, tehát az nmap script nem futott le normálisan

Végülis itt nem találtam se program hibát se rossz konfigurációt, úgyhogy ez a szolgáltatás jól lett bekonfigurálva. Javítani való nincs rajta.