W ramach profesjonalnej działalności programiści, pentesterzy i specjaliści ds. bezpieczeństwa muszą zmagać się z takimi procesami jak zarządzanie lukami w zabezpieczeniach (Vulnerability Management, VM) oraz (bezpieczny) cykl życia oprogramowania (Secure SDLC).
Pod tymi terminami kryją się różne zestawy praktyk i narzędzi, które są ze sobą powiązane, chociaż ich odbiorcy różnią się.
Postęp technologiczny jeszcze nie doszedł do tego etapu, aby jeden instrument mógł zastąpić człowieka w przeprowadzaniu analizy zabezpieczeń infrastruktury i oprogramowania.
Interesujące jest zrozumienie, dlaczego tak jest i z jakimi problemami trzeba się zmagać.
Procesy
Proces zarządzania lukami w zabezpieczeniach („Vulnerability Management”) ma na celu ciągłe monitorowanie bezpieczeństwa infrastruktury i zarządzanie poprawkami.
Proces bezpiecznego cyklu życia oprogramowania („Secure SDLC”) ma na celu wsparcie bezpieczeństwa aplikacji w trakcie jej rozwoju i eksploatacji.
Pokrewnym procesem jest ocenianie luk w zabezpieczeniach — Vulnerability Assessment, skanowanie w poszukiwaniu luk.
Główna różnica w skanowaniu w ramach VM i SDLC polega na tym, że w pierwszym przypadku celem jest wykrycie znanych luk w zewnętrznym oprogramowaniu lub konfiguracji. Na przykład, przestarzała wersja systemu Windows lub domyślna społecznościowa strona dla SNMP.
W drugim przypadku celem jest wykrycie luk nie tylko w komponentach zewnętrznych (zależnościach), ale przede wszystkim w kodzie nowego produktu.
To rodzi różnice w narzędziach i podejściu. Moim zdaniem, zadanie wyszukiwania nowych luk w aplikacji jest znacznie ciekawsze, ponieważ nie ogranicza się tylko do identyfikacji wersji, zbierania banerów, łamania haseł itd.
Aby przeprowadzić jakościowe automatyczne skanowanie luk w aplikacjach, niezbędne są algorytmy uwzględniające semantykę aplikacji, jej przeznaczenie oraz specyficzne zagrożenia.
Natomiast skaner infrastrukturalny często można zastąpić timerem, jak to ujął Sens jest taki, że czysto statystycznie można uznać swoją infrastrukturę za podatną, jeśli nie była aktualizowana, powiedzmy, od miesiąca.
Narzędzia
Skanowanie, podobnie jak analiza zabezpieczeń, można przeprowadzać zarówno w trybie black box, jak i white box.
Black Box
Przy skanowaniu w trybie black box narzędzie musi potrafić współdziałać z usługą przez te same interfejsy, przez które korzystają z niej użytkownicy.
Skanery infrastruktury (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose itd.) wyszukują otwarte porty sieciowe, zbierają "banery", określają wersje zainstalowanego oprogramowania i sprawdzają w swojej bazie wiedzy informacje o lukach w tych wersjach. Starają się również wykryć błędy konfiguracyjne, takie jak domyślne hasła czy otwarty dostęp do danych, słabe szyfry SSL itd.
Skanery aplikacji internetowych (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP itd.) również potrafią identyfikować znane komponenty oraz ich wersje (np. CMS, frameworki, biblioteki JS). Podstawowe kroki skanera to crawling i fuzzing.
Podczas crawlowania skaner zbiera informacje o istniejących interfejsach aplikacji, parametrach HTTP. W trakcie fuzzingu do wszystkich wykrytych parametrów wprowadzane są zmodyfikowane lub wygenerowane dane w celu wywołania błędu i odkrycia luki.
Takie skanery aplikacji zaliczają się do klas DAST i IAST — odpowiednio Dynamic i Interactive Application Security Testing.
White Box
W przypadku skanowania whitebox różnic jest więcej.
W ramach procesu VM skanery (Vulners, Incsecurity Couch, Vuls, Tenable Nessus itd.) często mają dostęp do systemów, przeprowadzając skanowanie z uwierzytelnieniem. Dzięki temu skaner może załadować zainstalowane wersje pakietów i parametry konfiguracyjne bez zgadywania ich przez banery usług sieciowych.
Skan staje się dokładniejszy i pełniejszy.
Jeśli jednak chodzi o skanowanie whitebox (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs itd.) aplikacji, to zazwyczaj ma to związek z analizą statyczną kodu i używaniem odpowiednich narzędzi klasy SAST — Static Application Security Testing.
Problemy
W trakcie skanowania pojawia się wiele problemów! Większość z nich napotykam osobiście podczas świadczenia usług związanych z budowaniem procesów skanowania oraz bezpiecznego rozwoju, a także przy przeprowadzaniu analiz bezpieczeństwa.
Wyróżnię 3 główne grupy problemów, które potwierdzają także rozmowy z inżynierami i kierownikami służb zapewnienia bezpieczeństwa w różnych firmach.
Problemy ze skanowaniem aplikacji internetowych
- Trudność we wdrożeniu. Skannery muszą być dostosowywane, konfigurowane i personalizowane pod każde zastosowanie, tworzyć środowisko testowe dla skanów oraz integrować się w procesie CI/CD, aby działały efektywnie. W przeciwnym razie staną się bezużyteczną formalnością, generującą jedynie fałszywe alarmy.
- Czas skanowania. Skannery w 2019 roku wciąż kiepsko radzą sobie z deduplikacją interfejsów i mogą skanować przez długie godziny tysiące stron z 10 parametrami na każdej, traktując je jako różne, chociaż za te same odpowiada ten sam kod. Decyzję o wdrożeniu w ramach cyklu rozwoju należy podejmować szybko.
- Ubogie rekomendacje. Skannery dają dość ogólne rekomendacje, przez co nie zawsze deweloper może szybko zrozumieć, jak obniżyć poziom ryzyka, a przede wszystkim, czy należy to zrobić natychmiast, czy można poczekać.
- Destrukcyjne oddziaływanie na aplikację. Skannery mogą przeprowadzić atak DoS na aplikację, a także stworzyć dużą liczbę obiektów lub zmienić istniejące (np. tworząc dziesiątki tysięcy komentarzy w blogu), dlatego nie warto bezmyślnie uruchamiać skanu w środowisku produkcyjnym.
- Niska jakość wykrywania luk. Skannery zazwyczaj korzystają z ustalonego zbioru ładunków ('payloads') i mogą łatwo pominąć lukę, która nie pasuje do znanego im schematu zachowania aplikacji.
- Niezrozumienie funkcji aplikacji przez skanery. Skannery same w sobie nie wiedzą, czym jest 'bank internetowy', 'płatność', 'komentarz'. Dla nich istnieją jedynie linki i parametry, co sprawia, że wiele potencjalnych luk w logice biznesowej pozostaje całkowicie nieodkrytych – nie zrozumieją, jak dokonać podwójnego obciążenia, zajrzeć do cudzych danych po ID czy zmanipulować saldo przez zaokrąglenie.
- Niezrozumienie semantyki stron przez skanery. Skannery nie potrafią czytać FAQ, nie rozpoznają captcha, same w sobie nie wiedzą, jak należy się zarejestrować, i że następnie należy się przelogować, że nie można naciskać 'logout' oraz jak podpisywać zapytania przy zmianie wartości parametrów. W rezultacie znaczna część aplikacji może pozostać całkowicie nieprzeskanowana.
Problemy ze skanowaniem kodu źródłowego.
- Fałszywe alarmy. Analiza statyczna to złożone zadanie, które wymaga wielu kompromisów. Często trzeba poświęcać dokładność, a nawet drogie skanery enterprise generują ogromną liczbę fałszywych alarmów.
- Trudność we wdrożeniu. Aby zwiększyć dokładność i kompletność analizy statycznej, konieczne jest ulepszanie reguł skanowania, a ich napisanie może być zbyt czasochłonne. Czasami łatwiej jest znaleźć wszystkie miejsca w kodzie z jakimś błędem i je naprawić niż stworzyć regułę do wykrywania takich przypadków.
- Brak wsparcia dla zależności. Duże projekty polegają na wielu bibliotekach i frameworkach, które rozszerzają możliwości języka programowania. Jeśli w bazie wiedzy skanera brakuje informacji o niebezpiecznych miejscach ("sinks") w tych frameworkach, stanie się to pustym miejscem, a skaner po prostu nie zrozumie kodu.
- Czas skanowania. Znajdowanie luk w kodzie to złożone zadanie, nawet w terminach algorytmicznych. Dlatego proces ten może się znacznie wydłużyć i wymagać znacznych zasobów obliczeniowych.
- Niskie pokrycie. Pomimo zużycia zasobów i długości skanowania, programy SAST wciąż muszą uciekać się do kompromisów i analizować nie wszystkie stany, w których program może się znajdować.
- Reprodukowalność odkryć. Wskazanie konkretnej linii i stosu wywołań, które prowadzą do luki, jest wspaniałe, ale w rzeczywistości często skaner nie dostarcza wystarczających informacji, aby zweryfikować istnienie luki z zewnątrz. Niedobór może znajdować się także w martwym kodzie, który jest niedostępny dla atakującego.
Problemy z skanowaniem infrastruktury.
- Niewystarczająca inwentaryzacja. W dużych infrastrukturach, szczególnie podzielonych geograficznie, często najtrudniej jest zrozumieć, które hosty należy skanować. Innymi słowy, zadanie skanowania jest ściśle powiązane z zarządzaniem zasobami.
- Zła priorytetyzacja. Skanery sieciowe często generują wiele wyników z niedociągnięciami, które w praktyce nie są wykorzystywane, ale formalnie ich poziom ryzyka jest wysoki. Konsument otrzymuje raport, który trudno zinterpretować i nie wiadomo, co należy naprawić w pierwszej kolejności.
- Ubogie rekomendacje. W bazie wiedzy skanera często znajduje się tylko bardzo ogólne informacje na temat podatności i sposobów ich naprawy, więc administratorzy będą musieli skorzystać z Google'a. Sytuacja jest nieco lepsza w przypadku skanerów whitebox, które mogą dostarczać konkretną komendę do naprawy.
- Praca ręczna. W infrastrukturach może być wiele węzłów, co oznacza potencjalnie wiele niedoskonałości, których raporty należy analizować ręcznie przy każdej iteracji.
- Słabe pokrycie. Jakość skanowania infrastruktury bezpośrednio zależy od rozmiaru bazy wiedzy o podatnościach i wersjach oprogramowania. Przy tym, , nawet liderzy rynku nie mają wyczerpującej bazy wiedzy, a w bazach bezpłatnych rozwiązań znajduje się wiele informacji, których brakuje liderom.
- Problemy z łatkami. Najczęściej łatki dotyczą aktualizacji pakietu lub zmiany pliku konfiguracyjnego. Dużym problemem jest to, że system, szczególnie starszy, może nieprzewidywalnie się zachować w wyniku aktualizacji. W zasadzie będzie trzeba przeprowadzić testy integracyjne na rzeczywistej infrastrukturze w produkcji.
Podejścia
Co robić?
Szczegóły dotyczące przykładów i tego, jak radzić sobie z wieloma z wymienionych problemów, omówię w następnych częściach, a na razie wskażę główne obszary, w których można pracować:
- Agregacja różnych narzędzi skanowania. Przy odpowiednim użyciu kilku skanerów można znacznie zwiększyć bazę wiedzy i jakość wykrywania. Można znaleźć nawet więcej podatności, niż suma wszystkich skanerów uruchomionych osobno, jednocześnie można dokładniej ocenić poziom ryzyka i udzielić więcej rekomendacji.
- Integracja SAST i DAST. Można zwiększyć pokrycie DAST i dokładność SAST dzięki wymianie informacji między nimi. Z kodu źródłowego można uzyskać informacje o istniejących trasach, a za pomocą DAST można sprawdzić, czy podatność jest widoczna z zewnątrz.
- Machine Learning™. W 2015 roku ja (i ) mówiłem o zastosowaniu statystyki, aby dać skanerom intuicję hakera i przyspieszyć je. To zdecydowanie jest pokarmem do rozwoju automatycznej analizy zabezpieczeń w przyszłości.
- Integracja IAST z testami automatycznymi i OpenAPI. W ramach pipeline'u CI/CD możliwe jest stworzenie procesu skanowania na podstawie narzędzi działających jako serwer proxy HTTP oraz testów funkcjonalnych opartych na HTTP. Testy i kontrakty OpenAPI/Swagger dostarczą skanerowi brakujące informacje o przepływach danych, umożliwiając skanowanie aplikacji w różnych stanach.
- Prawidłowa konfiguracja. Dla każdej aplikacji i infrastruktury należy stworzyć odpowiedni profil skanowania, uwzględniający liczbę i charakter interfejsów oraz używane technologie.
- Dostosowywanie skanerów. Często aplikację nie da się zeskanować bez modyfikacji skanera. Przykład — bramka płatnicza, w której każdy request musi być podpisany. Bez napisania konektora do protokołu bramy skanery będą pupować requestami z nieprawidłowym podpisem. Należy również pisać specjalistyczne skanery pod konkretne rodzaje podatności, takie jak
- Zarządzanie ryzykiem. Zastosowanie różnych skanerów oraz integracja z zewnętrznymi systemami, takimi jak zarządzanie zasobami i zarządzanie zagrożeniami, pozwoli na wykorzystanie wielu parametrów do oceny poziomu ryzyka, co umożliwi kierownictwu uzyskanie adekwatnego obrazu aktualnego stanu bezpieczeństwa rozwoju lub infrastruktury.
Pozostań na bieżąco i zakłóćmy proces skanowania podatności!
Źródło: habr.com
