Czy potrzebujesz właśnie testów penetracyjnych

Od dłuższego czasu zbieram się w sobie do napisania tego tekstu. Wcale nie jestem przekonany, że testy penetracyjne są tym, z czego klient odniesie najwięcej korzyści, mimo, że je chce zamówić (często pod nazwą audytu bezpieczeństwa). Chodzi mi tu o testy penetracyjne sieci a nie testy penetracyjne (dedykowanej) aplikacji internetowej bo to trochę dwie różne kwestie.

Według mnie celem testu penetracyjnego nie jest włamanie się , ale identyfikacja jak największej ilości podatności. Dotyczy to zarówno aplikacji internetowych, jak i testów penetracyjnych sieci. Klientowi powinno zależeć na tym, by te podatności były identyfikowane w sposób jak najbardziej efektywny. Tu nie chodzi o “zawody” kto jest lepszy, administrator(zy) czy pentester(zy), tylko o zidentyfikowanie rzeczy (rozwiązań technicznych, konfiguracyjnych, procedur, ...), które wymagają poprawy. Gdy test penetracyjny zostanie sprowadzony do zabawy w kotka i myszkę między administratorami i pentesterami oraz wzajemne (lub jednostronne ze strony administratorów) utrudnianie sobie życia, to efekt będzie mizerny. Podobnie jak efekt audytu (audytu w sensie oceny zgodności ze wzorcem, gdzie wzorcem są na przykład istniejące procedury), w trakcie którego uprzedza się ochronę, że dzisiaj mają wyjątkowo legitymować i spisywać gości na recepcji, bo mamy dziś audyt albo pracownikom idącym na rozmowę z audytorem robi się wcześniej pogadankę jak mają odpowiadać ma pytania i by przypadkiem nie powiedzieli, że w rzeczywistości sposób postępowania jest zupełnie inny, bo źle nas ocenią.

Trzeba sobie uświadomić to fakt, że zarówno administratorzy jak i pentesterzy w trakcie projektu (w trakcie testów) grają w tej samej drużynie. Osoby prowadzące testy mają nieco inną wiedzę niż administratorzy, inne doświadczenia i inny sposób patrzenia na systemy. Warto z tej wiedzy skorzystać, skoro się już za usługę płaci. I tutaj warto się zastanowić jaką usługę warto zamówić.

Pierwszą rzeczą, którą warto sprawdzić, to czy wiedza administratorów (czy ich przełożonych) o sieci pokrywa się ze stanem faktycznym. W szczególności chodzi tu o identyfikację aktywnych hostów (adresów IP) oraz udostępnianych przez nie usług. Tu nie ma co mydlić klientowi oczu, taką enumerację wykonuje się zwykle (przynajmniej w pierwszym etapie) przy pomocy narzędzi automatycznych, np. nmap, nessus, nikto czy OpenVAS. Usługa o takim zakresie nie powinna być określana jako test penetracyjny, lecz raczej test automatyczny lub rekonesans. Od prostego uruchomienia skanera różnić się ona powinna tym, że wyniki narzędzi są weryfikowane przynajmniej w celu identyfikacji false positives.

Gdy raport z testów automatycznych jest gotowy warto zastanowić się co z niego wynika. W szczególności warto zweryfikować czy:

Zarówno zbędne/nadmiarowe urządzenia jak i zbędne/zapomniane usługi są podatnością samą w sobie , przy czym podatnością dość łatwą do wyeliminowania – takie urządzenia i usługi należy po prostu wyłączyć. Wbrew pozorom ilość takich “sierot” może być naprawdę duża i warto się zastanowić, czy powinny być one przedmiotem dalszych testów, skoro i tak powinny zostać wyłączone niezależnie od tego, czy dane urządzenie/usługa poza sobą samym wnosi jakieś dodatkowe podatności.

O ile narzędzia automatyczne sprawdzają się umiarkowanie przy wyszukiwaniu nowych podatności, to radzą sobie dobrze przy identyfikacji znanych podatności. Po prostu jest sobie sygnatura podatności, jest test automatyczny, który ją sprawdza i informacje o jej wystąpieniu (lub prawdopodobnym wystąpieniu) umieszcza w raporcie. Na podstawie takich danych generowanych przez narzędzia automatyczne można określić na przykład to, czy w badanej sieci wykorzystywane są aktualne wersje oprogramowania. Jeśli ilość zgłaszanych podatności związanych z nieaktualnymi wersjami jest duża, oznacza to prawdopodobnie, że istnieje problem z procesem aktualizacji urządzeń/systemów/aplikacji. Warto się jednak zastanowić co jest głównym problemem , patrz metoda 5 why. Klientowi powinno zależeć na usunięciu problemu, a nie jego objawów. Przykładowo fakt, że można się włamać do systemu z wykorzystaniem podatności opisanej w MS08-067 jest zapewne jedynie objawem problemów z procesem aktualizacji systemów. Można oczywiście wykorzystać tę i kilka innych podatności po to, by udowodnić, że się da. Tylko czy to ma sens? Jaka jest wartość dodana takiej demonstracji? Nie twierdzę, że zawsze jest to pozbawione sensu – czasami jest to potrzebne ale tylko czasami.

