Najbardziej zaawansowana aplikacja do ochrony cybernetycznej dla Androida - Bitdefender Mobile Security & Antivirus

Pobierz

Poradniki

Głęboka analiza w bezpieczeństwie ofensywnym

Piotr R

22 maja 2024

W ciągu ostatniej dekady krajobraz cyberbezpieczeństwa stał się dziedziną znacznie bardziej dynamiczną niż dawniej. Atakujący są coraz bardziej wyrafinowani i uciekają się do złożonych technik w celu infiltracji systemów i kradzieży wrażliwych danych. Podczas gdy zespoły defensywne kupują szerszą gamę różnych produktów, aby powstrzymać napływ luk w zabezpieczeniach, w tym skanery podatności na ataki, niestandardowy charakter aplikacji utrudnia zatrzymanie exploitów bez odpowiedniej identyfikacji. Dlatego niezbędnym krokiem dla każdego przedsiębiorstwa staje się przeprowadzenie głębokiej analizy w bezpieczeństwie ofensywnym.

Zespół do spraw IT przeprowadza głęboką analizę w bezpieczeństwie ofensywnym

W tym artykule przeanalizujemy przykłady tego, jak testy ręczne mogą emulować złożone metody ataku powszechnie stosowane przez wyrafinowanych napastników. Przykłady pokazują luki, które mogły umożliwić osobie atakującej uzyskanie możliwości uruchamiania poleceń i kodu w systemach w celu przejęcia kontroli nad kontami w aplikacjach internetowych i mogły spowodować szkody finansowe i reputacyjne, gdyby nie zostały zidentyfikowane w celu usunięcia usterek w testach Bitdefender.

Znajdowanie luk za pomocą analizy łańcucha ataków

Jednym ze sposobów, w jaki ręczne testowanie i analiza przewyższa automatyczne skanowanie, jest możliwość łączenia różnych luk w zabezpieczeniach, z których niektóre nie pojawią się w wynikach typowego skanera podatności na ataki aplikacji internetowych.

Wykonanie kodu dla aplikacji mobilnej firmy energetycznej

Jedną z takich luk wykryto w aplikacji mobilnej dla firmy energetycznej. Tester odkrył funkcję umożliwiającą przesyłanie plików z wykonywalnymi rozszerzeniami i zawartością, takich jak pliki Active Server Page Extended (ASPX) lub pliki wykonywalne systemu Windows (EXE). Tester ominął typowe kontrole, używając jedynie rozszerzenia pliku (np. „aspx”) jako nazwy przesłanego pliku, co pokazało typową pomysłowość naszych testerów.

Pomyślne przesłanie pliku ASPX, który nie miał być dozwolony.

Skanery podatności aplikacji mogły przeoczyć tę lukę ze względu na unikalny przypadek testowy niezbędny do wykrycia tej luki. Zazwyczaj skanery podatności aplikacji testują luki w zabezpieczeniach przesyłania plików w przesłanej nazwie pliku, obserwując odpowiedź aplikacji na przesłanie zarówno podstawowej nazwy pliku (np. „plik1”), jak i rozszerzenia pliku (np. „aspx”). Przypadek testowy polegający na przesłaniu samego rozszerzenia pliku nie jest typowym przypadkiem testowym i zazwyczaj jest pomijany przez większość skanerów podatności na ataki.

Lista luk wykrytych przez skaner nie zawiera opisanej powyżej luki.

Tester jest następnie przywiązany do tego z luką w zabezpieczeniach umożliwiającą przekroczenie ścieżki, aby móc wykonać kod na działającym serwerze internetowym. Taka luka zostałaby przeoczona przez skaner podatności aplikacji internetowych, a luka ujawniłaby się jedynie po wykonaniu wielu kroków w określonej kolejności – przesłaniu pliku, próbie przeniesienia miejsca jego przesłania w systemie plików, a następnie próbie uzyskania dostępu. Bez zrozumienia kontekstu poprzez ręczne testowanie i eksplorację funkcji przesyłania i uzyskiwania dostępu do plików, ten łańcuch luk nie zostałby wykryty.

Przesyłanie poza zamierzony folder może zostać wykonane w wyniku luki w zabezpieczeniach umożliwiającej przejście ścieżki.

Wykonywanie poleceń dla aplikacji internetowej klienta motoryzacyjnego

Podobny przykład jest związany z klientem z branży motoryzacyjnej, który wykrył podobną lukę umożliwiającą przesyłanie plików. W tym przypadku ręczne testy wykazały, że pojawił się komunikat o błędzie, który zawierał więcej informacji, niż było to wymagane. Chociaż automatyczne skanowanie potraktowałoby ten problem jako lukę o „niskim” lub „informacyjnym” poziomie ważności, testerowi udało się wykorzystać tę lukę do zidentyfikowania lokalizacji, do której plik został przesłany, poprzez odczytanie ujawnionego kodu, który znajdował się w obrębie błędu wiadomości.


