Pięć podatności High, zero drogi do środka

Kontekst

Klient dał nam wąski, precyzyjny zakres: kilkanaście publicznych adresów wystawionych do internetu, klasyczny perymetr. Pytanie było równie proste. Czy ktoś z zewnątrz może się tędy dostać do środka.

Środowisko rosło latami i było to widać. Kilka serwerów Linux z usługami webowymi i SSH, garść przełączników sieciowych, serwer czasu, DNS, SNMP, panele administracyjne wystawione na świat. Część hostów wyglądała na świeżo utrzymywaną, część pamiętała czasy, o których wolelibyśmy nie pisać w teraźniejszości.

Wyzwanie

Na pierwszy rzut oka było źle. Automatyczny skan naliczył pięć podatności o wadze High i dziewiętnaście Medium, głównie na przestarzałych wersjach OpenSSH i nginx. Jeden z serwerów przedstawiał się banerem SSH sprzed dekady:

$ nc klient.example 22
SSH-2.0-OpenSSH_6.0p1 ...

Dla skanera taki baner to gotowa lista CVE. Dopisuje je z automatu, bo widzi numer wersji, a nie sprawdza, czy dziurę faktycznie da się wykorzystać. I tu zaczyna się cała robota.

Bo druga strona wyglądała inaczej, niż sugerowała lista. Perymetr nie był bezmyślny. Poczta chowała się za zewnętrzną bramą bezpieczeństwa, ruch webowy za usługą anty-DDoS, rekord SPF był poprawny, domyślnych haseł od producenta nigdzie nie było. Ktoś tu myślał o bezpieczeństwie, tylko nierówno. Wiarygodny raport musi to przyznać, zanim postawi tezę.

Co zrobiliśmy

Zaczęliśmy od pełnego rozpoznania: skan wszystkich portów TCP i tysiąca najpopularniejszych UDP, bez pingów, żeby wyłapać hosty, które nie odpowiadają na echo, ale nadal słuchają. Potem fingerprinting każdej usługi, żeby wiedzieć, z czym mamy do czynienia, a nie tylko jaki numer wersji się przedstawia.

Równolegle poszliśmy w biały wywiad. Podejście Grey Box, minimum interakcji z systemem, maksimum tego, co świat i tak o kliencie wie: subdomeny, konfiguracja DNS, publiczne wycieki danych.

Dostęp początkowy testowaliśmy dwutorowo. Brute force na usługi z logowaniem, w tym panele administracyjne i VPN. Oraz próba użycia tego, co znaleźliśmy w wyciekach, jako prawdziwych danych do logowania.

Całość mapuje się na MITRE ATT&CK tak:

Najważniejsza część tego testu to nie tabela CVE. To manualna weryfikacja każdej pozycji z tej tabeli. Sprawdziliśmy warunki wykorzystania po kolei: czy potrzebny moduł jest w ogóle włączony, czy atak działa wyłącznie na połączeniu zwrotnym, czy da się to spiąć z czymkolwiek innym w sensowny wektor. Odpowiedź za każdym razem brzmiała podobnie. Nie z tego miejsca.

Rezultat

Z żadnej z podatności wykrytych na perymetrze nie dało się wejść do sieci z zewnątrz. Zero CRITICAL. Te pięć High i dziewiętnaście Medium to były realne przestarzałe wersje, ale bez spełnionych warunków wykorzystania: brakowało włączonych modułów, część ataków działała tylko na połączeniach zwrotnych, żadna nie łączyła się w łańcuch. Domyślnych danych producenta też nie było. Próby brute force nie powiodły się.

Gdyby raport kończył się w tym miejscu, byłby przyjemny i bezużyteczny. Bo realne ryzyko leżało poza kolumną „severity”.

Po pierwsze, w publicznych wyciekach znaleźliśmy działające pary: adres e-mail pracownika i hasło dla kont z domeny klienta. Nie z jego sieci, tylko z cudzych baz, które wyciekły lata temu. Perymetr był szczelny, a zapasowe klucze leżały u sąsiada.

Po drugie, sam wiek tego oprogramowania coś mówił. Serwer z SSH sprzed dekady nie jest groźny dzisiaj, ale jest dowodem, że nie ma procesu automatycznego wdrażania poprawek. To, co dziś nieszkodliwe, jutro dostaje publiczny exploit i nikt tego nie zauważy, bo nikt nie patrzy.

Rekomendacje ustawiliśmy priorytetami:

• Wdrożyć proces automatycznego łatania i podnieść przestarzałe usługi do wersji wspieranych, zaczynając od hostów wystawionych do internetu.
• Wymusić reset haseł dla kont, które pojawiły się w wyciekach, i włączyć uwierzytelnianie wieloskładnikowe tam, gdzie go jeszcze nie ma.
• Wpiąć monitoring wycieków danych na stałe, żeby następne skojarzenie login plus hasło wyłapać, zanim wyłapie je ktoś inny.
• Uporządkować konfigurację certyfikatów i łańcuch zaufania na usługach wystawionych do internetu oraz ograniczyć nadmiarowe ujawnianie wersji w nagłówkach i stronach błędu.
• Wyłączyć słabe algorytmy MAC i szyfry CBC na SSH oraz domknąć podatność Terrapin przez rygorystyczną wymianę kluczy.

Test sieci zewnętrznej, który kończy się samą listą CVE, odpowiada na złe pytanie. „Jakie masz stare wersje” to nie to samo co „czy da się przez nie wejść”, a te dwa zdania prowadzą do zupełnie innych decyzji budżetowych.

Jeśli Twój ostatni test był listą podatności bez ani jednego zdania o tym, czy któraś jest realnie do wykorzystania, dostałeś skan, nie test. Kiedy ostatnio ktoś sprawdził, czy Twoje konta nie leżą już w cudzym wycieku?