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

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ń.

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:

• Configuration Management Testing,
• Business Logic Testing,
• Authentication Testing,
• Authorization Testing,
• Session Management Testing,
• Data Validation Testing,
• Denial of Service Testing,
• Web Services Testing,
• Ajax Testing.

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.

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.

Szczegóły metodologii:

• OWASP Web Application Penetration Testing (Testing Guide) v4 [draft, 2013]
• OWASP Web Application Penetration Testing (Testing Guide) v3 [stable]

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.

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.

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.).

Szczegóły metodologii:

• WASC-TC v2.0 (2011) (online, pdf)

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:

• Pre-engagement Interactions,
• Intelligence Gathering,
• Threat Modeling,
• Vulnerability Analysis,
• Exploitation,
• Post Exploitation,
• Reporting.

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

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

Szczegóły metodologii:

• PTES wiki

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.

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.

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.

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.

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.

Szczegóły metodologii:

• OSSTMM v3 (stable), v4 (draft), webapp

 — Adrian “Vizzdoom” Michalczyk dla serwisu Sekurak.pl