HARD CORE SECURITY LAB

Przeprowadzając testy penetracyjne, czyli testowe ataki na dany system komputerowy, naszym celem jest wskazanie praktycznych możliwości naruszenia bezpieczeństwa testowanych systemów. Co jednak w sytuacji, gdy za pomocą narzędzi takich jak Metasploit Framework nie jesteśmy w stanie odnaleźć jakichkolwiek podatności na atak, czyli inaczej mówiąc niemożliwe jest odnalezienie jakichkolwiek znanych luk w poszczególnych systemach operacyjnych lub działających pod ich kontrolą usługach?

Załóżmy, że w interesującej nas sieci komputerowej pracuje wiele systemów operacyjnych z rodziny Windows. Jednak ponieważ wszystkie Okienka oraz pracujące pod ich kontrolą usługi są w pełni załatane, użycie exploitów ze środowiska Metasploit Framework nie daje żadnych rezultatów.

W takiej sytuacji, kontrolę nad docelowymi Windowsami możemy uzyskać np. poprzez ataki socjotechniczne z wykorzystaniem narzędzia Social-Engineer Toolkit. Ich powodzenie zależeć będzie jednak od tego, jak dobrze ułoży nam się współpraca z użytkownikami tychże systemów. W takiej sytuacji warto sprawdzić, czy przypadkiem nie uda nam się uzyskać dostępu do docelowych Okienek za pomocą protokołu RDP.

Protokół RDP pozwala na komunikację z usługą Terminala Graficznego (Terminal Services), która jest obecna praktycznie we wszystkich nowoczesnych wersjach systemów Windows. Możliwość nawiązania połączenia jest co prawda domyślnie wyłączona, jednak wielu administratorów aktywuje ją, co pozwala im na proste łączenie się z tzw. zdalnym pulpitem i zdalne zarządzanie systemem.

Pierwszym krokiem jest zawsze odnalezienie potencjalnych celów, czyli w tym wypadku wyszukanie Windowsów zezwalających na zdalne sesje graficzne. Ponieważ serwery RDP domyślnie nasłuchują na porcie TCP 3389, dla przykładowej sieci 192.168.64.0 możemy to w dość prosty sposób osiągnąć za pomocą nieśmiertelnego Nmapa poprzez proste polecenie:

• nmap 192.168.64.0/24 -p 3389

Przykładowy wynik skanowania może mieć następującą postać:

Widzimy więc, że host o adresie 192.168.64.130 udostępnia zdalny pulpit. Spróbujmy więc to jakoś wykorzystać. Chcąc uzyskać dostęp do zdalnego systemu poprzez RDP, musimy dysponować poświadczeniami użytkownika uprawnionego do korzystania ze zdalnego pulpitu (administratorzy oraz członkowie grupy Użytkownicy pulpitu zdalnego). Widzimy więc, że przyda nam się narzędzie pozwalające na wykonanie ataku słownikowego na usługę RDP.

Przetestujmy praktyczne możliwości programu Ncrack, który zupełnie niedawno pośród wielu obsługiwanych już usług sieciowych, doczekał się możliwości testowania bezpieczeństwa poświadczeń broniących dostępu  właśnie do RDP. Najnowszą wersję Ncracka możemy pobrać np. za pomocą takiego polecenia:

• svn co --username guest --password "" svn://svn.insecure.org/ncrack

Domyślny słownikowy atak na zdalny pulpit naszego docelowego komputera z systemem Windows wykonamy za pomocą polecenia:

• ncrack 192.168.64.130:3389

Domyślnie Ncrack wykonuje atak słownikowy z wykorzystaniem najbardziej popularnych nazw użytkowników oraz haseł, rozpoczynając testy od poświadczeń najczęściej spotykanych. W przypadku odkrycia prawidłowych poświadczeń, o wszystkim zostaniemy poinformowani po wykonaniu wszystkich zaplanowanych prób:
Oczywiście za pomocą odpowiednich parametrów możemy dowolnie definiować słowniki poświadczeń:

• -U (wskazanie pliku z listą nazw użytkowników)
• -P (wskazanie pliku z listą haseł)
• --user (lista nazw użytkowników przekazywana wprost z linii poleceń)
• --pass (lista haseł przekazywana wprost z linii poleceń)

Jak wynika z moich testów, serwery RDP są dość wrażliwe na masowe próby logowania, warto więc również rozważyć wykorzystanie parametrów:

• CL (maksymalna liczba jednoczesnych prób logowania)
• cd (opóźnienie pomiędzy kolejnymi połączeniami)

Więcej informacji na temat poszczególnych opcji, można znaleźć w Ncrack Reference Guide. Warto jeszcze tylko wspomnieć, że oprócz obsługi RDP, Ncrack w najnowszej wersji doczekał się również modułu radzącego sobie z SMB.

Znając już poświadczenia pozwalające na skorzystanie ze zdalnego pulpitu komputera 192.168.64.130, możemy śmiało wskazać, że jest to słaby punkt testowanego środowiska. Oczywiście atak udał się tylko z tego powodu, że administrator komputera wykorzystał bardzo słabe hasło i korzystał z wbudowanego konta administrator (co nie jest zalecane). Niemniej jednak, takie sytuacje są bardzo powszechne i zawsze warto testować bezpieczeństwo poszczególnych systemów pod kątem występowania łatwych do złamania (lub nawet odgadnięcia) poświadczeń.