CyberLabs #3 – Testy Penetracyjne – znajdź błędy przed cyberprzestępcą

W trzeciej części naszego cyklu CyberLabs dowiesz się, co to są testy penetracyjne i dlaczego ich wykonywanie jest ważne dla zapewnienia cyberbezpieczeństwa.

Praktycznie każda firma posiada swoją aplikację webową, która jest dostępna z internetu. Nierzadko zdarza się, że przez te samą aplikację klienci logują się do swoich kont, aby dokonać zakupów czy wykonać pewne akcje. Można więc śmiało stwierdzić, że aplikacje te są “zbiorem” wielu danych a cyberprzestępcy wcześniej czy później spróbują się dostać do tych informacji.

Dlatego tak ważne jest, aby nasze aplikacje były przygotowane na różnego rodzaju próby ataków. Czy zatem wykonujemy testy bezpieczeństwa IT lub testy oprogramowania używanego, aby uchronić się od ataków hakerskich?

CyberLabs #2 – Bezpieczeństwo haseł, czyli dlaczego warto tworzyć silne hasła

Czym są testy penetracyjne?

Testy penetracyjne (krócej pentesty) to działania, za pomocą których wyszukiwana jest jak największa liczba błędów w aplikacjach webowych, mobilnych itp. które mogą wpływać negatywnie na poufność, integralność oraz dostępność przetwarzanych danych.

Mówiąc prostym językiem, testy te polegają na znajdowaniu jak największej liczby błędów, które cyberprzestępca mógłby wykorzystać do np. przejęcia kont użytkowników, wydobycia informacji z bazy danych czy do nawet przejęcia serwera, na którym działa aplikacja. Profesjonalne testy penetracyjne są bardzo ważnym punktem dla każdej firmy, która dba o cyberbezpieczeństwo.

Same pentesty jednak w odróżnieniu od ataków cyberprzestępców wykonywane są przez określony czas dla konkretnego zakresu aplikacji. Warto być też świadomym, że test penetracyjny nie wykryje wszystkich podatności. Jednym tego powodem jest właśnie ograniczony czas na takie testy. Innym tego powodem może być niepełne wykorzystanie zakresu testów penetracyjnych bądź powstanie nowych podatności, o których wcześniej nie było wiadomo (np. podatność w konkretnej wersji oprogramowania, której używa nasza aplikacja).

Klasyfikacja podatności

Przyjęło się, że znalezione błędy klasyfikuje się w pięciostopniowej skali. Skala ta definiuje poziom zagrożenia i skutków jej wykorzystania oraz czas, w jakim powinno się dane błędy naprawić.

CRITICAL

Podatność krytyczna, wykorzystanie podatności sklasyfikowanej jako krytyczna umożliwia przejęcie pełnej kontroli nad serwerem lub nad urządzeniem sieciowym. Podatności, które zostały oznaczone jako krytyczne, powinny być naprawione bezzwłocznie.

HIGH

Podatność o wysokim poziomie istotności, wykorzystanie tej podatności pozwala na uzyskanie dostępu do wrażliwych informacji, jednak wcześniej może wymagać spełnienia pewnych warunków w celu praktycznego wykorzystania. Podatności sklasyfikowane jako “high” powinny zostać naprawione w bardzo krótkim czasie od ich zgłoszenia.

MEDIUM

Podatność o średnim poziomie istotności, wykorzystanie tej podatności może zależeć od różnych czynników. Podatność ta zazwyczaj umożliwia dostęp do ograniczonej ilości danych lub do danych o mniejszej istotności. Naprawa tej podatności nie musi być zrealizowana od razu, jednak nie należy też z nią zwlekać.

LOW

Podatność o niskim poziomie istotności, wykorzystanie tej podatności ma niewielki wpływ na bezpieczeństwo lub wymaga bardzo trudnych warunków do jej spełnienia. Naprawa tej podatności może odbyć się przy aktualizacji aplikacji o np. nową funkcjonalność.

INFO

Ogólne zalecenia lub informacje, punkty oznaczone poziomem info nie są podatnościami bezpieczeństwa. Wskazują one jednak dobre praktyki, których zastosowanie pozwala zwiększyć ogólny poziom bezpieczeństwa aplikacji.

