Trochę statystyk z pracy pentestera 2018-2020

Od kilku ostatnich lat zbieram dane statystyczne z wyników swoich badań nad bezpieczeństwem komputerowym. Postanowiłem się nimi nieco podzielić. Tutaj możesz znaleźć przykładowy raport z testu penetracyjnego – raport. W dużej liczbie wywiadów z testerami penetracyjnymi słyszę pytanie – „Czy bezpieczeństwo aplikacji internetowych poprawiło się na przestrzeni lat?”. Moim zdaniem – tak, ale tylko tam, gdzie jest to niejako wymuszone przez oddolne regulacje. Czy testy penetracyjne pomagają poprawić bezpieczeństwo? – zdecydowanie tak!

O jakich danych mowa

W ciągu ostatnich 2 lat udało mi się zrealizować ponad 100 testów penetracyjnych, audytów bezpieczeństwa, analiz i retestów. Były to różne aplikacje dla różnych klientów. Zdecydowaną większość stanowiły aplikacje webowe. Gdy dana aplikacja była testowana po raz pierwszy, niemal zawsze znajdowany był w niej błąd z klasyfikacją zagrożenia jako krytyczne lub wysokie. Dla niewtajemniczonych wykorzystanie tego typu podatności prowadzi do przejęcia pełnej kontroli nad aplikacją (często też serwerem) albo umożliwia dostęp do wrażliwych danych.

Statystki według klasyfikacji podatności wyglądają następująco:

Postępujące od lat, wykrywanie tak dużej liczby błędów bezpieczeństwa w aplikacjach, moim zdaniem wskazuje na poświęcenie zbyt małej ilości czasu bezpieczeństwu na wczesnym etapie tworzenia oprogramowania. Mam tutaj na myśli edukację programistów, pochylenie się nad bezpieczeństwem przy samym już konstruowaniu architektury oprogramowania i modelowanie zagrożeń. Bez tego nadal podatności będą wyłapywane na końcowym etapie tworzenia oprogramowania (tym samym koszt naprawy jest duży) lub co gorsza, dopiero na środowiskach produkcyjnych przez tych mniej etycznych hackerów ;).

Najczęściej znajdowane podatności ze względu na typ

Pochylmy się nad kolejnymi statystykami. Tym razem najczęściej znajdowanych typów podatności.

Różnymi kolorami starałem się zaznaczyć typową klasyfikację ryzyka danej podatności (oczywiście upraszczając, w praktyce zależy ona od wielu czynników). Kolejno wygląda to następująco: bordowy – krytyczne, czerwony – wysokie, pomarańczowy – średnie, zielony- niskie.

Przede wszystkim można tutaj zauważyć, że XSSy są najczęściej znajdowanym typem podatności z tych najkrytyczniejszych. Zaskakujące jest to o tyle dla mnie, że jest ona znana już od około 30 lat. Dodatkowo jest to chyba najbardziej rozpoznawalna klasa błędów bezpieczeństwa. Tym samym jej występowanie powinno być już rzadkością.

Kolejno plasują się podatności związane z autoryzacją, czyli prawidłowym procesem sprawdzającym, czy użytkownik ma prawo do wykonania konkretnej operacji. Problem widoczny jest szczególnie w aplikacjach z rozbudowanymi interfejsami API.

Jeżeli popatrzeć na statystyki pod kątem najczęściej występujących błędów – na pierwszym miejscu jest ujawnianie informacji, które nie powinny być ogólnodostępne. Należy pamiętać, że pierwszą z faz hackowania aplikacji jest rekonesans. Każda nadmiarowa informacja, która z pozoru może wydawać się błaha, w ostatecznym rozrachunku może okazać się kluczowa do przeprowadzenia skutecznego ataku.

Następnie na liście znajdują się, niegeneryczne komunikaty błędów. Podobnie jak poprzednio ujawniają one często zbyt dużo danych wrażliwych np. na temat używanych technologi.

Na trzecim miejscu plasuje się problem, który moim zdaniem awansuje w najbliższych latach w statystykach na pierwszą pozycję. Jest to dług technologiczny i związane z tym używanie komponentów ze znanymi podatnościami. Z mojego punktu widzenia, dzisiejsze aplikacje są niejako składane z wielu małych klocków i łańcuchów zależności. Powoduje to, że niemal codziennie okazuje się, że jakiś mały komponent jest już nieaktualny. Podbicie jego wersji wiąże się często z przebudową części aplikacji (przynajmniej takie informacje dostaję od programistów 😉 ), a ten proces niestety konsumuje sporo zasobów.

OWASP Top 10 vs TOP 12 Pentestera

Zestawienie najczęściej wykrywanych przeze mnie podatności z listą OWASP Top 10 wygląda następująco:

Ciężko zmapować moje „znaleziska” 1 do 1 na listę OWASPa. Nie odnajdziemy tutaj odzwierciedlenia dla „Broken Authentication”. Spowodowane jest to po prostu tym, że brutforsowanie kont znajduje się najczęściej poza zakresem moich testów (a inne błędy wchodzące w zakres tego punktu nie znajdują się na mojej liście top). Na próżno też szukać odnośnika do XXE. Z moich obserwacji błędy tej klasy zdarzają się coraz rzadziej. Myślę, że związane jest to, z tym że frameworki odpowiedzialne za przetwarzanie XMLy domyślnie nie pozwalają już na korzystanie z zewnętrznych encji. Niemniej powyższe zestawienie pokazuje, że jak najbardziej lista OWASP TOP 10 nie jest tylko suchą teorią i ma odzwierciedlenie w praktyce. Tym samym warto z niej korzystać, jak i całej wiedzy przekazywanej przez Open Web Application Security Project.