-15% na nową książkę sekuraka: Wprowadzenie do bezpieczeństwa IT. Przy zamówieniu podaj kod: 10000

Czego uczą metodologie testów penetracyjnych (cz.2.)

02 grudnia 2013, 10:37 | Teksty | komentarzy 11
W poprzedniej części poznaliśmy ogólne podejście do testów penetracyjnych (Czego uczą metodologie testów penetracyjnych, cz. 1.).

Przyjrzyjmy się teraz pokrótce popularnym metodykom, aby poznać ich mocne i słabe strony.

 

Przegląd popularnych metodologii

1. OWASP Web Application Penetration Testing (Testing Guide)

OWASP Testing Guide jest jednym z najbardziej rozpoznawalnych projektów organizacji OWASP. Dokument ten opisuje metodologię OWASP Web Application Penetration Testing oraz sposoby testowania zabezpieczeń.

Metodyka organizacji OWASP zakłada, że testy mają charakter czarnej skrzynki (ang. blackbox), gdzie tester nie ma dostępu do kodu źródłowego badanej aplikacji. Metodologia OWASP definiuje podział na dwie fazy: pasywną oraz aktywną.
  1. W fazie pasywnej poznaje się logikę aplikacji oraz zbiera się informacje o badanym systemie (Information Gathering). Celem tej fazy jest zrozumienie metody działania aplikacji oraz enumeracja, jak największej liczby punktów wejścia (ang. access points; gates). Czynności wykonywane podczas zbierania informacji nie powinny mocno zakłócać działania badanego systemu.
  2. W fazie aktywnej wykonywane są kolejne testy bezpieczeństwa. OWASP w czwartej wersji dokumentu opisał ponad 70 testów, które zostały podzielone na następujące kategorie:

Każdy z testów posiada unikatową sygnaturę, np. Data Validation -> Testing for Stored Cross site scripting (OWASP-DV-002), co podczas wykrycia zagrożenia, pozwala wygodnie wskazać źródło opisujące naturę błędu.

Opisy poszczególnych zagrożeń są największą zaletą Testing Guide. Oprócz podstawowych informacji opisujących charakter luki, OWASP pokazuje metody znajdywania podatności, wskazuje przykładowe oprogramowanie wspomagające testy oraz odsyła do stron i prac naukowych, które dokładniej opisują dane zagadnienie.

Warto zaznaczyć, że OWASP w swojej metodologii nie narzuca metody znajdywania podatności – wskazuje jedynie elementy, które należy przetestować oraz podpowiada, w jaki sposób można to zrobić. Dobór narzędzi czy kolejność wykonywanych testów zależy całkowicie od pentestera.

Obecnie trwają pracę nad czwartą wersją dokumentu, w którym stopniowo dodawane są kolejne testy.  Testing Guide v4 odświeżył opisy zagrożeń oraz rozszerzył kategorie o nowe testy. Dokument nadal posiada wiele pustych elementów, ale w takich miejscach śmiało można się odnieść do wersji trzeciej, która mimo publikacji w 2008 r., nie straciła zbyt wiele z aktualności.

Elementy dokumentu są na tyle dobrze opisane, że stały się jednymi z najczęściej cytowanych źródeł w badaniach naukowych z dziedziny bezpieczeństwa web aplikacji. Referencje do testów tej metodyki często pojawiają się również w narzędziach bezpieczeństwa takich jak np. Burp Suite, OWTF, Dradis czy Acunetix.

OWASP Testing Guide można odebrać nie tylko jako prostą metodologię, ale przede wszystkim jako kompendium testów penetracyjnych aplikacji internetowych.

Zalety

Wady

  • elastyczna i prosta w nauce metodyka, dająca dużą swobodę w testach
  • bardzo dobra rozpoznawalność
  • duża liczba testów
  • bardzo szczegółowe informacje o testowanych niebezpieczeństwach
  • może pełnić rolę kompendium bezpieczeństwa web aplikacji
  • dość aktualna w porównaniu do innych metodyk
  • dotyczy wyłącznie testów aplikacji internetowych (ale posiada podstawowe informacje o testach infrastruktury)
  • nastawiona wyłącznie na testy blackbox – mało informacji o testach w metodzie białej skrzynki
  • zbyt wolny rozwój wersji 4., w której znajdują się nowe zagrożenia, np. testy bezpieczeństwa AJAX czy HTML5
  • przeplatanie w zasobach OWASP wersji 3. (starej) oraz 4. (niedokończonej)

