Wykładowca:
W trakcie kursu poznaliśmy szereg metod
wykrywania błędów i luk w różnych
typach oprogramowania i infrastruktury.
Zwykle pod koniec testu pentest musisz
poinformować klienta o wszystkich znalezionych
lukach lub o wszystkich wynikach,
co odbywa się
za pomocą raportu z testu pentest.
Więc w zasadzie to, co rozumiemy
przez raport z testu, jest to po prostu
dokument, który zawiera wszystko, co
znalazłeś podczas swojego zaangażowania, aby
klient lub administrator mógł kontynuować i naprawić
wszystkie znalezione luki i słabości.
Te raporty są również często czytane przez kierownictwo, dlatego
trzeba to uwzględnić, więc
dobry raport powinien być dość
łatwy, ale także łatwy do zrozumienia.
Teraz, jeśli pracujesz jako pentester, to
firma, dla której pracujesz, prawdopodobnie
będzie miała swój własny szablon i
własne standardy, których musisz przestrzegać podczas
pisania raportu.
W wielu przypadkach
nawet tego nie
zrobisz, po prostu prześlesz swoje ustalenia innemu członkowi
własnego
zespołu, a oni odpowiednio wypełnią puste pola w raporcie.
Dlatego prawdopodobnie nie będziesz musiał pisać
go
od zera, aw wielu przypadkach nie napiszesz nawet rzeczywistego raportu,
który widzi klient.
Mając to na uwadze, nadal chcę
pokazać, jak to się robi, aby dać ci
wyobrażenie o tym, jak wygląda testowy raport.
Teraz przede wszystkim, zanim pokażę wam
próbkę, którą mam,
dołączę to repozytorium, które zasadniczo zawiera dużą liczbę raportów z testów.
Możesz więc przejrzeć je w poszukiwaniu inspiracji i po
prostu zobaczyć różne style,
którymi kierują się
różne firmy, tworząc raport z testu.
Możesz więc kliknąć na którykolwiek z nich, a znajdziesz
raport i możesz
go przejrzeć, aby dowiedzieć się, jak ta konkretna firma pisze
swoje raporty, a może znajdziesz coś, co
ci się podoba, a co zaczniesz uwzględniać we własnych raportach .
Więc dołączę to do zasobów wykładu, abyście
mogli do niego wrócić po inspirację.
Ale to, co
naprawdę chcę zrobić, to przeprowadzić
cię przez przykładowy raport, którego używamy tutaj
w ZSecurity, aby dać ci wyobrażenie o głównych
sekcjach, które ma większość raportów.
Zamieszczę to również w zasobach, więc możesz
je modyfikować i używać lub
wziąć niektóre z nich, jeśli chcesz.
W repozytorium można zauważyć,
że każda firma ma swój własny styl pisania
raportów, ale ogólnie rzecz biorąc, w każdym raporcie
zawsze znajduje się kilka głównych sekcji.
Więc zaczynając od pierwszej strony tutaj,
mamy stronę tytułową.
Więc znowu, możesz to
sprzedać, jak chcesz, zwykle masz logo
firmy, masz
tytuł, a następnie masz datę raportu i wersję,
to jest bardzo ważne.
A potem mamy firmę, informacje o naszej firmie, więc ten raport
napisany przez nas, to są
informacje o naszej firmie.
A potem masz w polu
for, masz firmę, dla której piszesz ten raport.
Więc masz nazwę firmy,
będziesz miał konkretny identyfikator dla tej firmy.
To jest identyfikator, który identyfikujesz tę firmę
we własnych rejestrach.
Ponownie, prawdopodobnie nie jest
to coś,
co zrobisz sam, otrzymasz ten identyfikator od własnej firmy.
A potem mamy dane kontaktowe do obu firm.
Jak widać w tej firmie, mamy pentester
1 i pentester 2 z ich adresami e-mail,
może to być oczywiście
większa lista z całym zespołem, który robi
pentest, i
podobna do firmy, w której
robisz pentest bo znowu masz
ich nazwiska, ich stanowisko w firmie i ich dane kontaktowe.
Pamiętaj, że nie
zawsze musisz stylizować pierwszą stronę w ten sposób, ale
mniej więcej zazwyczaj na pierwszej stronie
znajdziesz tytuł, datę, wersję i dane
kontaktowe , tak to
robimy,
ale znowu możesz to zrobić
tak, jak chcesz i
możesz czerpać inspirację z zasobów, które tutaj zamieszczę.
Następnie zwykle mamy spis treści.
Znowu, jak
widać, proste rzeczy, zwykle będziemy mieć w dowolnym dokumencie.
Pomoże ci to poruszać się po całym dokumencie.
I tak jak
powiedziałem, tutaj widzimy główne sekcje każdego raportu z testów.
Dlatego bardzo ważne jest, aby mieć streszczenie, jest
to podsumowanie całego zaangażowania, które
jest przeznaczone dla mniej technicznych osób.
Ma więc dać im wyobrażenie o twoich
odkryciach bez zbytniego zagłębiania się w szczegóły techniczne.
Następnie mamy podsumowanie zaangażowania,
w którym
szczegółowo opisujemy zakres, więc
to jest to, co przetestowałeś, które
części ich systemu przetestowałeś, oceny
ryzyka, których użyłeś i przegląd wszystkiego, co znalazłeś.
Więc znowu, na razie nie nurkujemy
głęboko ani po prostu, to tylko podsumowanie całego zaangażowania.
Zrozumiesz to wszystko
lepiej, gdy będę przeglądać raport.
A potem w sekcji szczegółów technicznych, tutaj
zanurzasz się naprawdę głęboko we
wszystkim, co znalazłeś.
Więc w zasadzie mamy sekcję dla każdego znaleziska.
Jak widać, to
tylko próbka, więc dokonałem
tylko trzech ustaleń, mamy wstrzyknięcie SQL, fałszowanie
żądań między witrynami, CSRF i ujawnienie informacji.
Jak widać w pierwszej
sekcji, mamy po prostu
podsumowanie
wszystkiego, co znaleźliśmy,
podczas gdy w szczegółach technicznych zasadniczo rozbijamy
każde znalezisko i porozmawiamy o tym,
jak to
znaleźliśmy w szczegóły, jak ją powielić,
dołączysz zrzuty ekranu, jeśli możesz, aby zespół techniczny
mógł dokładnie zrozumieć powagę tej luki i
jak ją naprawić.
Zauważysz, że inne firmy dodadzą załącznik
na
końcu, będą zawierać zalecenia, w których
dokładnie powiedzą Ci, jak naprawić luki.
Jak powiedziałem, to naprawdę zależy od firmy,
każda firma ma swój własny
styl, a każda firma ma swój własny format.
To, co pokazuję
tutaj, to tylko próbka tego, jak
to robimy, możesz czerpać inspirację z zasobów,
a w wielu przypadkach
wystarczy postępować zgodnie z szablonem, który
ma Twoja firma, ponieważ tak nie jest chcesz, żebyś zrobił to
po swojemu.
Przejdźmy więc do następnej strony,
a zobaczysz na
tej stronie, że mamy informacje prawne.
I właśnie dlatego powiedziałem,
że prawdopodobnie nie zrobisz tego
sam, nigdy nie będziesz musiał
tego robić sam, ponieważ będziesz mieć takie części raportu, których
nigdy nie będziesz musiał modyfikować,
a faktycznie będą napisany przez zespół prawny w
Twojej firmie.
Będą więc uwzględniać wszystko, co może wymknąć się spod
kontroli, aby upewnić się,
że nie zostaniesz pozwany, jeśli
coś pójdzie nie tak, będzie zawierać takie informacje, jak zastrzeżenia,
RODO, prywatność, kwestie prawne i
wszystkie te rzeczy, które robimy Naprawdę nie wiem
zbyt dobrze, jak zwykle piszą pentesterzy i prawnicy.
A potem mamy dziennik zmian dokumentu.
Więc za każdym razem, gdy wprowadzana jest zmiana w
dokumencie, widać, że mamy
datę, mamy wersję i mamy komentarz, dlaczego
wprowadziliśmy tę zmianę?
Albo co jest tak znaczącego w tej zmianie?
Więc to był pierwszy raport, kiedy
zrobiliśmy go 1 stycznia,
a 10 stycznia zrobiliśmy
drugą wersję,
w której skończyliśmy ze Sceną Recon.
Znowu, to tylko przykłady,
ale tylko po to, aby dać ci wyobrażenie, że
prowadzenie dziennika zmian wszystkich zmian, przez które przechodzi
ten dokument, jest bardzo, bardzo ważne.
Nie wszystkie firmy to
robią, ale to tylko nasz własny wybór,
aby dodać to do naszego raportu.
Powtarzam to tylko po to, aby dać
wam wyobrażenie, że nie
ma ustalonych zasad tworzenia tego rodzaju dokumentów.
Możesz dodać lub usunąć
wszystko, co chcesz, ale główne
części to część prawna, streszczenie, a
następnie część techniczna, czyli główne części raportu.
Więc teraz mamy streszczenie i możesz
je przeczytać.
To nie powinno być
długie, więc
moim zdaniem musi to być strona, maksymalnie dwie
strony, jeśli naprawdę musisz.
I zasadniczo mówi
po prostu, że zostaliśmy poinstruowani, aby przetestować system X,
wyjaśni, jak zorganizowany jest ten dokument, gdzie pierwsza
sekcja jest mniej szczegółowa, aby
dać ci wyobrażenie o ryzyku,
a druga jest szczegółowa dla personel techniczny
w celu zrozumienia tych zagrożeń i ich naprawienia. .
A potem otrzymujemy ocenę
ryzyka, więc zakładamy, że jest to
obarczone wysokim ryzykiem, w oparciu o wykryte
luki w zabezpieczeniach, będzie ona szczegółowo opisywać metodologię, którą zastosowaliśmy.
A potem mamy tutaj kilka wykresów.
Pamiętaj, ta część została przeczytana przez kierownictwo, są
to ludzie, którzy przez większość
czasu nie są zbyt techniczni, a także nie mają dużo czasu.
Dlatego dołączamy tutaj wykresy,
aby pokazać liczbę znalezionych luk w zabezpieczeniach.
Widzimy więc, że mamy pięć luk, które są
wysokie, mamy 10, które są średnie, a osiem jest niskich.
To da im naprawdę dobre zrozumienie
zagrożeń, z którymi się borykają.
A potem przejdziemy do podsumowania.
Ponownie, będzie to nadal czytane przez mniej technicznych ludzi.
Przede wszystkim szczegółowo opisujemy zakres, aby upewnić
się, że powiemy im, co przetestowaliśmy, mimo
że już powiedzieli nam, co testować, tylko
po to, aby w przyszłości, gdyby
coś zostało odkryte poza naszym zakresem i wracają
do nas,
możemy powiedzieć, no cóż, to było poza zakresem,
nie testowaliśmy tego.
Następnie dołączamy oceny ryzyka.
Tak więc będziesz mieć
to w każdym dokumencie,
który chcesz, abym go zmodyfikował, zasadniczo mówimy tylko,
jak sklasyfikowalibyśmy określoną lukę jako niską, średnią, wysoką lub krytyczną.
A my mówimy, naszym zdaniem,
jak należy radzić sobie z słabymi, średnimi,
wysokimi i krytycznymi podatnościami.
Możesz zobaczyć krytyczne,
mówimy, że musisz naprawić natychmiast,
podczas gdy niskie, musisz
naprawić w następnym cyklu aktualizacji.
Ponownie, to tylko nasza własna opinia.
Następnie mamy przegląd ustaleń.
Więc wciąż jesteśmy w
sekcji pierwszej, to wciąż jest dla
kadry kierowniczej, nie musimy nurkować zbyt głęboko.
Więc właśnie otrzymaliśmy identyfikator luki w zabezpieczeniach.
Jak widać, pierwsza luka jest krytyczna, jest
to wstrzyknięcie SQL.
W wielu przypadkach, w
wielu raportach, poprzestają na stwierdzeniu, że to tylko wstrzyknięcie SQL.
Lubimy pokazywać wpływ w tej sekcji, ponieważ jak
powiedziałem, ci goście nie są
techniczni, więc jeśli przeczytają
wstrzyknięcie SQL, mogą nie wiedzieć, co to
jest wstrzyknięcie SQL, i zależy im na wpływie tej luki.
Ponownie, nie mają dużo czasu,
więc musisz przejść od razu do
sedna, więc mówimy, że jest to wstrzyknięcie SQL,
które może prowadzić do autoryzowanego dostępu do bazy danych.
Więc teraz wiedzą, że dzięki tej luce
haker może uzyskać dostęp
do ich bazy danych, prawdopodobnie jest to bardzo złe.
Inna luka, którą znaleźliśmy, jest średnia, a
CSRF ponownie, wiele raportów zatrzyma się tutaj, tak naprawdę
nie wyjaśnia niczego osobom nietechnicznym.
Mówimy więc, że klienci mogą być zmuszeni
do przesyłania pewnych niekrytycznych żądań, dlatego jest to
medium, nie są to żądania
niekrytyczne, ale mogą być zmuszeni do przesyłania rzeczy.
A potem mamy jedną
niską lukę, w której ujawniono wersję
PHP, więc nie jest to
bardzo ważne, ponieważ nie jest
to rzeczywista luka, którą można wykorzystać do uzyskania dostępu lub ujawnienia danych
użytkownika, ale ta informacja może być przydatna dla
hakerów do łączenia
się z inne ataki lub odkryć luki w tej konkretnej
wersji PHP,
dlatego jest to dozwolone, dlatego nie
trzeba pilnie się tym zająć,
jak te krytyczne, o których wspomnieliśmy powyżej.
I nie krępuj się przeczytać tekst
tutaj, zobaczysz, że wiele z nich jest po prostu po to, aby
usunąć nasze błędy i upewnić się, że rozumieją wszystko,
co jest w raporcie.
I to byłby koniec podsumowania, a teraz
przechodzimy do szczegółów technicznych.
Więc w tej sekcji mamy, tak jak powiedziałem,
podsekcję dla każdego pojedynczego odkrycia, które mamy,
i naprawdę zagłębiamy się w
szczegóły tego odkrycia.
Widać więc, że jest to
wstrzyknięcie SQL, o którym wspomnieliśmy wcześniej
w podsumowaniu, ale tym razem podajemy
im adres
URL, który jest podatny, podajemy im parametr
podatności, dajemy im odniesienia, aby
zrozumieć, co Wstrzyknięcie SQL polega na tym, że na wypadek,
gdyby nie rozumieli, przekazujemy
im dokładne żądanie i dokładną odpowiedź, którą
otrzymaliśmy, co skłoniło nas do ustalenia, że ta konkretna
strona jest podatna na wstrzyknięcie SQL.
Następnie dajemy im szczegółowy wpływ, nie tylko mówimy,
że mogą uzyskać dostęp do bazy danych, więc
mówimy, że mogą uzyskać dostęp
do bazy danych, mogą pobierać
dane, mamy dostęp do tabeli użytkownika,
więc jesteś zagłębię
się w szczegóły i powinieneś nawet zamieścić tutaj
zrzuty ekranu, jeśli uważasz, że będą przydatne.
W sekcji
łagodzenia po prostu dajemy im
szybką rekomendację, tak jak powiedziałem, niektóre firmy podają szczegółowe
zalecenia, to naprawdę zależy również od zaangażowania.
W tym przykładzie mówimy po
prostu, używaj przygotowanych instrukcji z zapytaniami sparametryzowanymi i
dajemy im odniesienie, aby dowiedzieć się, jak
to zrobić lub zrozumieć, jak to działa.
I to prawie wszystko.
Więc powtórzysz, że dla
każdej znalezionej luki
zostawiam resztę pustą, ponieważ to tylko próbka, ale masz
pomysł.
Więc będziesz miał podsekcję dla każdego odkrycia, które
masz, wyjaśnij wszystko szczegółowo, aby zrozumieli lukę,
a następnie mogli
iść dalej i ją naprawić.
Na koniec wiele firm miałoby załącznik i może
mieć większą sekcję rekomendacji, tak jak powiedziałem, to
jest nasz styl pisania raportów, ale każda
firma ma swój własny styl.
Jeśli Ci się to podoba, może poświęć
trochę czasu na przeglądanie przykładowych
raportów, które mamy w tym repozytorium.
Oczywiście umieszczę zarówno linki do mojej próbki, jak i
do innych próbek w zasobach, dzięki
czemu można je samemu przejrzeć
i zorientować się, jak wyglądają raporty z testów penetracyjnych.
Ale tak jak powiedziałem, w wielu
przypadkach po prostu wypełnisz próbkę podobną do
tej, którą mamy tutaj,
więc nigdy nie zostaniesz poproszony o wymyślenie takiej od zera.