Jeśli korzysta się ze standardowego oprogramowania, to głównymi powodami występowania podatności w sieci są:

To powyższe stwierdzenie jest pewnym uproszczeniem/uogólnieniem, ale w tej chwili nie mam sił na jego rozwinięcie i doprecyzowanie.

Nieaktualne wersje oprogramowania czyli takie, które zawierają znane podatności (patrz np. Common Vulnerabilities and Exposures). Oddzielnym przypadkiem jest sytuacja, w której wykorzystywana jest wersja oprogramowania niezawierająca znanych podatności, ale już nie wspierana przez producenta.

Zarówno ocena aktualności oprogramowania, jak i identyfikacja błędów w konfiguracji może być realizowana poprzez test penetracyjny, tylko znów nie koniecznie jest to najbardziej efektywny sposób. Lepsze efekty może dać przegląd konfiguracji oraz zebranie informacji o zainstalowanych wersjach oprogramowania, przy czym tutaj już zaczyna się sprawa nieco bardziej komplikować i zaczyna się pojawiać widoczna różnica między testami automatycznymi i testami penetracyjnymi.

Część systemów/aplikacji jest intensywnie badanych pod względem bezpieczeństwa. Jeśli przykładowo w trakcie testów trafi się system z OpenBSD, to należy spróbować ustalić jego wersję a następnie odwiedzić erratę dla odpowiedniej wersji. Podobnie jest z Windows (Security Bulletin Search, Microsoft Baseline Security Analyzer) czy różnymi dystrybucjami Linuksa. Można też próbować szukać nowych podatności, tylko co z tego ma klient i czy aby na pewno o to mu chodzi? Nie ma żadnych gwarancji, że zostaną znalezione wszystkie podatności (bo nie zostaną), więc lepszą inwestycją w bezpieczeństwo dla klienta może być sprawdzenie i ewentualne usprawnienie procesu aktualizacji oprogramowania. Wyniki testu automatycznego czy też szybkiego ręcznego rekonesansu pozwolą sprawdzić, czy opisywana przez administratorów procedura jest rzeczywiście stosowana, czy jest ona wyłącznie piękną opowiastką przygotowaną specjalnie na wizytę Audytorów (specjalnie przez duże “A”).

Nie można jednak zakładać, że każda aplikacja/system jest w ten sposób badana i jest jakieś miejsce, gdzie można szukać tego typu informacji. W szczególności jest to prawda dla aplikacji dedykowanych dla konkretnego klienta, lub ich niewielkiej grupy. I takim właśnie aplikacjom warto się przyjrzeć bliżej, czego już narzędzia automatyczne nie potrafią. Co więcej znalezienie podatności w takiej aplikacji może być dużo łatwiejsze niż znalezienie nowego błędu w Windows nie tylko dla zespołu wykonującego testy, ale również dla potencjalnego intruza. I właśnie to może mieć dla klienta największą wartość – identyfikacja podatności w aplikacjach/systemach, których poza nim nie używa (prawie) nikt, a które może (nad)użyć intruz.

I na zakończenie małe podsumowanie. Klient potrzebuje usługi. Często nie potrafi dokładnie powiedzieć czego potrzebuje, ewentualnie używa pojęć, które gdzieś zasłyszał, choć nie do końca wie co one znaczą i czy aby na pewno chodzi mu właśnie o to. Warto wówczas poświęcić chwilę czasu, by dokładniej określić czego klient (lub potencjalny klient) potrzebuje, a wyjść można od określenia jakich efektów oczekuje. Znając oczekiwane produkty można przedstawić ofertę zestawu usług, które w rezultacie dadzą to, czego klient oczekuje. Warto przy tym dla każdej z oferowanych w zestawie usług opisać:

Takie podejście ma kilka zalet , wymienię tylko dwie. Po pierwsze klient wie co będzie produktem usługi (i przy okazji w jaki sposób usługa zostanie wykonana) i jaki jest jej zakres. Druga kwestia to określenie, czy usługa została wykonana zgodnie z ofertą (i umową). Jest to ważne zarówno dla klienta (jeśli wykonawca okazuje się nie do końca poważny i jako raport przedstawi wyniki narzędzia automatycznego gdzie jedyny jego wkład to wprowadzenie z tekstem, że raport nie jest tłumaczony na język polski by uniknąć niejednoznaczności), jak i dla wykonawcy gdy klient nagle zaczyna mieć pretensje, że coś nie zostało zrobione, lub zostało zrobione w inny sposób, niż on po przeczytaniu najnowszego artykułu w (...) uważa za sposób najlepszy.

Oryginał tego wpisu dostępny jest pod adresem Czy potrzebujesz właśnie testów penetracyjnych

Autor: Paweł Goleń