Wyszukiwanie podatności to większa część pracy pentestera, szczególnie jeśli wykonuje on manualne testy penetracyjne sieci, jednak nie tylko tym się zajmuje. Po przeprowadzeniu testów tworzy przykładowy raport, z którego możemy się dowiedzieć, jakie podatności zostały znalezione w naszych aplikacjach.

Dodatkowo pod koniec opisu każdej znalezionej podatności, będziemy mogli przeczytać zalecenia po zastosowaniu, do których będziemy mogli wyeliminować znalezioną podatność. Raporty pentestera służą do oceniania skuteczności zastosowanych zabezpieczeń w oparciu o dostępne rodzaje testów penetracyjnych.

Fazy testów penetracyjnych

• • Zdefiniowanie zakresu testów – wyznaczony zakres jest dla każdego etycznego testera granicą, której nie można przekroczyć. To podczas tej fazy ustalane jest, co będzie testowane i w jaki sposób. Dobranie odpowiedniego zakresu jest ważne dla dwóch stron dlatego, że zbyt wąski zakres testów może skutkować tym, że nie zostaną wykryte krytyczne podatności, z kolei zbyt szeroki zakres może skutkować brakiem czasu, aby przetestować każde miejsce w poszukiwaniu błędów. Jeśli mamy do przetestowania duży zakres warto zastanowić się nad przeprowadzeniem np. dwóch osobnych pentestów.

• • Rekonesans – jedna z ważniejszych części ataku. Polega na wyszukiwaniu i gromadzeniu jak największej informacji na temat testowanego zakresu, które mogą się przydać w dalszym ataku. Może to być wyszukiwanie loginów, ukrytych katalogów, endopointów API itd. W tej fazie również warto przyjrzeć się, jak działa dana aplikacja. To, w jakim stopniu przyłożymy się do tej fazy, może skutkować ilością późniejszych znalezionych podatności.

• • Wyszukiwanie podatności – wykorzystując informacje zdobyte w poprzedniej fazie, testowany jest już aktywnie ustalony zakres testów. W tym momencie pentester wysyła do aplikacji różne payloady, dzięki którym może ustalić, czy w aplikacji występują konkretne podatności.

• • Wykorzystywanie podatności / eskalacja uprawnień / eksfiltracja danych – po znalezieniu pewnych podatności np. podatności SQL Injection pentester może próbować wykorzystać znalezioną podatność, aby za jej pomocą dostać się np. do serwera. W tym momencie tester może też próbować eskalować swoje uprawnienia bądź eskfiltrować specjalnie przygotowane dane (ważne jest to, aby ustalić podczas fazy, w której definiujemy zakres testów czy tester ma dokonywać tych czynności).

• • Tworzenie raportu  – po zakończeniu testów, każdy test jest podsumowywany specjalnie przygotowanym raportem, w którym możemy znaleźć wyszczególnione podatności, które udało się znaleźć oraz informacje na temat naprawy tych podatności.

Powyższe fazy są tylko ogólnym “spisem” każdego testu penetracyjnego i w rzeczywistości każdą ze wspomnianych faz można rozbić na bardziej szczegółowe punkty. Po naprawie znalezionych podatności warto wykonać tzw. Retest, aby zweryfikować czy dane podatności rzeczywiście zostały wyeliminowane.

Metodologie i standardy testów penetracyjnych

Pentesty mogą być wykonywane według własnych metod, reguł czy zasad, jednak istnieją sprawdzone metodologie i standardy, które są ogólnie znane wśród osób zajmujących się cyberbezpieczeństwem. Poniżej zostały przedstawione cztery znane metodologie i standardy:

• • OWASP TOP 10 – jeden z najbardziej znanych standardów bezpieczeństwa aplikacji webowych. Dokument przedstawia 10 najistotniejszych kategorii zagrożeń / problemów bezpieczeństwa związanych z aplikacjami webowymi.
    
    
    

    OWASP Top 10 jest standardowym dokumentem dotyczącym świadomości programistów i bezpieczeństwa aplikacji internetowych