Szczegóły metodologii:

 

2. Web Application Security Consortium Threat Classification (WASC-TC)

Dokument OWASP Testing Guide opisuje pewne elementy metodyczne, ale w praktyce traktowany jest jako dobrze udokumentowana klasyfikacja błędów bezpieczeństwa w aplikacjach internetowych. Podobny podział błędów znajduje się w dokumencie WASC-TC.

Web Application Security Consortium stworzyło klasyfikację opisującą zarówno błędy (ang. vulnerability), jak i słabości (ang. weakness) aplikacji internetowych. W wersji drugiej standardu (obecnie najnowszej) scharakteryzowano 49 zagrożeń.

WASC niektóre błędy opisuje bardziej ogólnie niż OWASP (np. błędy XSS nie są rozbijane na różne podgrupy), ale uogólniając, liczba zagrożeń w obu dokumentów jest podobna. Niestety w klasyfikacji WASC  znajdują się też zagrożenia, które w zasadzie od wielu lat raczej nie są spotykane w aplikacjach internetowych (np. błędy Buffer Overflow lub Integer Overflow).

Poszczególne zagrożenia WASC-TC również opisywane są bardzo szczegółowo, w podobnej formie, jak ma to miejsce w Development Guide. Tym co odróżnia metodologię WASC od OWASP, jest inne podejście do kategoryzacji zagrożeń.

WASC-TC, zamiast ogólnych kategorii czy faz, posiada trzy widoki, pokazujące różną perspektywę wyszukiwania zagrożeń:

  • Enumeration View — zawiera szczegółowy opis każdego błędu lub słabości, który wpływa na bezpieczeństwo web aplikacji. Każdy element ma przypisany identyfikator WASC-ID;
  • Development View — perspektywa programisty pokazująca sposób, w jaki można doprowadzić do błędu bezpieczeństwa — zarówno w fazie projektowania, implementacji, jak i wdrażania oprogramowania (ang. design, implementation, deployment);
  • Taxonomy Cross Reference View — pomaga przyporządkować dane zagrożenie do innych metodyk lub standardów, takich jak: Mitre’s CWE, SANS CWE, CAPEC czy nawet OWASP TOP 10.

Widoki WASC-TC pozwalają spojrzeć na dane zagrożenie zarówno z perspektywy:

  • inżyniera bezpieczeństwa — szukającego metody testowania,
  • programisty — którego interesuje proces pojawiania się błędu w systemie oraz
  • audytora — którego celem jest zlokalizowanie i sklasyfikowanie ryzyka.
WASC-TC Enumeration View.

WASC-TC Enumeration View.

Klasyfikacja WASC-TC 2.0 została opublikowana w 2011 roku. Aktualność dokumentu w wersji drugiej odpowiada w przybliżeniu OWASP Development Guide v3 (2008 r.).

Zalety

Wady

  • dobre uzupełnienie/zastępstwo OWASP Testing Guide
  • dokument ogniskujący uwagę na klasyfikacji błędów, bez zbędnych, ideologicznych otoczek
  • ciekawa idea widoków,  która pozwala spojrzeć na zagrożenia z perspektywy testera, programisty oraz audytora
  • dotyczy wyłącznie testów aplikacji internetowych (ale posiada podstawowe informacje o testach infrastruktury)
  • jest w praktyce klasyfikacją błędów, a nie metodyką
  • nieznacznie mniej szczegółowy opis zagrożeń niż w OWASP Testing Guide
  • dużo odwołań do języka C, C++ oraz Perl, które obecnie są rzadko stosowane w kontekście aplikacji internetowych

Szczegóły metodologii:

 

3. Penetration Testing Execution Standard (PTES)

Standard PTES jest tworzony przez doświadczonych inżynierów bezpieczeństwa, którzy postanowili stworzyć metodologię, ułatwiającą pogodzenie warstwy biznesowej oraz technicznej testów penetracyjnych.

PTES, podobnie jak inne metodologie, wyróżnia kilka faz, w ramach których wykonywane są testy bezpieczeństwa. Penetration Testing Execution Standard wymienia następujące fazy:

