Jeśli my moŝemy to zrobić, to napastnik moŝe równieŝ.

Transkrypt

1 Dokument pobrany z serwisu: Autor artykułu: Michał Melewski Atak kontrolowany Zacznijmy moŝe od wyjaśnienia czym są, a moŝe przede wszystkim czym nie są testy penetracyjne. Testy penetracyjne, zwane dalej pen-testami to działania polegające na przeprowadzeniu symulowanego ataku na wskazany cel. Cel moŝe być w zasadzie dowolny - serwis internetowy, baza danych lub teŝ infrastruktura sieciowa. Nic nie stoi równieŝ na przeszkodzie, Ŝeby celem była konkretna informacja lub dostanie się do konkretnego segmentu sieci. Tak naprawdę wszystko zaleŝy od załoŝeń początkowych. Same testy równieŝ mogą ewoluować podczas trwania tego procesu - początkowy atak na serwis intranetowy moŝe przerodzić się w testowanie odporności bazy danych lub firewalla. Efektem takiego ataku powinno być zidentyfikowanie wszystkich słabych punktów celu oraz wskazanie sposobów, dzięki którym potencjalny napastnik moŝe naruszyć bezpieczeństwo badanego celu. Arsenał środków, którymi posługują się osoby wykonujące test penetracyjny jest w zasadzie nieograniczony (a raczej ograniczony prawem i etyką zawodową), chyba, Ŝe warunki kontraktu mówią inaczej. O ile metody inŝynierii socjalnej są dopuszczalne (np. wysłanie zwykłego mail'a), to ataki typu DoS oraz DDoS na część infrastruktury juŝ raczej nie (chyba, Ŝe klient to dopuszcza). Porwanie administratora wraz z rodziną w celu wydobycia haseł nie jest juŝ raczej dobrym pomysłem. Poza tym, w zasadzie wszytko jest dozwolone - wykorzystywanie dziur w programach, 0-day'e, słabości konfiguracyjne, ataki na infrastrukturę sieciową, ataki brute force, snifing sieci itp. Zawsze przyświeca nam motto - Jeśli my moŝemy to zrobić, to napastnik moŝe równieŝ. Same testy mogą być przeprowadzane zarówno z zewnątrz sieci, jak teŝ z wewnątrz. Często łączy się te dwa podejścia i sprawdza się, czy wykonanie ataku będzie równie trudne z obu tych kierunków. Testy przeprowadzane z zewnątrz spotykane są najczęściej i najlepiej obrazują prawdopodobne wektory ataków, ale dla uzyskania pełnego obrazu naleŝałoby przeprowadzić teŝ testy od wewnątrz, Ŝeby zminimalizować szansę, Ŝe padniemy ofiarami naszych własnych pracowników. Oczywiście są teŝ przypadki, gdzie w grę wchodzi tylko jeden z kierunków ataku. Trudno przecieŝ atakować serwis Intranetowy z zewnątrz. Nie ma teŝ większego sensu atakować portalu Internetowego z wewnątrz firmy, bo to nie pracownicy będą tutaj zagroŝeniem. Jednym z waŝniejszych kryteriów jeśli chodzi o rozróŝnienie rodzajów pentestów jest wiedza, jaką o celu dysponuje zespół testujący. Właśnie wzdłuŝ tej granicy rysuję się podział na testy typu Black Box oraz Crystal Box (zwany teŝ White Box). Zawsze zostaje teŝ kwestia, czy atakowany cel powinien być podłączony do środowiska produkcyjnego, czy teŝ powinien to być wyizolowany system umieszczony w środowisku testowym. W zasadzie podejścia są róŝne i sporo zaleŝy od krytyczności danego systemu.

2 Osobiście skłaniałbym się bardziej w kierunku testowania systemów w Ŝywym środowisku, poniewaŝ właśnie w takich warunkach będzie on atakowany. Oczywiście istnieje ryzyko, Ŝe system wyłoŝy się w trakcie testów, ale po to w końcu mamy kopie zapasowe. Sprawę pozostawiam do dyskusji. Po co nam pen-testy Biorąc pod uwagę koszty takiej imprezy, jaką jest wpuszczenie do firmy gromady lekko niepoczytalnych osób z ciekawymi pomysłami (np. A wiecie, Ŝe jednym pakietem HSRP mogę wyłączyć wasz główny router?) zadajecie sobie pewnie pytanie - po co w ogóle robić takie testy? PrzecieŜ wystarczy postępować zgodnie z instrukcją zabezpieczania danego systemu i wszystko będzie dobrze. OtóŜ nie - wcale nie ma takiej gwarancji. Dobrze przeprowadzony test penetracyjny to niezaleŝna ocena stanu bezpieczeństwa twoich systemów - tego nie zastąpi Ŝadne inne działanie. Nie ma równieŝ sensu angaŝować do tego administratorów - nikt nie jest w stanie niezaleŝnie oceniać swojej pracy. Z testami penetracyjnymi jest jak z testami zderzeniowymi samochodów - niby moŝna to wymodelować na komputerze, obliczyć na podstawie wytrzymałości materiałów, ale zawsze ostatecznym testem jest rozpędzenie samochodu do 70 km/h i walnięcie w betonową przeszkodę. Dopiero to daje miarodajne rezultaty, na ile bezpieczny jest samochód. W świecie bezpieczeństwa takim walnięciem w przeszkodę jest dla systemu zetknięcie z grupą pentesterów. Black Box vs. Crystal Box KaŜdy teren działania ma w sobie świętą wojnę. Nie inaczej jest tutaj. Na polu testów penetracyjnych spotyka się zazwyczaj dwa podejścia do sprawy. Testy penetracyjne typu Black Box zakładają, Ŝe przed rozpoczęciem testów nie mamy Ŝadnych informacji o celu, poza zupełnie podstawowymi, np. czym jest cel, jaką spełnia funkcję i jakie elementy wchodzą w jego skład. W tym podejściu bardzo waŝnym etapem jest pierwsze rozpoznanie z czym mamy do czynienia, jakie oprogramowanie atakujemy, jak wygląda otoczenie sieciowe celu i jakie mechanizmy chronią dostępu do niego. Za plus tej metody naleŝy uznać to, Ŝe moŝliwie najdokładniej odzwierciedla ona prawdziwy atak przeprowadzany przez potencjalnych napastników. Minusem jest to, Ŝe poświęcamy czas na działania poboczne zamiast skupić się na próbach atakowania celu - moŝe to mieć niebagatelne znaczenie w przypadku komercyjnych testów, gdzie klient płaci za kaŝdy dzień pracy zespołu. Drugie podejście zwane Crystal Box zakłada, Ŝe zespół testujący posiada maksymalnie duŝo (w granicach rozsądku) informacji o atakowanym systemie. Czasami nazywa się to "scenariuszem najgorszego przypadku", kiedy potencjalny napastnik uzyskał dostęp do tych informacji w jakiś inny sposób. ChociaŜ ten przypadek nieco róŝni się od normalnego ataku, to jest zdecydowanie szybszym sposobem przeprowadzenia testów bezpieczeństwa. W praktyce najczęściej spotyka się kombinację powyŝszych podejść zwaną Grey Box, w której pentesterom przekazuje się pewne informacje o celu, ale bez szczegółów. Czasami równieŝ najpierw przeprowadza się testy w podejściu Black Box, a potem atakuje się jeszcze raz, juŝ po tym, jak klient dostarczył dokumentację celu.

3 Metodyki testów Typowe wyobraŝenia testów penetracyjnych najczęściej wygląda tak: do firmy wpada grupa ludzi, którzy wyglądają jakby właśnie wyszli z cięŝkiej imprezy (patrz wizerunek typowego pentestera), podpinają laptopy i zaczynają stukać w klawiatury z prędkością wpędzającą maszynistki w kompleksy. Po 5 dniach walki rzucają klientowi, Ŝe system jest dziurawy, a oni włamali się poprzez dziurę w foo bar, proszę przelać pieniądze na nasze konto, dziękuję. Taki opis niewiele wspólnego ma z rzeczywistością. śeby nieco wziąć w karby takich kowbojów mądrzy ludzie opracowali coś, co nazywa się metodyką przeprowadzania audytów teleinformatycznych (testy penetracyjne to cześć takich audytów). Najbardziej znaną metodyką jest z całą pewnością Open Source Security Testing Methodology. Jest to dość szeroka metodyka obejmująca swoim zakresem zarówno aspekty teleinformatyczne, fizyczne, prawne oraz aspekty związane z świadomością uŝytkowników oraz podatnością na inŝynierię socjalną. Standard ten zawiera sporo informacji dotyczących planowania audytów, obszarów wymagających testowania, zasad raportowania (o tym później) oraz sposobu oceniania wyników. OSSTM Manual zawiera jeszcze jedną waŝną rzecz - Rules of Engagement (czyli zasady walki). Jest to zbiór zasad, który określa ramy prawne i etyczne postępowania podczas oferowania usług związanych z bezpieczeństwem. Poruszane są tam zasady sprzedaŝy i marketingu, negocjacji kontraktu, procesu wykonywania testów penetracyjnych oraz zasady raportowania. Warto, aby kaŝdy kto zajmuje się bezpieczeństwem zapoznał się z tymi zasadami i zaczął ich przestrzegać. To pozwoli wyeliminować przypadki, które psują nam reputację (chyba nie muszę mówić, o kogo chodzi). Kolejną z metodyk wartych chociaŝ wspomnienia jest publikacja NIST o numerze Oprócz metodyk przeprowadzania testów istnieją teŝ wytyczne dotyczące obszarów testowania. Ogólne wytyczne moŝna znaleźć w OSSTMM, natomiast naleŝy wspomnieć o bardzo ciekawym projekcie pt. OWASP. Jednym z celów projektu jest stworzenie podręcznika który obejmowałby maksymalnie wiele aspektów testowania aplikacji webowych. KaŜdy, kto w ogóle ma zamiar zająć się tym tematem powinien przeczytać OWASP Testing Guide. Dodatkowo warto zainteresować się innymi projektami konsorcjum OWASP (np. WebScarab, ale o tym później). Jak więc wygląda typowy test penetracyjny? Wbrew pozorom całkiem zwyczajnie. Pierwszym krokiem kaŝdego testu (w przypadku pracy dla klienta zewnętrznego) jest podpisanie umowy NDA (Non-disclosure agreement), która mówi, Ŝe nas zastrzelą, jeśli chociaŝ piśniemy słowo na temat tego, co robimy i zrobiliśmy. Drugim krokiem jest wykonanie harmonogramu testów - trzeba powiadomić klienta, co w jakich dniach będziemy testować i ustalić ścieŝki komunikacji z administratorami (w razie, jakbyśmy coś zepsuli). Szczegółowość planu zaleŝy głównie od ilości informacji dostarczonej

4 przez klienta. Oczywiście w trakcie negocjacji ustala się teŝ wiele nudnych szczegółów, kwestię skąd będą przeprowadzane testy, co znajdzie się w raporcie. W końcu przychodzi dzień, gdzie zespół pentesterów zaczyna pracę. Pierwsze dni testów to najczęściej rekonesans, badanie wersji oprogramowania, architektury systemu/aplikacji itp. Kolejne dni to radosne próby włamania na zasadzie wszystkim na wszystko. Dopiero później przychodzi czas na metodyczne testy kaŝdego z obszarów działania aplikacji. Końcówka testu do szczegółowe badanie znalezionych dziur, pisanie Proof of Concept i próby potwierdzenia podatności korzystając z innych metod ataku. Po fazie testów przychodzi czas na najwaŝniejszą z punktu widzenia klienta część - pisanie raportu. Jeśli pamiętaliśmy o tym, Ŝeby dokumentować kaŝdy z podejmowanych kroków w czasie samych testów, to pisanie raportu nie będzie trudne. WaŜne, Ŝeby w raporcie znalazły się opisy prowadzonych prac, znalezione błędy itp. Temat ten rozwinę później. Narzędzia Narzędzia w testach penetracyjnych to chyba jedne z najbardziej przecenianych aktywów. Początkującym w tej dziedzinie wydają się mitycznym oręŝem, dzięki któremu Ŝaden cel im się nie oprze. Na róŝnych forach i grupach dyskusyjnych często padają pytania o nazwę programów do hakowania. W odpowiedzi na takie pytania warto jedynie wspomnieć, Ŝe Musashi Miyamoto nie był mistrzem miecza dlatego, Ŝe uŝywał katany +3 do szybkości, ale dlatego, Ŝe rozumiał sztukę walki. Zabrzmiało to nieco patetycznie, ale tak miało być. Kiedy się tnie, ostrze jest tylko ostrzem, a kiedy przeprowadza się testy penetracyjne narzędzie nie będzie myślało za nas. Oczywiście dobrze dobrane narzędzia znakomicie ułatwiają przeprowadzenie testów, a przeprowadzenie niektórych z nich bez odpowiednich programów byłoby niemal niemoŝliwe. Same programy wspomagające wykonywanie testów penetracyjnych to często małe dzieła sztuki i doskonałe przykłady na świetne zrozumienie sztuki pisania kodu. Nie ma sensu, Ŝebym wymieniał wszystkie, których zdarzyło mi się uŝywać, a zresztą w toku testów czasami przychodzi pisać własne kawałki kodu. Wspomnę o kilku, które szczególnie sobie cenię (z naciskiem na testowanie aplikacji Webowych). Pierwszym i jednym z waŝniejszych narzędzi przy testowaniu aplikacji webowych jest odpowiedni serwer Proxy, dzięki któremu moŝemy swobodnie modyfikować zapytania przesyłane do serwera oraz logować odpowiedzi. Wśród programów, których uŝywam wymienić naleŝy BurpProxy oraz WebScarab. Co ciekawe, obydwa programy napisane są w języku Java, dzięki czemu moŝemy wykorzystywać je pod dowolną platformą sprzętową. Z innych, ciekawych programów słuŝących do przeprowadzania ataków typu Blind SQL Injection wymienić moŝna sqlmap. To narzędzie jest akurat napisane w pythonie.

5 Kolejnym ciekawym narzędziem, które moŝna zastosować jest program Michała Zalewskiego - st0mpy. Program słuŝy do jakościowej analizy identyfikatorów sesji, celem ustalenia ich nieprzewidywalności, a co za tym idzie, bezpieczeństwa mechanizmu sesyjnego. Cztery narzędzia to niewiele, ale biorąc pod uwagę, Ŝe BurpProxy składa się z 4 głównych modułów, a w module Intruder moŝna pisać własne testy, więc jest tego sporo więcej. Po opis reszty funkcjonalności odsyłam na stronę programu. Osobom zainteresowanym pełnym środowiskiem testowym polecam dystrybucję Linuksa (LiveCD) o nazwie BackTrack. Raportowanie wyników Co robi kaŝdy pentester po rozjechaniu w diabły wskazanego celu? Najchętniej oczywiście walnąłby się na kanapie, otworzył piwo i odpoczął. Niestety tak róŝowo nie jest. Po zakończonych testach przychodzi czas na jedną najbardziej nuŝących części całego procesu - na napisanie raportu. Raport niestety jest konieczny, poniewaŝ dopóki on nie powstanie, to cała praca, którą wykonał zespół testujący jest z punktu widzenia klienta bezwartościowa. Czym charakteryzuje się dobry raport. Przede wszystkim jest wyczerpujący - dokładnie opisuje przebieg prac, przeprowadzone testy oraz zidentyfikowane luki. Dobrą praktyką jest równieŝ rozbicie raportu na dwie części - część dla kierownictwa oraz część dla osób technicznych. W końcu nie ma sensu zanudzać prezesa szczegółowym opisem luki typu Heap Overflow w oprogramowaniu serwera. Nie moŝna teŝ zapomnieć o podsumowaniu, gdzie w kilku zgrabnych zdaniach opiszemy, jak fajnie się pracowało i jak tragicznie oceniamy odporność celu na ataki. W raporcie kaŝda luka musi równieŝ zostać opisana w odpowiedni sposób - waŝne, Ŝeby to nie był opis pt. znaleźliśmy XSS'a na waszej stronie. Opis powinien składać się z wskazania miejsca, gdzie błąd występuje, pełnego opisu podatności, który pozwoli na odtworzenie ataku przez osoby czytające raport oraz oceny krytyczności danej luki. Przyporządkowanie luki do odpowiedniego poziomu zagroŝenia to często nietrywialna sprawa. Oczywiście kaŝdą lukę moŝna zaklasyfikować jako "Extremely critical", tak jak to czynią niektórzy, ale z rzeczywistością nie ma to jednak wiele wspólnego. W naszym zespole lukę klasyfikujemy do jednego z trzech poziomów zagroŝenia, które oznaczamy kolorami. Kolor zielony, to luka niezbyt krytyczna, której załatanie nie podniesie w znaczący sposób bezpieczeństwa. Kolor Ŝółty to umiarkowanie powaŝna luka i zaleca się jej usunięcie, ale nie jest wymagana natychmiastowa akcja. Kolor czerwony to luka krytyczna i wymagane jest jak najszybsze podjęcie akcji zmierzającej do jej usunięcia. Istnieje wiele czynników, które mogą zdecydować o przypisaniu danej luki do konkretnego poziomu zagroŝenia. Dwa najwaŝniejsze czynniki to waga skutków wykorzystania danej luki (np. jak wysokie uprawniania moŝemy zdobyć, do jakich danych moŝemy uzyskać dostęp itp.) oraz łatwość wykorzystania luki (czy twoja dziewczyna była by w stanie napisać tego exploita?). Istnieją równieŝ inne czynniki, które zazwyczaj bierzemy pod uwagę np. siłę powiązań komponentu, w którym znaleziono luki z resztą systemu. Tak napisany raport powinien spodobać się klientowi - warto teŝ zadbać o ładną formę graficzną oraz brak błędów ortograficznych oraz gramatycznych. Zasady niby proste, ale

6 niektórzy o nich zapominają - szczytem był pewien raport, który miałem okazję oglądać - napisany był ręcznie - nie dało się odcyfrować połowy treści. Podsumowanie Tak właśnie wyglądają testy penetracyjne - niby nic trudnego, ale wymagające zarówno pewnej dawki wiedzy technicznej, elastyczności (nigdy nie wiesz, co będzie twoim następnym celem) jak i systematyczności (dokumentuj durniu!). MoŜe zabrzmi to jak kiepska reklama, ale uwaŝam, Ŝe kaŝdy serwis wystawiany na widok publiczny powinien przejść chociaŝ krótki cykl testów penetracyjnych - oczywiście nie jest to zabawa tania, ale tam, gdzie w grę wchodzą pieniądze i bezpieczeństwo uŝytkowników lub danych jest to niezbędne. Ale przede wszystkim testy penetracyjne to świetna zabawa :).