Kupujemy roczną subskrypcję na usługi skanowania za 199 funtów, generujemy surowy raport, upychamy go w szablon naszej „metodologii” i sprzedajemy jako efekt pięciodniowego projektu „konsultingowego” ze stawką 1000 funtów za dzień. Brzmi jak przepis na niezły biznes. Niestety, nie dla klienta…

W ciągu kilku ostatnich lat uczestniczyłem w setkach testów penetracyjnych, zarówno jako testujący, jak i „broniący”. Na co dzień testuję wiele aplikacji wewnętrznych, które później są badane przez zewnętrzne zespoły pentestowe. Stale porównuję rezultaty testów własnych i tych prowadzonych przez podmioty trzecie, co jest o tyle łatwe, że zwykle wykorzystujemy to samo narzędzie. BurpSuite używają prawie wszyscy. Jest niezawodne, zawiera mnóstwo funkcji i ma wspomnianą wyżej dobrą cenę. Za takie możliwości, 199 funtów to naprawdę mało. Można by się spodziewać, że skoro narzędzie jest tanie, wykorzystujący je eksperci mają spore pole do popisu w kwestii interpretacji wyników – to w końcu tylko narzędzie…

Podatności i „podatności”

I tu zaskoczenie. Większość trafiających do mnie raportów wykonywanych przez firmy trzecie to praktycznie surowe zrzuty danych z BurpSuite. Praca interpretacyjna, jeśli w ogóle jest wykonywana, to minimalnym nakładem. Autorzy zwykle nawet nie próbują zrozumieć kontekstu działania testowanej aplikacji, co pozwoliłoby odsiać większość zgłaszanych przez narzędzie podejrzanych zachowań. Najbardziej martwi mnie jednak to, że taką leniwą postawę prezentują znane i poważane marki, posiadające wszelkie możliwe certyfikaty w dziedzinie bezpieczeństwa.

„Większość trafiających do mnie raportów wykonywanych przez firmy trzecie to praktycznie surowe zrzuty danych z BurpSuite. Praca interpretacyjna, jeśli w ogóle jest wykonywana, to minimalnym nakładem. Autorzy zwykle nawet nie próbują zrozumieć kontekstu działania testowanej aplikacji, co pozwoliłoby odsiać większość zgłaszanych przez narzędzie podejrzanych zachowań”

Chyba najczęściej zgłaszaną „podatnością” jest brak flagi httpOnly w ciasteczkach (cookies). BurpSuite wychwytuje je bez problemu, bo łatwo je zauważyć, ale zgłaszanie ich jako dziury w bezpieczeństwie świadczy albo o szkodliwej rutynie, albo o niezrozumieniu sensu tej flagi. Jej celem jest ograniczenie widoczności ciasteczka dla kodu JavaScript. To, czy ciasteczko ma być widoczne, czy też nie, jest wyłącznie decyzją architekta aplikacji, a nie bezwzględną zasadą projektowania. BurpSuite ma prawo tego „nie wiedzieć” – ekspert, który się nim posługuje – powinien.

Podobnie będzie ze zgłaszaniem braku flagi Secure w przypadku takiego cookie: Set-Cookie: myCookie=; path=/. Bo czy brak flagi rzeczywiście spowoduje ujawnienie zawartości pliku cookie? Nie, bo nie ma tutaj żadnego cookie. Taki nagłówek kasuje, a nie ustawia cookie. Nie ma cookie, nie ma wycieku danych. Zgłaszanie tego jako podatności to po prostu błąd rzeczowy.

W raportach często można znaleźć przykłady traktowania wszystkiego co zgłasza skaner jako „pomniejszych podatności”. Tak zwykle traktowany jest raport application data is cached on client browsers. Na jakiej podstawie? BurpSuite raportuje to, gdy nie widzi nagłówka Cache-Control, ale słusznie zgłasza to jako informational item. Przerabianie tego na „podatność” świadczy jednak o niezrozumieniu tego, jak działa buforowanie stron pobieranych przez TLS.

Pojawiają się także kwestie dyskusyjne. Czy, na przykład, API zwracające bez filtrowania dane wejściowe w odpowiedzi JSON to już reflected XSS? Odpowiedź brzmi: to zależy. Biorąc pod uwagę istnienie ataków Reflected File Download pewnie wolałbym wiedzieć o takich przypadkach. Ale klasyfikowanie takiego odkrycia od ręki jako reflected XSS vulnerability nie jest zbyt profesjonalne.

„Bezużyteczne” wyniki pentestów?

Firmy wykonujące testy penetracyjne są zatrudniane w celu weryfikacji jakości kodu tworzonego wewnętrznie lub kodu pochodzącego od dostawcy zewnętrznego. Sponsorzy tych projektów zwykle nie dysponują wiedzą pozwalającą im samodzielnie ocenić jakość pracy programistów (inaczej nie wynajmowaliby pentesterów), a tym bardziej efektów testów penetracyjnych. Firma wykonująca testy ma więc w projekcie bardzo odpowiedzialną rolę. Wykorzystuje wiedzę, która nie jest powszechna, bierze za to spore pieniądze, a na dodatek jej rady mogą wpływać na jakość relacji biznesowych między dostawcą i sponsorem projektu. Pytanie: kto będzie kontrolować kontrolera? Wykonywanie testów penetracyjnych staje się zawodem zaufania publicznego, i dlatego osoby parające się tym powinny stronić od bezmyślnego kopiowania surowych danych z automatycznych skanerów podatności.