Komunikat o błędzie ujawnia lokalizację strony zawierającej kod źródłowy.

Mając te informacje, tester znalazł funkcję, którą mógł wywołać, która ostatecznie ujawniła lokalizację przesłanego pliku. Uzyskując dostęp do przesłanego spreparowanego pliku, tester wykazał, że osoba atakująca może uruchomić dowolny wybrany przez siebie kod.

Lokalizacja przesłanego pliku znaleziona za pomocą funkcji wykrytej poprzez dostęp do ujawnionego kodu.

Tester wykazał, że polecenia systemu operacyjnego można uruchamiać na serwerze WWW.

Powstrzymywanie ataków manipulacyjnych umożliwiających przejmowanie kont

Luka lub seria luk może doprowadzić do przejęcia konta, co zapewni atakującym pełny dostęp do wybranego konta użytkownika i wszystkich jego uprawnień. Jednym z prostych sposobów, w jaki atakujący mogą to zrobić, jest upychanie poświadczeń, które wykorzystuje automatyczne skrypty do odgadnięcia nazwy użytkownika i hasła (zwykle na podstawie haseł wyciekających w wyniku naruszenia bezpieczeństwa danych w innej witrynie). Wdrożenie uwierzytelniania dwuskładnikowego w wielu systemach klientów Bitdefender zmniejszyło ryzyko takich ataków polegających na upychaniu poświadczeń. Zespół Bitdefender zidentyfikował kilka przypadków, w których implementacje uwierzytelniania dwuskładnikowego były źle zaimplementowane lub skonfigurowane i w związku z tym można było je ominąć.

Obejście uwierzytelniania drugiego stopnia

W teście aplikacji internetowej firmy inwestycyjnej tester Bitdefender ominął implementację uwierzytelniania dwuskładnikowego w ramach przypadków testowych przeprowadzonych w celu sprawdzenia skuteczności funkcji uwierzytelniania wieloskładnikowego.

Podczas badania tester Bitdefender zidentyfikował pole e-mail wysłane podczas procesu uwierzytelniania dwuskładnikowego jako wektor przejęcia konta. Podczas testu zaobserwowano, że przesłane żądanie HTTP zawierało parametr adresu e-mail (patrz zrzut ekranu poniżej). Z założenia adres e-mail będzie prawidłowym adresem e-mail użytkownika. Tester zaobserwował jednak, że zmiana tego adresu na własny e-mail (symulując działanie atakującego) spowoduje, że aplikacja wyśle na jego adres e-mail kod uwierzytelniania dwuskładnikowego.

Mechanizm weryfikacji 2FA (2-czynnikowy) podjął decyzję na podstawie podanego adresu e-mail użytkownika.

Typowe skanery podatności aplikacji internetowych nie byłyby w stanie wykryć tej luki ze względu na konieczność (1) posiadania dostępu do działającego systemu poczty elektronicznej oraz (2) zrozumienia logiki mechanizmu uwierzytelniania dwuskładnikowego w celu zidentyfikowania, że adres e-mail nie powinien być używany lub wymagany na tym etapie. Identyfikacja i naprawa tej luki zmniejszyła ryzyko przejęcia konta poprzez usunięcie tego wektora z aplikacji.

W przypadku niektórych klientów Bitdefender, którzy nie posiadają uwierzytelniania dwuskładnikowego, testerzy znaleźli metody na całkowite ominięcie wymogu uwierzytelnienia i przejęcie kont innych użytkowników. Poniżej załączamy krótki opis dwóch takich przypadków, jednej dla klienta z sektora Fintech i drugiej z branży energetycznej.

Przejęcie konta poprzez rejestrację nadpisaną

W przypadku firmy Fintech tester Bitdefender odkrył lukę, która umożliwiłaby złośliwemu aktorowi przejęcie kontroli nad kontem. Tester wykazał, że osoba atakująca może dokonać rejestracji przy użyciu tego samego identyfikatora, co istniejący użytkownik.

