Testy penetracyjne aplikacji WWW

Wstęp

W pierwszej części artykułu przedstawiliśmy ogólną tematykę związaną z bezpieczeństwem i audytem bezpieczeństwa plikacji www. W niniejszym tekście przedstawimy jedną z najskuteczniejszych metod badania bezpieczeństwa aplikacji webowej - testy penetracyjne.

Często audyt aplikacji WWW przybiera formę kontrolowanych ataków na aplikację. Działając w ten sposób audytorzy lokalizują podatności w sposób, który mógłby być wykonany przez hackerów.  Cały proces – nazywany niekiedy testem penetracyjnym aplikacji  - opisujemy bardziej szczegółowo w dalszej części artykułu.  Inne – bardziej ogólne i komplementarne podejścia do audytu bezpieczeństwa aplikacji webowej prezentujemy w następnej kolejności.

Cel testów penetracyjnych

Mając świadomość w jaki sposób wykonywane są testy penetracyjne (symulacja realnych ataków), można wskazać pytania, na które odpowiedzieć może tego typu audyt:

• Jakie luki bezpieczeństwa znajdują się w aplikacji? Jakie są potencjalne skutki wykorzystania tych podatności przez hackerów? W jaki sposób można naprawić znalezione błędy?
• Jakie metody zabezpieczające przed atakami wykorzystuje aplikacja WWW?
• W jakim stopniu działają ewentualne dodatkowe środki ochrony zaimplementowane w systemie (np. firewalle aplikacyjne, systemy klasy IDS).
• W jakim stopniu próby ataków są wykrywane ? (np. poprzez reakcje zespołu bezpieczeństwa na automatycznie generowane alarmy).
• Przez jaki czas aplikacja oraz cały system mogą skutecznie opierać się atakom?

Testy tego typu najczęściej wykonywane są w sposób ściśle usystematyzowany. Całość opiera się na kilku logicznie połączonych ze sobą fazach. Poniżej prezentujemy przykładowe etapy testu penetracyjnego – przy zaznaczeniu, iż w zależności od przyjętej metodologii mogą one ulegać pewnym zmianom.

Testy penetracyjne - etapy prac

Etap I – wstępne badanie.

Audytorzy badają ogólną charakterystykę aplikacji. Na tym etapie nie wykonywane są jeszcze ataki na system. Przykładowe testy obejmują:

• Sprawdzenie czy aplikacja dostępna jest do pobrania w Internecie (np. jako OpenSource).
  W takim przypadku – w dalszym kroku - hacker może zainstalować aplikację w swoim testowym środowisku, ułatwiając tym samym analizę. Może również dokonać analizy kodu źródłowego, również w ten sposób zwiększając prawdopodobieństwo wykrycia istotnej luki bezpieczeństwa.
  

• Sprawdzenie czy aplikacja nie jest wykorzystywana w innych firmach – możliwe jest uzyskanie tego typu informacji np. korzystając z przeglądarki Google. Poza standardowymi metodami wyszukiwania, istnieje możliwość wykorzystania techniki  google  hacking – czyli zadawania zaawansowanych zapytań do Google precyzyjnie określających poszukiwane zasoby. Po lokalizacji aplikacji w wielu środowiskach, hacker może próbować znaleźć podatności w najsłabiej zabezpieczonym systemie, a następnie przenieść atak na swój główny cel.

• Sprawdzenie czy audytor / firma audytorska nie testowała wcześniej aplikacji – w ramach prac zleconych przez innego klienta. Jeśli tak – istnieje prawdopodobieństwo, iż błędy wykryte w trakcie zupełnie innego audytu bezpieczeństwa, znajdują się również w obecnie testowanej aplikacji.
• Sprawdzenie czy dana aplikacja nie posiada znanych błędów. Często hackerzy nie tracą czasu na poszukiwanie podatności w aplikacji w sposób bezpośredni. Niekiedy wystarczy zaznajomić się z archiwami znanych list dyskusyjnych dotyczących bezpieczeństwa (np. „słynny” bugtraq), aby zlokalizować krytyczne błędy bezpieczeństwa w konkretnej aplikacji.
  

Warto zauważyć, że już podczas takiego wstępnego badania mogą zostać wykryte krytyczne luki bezpieczeństwa, mogące prowadzić do całkowitego przejęcia kontroli nad systemem przez hackera.

Dla osoby atakującej system, dalsze kroki są zazwyczaj niekonieczne. Zakładany cel  - tj. przełamanie systemu - został osiągnięty. Jednak w przypadku osób przeprowadzających testy penetracyjne to dopiero początek pracy – zadaniem audytorów jest wykrycie jak największej ilości podatności i tym samym minimalizowanie prawdopodobieństwa ich znalezienia przez wrogie osoby.