• • OWASP Application Security Verification Standard Project (OWASP ASVS) – jedna z ważniejszych części ataku. Polega na wyszukiwaniu i gromadzeniu jak największej informacji na temat testowanego zakresu, które mogą się przydać w dalszym ataku. Może to być wyszukiwanie loginów, ukrytych katalogów, endopointów API itd. W tej fazie również warto przyjrzeć się, jak działa dana aplikacja. To, w jakim stopniu przyłożymy się do tej fazy, może skutkować ilością późniejszych znalezionych podatności.

• • Open Source Security Testing Methodology Manual (OSSTMM) – OSSTMM opisuje sposób zabezpieczenia tak naprawdę dowolnego systemu informatycznego, definiuje on 5 kanałów, które wskazują nam charakter testów. Testy te obejmują m.in. bezpieczeństwo fizyczne oraz bezpieczeństwo czynnika ludzkiego. Ponadto obejmuje bezpieczeństwo sieci przewodowych jak i bezprzewodowych.
    

Penetration Testing Execution Standard (PTES) – po zakończeniu testów, każdy z nich jest podsumowywany specjalnie przygotowanym raportem, w którym możemy znaleźć wyszczególnione podatności oraz informacje na temat ich naprawy.

Najczęściej spotykane podatności

W zależności od rodzaju testowanego systemu, aplikacji rodzaje podatności mogą się różnić. O bezpieczeństwo samych aplikacji warto zadbać już od pierwszych etapów wytwarzania oprogramowania, a nie dopiero w momencie, gdy jest ono już “dojrzałe”. Istnieje bowiem szansa, że oprogramowanie ze względu na podatności nie będzie mogło zostać upublicznione w założonym terminie, co może wiązać się z różnymi negatywnymi skutkami.

Jednak, aby móc odpowiednio zabezpieczyć nasze aplikacje, warto wiedzieć, z jakimi podatnościami musimy sobie poradzić. Poniżej zostało przedstawione kilka najczęstszych podatności w aplikacjach webowych.

• • XSS (Cross-Site Scripting) – za pomocą podatności XSS atakujący jest w stanie osadzić złośliwy kod JavaScript w danej aplikacji. W zależności od rodzaju XSS’a atakujący jest w stanie np. zmodyfikować wygląd strony, uruchomić złośliwe oprogramowanie, wykradać ciasteczka sesyjne czy tworzyć nowe konta z uprawnieniami administratora.

• • SQL Injection  – wykorzystując podatność SQL Injection (w zależności też od miejsca występowania) atakujący, jest w stanie ominąć panel logowania, wydobyć oraz modyfikować bazę danych. W krytycznych sytuacjach za pomocą tej podatności jest w stanie odczytać dowolny plik z serwera czy przejąć cały serwer.

• • CSTI / SSTI (Client/Server-Side Template Injection) – wiele dzisiejszych aplikacji korzysta z silnika szablonów, jednak nie każdy wie, że wykorzystując tę podatność, możemy wstrzyknąć złośliwy kod do szablonu, który zostanie wykonany albo po stronie klienta, albo serwera. W zależności od jego wykonania możemy mówić o skutkach podobnych do XSS (kod wykonuje się po stronie klienta) bądź atak może skutkować nawet przejęciem serwera (kod wykonuje się po stronie serwera).

• • OS Command Injection – jeśli nasza aplikacja jest podatna na ten błąd, atakujący będzie w stanie wykonać polecenia systemowe na serwerze, na którym ona działa.

• • Path Traversal – za pomocą podatności Path Traversal atakujący może odczytać każdy plik z serwera (np. pliki konfiguracyjne). W przypadku dostępu do logów aplikacji istnieje możliwość wykonania ataku Log Poisoning, w którym to nasz kod umieszczamy w logach za pomocą błędnego logowania do SSH (kod zazwyczaj umieszczany jest w miejscu nazwy użytkownika). Po odwołaniu się  do tego pliku kod zostanie wykonany.

