TABLE OF CONTENTS:
Inwestujemy w kompetencje w zakresie cyberbezpieczeństwa, aby tworzone przez nas oprogramowanie (zwłaszcza jeśli chodzi o rozwiązania IoT, systemy krytyczne i oprogramowanie wbudowane) było jak najbardziej odporne na ataki hakerów.
Krzysztof Labuda, inżynier bezpieczeństwa opowie Wam więcej na temat modeli do projektowania zagrożeń: STRIDE oraz OWASP TOP 10 jako źródeł metodyk, które ułatwiają sprawne przeprowadzenie testów penetracyjnych.
W ramach tego artykułu chciałbym przybliżyć temat modelu zagrożeń (jednego z prawdziwego ich mrowia), którego można z powodzeniem użyć do opracowania strategii przeprowadzenia testów bezpieczeństwa oprogramowania. Wybrałem dwa modele: STRIDE oraz OWASP TOP 10 (choć ten drugi, może nie jest modelem zagrożeń, ale w środowisku osób zajmujących się bezpieczeństwem aplikacji webowych jest to źródło mające wymiar niepisanego standardu).
Testy bezpieczeństwa oprogramowania to wbrew pozorom ciężki kawałek chleba. Nie polegają one, jak mogłoby się wydawać, na przykład na bezrefleksyjnym atakowaniu danego systemu eksploitami oferowanymi przez choćby Metasploit Framework przy użyciu domyślnych ustawień. Za każdym dobrze przeprowadzonym testem (w tym także penetracyjnym) kryje się plan – jako gwarancja przewidywalności i porządku.
W harmonogramie działań dobrze jest ująć ramy czasowe na podejście eksploracyjne (zwłaszcza, gdy mamy do czynienia z jakimś prototypem urządzenia, czy zupełnie nowo powstałą aplikacją webową). Niemniej – dobrą i pożądaną praktyką jest, żeby te wszystkie działania były przeprowadzone niezależnie od siebie.
Przy opracowywaniu planu testów wielu inspiracji do testów aplikacji webowych dostarcza OWASP, a dokładniej lista opracowana przez tę fundację – OWASP TOP 10.
Organizacja OWASP to fundacja, która pro publico bono opracowuje i gromadzi narzędzia, artykuły, poradniki, dostępne reguły do WAF (Web Application Firewall) czyli dostęp do bazy wiedzy, stawiając sobie za cel zwiększanie bezpieczeństwa aplikacji webowych. Choć nie tylko.
W bazie wiedzy z powodzeniem znajdziemy poradniki dla aplikacji mobilnych oraz pomoce dydaktyczne, które pomogą opracować testalia potrzebne do przeprowadzenia testów bezpieczeństwa oprogramowania.
OWASP TOP 10 ma charakter 10. punktowej listy, w której kolejności haseł przyporządkowana jest liczba od 1 do 10. Im niższy numer na liście, tym częstotliwość występowania problemu w aplikacjach jest wyższa.
OWASP TOP 10 zostało opublikowane po raz pierwszy w 2003 roku i na przestrzeni 19 lat doczekało się siedmiu odsłon (z czego lista z 2003 i 2004 roku jest identyczna – więc tak naprawdę było ich 6). Lista jest bardzo pomocna podczas planowania jak i przeprowadzania testów penetracyjnych dla aplikacji webowych. Aktualna lista OWASP TOP 10 jest wydana na rok 2021. Lista znajduje się na dedykowanej do tego domenie, ale odnośniki możemy też znaleźć na stronie fundacji.
OWASP dostarcza obiektywnych i mierzalnych frameworków, narzędzi, artykułów, poradników w tym m.in. nawiązania do bazy CWE (Coomon Weakness Enumeration), które służą do przeprowadzania testów bezpieczeństwa:
Lista ta ma charakter uświadamiający – zarówno twórców oprogramowania, jak i osoby je testujące – o wspólnych problemach natury bezpieczeństwa systemów informatycznych, występujących w aplikacjach webowych.
Cytując starożytnego dalekowschodniego generała, a zarazem myśliciela i filozofa Sun Tzu: Jeśli nie poznasz swego wroga, lecz poznasz siebie, jedną bitwę wygrasz, a drugą przegrasz. Jeśli nie znasz ni siebie, ni wroga, każda potyczka będzie dla Ciebie zagrożeniem.
Świadomość zagrożenia jest jednym z kluczowych elementów, aby móc odeprzeć atak, a nawet zniechęcić napastnika (musimy zdawać sobie sprawę, że test penetracyjny ma na celu symulację prawdziwego ataku na nasze systemy!), odpowiednio się przy tym zabezpieczając.
Jako że zdryfowałem tutaj w dygresję i zeszliśmy na niwę militarną, pozwolę sobie dopowiedzieć, że w literaturze można się spotkać z określeniem na metodyki podejścia do cyberataku, (zapożyczonym rodem z armii Stanów Zjednoczonych Ameryki Północnej) pod nazwą Kill Chain, z tą małą różnicą, że dopisuje się słowo kluczowe: Cyber. Temat jest jednak na tyle szeroki, że zasługuje na osobny artykuł.
Wróćmy do listy OWASP TOP 10 z 2021 – w jej kolejnych wydaniach można zaobserwować ewolucję, jaką przeszły aplikacje webowe. W 2021 pojawiły się trzy nowe kategorie, cztery zmieniły nazwę i zakres oraz konsolidację ryzyk / problemów z poprzednich wersji dokumentu.
OWASP TOP 10 pomaga nie tylko w opracowywaniu strategii testów penetracyjnych i ich zakresu, czy definiowaniu przypadków testowych, ale również w zrozumieniu mechanizmów rządzących aplikacjami webowymi, które z punktu widzenia bezpieczeństwa systemów IT są przyczynkiem powstawania ryzyka. Korzystanie z tych wskazówek pomaga unikać błędów, ułatwiając tym samym pracę w fazie rozwoju oprogramowania.
Wiele z podatności typu np. XSS (Cross Site Scripting) to zjawiska, które atakujący, badacze bezpieczeństwa aplikacji webowych i pentesterzy testują, znajdują i w końcu exploitują (czyli wykorzystują daną podatność) od zarania aplikacji webowych, gdy te zaczęły używać skryptów w swoich funkcjonalnych warstwach.
Scenariusze ataków
Niemniej jednak przyczyną problemów, które kryły się przez ostatnich 19 lat pod hasłem Injection na liście OWASP i lądowały na najwyższych pozycjach w zestawieniach, był niewystarczający lub całkowity brak walidacji danych wejściowych do web aplikacji i ufanie a priori, że dane podane przez użytkownika będą właściwe. Trzeba jednak zdawać sobie sprawę, że nie są to jedyne czynniki, wprowadzające do systemów tego rodzaju błędy.
Poprzednia kategoria z 2017 roku – XXE, na liście z 2021 roku kryje się pod hasłem Security Misconfugration. Wyobraźmy sobie, że pozwalamy na import encji w dokumentach XML-owych przesyłanych od użytkownika. Podczas ich analizy składniowej w dokumencie XML, po stronie serwera możemy się narazić na wyciek informacji (OWASP jako organizacja dostarcza również gotowe przykłady, jak podejmować próby ataku). Przy pomocy rzeczonych encji można uruchamiać komendy umożliwiające przeglądanie systemu plików na systemie operacyjnym ofiary.
Równie ciekawy jest scenariusz odmowy dostępu – DoS (Denial of Service), tzw. atak miliarda uśmiechów, który jest w stanie dokonać dzieła zniszczenia, gdy nagle okaże się, że rozwiązując zaimportowane encje w pętli, liczba potrzebnych do tego zasobów zaczyna bezlitośnie rosnąć tempem wykładniczym, wysycając błyskawicznie zasoby web serwera.
Przejdźmy teraz do drugiego modelu zagrożeń, który również stanowi pomoc w opracowywaniu planu testów penetracyjnych – STRIDE.
Model STRIDE został opracowany w latach 90 ubiegłego stulecia przez dwóch inżynierów Microsoft – Lorena Kohnfeldera i Praerita Garga. Objaśnienia wymienionych „mnemoników” są następujące:
Są one skonfrontowane w kierunku pożądanych właściwości (desired secuirty properities) prezentowanych przez bezpieczny system.
Podczas przeprowadzania testów wysokospecjalizowanego urządzenia sieciowego dla jednego z klientów – OWASP TOP 10 pomógł nam opisać parametry poddane testom penetracyjnym oraz dokładniej określić powierzchnie ataku dla interfejsu webowego.
Przy pomocy modelu STRIDE określiliśmy dalsze i równie istotne z punktu widzenia bezpieczeństwa systemów informatycznych kluczowe elementy, które musiały zostać sprawdzone.
Było to urządzenie, które miało monstrualne możliwości przełączania i było umiejscawiane w sieciach szkieletowych. Taki element musiał być sprawdzony pod kątem DoS i DDoS oraz trzeba było sprawdzić, czy istnieje sposób, aby badany system zużywał nieproporcjonalnie dużo zasobów przy jednoczesnej obsłudze niepozornych, pojedynczych żądań (idea ataków typu wymienionych powyżej – atak miliarda uśmiechów czy próba ataku opartego o mechanizm amplifikacji DNS).
Skierowaliśmy naszą uwagę w kierunku poszukiwania słabych algorytmów kryptograficznych (za mnemonikiem I oraz R) w systemach SSH czy SSL/TLS. Problemy z jakimi można się spotkać w takich sytuacjach, to między innymi błędy w algorytmach wymiany klucza w protokole Diffiego Helamana (np. mogące się pojawić się podatności w SSH czy TLS typu logjam)
Spoofing. Opracowując ten element, poszukiwaliśmy błędów i scenariuszy na to, czy mamy do czynienia z ekspozycją danych poufnych typu prywatny klucz danego web serwera. Widać tutaj „zazębianie się” różnych zagrożeń – z I wynika S.
Aby stało się zadość mnemonikowi T (Tempering), przeprowadziliśmy fuzzing wybranych protokołów sieciowych oferowanych przez urządzenie.
Ostatni z mnemoników „E” był źródłem przypadków testowych, które miały na celu sprawdzenie mechanizmów autoryzacji. Tworząc użytkowników na potrzeby testowe, sprawdzaliśmy czy dany użytkownik może wykonywać konkretne czynności na badanym systemie. Te i żadne inne, zgodnie z dobrą praktyką (to pryncypium można spotkać pod nazwą zasadą najmniejszego uprzywilejowania), nadawania minimalnych, ale jednocześnie wystarczających uprawnień, by móc realizować zadania w danym systemie.
Model STRIDE znacząco pomógł i przyspieszył ogólną ocenę i znalezienie właściwej perspektywy w projektowaniu testów. Jak wynika z testerskiej praktyki, jest to równie istotne jak warsztat i umiejętności zespołu testerów w szukaniu błędów.