Łatwo zauważyć, że fazy opisane w tej metodologii przypominają kategorie OWASP Testing Guide, więc PTES opisuje „klasyczny” model pentestów.

W odróżnieniu jednak od poprzednich metodologii, w PTES akcje wykonywane przez pentestera zostały przedstawione jako mapa myśli. Każdy element mapy został pokrótce opisany, jednak informacje o zagrożeniach są bardzo krótkie i ogólne. Niestety PTES jest więc bardzo ogólnym standardem i nadaje się wyłącznie jako natchnienie lub uporządkowanie myśli pentestera. W zasadzie wszystkie elementy w metodologii opisano bardzo pobieżnie – bez szerszej analizy celów i problemów każdej czynności.

Mimo tego PTES można polecić początkującym penteserom, jak punkt startowy do nauki innych metodologii.

Zalety

Wady

  • bardzo prosty koncept  testów penetracyjnych
  • dostosowany do dowolnych testów penetracyjnych (nie tylko web-aplikacji)
  • dobry dla początkujących inżynierów bezpieczeństwa
  • nie narzuca konkretnych narzędzi
  • bardzo lakoniczne opisy elementów metodologii
  • niezbyt wygodna forma dokumentu (w postaci kiepskiej strony wiki)
  • nie nadaje się jako referencja lub dokument audytowy do poważnych testów


Szczegóły metodologii:

 

4. Open Source Security Testing Methodology Manual (OSSTMM)

Opracowany przez instytut ISECOM dokument OSSTMM jest kolejną metodologią do przeprowadzania testów bezpieczeństwa, która została stworzona w duchu Open Source.

OSSTMM jest niezwykle szczegółowym dokumentem, który został stworzony na bazie wielu badań. Jest bardzo dobrze rozpoznawany w środowisku audytorów, pentesterów, a nawet inżynierów bezpieczeństwa, pracujących na co dzień w projektach IT.

Największą zaletą standardu jest jego kompleksowe przygotowanie, które uwzględnia nie tylko sposoby znajdowania podatności, ale również ryzyko biznesowe, koszty testów oraz problemy związane z wdrażaniem poprawek. Dzięki tak szerokiej perspektywie OSSTMM jest bardzo często wybierany przez firmy, jako element cyklu bezpiecznego wytwarzania oprogramowania.

OSSTMM opisuje sposób zapewniania bezpieczeństwa dowolnego systemu informatycznego, więc nie skupia się tylko na aplikacjach internetowych. OSSTMM definiuje pięć sekcji, nazywanych kanałami (ang. channels), które wskazują charakter testów. Klasa testów, zależna od wybranych kanałów, została przedstawiona poniżej.

OSSTMM Channels.

OSSTMM Channels.

Klasa testów — bezpieczeństwo fizyczne, spektrum oraz komunikacyjne — zależy od wybranych kanałów.

Kanał definiuje badanie następujących obszarów badanego systemu:

  1. Human — dotyczy elementów komunikacji międzyludzkiej;
  2. Physical — to testy bezpieczeństwa fizycznego, które dotyczą zarówno interakcji z urządzeniami elektronicznymi, jak i fizycznego kontaktu z elementami badanej infrastruktury;
  3. Wireless — dotyczy łączności bezprzewodowej;
  4. Telecommunications — obejmuje badanie sieci telekomunikacyjnej, mediów analogowych oraz cyfrowych, gdzie interakcja wymaga ustanowienia połączenia wdzwanianego lub połączeń podobnego rodzaju;
  5. Data Networks — testy wszystkich systemów i sieci, w których ustanawiane są połączenia kablowe lub połączenia podobnego rodzaju.
Każdy element występujący w OSSTMM jest rozpisany w największych szczegółach. Dokument wyjaśnia krok po kroku sposób przeprowadzenia testów, ich cel, przedstawia motywacje testera oraz klienta. Dokładny opis i szerokie spojrzenie na aspekt bezpieczeństwa powoduje, że metodologia instytutu ISECOM ma charakter audytowo–procesowy. Na szczęście, pentesterzy również mogą dowiedzieć się z dokumentu, jak przeprowadzać swoje testy — zostały one zdefiniowane jako jeden z rodzajów testów.

