„90% of Java services have critical or severe security vulnerabilities”… czyli o tym, jak trudno mówi się o bezpieczeństwie – JVM Weekly vol. 172

Tym razem będzie nieco filozoficznie. Jak pewnie domyślacie się, wybierając tematy do każdej kolejnej edycji przebijam się przez masę nagłówków i tematów, aby wybrać realnie to co z mojej perspektywy najciekawsze. Dlatego też kiedy zobaczyłem, że w raporcie The State of DevSecOps DataDoga (którego osobiście wyjątkowo szanuje) sporo miejsca poświęcono Javie, stwierdziłem że muszę się z tym wpisem lepiej zapoznać – bezpieczeństwo ważna rzecz, w związku z tym zobaczmy, co oni tam ciekawego wygrzebali. I co mnie przywitało?

I w tym momencie stwierdziłem, że ja już świata nie rozumiem. Albo mamy totalną apokalipsę jeśli chodzi o software i software supply chain, albo z tymi liczbami jest coś nie tak. Ponieważ wiecie – skoro 90% serwisów Javowych posiada POWAŻNE luki security, to biorąc pod uwagę, że w dzisiejszych czasach byle dzieciak z ChatGPT podobno może zostać hakerem, to w tej większości biznesów to już powinno nie być, prawda? Dlatego też stwierdziłem, że wykorzystam tą sytuację aby trochę wyjaśnić sytuację, bo świetnie wpisuje w szerszą dyskusję na temat raportowania zagrożeń.

No dobra, ale co tak naprawdę mówi nam The State of DevSecOps? Raport, oparty o dane telemetryczne zbierane masowo przez DataDog, podsumowuje (między innymi) ilość aplikacji posiadających groźne podatności, w oparciu Katalogu Znanych Wykorzystywanych Podatności (KEV) prowadzonym przez Amerykańską Agencję Cyberbezpieczeństwa i Bezpieczeństwa Infrastruktury (CISA). Katalog ten, będący aktualizowanym na bieżąco zbiorem, zawiera informacje o podatnościach aktywnie wykorzystywanych przez cyberprzestępców do kompromitowania systemów. Analiza danych z tego katalogu pokazuje, że usługi Java są nadreprezentowane w stosunku do innych języków programowania, z 55% usług Java dotkniętych problemem (szczerze to nie wiem skąd wzięła się liczba 90% na wykresie – wgryzając się w metodologie, to pewnie wyniki ze wspomnianego w metodologi Software Composition Analysis, funkcjonalności Datadog Application Security Management), w porównaniu do tylko 7% usług zbudowanych przy użyciu innych technologii.

The State of DevSecOps pochyla się też nad przyczyną, podatnościami w javowych często wynika z tzw. pośrednich zależności, czyli bibliotek third-party, dystrybuowanymi z używanymi przez nas zależnościami, choć nie są bezpośrednio dodawane przez programistów – jest to tak zwany Software Supply Chain, o którym się tyle mówi ostatnimi laty. Te pośrednie zależności stanowią większość podatności zależności third-party, co znacząco utrudnia identyfikację i zarządzanie potencjalnymi ryzykami bezpieczeństwa. Java pod tym kątem prezentuje się gorzej od w zasadzie każdego innego porównywanego ekosystemu. Chociaż jak się wczytać w metodologie raportu, to jest w tym mały kruczek…

Artykuł podkreśla też konieczność analizy pełnego drzewa zależności (dobra rada, warto wiedzieć co ma się w bebechach), zarówno bezpośrednich, jak i pośrednich, podczas skanowania aplikacji pod kątem podatności. Prezentuje też narzędzia takie jak Scorecard od OpenSSF, oceniające stan zdrowia bibliotek open source. Mamy więc całkiem pokaźny zbiór informacji.

I to są wszystko dobre rady, ale…

Wspomniany KEV opiera się o CVSS jest standardem branżowym, który dostarcza otwartą i ujednoliconą metodę oceny ciężaru podatności bezpieczeństwa IT. System punktacji CVSS przypisuje liczbową wartość ciężaru podatności (od 0 do 10), bazując na różnych metrykach, takich jak złożoność wykorzystania, wpływ na poufność, integralność i dostępność systemu oraz inne czynniki.

