Korzyści z włamania

Etapami do przodu

Test penetracyjny jest w pewnym stopniu symulacją włamania do sieci/systemu. Metody i narzędzia, jakimi posługuje się zespół testujący, powinny więc odpowiadać tym stosowanym przez potencjalnych włamywaczy. Celem testu jest pozyskanie jak największej ilości informacji o testowanym obiekcie, a jeśli będzie to możliwe, przełamanie zabezpieczeń. Każdy z kroków zmierza do zdobycia coraz większej ilości informacji o testowanym obiekcie. Dane zebrane podczas wcześniejszych kroków służą jako dane wejściowe dla kroków kolejnych.

Planowanie. Na tym etapie określa się obiekt i cel testów oraz uściśla warunki, w jakich testy będą wykonywane. Musi być ustalony praktycznie każdy szczegół: skład zespołu, punkt, z którego będzie działać zespół testujący, zestaw uprawnień początkowych, zestaw informacji o obiekcie, jakie zostaną przekazane na początku zespołowi testującemu, czas trwania testu. Jeśli usługodawcę wybiera się na drodze konkursu ofert (czy przetargu), etap ten jest wykonywany w ramach postępowania związanego z wyborem usługodawcy. Powyższe parametry powinien narzucić zamawiający, w przeciwnym razie może mieć poważne problemy z porównaniem ofert. Jeśli testy są wykonywane przez zespół wewnętrzny lub nie jest stosowany konkurs ofert, parametry te mogą być ustalane w porozumieniu z zespołem testującym.

Poszukiwanie podatności. Zdobywanie informacji o testowanym obiekcie. Działania na tym etapie można podzielić na trzy podetapy:

Wstępny rekonesans - np. rozpoznanie zakresu adresów, sprawdzenie informacji w systemach DNS i poprzez usługi WHOIS, sprawdzenie informacji na serwisie WWW.

Rozpoznanie działających usług - np. wykrycie aktywnych adresów IP, skanowanie portów TCP i UDP, próby rozpoznania reguł filtrowania pakietów przez zapory firewall, próby obejścia zapór, skanowanie automatami.

Rozpoznanie zasobów - identyfikacja aplikacji, systemów operacyjnych i ich wersji, użytkowników, udziałów itp.

Dopiero na podstawie tych informacji można opracować scenariusze ataków, nie jest to więc jeszcze atak właściwy.

Weryfikacja podatności (ataki i analiza ich rezultatów). Sprawdzenie, czy wykryte podatności można wykorzystać w praktyce. Sprawdzenie to może polegać na prawdziwych próbach ataku bądź ograniczać się tylko do analizy takiej możliwości. Przykładowo, próby ataków mogą polegać na: próbach wykorzystania użytkowników i haseł standardowych, próbach łamania haseł, próbach wykorzystania znanych exploitów lub samodzielnym tworzeniu exploitów i ich testowaniu, próbach ataków DoS (Denial of Service) itp.

Zauważmy, że większość tych działań może znacznie zakłócić pracę systemu. Często zdarza się, że warunkiem stawianym przez zamawiającego testy jest utrzymanie dostępności systemu (takie wymagania mogą dotyczyć np. testów serwisu bankowości elektronicznej, który musi być dostępny non stop). W takich przypadkach rezygnuje się z prób ataku, które mogłyby zakłócić działanie systemu na rzecz analizy możliwości wykorzystania określonych scenariuszy ataków. Analizę stosuje się także wtedy, gdy zespół testujący nie zna oprogramowania mogącego skutecznie wykorzystać daną podatność (exploit lub oprogramowanie pomocnicze automatyzujące atak), a czas trwania testu nie pozwala na stworzenie takiego oprogramowania. W praktyce takie przypadki zdarzają się dość często, więc umiejętności analityczne zespołu wykonującego test są równie ważne, jak umiejętności atakowania systemów.

Podczas prac związanych z próbami wykorzystania znalezionych słabości może się okazać, że pojawiły się nowe okoliczności, które mogłyby owocować nowymi metodami ataku. W takim przypadku należy wrócić do etapu poszukiwania podatności. Przykładowo, w wyniku udanego ataku na serwer WWW można uzyskać uprawnienia użytkownika, z prawami którego działa serwis WWW, i dalej próbować eskalować uprawnienia na tym serwerze do uprawnień administratora lub wykorzystać zdobyty przyczółek w testowanej sieci i kontynuować ataki na inne serwery.

Usunięcie śladów. Bardzo ważne jest, żeby proces testowania nie pozostawiał śladów w testowanym systemie. W szczególności chodzi o to, aby upewnić się, że test nie obniżył bezpieczeństwa systemu - wiele exploitów uruchamia w atakowanym systemie programy typu backdoor . Jeśli proces weryfikacji podatności pozostawił trwałe ślady w systemie, należy je udokumentować i usunąć. Nawet pomimo usunięcia śladów testu, wszelkie działania wiążące się z modyfikacją testowanego środowiska należy precyzyjnie udokumentować.

Raportowanie. Po zakończeniu działań na obiekcie testów przystępuje się do analizy uzyskanych wyników i sporządzenia raportu szczegółowego. Dane do raportu są gromadzone na wszystkich etapach prac. Podczas etapu raportowania zwykle sporządza się spis znalezionych podatności i ocenia zagrożenia związane z poszczególnymi słabościami. Ocena ta nie może mieć oczywiście nic wspólnego z pełną analizą ryzyka, gdyż zespół testujący nie ma po temu wystarczającej wiedzy, np. o biznesie klienta. Niemniej, każda słabość powinna być oceniona w kontekście potencjalnych, możliwych do przewidzenia zagrożeń.


TOP 200