Pełen artykuł

Dokument pobrany z serwisu: www.Centrum.Bezpieczenstwa.pl
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.
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.
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 800-42.
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
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.
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
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 :).