Etap II - Mapowanie aplikacji

Po wstępnym etapie prac następuje przygotowanie do bardziej szczegółowych testów. Audytorzy  starają się uzyskać jak najwięcej informacji  technicznych oraz funkcjonalnych dotyczących konkretnej instancji aplikacji. Zbierane są dane możliwe do pozyskania podczas normalnego korzystania z oprogramowania. Testerzy – poza przeglądarką internetową - używają jednak dodatkowe specyficzne narzędzia (np. http proxy). Badane są takie czynniki jak:

• Ustalenie technologii w jakiej zbudowana została aplikacja – umożliwi to późniejsze dalsze profilowanie testów dla konkretnej technologii.
• Ustalenie ogólnych mechanizmów zaimplementowanych w celu ochrony aplikacji (np. sposoby walidacji formularzy).
• Ustalenie jakiego typu mechanizmy uwierzytelniania i autoryzacji zostały wykorzystane w aplikacji. 
• Wykorzystanie ogólnych mechanizmów aplikacyjnych (np. częste wykorzystanie AJAX czy technologii Flash).
• Wykorzystanie znanych komponentów czy bibliotek (ułatwi to próbę lokalizacji podatności w tych komponentach).
• Funkcjonalności dostępne w aplikacji.
• Funkcjonalności  szczególnie narażone na atak.
  

Przykładowe informacje, które mogą być uzyskane na tym etapie:

• Aplikacja wykorzystuje technologię PHP.
• W systemie została wykorzystana biblioteka OpenSource, posiadająca krytyczne błędy bezpieczeństwa i umożliwiająca zdalne przejęcie kontroli nad systemem.
• Aplikacja korzysta z własnego podsystemu uwierzytelniania. Używane są identyfikatory sesji, których długość jest niewystarczająca. Umożliwia to przejęcie kontroli nad kontami zalogowanych użytkowników. 
  

Zauważmy, iż do tej pory wykonanie realnych ataków nie było konieczne – zatem niemożliwym było również wykrycie naruszeń bezpieczeństwa przez właściciela aplikacji. Jednocześnie tego typu pasywne badania pozwoliły na uzyskanie wielu interesujących informacji o aplikacji, a być może nawet znalezienie możliwości całkowitego przełamania systemu.

Etap III – atak

Po wcześniejszych etapach, niejako sondujących audytowane środowisko, następuje część związana z wykonaniem realnych ataków na aplikację. Jest to często najbardziej czasochłonna część audytu, dająca niejednokrotnie najlepsze wyniki. Faza rozpoczyna się odpowiednim doborem narzędzi, za pomocą których będzie wykonana symulacja ataków oraz tzw. payloadów do ataków (tj. odpowiednio spreparowanych fragmentów danych, które będą przesyłane do aplikacji w celu lokalizacji podatności). Tego typu dobór znacznie optymalizuje audyt, zwiększając jego skuteczność. Przykładowo – testowanie błędów charakterystycznych dla bazy danych MySQL jest stratą czasu, kiedy pewne jest, że aplikacja wykorzystuje bazę danych Oracle.
W tabeli poniżej prezentujemy klasy błędów bezpieczeństwa występujących w aplikacjach webowych. Podatności te mogą być wykryte przez test penetracyjny. Dodatkowo tabela zawiera przykładowe efekty, które może osiągnąć hacker wykorzystując daną lukę.

Wybrane klasy podatności wraz z zagrożeniami płynącymi z ich wykorzystania.

Powyższa lista jest długa, choć warto zaznaczyć że zdecydowanie nie wyczerpuje ona wszystkich klas podatności, które mogą znaleźć się w aplikacji webowej.  Powstaje również pytanie – jak często błędy te występują w aplikacjach webowych? Otóż z naszego doświadczenia wynika, iż trudno jest wskazać rozbudowaną aplikację webową,  nie posiadającą choć kilku znaczących błędów bezpieczeństwa. Jednocześnie bardzo wiele aplikacji posiada podatności o znaczeniu krytycznym (np. SQL injection czy stored XSS).

Sposoby prowadzenia testu penetracyjnego (symulowany atak)

Często symulacja ataku prowadzona jest dwoma sposobami: metodą manualną oraz automatyczną. 
Metoda ręczna pozwala wykryć krytyczne, a zarazem nietypowe błędy bezpieczeństwa. Jest to również jedyny sposób umożliwiający wykrycie pewnej klasy błędów – np. logicznych. Metoda automatyczna umożliwia z kolei przyspieszenie procesu wykrywania częstych, a stosunkowo prostych do wykrycia podatności. 
Metoda hybrydowa – stanowiąca połączenie dwóch powyższych sposobów prowadzenia testu   optymalizuje czas prac przy jednoczesnej maksymalizacji uzyskanego efektu.