• • Podatności związane z nieaktualnym oprogramowaniem – pod ten punkt można podpiąć wiele innych podatności, bo tak naprawdę wszystko zależy od znalezionych podatności w używanym oprogramowaniu. Bardzo ważną częścią bezpiecznego systemu jest aktualizacja oprogramowań których używa nasz system. Jeśli z jakichś powodów nie możemy przeprowadzić aktualizacji warto zastanowić się nad mitygacją podatności, która pozwoli na ograniczenie pola ataku. 
    

• • Podatności związane z nieprawidłową kontrolą dostępu – jest to jedna z tych podatności w której atakujący nie musi zbytnio znać się na hackowaniu. Podatność tego typu może np. występować w miejscu w którym przechodzimy do ustawień naszego konta, a w adresie URL widzimy identyfikator dla naszego konta. Jeśli aplikacja jest podatna na tą podatność po zmianie identyfikatora zobaczymy np. dane innego konta. 

Oczywiście powyższe podatności to tylko część tego z czym muszą się zmierzyć programiści bowiem lista podatności jest wiele, wiele dłuższa…

Testy penetracyjne vs Testy Red Teamowe

Testy penetracyjne nastawione są na znalezienie jak największej ilości podatności we wskazanych np. aplikacjach webowych. Pentester podczas takich testów trzyma się „sztywno” swojego zakresu, czyli konkretnej aplikacji, a znalezionych błędów nie łączy w tzw. łańcuchy ataków (ang. cyber kill-chain), za pomocą których można by było przejąć wrażliwe dane.

Testy penetracyjne aplikacji webowych pozwalają więc sprawdzić, czy dana aplikacja webowa jest bezpieczna, jednak nie pozwalają określić czy dana organizacja jest przygotowana na realne cyberzagrożenia ze strony hakerów. Rozwiązaniem tego problemu są testy Red Teamowe.

Testy Red Teamowe różnią się od tych penetracyjnych pod wieloma względami, a przede wszystkim:

• • Nie ograniczają się tylko i wyłącznie do użytej technologii. Testy dotyczą również czynnika ludzkiego czy bezpieczeństwa fizycznego.

• • Nie polegają na znalezieniu jak największej ilości podatności, tylko na znalezieniu najskuteczniejszej metody do przełamania zabezpieczeń danej organizacji.

• • Nie są ograniczone do wskazanej aplikacji webowej.

Można więc podsumować różnice między nimi tak: testy penetracyjne sieci są dobrym rozwiązaniem, jeśli chodzi o znalezienie jak największej ilości słabych punktów w danym systemie, które należy poprawić, a testy red teamowe są idealnym rozwiązaniem, jeśli chodzi o gotowość firmy na ataki hakerskie.

Zalety testów Read Teamowych

• • Są to najbardziej zaawansowane testy bezpieczeństwa.

• • Testy te są realną symulacją cyberzagrożeń.

• • Dzięki nim weryfikowane są zabezpieczenia organizacji oraz oceniana jest zdolność wykrywania, reagowania na różne incydenty.

Testy penetracyjne: garść dobrych rad

Tak jak w poprzednich artykułach z serii CyberLabs – wszystko co musisz wiedzieć o cyberbezpieczeństwie poniżej znajdziesz kilka dobrych rad, które pozwolą na zwiększenie poziomu cyberbezpieczeństwa w Twojej organizacji:

• • Pamiętaj o aktualizacjach oprogramowania, którego używasz w swojej aplikacji. Często z powodu braku tych aktualizacji w Twojej aplikacji powstają poważne błędy bezpieczeństwa.

• • Postaraj się nie zawężać zakresu testu do minimum. Stosując takie podejście może się zdarzyć, że system który jest zbyt krytyczny na testy posiada wiele poważnych podatności. Jeśli nie można testować konkretnego systemu może można go zabezpieczyć w inny sposób. Pamiętaj że cyberprzestępca skorzysta z każdej okazji, aby osiągnąć swój cel.

• • Podczas realnych ataków często wykorzystywany jest ludzki błąd. Dlatego phishing jest często wykorzystywany w pierwszych fazach ataku. Warto więc przetestować również ten element “systemu” poprzez np. kontrolowane testy socjotechniczne.

Stay secure! 👾