Testy penetracyjne cz. 2. Szpiegowania ciąg dalszy

W {{a:http://www.networld.pl/artykuly/50695/Testy.penetracyjne.cz.1.html}}poprzednim odcinku{{/a}} staraliśmy się dowiedzieć co nieco o naszym przeciwniku w sposób typowo szpiegowski - wstępnie rozpoznać teren działań, a przy tym nie przyciągać zbytnio niczyjej uwagi. Ale - jak ustaliliśmy ostatnio - to dopiero wierzchołek góry lodowej. Jak to bywa w pracy szpiega, jest czas na konwenanse oraz kurtuazję i czas na brutalne działania. Tym razem musimy być bardziej zdecydowani i bezwzględni - chcemy przecież przeniknąć do badanych struktur i wykazać błędy konfiguracyjne w zabezpieczeniach. A więc do dzieła.

Wszystkie działania, które wykonywaliśmy ostatnio, prowadziły do ustalenia rzeczy elementarnych. Nie zagłębialiśmy się zbytnio w szczegóły. Zakończyliśmy na rozpoznaniu serwerów pocztowych, WWW i FTR Każda z maszyn wyglądała tak, jakby była dostępna bezpośrednio z zewnątrz, ale bądźmy realistami - w rzeczywistości nikt nie wystawia serwerów "na łaskę" Internetu.

Testy penetracyjne cz. 2. Szpiegowania ciąg dalszy

Tego trzeba się trzymać

Przeważnie stoją one w strefie DMZ, a zatem dostęp do nich ograniczany jest przynajmniej przez zaporę. To, że mają adresy publiczne nic nie znaczy, bo przecież wszyscy znamy dobrodziejstwa statycznego NAT Nie znamy usług działających na tych serwerach, nie wiemy zbyt wiele o ich systemach operacyjnych itp. Jednakże to, co mamy, jest już dobrym początkiem.

Zobacz również:

  • Testy penetracyjne systemów IT - czy warto w nie zainwestować?
  • Bezpieczeństwo w chmurze publicznej nadal priorytetowe

Zanim przejdziemy dalej, możemy skorzystać z serwisu, który dorzuci nam kilka przydatnych informacji o usługach, a przy tym w dalszym ciągu nie podniesiemy alarmu -http://uptime.netcraft.com . Za pomocą tego portalu możemy sprawdzić np. rodzaj i wersję serwera WWW oraz typ systemu operacyjnego, pod którym pracuje nasz cel. Dodatkowo możemy sprawdzić, czy w danej domenie nie działają inne serwery webowe. Lista ta oczywiście nie musi być kompletna. Znajdziemy na niej tylko te serwery, które skatalogował serwis. Niemniej informacje te mogą okazać się przydatne podczas dalszych działań.

Z reguły bowiem jest tak, że administratorzy poświęcają możliwie dużo uwagi serwerom podstawowym. Drugoplanowe serwisy pozostają w cieniu i może się okazać, że pracują na bardziej podatnych na ataki wersjach oprogramowania. Weźmy zatem badaną "Naszą-Firmę" i sprawdźmy, na czym działa jej serwer WWW

Możemy dodatkowo spróbować dostać się na typowy dla danej usługi port i zobaczyć, czy otrzymamy baner informujący wersji oprogramowania z nagłówka, np.:

# telnet www.naszafirma.xxx 80

Trying www.naszafirina.xxx

Connected:

Escape characteris '^]'.

HEAD /HTTP/'1.0

HTTP/1.1 200 OK

Datę: Tue, 24 Jan 2006 13:38:33 GMT

Server: Apache/2.0.54 (Gentoo/Linux)

mod_ssl/2.0.54 OpenSSL/0.9.7e PHP/4.4.0

Last-Modified: Mon, 06 Jun 2005 08:05:10 GMT

ETag: "3d3d2-5a3-299fd980"

Accept-Ranges: bytes

Content-Length: 1443

Connection: close

Content-Type: text/html; charset=ISO-8859-l

LISTING 1

Widzimy, że nasz serwer WWW pracuje na Apache w wersji 2.0.54 z obsługą SSL. Dodatkowo znaleźliśmy wersję zainstalowanego PHR Teraz rzut okiem np. nahttp://www.securityfocus.com/vulnerabilities i znajdujemy kilka potencjalnych luk, które może wykorzystać atakujący. Dalej sprawdźmy, jakie opcje ów Apache oferuje zwykłemu użytkownikowi odwiedzającemu portal. Postępujemy podobnie jak w listingu 1, zamieniając jedynie komendę HEAD na OPTIONS. I znowu pojawienie się np. opcji DELETE dostępnej dla zwykłych użytkowników (strefa publiczna) w wynikach świadczy o krytycznym wręcz uchybieniu - pozwala na usunięcie treści z serwisu. Oczywiście należy brać poprawkę na to, że informacje znajdujące się w nagłówku, mówiące o wersji oprogramowania, wcale nie muszą pokrywać się z rzeczywistością. Wpisy te administrator może celowo modyfikować, aby wprowadzić atakującego w błąd. Dodatkowo możemy wykorzystać oprogramowanie do diagnozowania komponentów serwerów WWW - WebServerFP.

Nieocenionym źródłem informacji o serwerach WWW jest również portal google.com. Wiadomo, że "google" to temat na książkę, ale jeden przykład nie zaszkodzi. Często wykorzystywanym narzędziem do monitorowania serwera webowego jest narzędzie awstats (http://awstats.sourceforge.net/ ). Pozwala ono na uzyskanie szeregu informacji, w tym hostów, które miały dostęp do serwera, obciążenia, oprogramowania itp. Są to niezwykle cenne dane dla napastnika. Prostym zapytaniem - intitle: "statistics of" "advanced Web statistics" site:naszafirma.xxx - site:www.naszafirma.xxx - sprawdzimy obecność tego oprogramowania, może również dostęp do samych statystyk. A to dopiero jedna usługa. Musimy jeszcze sprawdzić wiele innych - serwery FTP DNS, SMTP itp.

Co jest po drodze?

Innym krokiem może być próba stwierdzenia, czy na drodze do badanego serwera stoi firewall oraz podjęcie wysiłków w celu jego identyfikacji i ewentualnie próby ominięcia. Technik pozwalających na stwierdzenie obecności zapory jest zbyt wiele, żeby wszystkie opisywać, dlatego też skupmy się na kilku tylko przykładach. Możemy np. wykorzystać technikę skanowania półotwartego (tzw. SYN scan) i wysłać pojedynczy pakiet z flagą SYN na określony port, a następnie czekać na reakcję maszyny docelowej.

Wiemy już, że port 80 jest otwarty. Co z tego wynika? Jeszcze nic. Tak naprawdę interesuje nas, jak będzie wyglądała odpowiedź serwera w przypadku, kiedy natrafimy na port zamknięty. Zgodnie z normami RFC, jeżeli port jest rzeczywiście zamknięty, powinniśmy otrzymać pakiet zwrotny z flagą RST (reset) oznaczającą zerwanie połączenia. Jeżeli jednak nie otrzymamy żadnej odpowiedzi, może to oznaczać obecność oprogramowania filtrującego.

Możemy również wysłać pakiet z ustawioną flagą ACK (acknowledgement). Jeżeli otrzymamy w odpowiedzi RST, domyślamy się, że na drodze do serwera stoi firewall.

Do celów naszych testów możemy wykorzystać dwa bardzo użyteczne narzędzia. Pierwsze to Nmap (http://www.insecure.org/nmap ). Jest to skaner sieciowy, którego nie trzeba specjalnie nikomu przedstawiać - bez niego życie każdego administratora jest pozbawione sensu. Dostępny jest i pod Linuxa, i pod Windows. Dodatkowo można pobrać GUI ułatwiające korzystanie z tego narzędzia, co z pewnością ucieszy przeciwników trybu tekstowego. Co prawda, jak mówią twórcy Nmapa, konsola graficzna nie wykorzystuje w pełni jego możliwości, ale zawsze to jakiś początek.

Drugim narzędziem jest Hping2 (http://www.hping.org ). Służy przede wszystkim do tworzenia pakietów Można je uruchomić tylko w środowiskach unixowych, ale przecież zawsze można skorzystać z emulatora Linuxa (np. Cygwin).

Zajmijmy się serwerem wwwnaszafirma.xxx. Sprawdźmy, jak wygląda stan pozostałych portów za pomocą prostego skanowania.

Jak wiemy, odrobina paranoi nigdy nie zaszkodzi, dlatego też uzbroimy się w cierpliwość (całą masę cierpliwości) i zastosujemy tryb nomen omen paranoid. Pozwoli on nam na zmniejszenie "hałasu" poprzez rozciągnięcie prób skanowania (jeden pakiet na 5 min!) i jest szansa, że pozostaniemy niezauważeni. Ponieważ skanowanie takie zabrałoby całe wieki, ograniczymy też interesujące porty do tych, które według nas mogą za sobą kryć podatne na ataki usługi. Niech będą to np. porty 21 (FTP), 22 (SSH), 23 (TELNET), 25 (SMTP), 37 (NTP),53(DNS)i5900 (VNC):

#nmap -PO -n -v -p21,22,23,25,37,53,5900 -TParanoid

www.naszafirma.xx

Starting nmap 3.81 (http://www.insecure.org/nmap/ ) at 2006-01-25 12:14 CET

Interestingports on www.naszafirma.xxx

<pre>PORT STATE SERVICE

21/tcp filtered ftp

22/tcp open ssh

23/tcp filtered telnet

25/tcp filtered smtp

37/tcp open time

53/tcp filtered domain

5900/tcp filtered https</pre>

MACAddress: 00:04:76:71:AB:BO (3 Com)

Nmap finished: 1 IP address (1 host up) scanned in 1.561 seconds

Widzimy zatem, że na skanowanej maszynie, oprócz poznanego wcześniej portu 80, na pewno otwarte są trzy porty 22 (SSH), 37 (NTP) oraz 5900 (VNC). Przy tym skanowanie zajęło tylko 35 min. Co do pozostałych portów nie mamy pewności. Wyślijmy zatem pojedynczy pakiet SYN na port 23 (TELNET).

# hping -S -p 23 -c 2 www.naszafirma.xxx

HPING www.naszafirma.xxx (ethOxxx.xxx.xxx.xxx): S set, 40 headers + 0 data bytes

--- xxx.xxx.xxx.xxx hping statistic ---

2 packets transmitted, 0 packets received, 100%packet loss round-trip min/avg/max = 0.0/0.0/0.Oms

Nie otrzymaliśmy żadnej odpowiedzi. Oznacza to, że port jest filtrowany, a możliwa odpowiedź z tego portu jest blokowana, co definitywnie potwierdza obecność mechanizmów filtrujących po drodze do hosta.

Możemy również badać porty UDP, podejmować próby skanowania ICMP (np. używając programu SING -http://www.sourceforge.net/sing ) itp.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200