Zalety i wady automatycznych narzędzi do wykonywania testów penetracyjnych.

 Zalety i wady manualnego wykonywania testów penetracyjnych.

Testy penetracyjne – przygotowanie dowodu istnienia luki

W przypadku znalezienia podatności, przygotowany jest tzw. Proof of Concept, czyli możliwie realny przykład udowadniający, iż dana podatność rzeczywiście istnieje w systemie. Optymalnie aby PoC przygotowywany był dla każdej zgłaszanej przez audytorów luki.

W czym mogą być pomocne tego typu przykłady? Poza wspomnianym powyżej uprawdopodobnieniem istnienia podatności, całość może być niezmiernie użyteczna przy naprawie błędu. Dowody istnienia luk są jednym z istotniejszych elementów, które znajdują się w raportach poaudytowych.

Etap IV – przygotowanie raportów

Podczas prac testowych, przygotowywane są często dwa raporty. Skrócony raport dla managementu, zawierający takie informacje jak:

• Podsumowanie wykonanych prac.
• Skrótowy opis najistotniejszych znalezionych podatności. 
• Szacowany poziom bezpieczeństwa aplikacji.
• Rekomendowane środki zaradcze.
  

Raport zlokalizowanych podatności, zawierający przykładowo:

• Słowny opis podatności.
• Lokalizacja podatności - opis sposobu, w jaki można zlokalizować i powtórzyć testowy atak na podatność (PoC).
• Poziom niebezpieczeństwa podatności.
• Łatwość odkrycia błędu przez potencjalnego atakującego.
• Sposób naprawy podatności.
  

Warto zaznaczyć, iż raporty w zależności od charakteru audytu mogą się między sobą różnić. Przykładowo – dokument powstały w wyniku testu zgodności systemu z ustawą o ochronie danych osobowych będzie zawierał specyficzne elementy określone w Ustawie. W ogólności jednak dobrze przygotowane dokumenty poaudytowe umożliwiają:

• Osobom nietechnicznym odczytanie wniosków poaudytowych (w tym określenie poziomu bezpieczeństwa aplikacji oraz ewentualne rekomendacje zmian - wyartykułowane na ogólnym poziomie).
• Osobom technicznym – uzyskanie szczegółowych informacji na temat całościowego bezpieczeństwa aplikacji.
• Osobom odpowiedzialnym za kwestie konfiguracyjne i programistyczne związane z audytowanym systemem - lokalizację znalezionych przez audytorów podatności oraz późniejszą naprawę błędów.

Etap V – sprawdzenie skuteczności poprawek

Po dostarczeniu raportów, audytowana firma wdraża poprawki usuwające wykryte błędy bezpieczeństwa. Często jednak pomija się kolejny etap prac testowych - sprawdzenie skuteczności wprowadzonych korekt. Warto mieć świadomość, iż poprawka błędu bezpieczeństwa może być nieskuteczna. Istnieje zarówno wiele metod obejścia wprowadzonych zabezpieczeń jak i mnogość wariantów wykorzystania danej podatności. Aby uzyskać wysokie prawdopodobieństwo usunięcia błędu, warto dokładnie, ponownie sprawdzić znalezione wcześniej luki.

Najczęściej proces ten polega na powtórzeniu większości wykonanych w trakcie audytu testów, jednak ograniczając się tylko do wcześniej znalezionych podatności.

Inne warianty audytu aplikacji WWW

Opisany wcześniej audyt sprowadza się w głównej mierze do testów penetracyjnych aplikacji. Jednak całą procedurę można rozszerzyć o takie elementy jak:

• Audyt infrastruktury (np. serwera HTTP, serwera aplikacyjnego, systemu operacyjnego czy też bazy danych, z której korzysta aplikacja).
• Audyt sieci, w której znajduje się badany system.
• Recenzja bezpieczeństwa aplikacji - na ogólnym poziomie abstrakcji. Np. lokalizacja błędów architektonicznych, integracyjnych czy mających miejsce w procedurach utrzymaniowych aplikacji. 
• Audyt oparty o ściśle określone wytyczne - np. test  systemu na zgodność z ustawą o ochronie danych osobowych.
  

Niekiedy trudno jest określić, jaki zakres audytu wybrać – w takim przypadku zalecamy poprosić  o uzasadnioną rekomendację firmę, z którą zamierzamy współpracować przy audycie.

Kiedy warto wykonywać audyt bezpieczeństwa?