Niezależnie od tego, jakie kanały zostaną wybrane przez klienta, testy mogą być przeprowadzane na kilka sposobów — w zależności od ilości informacji znanych osobie przeprowadzającej testy oraz wiedzy osób utrzymujących testowany system. Rodzaje testów OSSTMM i zależności występujące między nimi, obrazuje poniższy schemat:

OSSTMM Common Test Types.

OSSTMM Common Test Types.

W zależności od ilości informacji przezywanych klientowi oraz testerowi wyróżniamy następujące rodzaje testów:

  • Blind (War Gaming/Role Playing) — wykorzystywane głównie do sprawdzenia wiedzy testera: klient jest całkowicie zaangażowany w testy i ma dużą wiedzę o systemie, tester nie dostaje żadnych informacji o systemie;
  • Double Blind (Black Box/Penetration Test) — typowe podejście testów penetracyjnych: klient nie wie, czego się spodziewać po ataku, pentester symuluje atak z perspektywy włamywacza rozpoczynającego atak (zazwyczaj) spoza infrastruktury;
  • Gray Box (Vulnerability Test) — z jednej strony może to być odmiana testów ślepych (Blind), które mają na celu testowanie umiejętności, ale mogą to być również czynności inżynierów bezpieczeństwa, dokonujących samooceny stanu bezpieczeństwa pewnego systemu w obrębie firmy lub bliźniaczego projektu;
  • Double Gray Box (White Box) — w tym wariancie klient zna zalety testów, ustala ich zasięg i czas trwania, nie wie jednak dokładnie, jakie kanały i w jaki sposób będą testowane. Celem testera jest przeprowadzenie ataku oraz analiza nie tyle wyłącznie podatności, a reakcji klienta na zmieniające się środowisko w momencie znajdywania luk bezpieczeństwa;
  • Tandem (Crystal Box) — w tym rozwiązaniu analityk wie wszystko o testowanym systemie i ściśle współpracuje z klientem. Sytuacja ta występuje przykładowo wtedy, gdy inżynier bezpieczeństwa jest częścią zespołu programistycznego oraz procesu wytwarzania oprogramowania.
  • Reversal — specyficzny typ testów, w których klient ma świadomość zatrudnienia specjalisty, ale nie wie, kiedy oraz w jaki sposób system zostanie przetestowany przez analityka posiadającego szczegółowe informacje o systemie. Do tej kategorii zaliczają się tzw. testy grupy „Red Team”.

Tematyka OSSTMM jest dużo bardziej rozległa i opisuje wiele innych aspektów zapewniania bezpieczeństwa. Jest to ogromny dokument, który opisuje wiele wskazówek dla różnego rodzaju inżynierów bezpieczeństwa.

Niezależnie od tego, czy inżynier bezpieczeństwa zamierza wdrożyć proces do projektu, przeprowadzić audyt lub test penetracyjny, OSSTMM będzie nieocenionym źródłem informacji oraz narzędziem, dzięki któremu bardzo dokładnie będzie można określić stopień bezpieczeństwa badanego systemu.

Zalety

Wady

  • dobrze zdefiniowany, otwarty standard
  • duża rozpoznawalność
  • dokument napisany przystępnym językiem, co pozwala na poszerzenie horyzontów inżynierów bezpieczeństwa
  • spojrzenie metodyczne, audytowe oraz pentesterskie
  • dokładny opis sposobu testowania różnego rodzaju infrastruktury (channels)
  • możliwość przeprowadzania certyfikowanych testów
  • pozwala szczegółowo określić aktualny stan bezpieczeństwa badanego systemu
  • dość aktualizowany
  • mimo dokładnej metodologii, brak narzucania konkretnych narzędzi
  • mało kontekstu stricte pentesterskiego (przeważa podejście procesowo-audytowe)
  • bardzo obszerny dokument, którego raczej nie powinno poznawać się wybiórczo
  • dość skomplikowany sposób liczenia metryk
  • nie nadaje się do jednorazowych, szybkich testów bezpieczeństwa

Szczegóły metodologii:

 

W kolejnej, ostatniej już części artykułu, krótko zapoznamy się z metodologiami, normami i wytycznymi, które nie dotyczą stricte tematyki testów penetracyjnych, ale dzięki którym można zwiększyć jakość testów bezpieczeństwa oraz raportowanych podatności.