Rozdymanie raportów z testów penetracyjnych po to, by udowodnić, że swoją robotę wykonało się rzetelnie, to marnowanie czasu swojego i wszystkich uczestników projektu. Ponadto, w ten sposób można wprowadzić do projektu ryzyko dużo poważniejsze, niż brak flagi w pliku cookie. Jeżeli zespół deweloperski wie co robi, może z łatwością bronić się i udowodnić, że wykryte podatności w gruncie rzeczy nimi nie są. Tyle, że odpowiedzialność za takie rzeczy leży po stronie pentesterów, a nie deweloperów. W skrajnych przypadkach, w imię teoretycznych najlepszych praktyk (najlepszych w jakim kontekście?), pompowane raporty mogą prowadzić do poświęcania cennych zasobów i czasu na uszczelnianie czegoś, co w gruncie rzeczy nie wymaga uszczelniania.

„Rozdymanie raportów z testów penetracyjnych po to, by udowodnić, że swoją robotę wykonało się rzetelnie, to marnowanie czasu swojego i wszystkich uczestników projektu. Ponadto, w ten sposób można wprowadzić do projektu ryzyko dużo poważniejsze, niż brak flagi w pliku cookie”

Należy pamiętać, że oznaczanie teoretycznych wektorów ataku jako zagrożeń, choćby średniej klasy, wcale nie zwiększy czujności zespołu deweloperów, jak się wydaje niektórym pentesterom. Google, które było zasypywane informacjami o rzekomych i hipotetycznych podatnościach, właśnie z tych powodów opublikowało niedawno listę raportów o błędach, których nie honoruje w ramach bug-bounty.

Wzorcowy raport z pentestu

Przede wszystkim, z języka raportu należy wyplenić słowa i konstrukcje rozmiękczające, typu: „może stanowić ryzyko”, „może pozwalać na” lub „może potencjalnie umożliwiać”. Rolą pentestów jest ograniczanie niepewności, a nie jej zwiększanie poprzez spekulacje.

Należy też jednoznacznie rozróżniać podatności i brak zabezpieczeń. To nie to samo. Podatność to możliwość ominięcia zabezpieczeń lub logiki aplikacji, nadająca się do zademonstrowania lub możliwa do wykorzystania z dużym prawdopodobieństwem (nie mamy gotowego kodu exploita, ale zwracany jest błąd). Ostatecznym dowodem jest eksploit, ale poważne poszlaki też mają znaczenie. Brak zabezpieczeń oznacza, że należy je dodać, aby uchronić aplikację przed możliwymi atakami. Mają tu zastosowanie wszelkie sprawdzone techniki i dobre praktyki z dziedziny bezpieczeństwa. Raport powinien wprost powoływać się na nie.

„Jeśli [pentester] nie rozumie logiki aplikacji lub jej wewnętrznej architektury (co jest w pełni zrozumiałe, ponieważ z dużym prawdopodobieństwem styka się z nią po raz pierwszy), powinien po prostu umówić się na rozmowę z deweloperami”

Z drugiej strony, trzeba pamiętać, że każdą aplikację można poprawiać w nieskończoność, np. zamienić TLS na STS, dodać HPKP, później stapling, verifed stapling… końca nie widać. Kierownik projektu musi pogodzić mechanizmy zabezpieczeń z wymogami użytkowymi. Nic nie stoi na przeszkodzie, by zamiast informacji o „pomniejszych problemach” zawrzeć w raporcie „sugerowane udoskonalenia”. To pokaże, że testy zostały wykonane starannie, ale bez wprowadzania nerwowej atmosfery wynikającej z użycia słowa „problem”.

Ważne jest ponadto, by zawartość raportu z pentestów jednoznacznie odnosiła się do testowanej aplikacji. Zwykle istnieje możliwość analizy całego ruchu sieciowego, można więc łatwo ustalić, czy JavaScript na stronie może „legalnie” korzystać z ciasteczek, czy nie. Tworzenie raportu przez kopiuj/wklej bez uwzględnienia takich niuansów dowodzi jednego: że pentester nie ma pojęcia o tym, co robi. Jeśli nie rozumie logiki aplikacji lub jej wewnętrznej architektury (co jest w pełni zrozumiałe, ponieważ z dużym prawdopodobieństwem styka się z nią po raz pierwszy), powinien po prostu umówić się na rozmowę z deweloperami.

Autor jest menedżerem ds. bezpieczeństwa aplikacji w firmie Kainos w Wielkiej Brytanii. Artykuł jest tłumaczeniem tekstu, który po raz pierwszy ukazał się w j. angielskim na stronie ipsec.pl, po czym wywołał żywą dyskusję m.in. na Reddicie.