Całość skupia się więc na ocenie tzw. „worst case risk” – ryzyka w najgorszym możliwym scenariuszu. Oznacza to, że priorytetyzacja podatności w KEV opiera się na przypuszczeniu, że jeśli podatność może być wykorzystana do poważnych ataków, takich jak zdalne wykonanie kodu lub pełne przejęcie kontroli nad systemem, jest ona traktowana z najwyższym priorytetem. Priorytetyzacja bierze więc pod uwagę potencjalny maksymalny wpływ, jaki dana podatność może wywołać, niezależnie od obecnych okoliczności lub specyfiki środowiska, które mogłoby zmniejszyć to ryzyko w konkretnym przypadku.

Ten konserwatywny podejście do oceny ryzyka ma kluczowe znaczenie dla skutecznej obrony przed najbardziej destrukcyjnymi atakami, ponieważ pozwala organizacjom przygotować się na najgorsze, nawet jeśli rzeczywiste warunki eksploatacji mogą być mniej krytyczne. KEV, koncentrując się na najgorszym scenariuszu, pomaga w identyfikacji i priorytetyzacji podatności, które mają największe potencjalne skutki dla bezpieczeństwa ogólnego.

No i tu jest pies (DataDog) pogrzebany i temat, który od dłuższego czasu mnie nurtował. Pamiętacie Grudzień 2021, kiedy cały świat IT łatał podatność Log4Shell, która miała zagrozić całej światowej infrastrukturze? Już wtedy badacze podawali, że 93% rozwiązań cloudowych może być podatnych, a ostatnio Biały Dom wspominał go w swoim raporcie, przytaczając przykład groźnej podatności z ostatnich lat. I choć rzeczywiście uniknęliśmy wtedy groźnej sytuacji dzięki kolektywnemu działaniu, to kilka spektakularnych incydentów się po drodze wydarzyło. Ostatnio też zupełnie przypadkiem uniknęliśmy podobnie groźnej sytuacji z biblioteką xz – iście fascynująca historia.

Jednak nie wiem jak wy, ale kiedy słyszę, że 90% aplikacji posiada poważny wektor ataku (choć jak pisałem, gdy lepiej się przyjrzeć to bardziej mowa tu o 55%, co i tak jest jakąś kosmiczną liczbą), to czyta się to wręcz nierealnie. I pewnie dlatego coraz częściej w społeczności security (a jako, że nie jestem Security Engineerem w temacie nie jestem, to celeowo odbiłem sobie te przemyślenia od specjalistów z prośbą o proof reading) mówi się o problemach z CVSS, wymyślając alternatywne metryki jak VISS (Vulnerability Impact Scoring System) od Zooma czy EPSS (Exploit Prediction Scoring System). I akurat wymienione javowe podatności rzeczywiście należą do groźnych choćby według wspomnianego EPSS, a i sam DataDog ostrzega przed zwodniczością “krytyczności” poszczególnych zagrożeń, to robi to robi to dopiero, gdy już najpierw wszystkich postraszy wykręconymi liczbami. Do tego podatności w samych językach i bibliotekach mają inna specyfikę od podatności np. w urządzeniu sieciowym gdyż dużo ciężej dostać się do nich, bo mało który interfejs jest wystawiany bezpośrednio na Internet. No i pytanie, czy nie warto wyraźniej podkreślić to, że podatność w komponencie nie oznacza podatności w aplikacji – bo może nie być dana funkcja wykorzystywana/lub nie istnieć łatwa ścieżka exploitacji.

I żeby była jasność, ja nie mówię, żeby bagatelizować (i tak szeroko rozumiany biznes to będzie właśnie robił, nawet bez mojego dokładania kamyczków do ogródka). To nad czym się zastanawiam, to czy takimi krzykliwymi nagłówkami nie robimy sobie po prostu krzywdy i one po prostu bardziej usypiają czujność niż realnie mają przełożenie na zwiększanie świadomości organizacji. Fakt jest taki, że większość osób do których może trafić artykuł nie wie, jak należy rozumieć używane w nim terminy, dzięki temu łatwo wybierać sobie złe cele – jak na przykład eliminowanie Javy (no bo niebezpieczna) lub inwestycja w jeszcze lepsze skanery podatności (co by wykrywać jeszcze większe ilości podatności, w dużych enterprisach potrafiących iść w tysiące).

Dzięki córce na nowo odkrywam, mądrość zawartą w starych bajkach, i to takich naprawdę starych, bo mowa tutaj o Ezopie, szczególnie w jego Chłopiec, który wołał o pomoc, gdzie tytułowy Chłopiec wielokrotnie fałszywie alarmował o ataku wilka, a gdy naprawdę się pojawił, nikt mu nie uwierzył i nie przyszedł z pomocą. Myślę, że analogia jest tutaj czytelna.