Najprostsza odpowiedź na to pytanie wygląda następująco: wtedy, kiedy ma to największą wartość biznesową dla przedsiębiorstwa. W praktyce jednak często trudno jest określić sytuacje, w której audyt przyniesie nam największą korzyść. W przypadku aplikacji webowych można posłużyć się pewnymi ogólnymi zasadami. Często pozytywna odpowiedź na zaledwie jedno z poniższych pytań może potwierdzić słuszność decyzji o wykonaniu audytu bezpieczeństwa.

• Kiedy w aplikacji przetwarzane są istotne dane (np.: dane Klientów przedsiębiorstwa, dane finansowe, dane osobowe).
• Kiedy znaczna część  działalności firmy opiera się o aplikacje webowe udostępnione w Internecie (np. sklepy internetowe działające w Sieci).
• Kiedy w dostępnym w Internecie systemie przetwarzane są dane osobowe – system taki powinien spełniać wymogi określone w ustawie o ochronie danych osobowych.
• Kiedy wartość chronionych danych znacznie przerasta koszty audytu oraz inne stosowane zabezpieczenia.
• Kiedy istnieją podejrzenia naruszenia bezpieczeństwa aplikacji.
• Kiedy chcemy znacznie zminimalizować ryzyko ataku na system IT, w którego skład wchodzą rozwiązania oparte o WWW.
  

Warto również pamiętać, iż audyt służy przede wszystkim zmniejszaniu ryzyka, za którym stoją realne straty przedsiębiorstwa. Poza szkodami bezpośrednio finansowymi, mogą to być:

• Utrata reputacji  (np. po udanym włamaniu na portal firmowy i nieautoryzowanej zmianie jego treści; po tzw. szumie medialnym dotyczącym niewielkiego poziomu bezpieczeństwa w obrębie danej organizacji).
• Utrata korzyści (np. po wyłączeniu z działania sklepu internetowego).
• Konsekwencje wynikające ze złamania wymogów prawnych (np. po złamaniu ustawy o ochronie danych osobowych).

Zalety i wady audytu bezpieczeństwa aplikacji webowych

Często decyzja o wykonaniu i zakresie audytu bezpieczeństwa, podejmowana jest w oparciu o bardzo wiele specyficznych kryteriów. Z racji na charakter niniejszego artykułu niemożliwym jest zaprezentowanie skrótowego, a zarazem możliwie pełnego zestawienia kryteriów przydatnych do podjęcia decyzji o przeprowadzeniu audytu. Istnieją jednak pewne ogólne cechy charakteryzujące tego typu prace, o których wspominamy poniżej.

 Wśród zalet audytu bezpieczeństwa można wyliczyć:

• Dostarczenie dokumentacji zawierającej przekonywujące informacje dla zarządu - o stanie bezpieczeństwa systemu – umożliwiające podjęcie świadomej decyzji o ryzyku.
• Dokładne wskazanie podatności wraz ze sposobem ich naprawy.
• Możliwość kompleksowej weryfikacji bezpieczeństwa całego systemu IT.
• Możliwość wdrożenia ochrony systemu przed rzeczywistymi atakami.
• Elastyczny kosztowo sposób zwiększania bezpieczeństwa organizacji.
  

Wśród wad audytu można wyliczyć:

• Konieczność  zaangażowania pracowników firmy zlecającej audyt w całość prac (koordynacja prowadzenia testów, koordynacja naprawy podatności).
• W przypadku niekompletnej technicznej wiedzy audytorów – efekt niższy od spodziewanego.
• Dodatkowy koszt dla organizacji zlecającej audyt.
  

Podsumowanie

Obecnie zdecydowana większość ataków na systemy webowe udostępniane w Internecie odbywa się w warstwie aplikacyjnej.  Spowodowane jest to łatwością ataku oraz słabym zabezpieczeniem samych aplikacji WWW. Metodą weryfikującą bezpieczeństwo systemów webowych jest audyt bezpieczeństwa, który często przybiera formę symulowanych realnych ataków na aplikację, zwanych testami penetracyjnymi. Jest to jedna ze skuteczniejszych metod sprawdzenia bezpieczeństwa systemu, pozwalająca sprawdzić jego rzeczywistą ochronę.

W krajach wysoko rozwiniętych, ataki na systemy IT stały się faktem – aby się o tym przekonać wystarczy prześledzić doniesienia zagranicznej prasy. W Polsce era hackingu dopiero się rozpoczyna. Czy Twój system jest na tyle bezpieczny aby oprzeć się nowym zagrożeniom?

Zapraszamy na szkolenie autorskie autora artykułu -
testy penetracyjne systemów IT.

--Michał Sajdak (michal.sajdak@securitum.pl)