Pentest jest wart tyle, ile ludzie, którzy go zrobili

Co jest potwierdzone, a co tylko powiedziane

10 sierpnia MyDr ogłosiło, że bada poważny incydent bezpieczeństwa. Tego samego wieczoru Zaufana Trzecia Strona opisała kontakt z osobami podającymi się za sprawców, które twierdzą, że mają 18 814 422 unikatowe numery PESEL. 12 sierpnia wicepremier Krzysztof Gawkowski potwierdził wyciek i mówił o blisko 19 milionach osób oraz 12 tysiącach placówek medycznych. 13 sierpnia Prokuratura Okręgowa w Warszawie poinformowała, że nadzoruje dochodzenie prowadzone przez CBZC, a Prezes UODO zapowiedział kontrolę w spółce. 14 sierpnia Centrum e-Zdrowia zaczęło prewencyjnie wymieniać certyfikaty służące do komunikacji z systemem P1, zaznaczając przy tym, że nic nie wskazuje na ich przejęcie.

Sama firma przekazała, że dane objęte incydentem najprawdopodobniej mają charakter historyczny, z 2024 roku oraz lat wcześniejszych. Sprawcy mówią o 2,5 TB. Żadnej z tych liczb nikt z zewnątrz nie zweryfikował.

Czy MyDr zamawiało testy penetracyjne, nie wiem. Kto je prowadził i co obejmował zakres, też nie wiem, bo nikt tego publicznie nie podał. Każdy, kto dziś pisze, że firma widocznie odpuściła sobie bezpieczeństwo, zgaduje. Zwykle zgaduje z ulgą, że tym razem chodzi o kogoś innego. Dlatego resztę tego tekstu poświęcam pytaniu, które po takim tygodniu warto zadać u siebie.

Jedyny techniczny szczegół, jaki mamy, pochodzi od sprawców

Zaufanej Trzeciej Stronie opisali swoją ścieżkę wejścia: podatność typu XXE przy obsłudze certyfikatów PKCS#12, z niej zdalne wykonanie kodu, dalej klucz API do GitHuba, kod źródłowy serwisu, na końcu infrastruktura w AWS. Redakcja wprost pisze, że nie była w stanie tego zweryfikować, a firma tego scenariusza nie potwierdziła. Przy takich sprawach ostateczne ustalenia potrafią się różnić od pierwszej wersji, więc potraktuj to jako ćwiczenie, nie jako fakt.

Ćwiczenie jest pouczające niezależnie od tego, czy wydarzyło się akurat tam.

Skaner podatności widzi w takim miejscu funkcję przyjmującą plik z certyfikatem oraz odpowiedź 200. Człowiek pyta, co ten kontener rozbiera po drodze, czy w ścieżce siedzi parser XML i czy ktoś pamiętał o wyłączeniu encji zewnętrznych. Potem pyta, co ten proces trzyma w zmiennych środowiskowych. Potem sprawdza, czy znaleziony token faktycznie otwiera repozytorium, a jeśli otwiera, czy w historii commitów leżą kolejne sekrety. Żaden z tych kroków nie wynika z listy kontrolnej. Każdy jest czyjąś decyzją, podjętą w trzecim dniu testu, kiedy łatwe rzeczy są już sprawdzone.

Dlaczego „czy mieliśmy pentest” to złe pytanie

Test penetracyjny nie jest produktem z półki, kupujesz konkretne osoby na konkretną liczbę dni. Dwie oferty potrafią mieć ten sam tytuł, tę samą metodykę wpisaną w PDF i różnicę ceny rzędu połowy stawki, a pod spodem być zupełnie innym przedsięwzięciem. W jednej ktoś przez cztery dni grzebie w obsłudze plików i podpisu elektronicznego. W drugiej ktoś odpala skaner, przenosi wynik do szablonu i wysyła raport w piątek po południu.

Żaden test nie daje gwarancji. Sprawdza fragment środowiska w konkretnym tygodniu, a dwa tygodnie później wchodzi release, którego nikt jeszcze nie oglądał. O tym, gdzie ten test zajrzy, nie decyduje jednak przypadek. Decyduje, kto go prowadzi i ile ma na to dni. Jeden pentester skończy na formularzu logowania, bo tam kończy się jego rutyna. Drugi otworzy import certyfikatu i zacznie się zastanawiać, co ten plik rozbiera po drodze.

Sporą część projektów dostajemy na aplikacje i sieci, które ktoś już wcześniej testował. Regularnie wychodzą z nich rzeczy, których w poprzednim raporcie nie ma. Bywają to drobiazgi, bywają znaleziska, które lądują na pierwszej stronie podsumowania. Wolałbym napisać, że to wyjątek. Zamiast tego słyszę na spotkaniach zamykających jedno pytanie częściej niż jakiekolwiek inne: dlaczego tamci tego nie znaleźli?

Sześć pytań, zanim zamówisz kolejny test

• Kto imiennie wykona test i co ta osoba robiła przez ostatni rok. Jeśli w odpowiedzi pada „zespół doświadczonych ekspertów”, pytaj dalej, bo nazwiska zwykle pojawiają się dopiero za drugim podejściem.
• Ile mandays obejmuje oferta i jak dzielą się na rozpoznanie, pracę manualną oraz raport. Sama suma niczego nie mówi, bo w tych samych dziesięciu dniach mieści się solidny test albo tydzień pisania dokumentu.
• Co zostaje poza zakresem i czyja to była decyzja. Najczęściej wypadają obsługa plików, podpis elektroniczny, integracje z podmiotami trzecimi, repozytoria oraz CI/CD, zwykle bez jednego zdania wyjaśnienia w ofercie.
• Ile znalezisk w przykładowym raporcie pochodzi ze skanera, a ile z pracy ręcznej. Poproś o taki raport przed podpisaniem umowy, bo później nie masz już czym negocjować.
• Czy retest po poprawkach jest w cenie i do kiedy można go wykorzystać.
• Kto czyta raport przed tobą. Drugi pentester wyłapuje błędy techniczne, ale też znaleziska opisane tak, że nikt ich potem nie naprawi.

Zarząd ma w tym miejscu prostą arytmetykę. Administratorem dokumentacji medycznej pacjenta pozostaje przychodnia, więc to ona odpowiada przed UODO i to do niej trafią roszczenia z art. 82 RODO, choć systemu nie pisała ani nie utrzymywała. W tej sprawie takich placówek jest kilkanaście tysięcy i wszystkie czekają dziś, aż dostawca ustali, czyje dane wyciekły. Różnica między dwiema ofertami pentestowymi to zwykle kilkadziesiąt tysięcy złotych. Postępowanie po wycieku liczy się w innej skali i ciągnie latami.

Żadne z tych sześciu pytań nie wymaga budżetu ani zgody zarządu. Wystarczy jeden mail do dostawcy oraz kwadrans na przeczytanie odpowiedzi. Wyślij go do firmy, która testuje cię dzisiaj, potem policz, ile czasu zajęła jej odpowiedź na pierwsze pytanie z listy. Test jest wart tyle, ile ludzie, którzy go zrobili, więc jedno pytanie zostaje na koniec: czy potrafisz dziś podać imię i nazwisko osoby, która sprawdzała twoją najważniejszą aplikację?