Znając perspektywę pentesterską, audytową oraz procesową, będziemy mogli zastanowić się również, w jaki sposób odnosić się do opisanych metodologii.

 — Adrian “Vizzdoom” Michalczyk dla serwisu Sekurak.pl

 

Spodobał Ci się wpis? Podziel się nim ze znajomymi:



Komentarze

  1. bl4de

    Tak się zastanawiam…

    Czy @Sekurak mógłby się jakoś odnieść do tematu od strony „praktycznej” ? :)

    Jak wygląda kwestia stosowania takich metodyk w codziennej pracy takich firm, jak Securitum? Tak z ciekawości pytam – jak ma się to do codziennej pracy przy wykonywaniu testów penetracyjnych?

    PS. Vizzdoom – jak zwykle świetny tekst :)

    Odpowiedz
    • @bl4de

      w praktyce, naprawdę ciężko powiedzieć.
      Najlepiej to sprawdzić…przez praktykę ;-)

      Odpowiedz
  2. bl4de

    :)

    No tak, ale ja w… hmm…. „praktyce”, raczej nie stosuję żadnej z opisanych metodologii ;)

    A poważnie – np. w przypadku testów typu black-box, gdy dodatkowo trzeba zachować, powiedzmy, tryb „stealth”, by pracownicy odpowiedzialni za infrastrukturę nie zorientowali się, że coś się dzieje – jak takie metodologie się stosuje? Wydaje mi się, że zastosowanie się ściśle do ich wymagań generuje spory „hałas” na łączach.

    No chyba, że wymagania testów zakładają, że pracownicy są świadomi, że infrastruktura podlega właśnie audytowi?

    Odpowiedz
    • No widzisz, w metodologiach nawet są określenia typu 'blue teaming’ i 'red teaming’ – w zależności od tego czy 'cel’ wie o testach czy nie ;-)

      Odpowiedz
    • No i na pewno metodologie przydają się jak chcesz zlecić pentesty – bo zwiększasz szansę że dostaniech z różnych miejsc w miarę podobny zakres (np. ASVSv2) – choć im więcej masz doświadczenia tym w sumie chyba z tym zaczyna być różnie ;)

      Odpowiedz
  3. bl4de

    No tak, z ostatnim się zgodzę, na pewno stosowanie się do określonej metodologii pozwala na w miarę konkretne porównanie dwóch badanych zasobów.

    Podoba mi się „Double blind” – chyba najbardziej zbliżony do rzeczywistych warunków, prawda?
    No i „Reversal” – tu musi być niezły „fun” :)

    Odpowiedz
  4. bl4de – ten cykl był pisany wbrew pozorom ze strony praktycznej. Czy opłaca się poznawać te techniki i co tak na prawdę się z tego wynosi podczas pentestów – to trudne pytanie. Ale na nie, tak jak obiecałem, spróbujemy odpowiedzieć w trzeciej części :) I właśnie tam liczę na dyskusję i wymianę poglądów ;)

    Odpowiedz
  5. bl4de

    @vizzdoom

    Czekam zatem na część 3. :)

    Odpowiedz
    • bl4de: 3cia część jest już w zasadzie gotowa do publikacji :) Parę dni i będzie na sekuraku.

      Odpowiedz
  6. MateuszM

    @bl4de, z doświadczenia mogę powiedzieć, że wszystko co porządkuje i układa „temat” jest pożyteczne i warte zastosowania. Co prawda miałem styczność z informatyką śledczą i tam postępowanie krok po kroku zgodnie z określonymi zasadami jest bezcenne. Przypuszczam, że od drugiej strony metodyczne podejście też nie zaszkodzi. Oczywiście raz jest to kartka i długopis plus lista TODO a raz metodyka rozpisana na kilkuset stronach. Dzięki temu masz pewność, że zrobisz wszystko co zamierzałeś i co powinieneś.

    Możecie polecić jakieś aplikacje wspomagające opisane metodyki?

    Odpowiedz
  7. @MateuszM
    Są takie narzędzia, chociaż nie jest tego bardzo dużo. Głównie są to róznego rodzaju szablony do systemów bugtrackingowych (ewentualnie łatwo coś takiego zrobić raz i sobie kopiować).

    Są też dedykowane narzędzia do takich praktyk, jak np. Dradis. Będę o tym pisał za jakiś czas, ale nie potrafię się do końca do niego przekonać.

    Odpowiedz

Odpowiedz