Podczas testu penetracyjnego aplikacji tester poczynił następujące obserwacje:

  • Podczas procesu rejestracji aplikacja przydzielała dla każdej nowej rejestracji nowy identyfikator rejestracji.
  • Identyfikator rejestracyjny mógł zostać zmieniony w momencie wysłania go z przeglądarki internetowej.
  • Aplikacja zaakceptowała zmieniony identyfikator rejestracyjny i połączyła w jedną całość informacje z dwóch rekordów. Osoba atakująca może to wykorzystać do utworzenia rejestracji powiązanej z jego własnym adresem e-mail.
  • Aplikacja sprawdziła, czy rejestracje z tym samym numerem telefonu komórkowego zostały odrzucone. To sprawdzenie może zostać wykorzystane do ustalenia, czy numer telefonu komórkowego jest ważny.
  • W każdym etapie procesu rejestracji nie obowiązywały żadne ograniczenia w liczbie zgłoszeń (technicznie rzecz biorąc, brak ograniczenia szybkości żądań HTTP i wywołań API).

Testerowi udało się połączyć wiele słabych praktyk i luk w zabezpieczeniach, aby wykazać krytyczną lukę polegającą na przejęciu konta:

  • System nie miał ograniczeń co do szybkości prób ustalenia prawidłowych numerów telefonów, co ułatwiło atakującemu identyfikację prawidłowych numerów w wyniku wielokrotnych prób.
  • Aplikacja niepotrzebnie ujawniała użytkownikom identyfikator abonenta.
  • Aplikacja nie sprawdzała, czy identyfikator abonenta był już używany przed utworzeniem użytkownika.
  • Baza danych nie ustawiła identyfikatora rejestrującego jako unikalnego klucza w odpowiednich tabelach bazy danych, dlatego możliwe było utworzenie wielu rekordów z tym samym identyfikatorem.

Przejęcie konta poprzez zmieniony parametr

W innym przypadku przejęcia konta tester Bitdefender zaobserwował, że w przechwyconych żądaniach znajdował się parametr zawierający pole nazwy użytkownika podczas procesu logowania. Zmieniając selektywnie parametr na parametr innego użytkownika dla niektórych żądań, tester wykazał, że osoba atakująca może uzyskać dostęp do konta o wyższych uprawnieniach. Ekspert do spraw cyberbezpieczeństwa z Bitdefender był w stanie to zrobić dzięki swoim wcześniejszym doświadczeniom z różnymi implementacjami pojedynczego logowania i jego zdolności do zrozumienia, które żądania należy modyfikować, a których nie.

Głęboka analiza ręczna – kluczowe wnioski

Przykłady przedstawione powyżej podkreślają niektóre słabości bezpieczeństwa, które można zidentyfikować poprzez ofensywne testy bezpieczeństwa. Tradycyjne produkty obronne, takie jak zapory aplikacji internetowych, same często nie są w stanie powstrzymać skomplikowanych ataków wykorzystujących takie słabości, co podkreśla znaczenie kompleksowych ofensywnych testów bezpieczeństwa. Oprócz odkrywania ukrytych luk w zabezpieczeniach w celu ich naprawienia, ofensywne testy bezpieczeństwa wykazują również należytą staranność dzięki proaktywnym wysiłkom w zakresie bezpieczeństwa i wspierają wysiłki w zakresie zgodności, takich jak ISO 27001, SOC 2 typ 2, RODO, PCI-DSS i HIPAA.

Przyjęcie ofensywnej strategii cyberbezpieczeństwa to nie tylko opcja, ale konieczność dla firm i liderów IT, którzy chcą być o krok przed wyrafinowanymi przeciwnikami. Dlatego integracja środków ofensywnych ma kluczowe znaczenie dla zbudowania solidnej, dynamicznej obrony, która jest w stanie udaremnić nawet najbardziej zaawansowane zagrożenia cybernetyczne.

Jeśli chcesz podnieść poziom cyberbezpieczeństwa swojej firmy, to sprawdź nasz flagowy produkt z linii Bitdefender GravityZone, lub skontaktuj się z nami.


Autor


Piotr R

Account Manager, od ponad roku pracuję w branży IT i od ponad 5 lat jestem copywriterem. Do moich zadań należy nawiązywanie współpracy partnerskich, pisanie i redagowanie tekstów, kontakt z dziennikarzami, tworzenie notatek prasowych oraz zamieszczanie ich na stronach internetowych i w naszych mediach społecznościowych. Wcześniej byłem przez kilka lat związany z branżą OZE oraz z technologiami telemetrycznymi i elektronicznymi. Interesuję się językoznawstwem, literaturą, grą na gitarze oraz branżą gier.

Zobacz posty autora


Artykuły które mogą Ci się spodobać

    Formularz kontaktowy

    Wybierz odpowiednią opcję aby przejść do formularza kontaktowego. Odpowiemy najszybciej jak to możliwe!

    klient-indywidualnyklient-biznesowyreseller

    Dane kontaktowe




    stalynowy