przez SeerLight
Budowanie jakiejkolwiek usługi wiąże się z koniecznością ciągłej pracy nad bezpieczeństwem. Bezpieczeństwo to proces ciągły, który obejmuje ciągłą analizę i doskonalenie bezpieczeństwa produktów, monitorowanie wiadomości o lukach w zabezpieczeniach i wiele więcej. Łącznie z audytami. Audyty przeprowadzane są zarówno przez ekspertów wewnętrznych, jak i zewnętrznych, którzy mogą radykalnie pomóc w kwestii bezpieczeństwa, ponieważ nie są zanurzeni w projekcie i mają otwarty umysł.
Artykuł przedstawia najprostszą opinię ekspertów zewnętrznych, którzy pomogli zespołowi Mail.ru Cloud Solutions (MCS) przetestować usługę w chmurze, oraz to, co odkryli. Jako „siłę zewnętrzną” MCS wybrało firmę Digital Security, znaną z dużej wiedzy specjalistycznej w kręgach bezpieczeństwa informacji. A w tym artykule przeanalizujemy kilka ciekawych luk wykrytych w ramach zewnętrznego audytu - aby uniknąć tego samego prowizji przy tworzeniu własnej usługi w chmurze.
Описание продукта
to platforma do budowy wirtualnej infrastruktury w chmurze. Obejmuje IaaS, PaaS oraz rynek gotowych obrazów aplikacji dla programistów. Biorąc pod uwagę architekturę MCS konieczne było sprawdzenie bezpieczeństwa produktu w następujących obszarach:
- ochrona infrastruktury środowiska wirtualizacji: hypervisory, routing, firewalle;
- ochrona infrastruktury wirtualnej klientów: izolacja od siebie, w tym sieci, sieci prywatnych w SDN;
- OpenStack i jego otwarte komponenty;
- S3 własnego projektu;
- IAM: projekty wielodostępne z wzorem do naśladowania;
- Wizja (wizja komputerowa): interfejsy API i luki w zabezpieczeniach podczas pracy z obrazami;
- interfejs sieciowy i klasyczne ataki sieciowe;
- podatności komponentów PaaS;
- API wszystkich komponentów.
Być może to wszystko, co jest istotne dla dalszej historii.
Jakiego rodzaju prace zostały wykonane i dlaczego były potrzebne?
Audyt bezpieczeństwa ma na celu identyfikację podatności i błędów konfiguracyjnych, które mogą prowadzić do wycieku danych osobowych, modyfikacji wrażliwych informacji lub zakłócenia dostępności usług.
Podczas prac, które trwają średnio 1-2 miesiące, audytorzy powtarzają działania potencjalnych atakujących i szukają podatności w części klienckiej i serwerowej wybranej usługi. W kontekście audytu platformy chmurowej MCS zidentyfikowano następujące cele:
- Analiza uwierzytelnienia w serwisie. Luki w tym komponencie pomogłyby natychmiast dostać się na konta innych osób.
- Badanie modelu do naśladowania i kontroli dostępu między różnymi kontami. Dla atakującego pożądanym celem jest uzyskanie dostępu do cudzej maszyny wirtualnej.
- Luki po stronie klienta. XSS/CSRF/CRLF/itp. Czy możliwe jest atakowanie innych użytkowników za pomocą złośliwych linków?
- Luki po stronie serwera: RCE i wszelkiego rodzaju zastrzyki (SQL/XXE/SSRF i tak dalej). Luki w zabezpieczeniach serwerów są zazwyczaj trudniejsze do znalezienia, ale prowadzą do zagrożenia bezpieczeństwa wielu użytkowników jednocześnie.
- Analiza izolacji segmentu użytkowników na poziomie sieci. Dla atakującego brak izolacji znacznie zwiększa powierzchnię ataku na innych użytkowników.
- Analiza logiki biznesowej. Czy można oszukać firmy i stworzyć maszyny wirtualne za darmo?
W tym projekcie prace odbywały się w modelu „Gray-box”: audytorzy wchodzili w interakcję z usługą z uprawnieniami zwykłych użytkowników, ale częściowo posiadali kod źródłowy API i mieli możliwość doprecyzowania szczegółów z programistami. Jest to zazwyczaj najwygodniejszy, a jednocześnie dość realistyczny model pracy: informacje wewnętrzne nadal mogą zostać zebrane przez atakującego, jest to tylko kwestia czasu.
Znaleziono luki
Zanim audytor zacznie wysyłać różne ładunki (ładunek użyty do przeprowadzenia ataku) w losowe miejsca, konieczne jest zrozumienie, jak wszystko działa i jaką funkcjonalność zapewnia. Może się wydawać, że jest to ćwiczenie bezużyteczne, ponieważ w większości badanych miejsc nie będzie żadnych podatności. Jednak dopiero zrozumienie struktury aplikacji i logiki jej działania umożliwi znalezienie najbardziej złożonych wektorów ataku.
Ważne jest, aby znaleźć miejsca, które wydają się podejrzane lub w jakiś sposób bardzo różnią się od innych. I w ten sposób odkryto pierwszą niebezpieczną lukę.
IDOR
Luki IDOR (Insecure Direct Object Reference) to jedna z najczęstszych podatności w logice biznesowej, która pozwala jednej lub drugiej uzyskać dostęp do obiektów, do których dostęp faktycznie nie jest dozwolony. Podatności IDOR stwarzają możliwość uzyskania informacji o użytkowniku o różnym stopniu krytyczności.
Jedną z opcji IDOR jest wykonywanie akcji na obiektach systemu (użytkownicy, konta bankowe, pozycje w koszyku) poprzez manipulację identyfikatorami dostępu do tych obiektów. Prowadzi to do najbardziej nieprzewidywalnych konsekwencji. Na przykład możliwość podmiany konta nadawcy środków, dzięki czemu można je ukraść innym użytkownikom.
W przypadku MCS audytorzy właśnie odkryli lukę IDOR związaną z niezabezpieczonymi identyfikatorami. Na koncie osobistym użytkownika identyfikatory UUID były wykorzystywane do uzyskiwania dostępu do wszelkich obiektów, które według ekspertów ds. bezpieczeństwa wydawały się imponująco niebezpieczne (to znaczy chronione przed atakami typu brute-force). Jednak w przypadku niektórych podmiotów odkryto, że w celu uzyskania informacji o użytkownikach aplikacji wykorzystywane są regularne, przewidywalne liczby. Myślę, że można się domyślić, że udało się zmienić ID użytkownika o jeden, wysłać żądanie ponownie i w ten sposób uzyskać informacje z pominięciem ACL (lista kontroli dostępu, reguły dostępu do danych dla procesów i użytkowników).
Fałszowanie żądań po stronie serwera (SSRF)
Dobrą rzeczą w produktach OpenSource jest to, że mają ogromną liczbę forów ze szczegółowymi opisami technicznymi pojawiających się problemów i, jeśli masz szczęście, opisem rozwiązania. Ale ten medal ma też drugą stronę: znane luki są również szczegółowo opisane. Na przykład na forum OpenStack znajdują się wspaniałe opisy luk и , z którym z jakiegoś powodu nikt nie spieszy się z naprawą.
Wspólną funkcjonalnością aplikacji jest możliwość przesłania przez użytkownika linku do serwera, w który serwer klika (np. w celu pobrania obrazu z określonego źródła). Jeśli narzędzia bezpieczeństwa nie filtrują samych łączy ani odpowiedzi zwracanych użytkownikom przez serwer, atakujący mogą z łatwością wykorzystać taką funkcjonalność.
Luki w zabezpieczeniach SSRF mogą znacznie przyspieszyć rozwój ataku. Osoba atakująca może uzyskać:
- ograniczony dostęp do zaatakowanej sieci lokalnej, np. tylko przez określone segmenty sieci i przy użyciu określonego protokołu;
- pełny dostęp do sieci lokalnej, jeśli możliwe jest zejście z poziomu aplikacji do poziomu transportowego i w rezultacie pełne zarządzanie obciążeniem na poziomie aplikacji;
- dostęp do odczytu plików lokalnych na serwerze (jeżeli obsługiwany jest schemat file:///);
- И многое другое.
W OpenStack od dawna znana jest luka SSRF, która ma charakter „ślepy”: kiedy kontaktujesz się z serwerem, nie otrzymujesz od niego odpowiedzi, ale otrzymujesz różnego rodzaju błędy/opóźnienia, w zależności od wyniku żądania . Na tej podstawie możesz wykonać skanowanie portów na hostach w sieci wewnętrznej, ze wszystkimi wynikającymi z tego konsekwencjami, których nie należy lekceważyć. Na przykład produkt może mieć interfejs API zaplecza, do którego można uzyskać dostęp tylko z sieci firmowej. Dzięki dokumentacji (nie zapomnij o osobach poufnych) osoba atakująca może użyć SSRF, aby uzyskać dostęp do metod wewnętrznych. Na przykład, jeśli w jakiś sposób udało Ci się uzyskać przybliżoną listę przydatnych adresów URL, to za pomocą SSRF możesz je przejrzeć i wykonać żądanie - mówiąc relatywnie, przelać pieniądze z konta na konto lub zmienić limity.
To nie pierwszy przypadek wykrycia luki SSRF w OpenStack. W przeszłości możliwe było pobieranie obrazów ISO maszyny wirtualnej z bezpośredniego łącza, co również prowadziło do podobnych konsekwencji. Ta funkcja została teraz usunięta z OpenStack. Najwyraźniej społeczność uznała to za najprostsze i najbardziej niezawodne rozwiązanie problemu.
Oraz w publicznie dostępny raport z usługi HackerOne (h1), wykorzystanie już nieślepego SSRF z możliwością odczytu metadanych instancji prowadzi do dostępu root do całej infrastruktury Shopify.
W MCS luki w zabezpieczeniach SSRF wykryto w dwóch miejscach o podobnej funkcjonalności, ale ich wykorzystanie było prawie niemożliwe ze względu na zapory sieciowe i inne zabezpieczenia. Tak czy inaczej zespół MCS i tak naprawił ten problem, nie czekając na społeczność.
XSS zamiast ładować powłoki
Pomimo setek opublikowanych badań, rok po roku ataki XSS (cross-site scripting) nadal cieszą się największą popularnością luka w zabezpieczeniach internetowych (lub ?).
Przesyłanie plików to ulubione miejsce każdego badacza bezpieczeństwa. Często okazuje się, że można załadować dowolny skrypt (asp/jsp/php) i wykonać polecenia systemu operacyjnego, w terminologii pentesterów – „ładuj powłokę”. Jednak popularność takich luk działa w obie strony: są one zapamiętywane i opracowywane są na nie środki zaradcze, tak że ostatnio prawdopodobieństwo „załadowania powłoki” dąży do zera.
Zespół atakujący (reprezentowany przez Digital Security) miał szczęście. OK, w MCS po stronie serwera sprawdzono zawartość pobranych plików, dozwolone były tylko obrazy. Ale SVG to także obraz. W jaki sposób obrazy SVG mogą być niebezpieczne? Ponieważ możesz w nich osadzić fragmenty JavaScript!
Okazało się, że pobrane pliki są dostępne dla wszystkich użytkowników usługi MCS, co oznacza, że istnieje możliwość zaatakowania innych użytkowników chmury, czyli administratorów.
Przykład ataku XSS na phishingowy formularz logowania
Przykłady wykorzystania ataku XSS:
- Po co próbować kraść sesję (zwłaszcza, że teraz wszędzie są pliki cookie tylko HTTP, chronione przed kradzieżą za pomocą skryptów js), jeśli załadowany skrypt może natychmiast uzyskać dostęp do interfejsu API zasobów? W takim przypadku ładunek może wykorzystać żądania XHR w celu zmiany konfiguracji serwera, na przykład dodania publicznego klucza SSH atakującego i uzyskania dostępu SSH do serwera.
- Jeśli polityka CSP (polityka ochrony treści) zabrania wstrzykiwania JavaScriptu, atakujący może się bez niego obejść. Używając czystego HTML, utwórz fałszywy formularz logowania do witryny i ukradnij hasło administratora poprzez ten zaawansowany phishing: strona phishingowa użytkownika trafia pod ten sam adres URL i użytkownikowi trudniej ją wykryć.
- Wreszcie atakujący może się zorganizować — ustaw Cookies większe niż 4 KB. Użytkownik musi tylko raz otworzyć link, a cała witryna staje się niedostępna, dopóki użytkownik nie pomyśli o konkretnym wyczyszczeniu przeglądarki: w zdecydowanej większości przypadków serwer WWW odmówi przyjęcia takiego klienta.
Spójrzmy na przykład kolejnego wykrytego XSS, tym razem z bardziej sprytnym exploitem. Usługa MCS umożliwia łączenie ustawień zapory sieciowej w grupy. Nazwa grupy, w której wykryto XSS. Jego osobliwością było to, że wektor nie był uruchamiany natychmiast, nie podczas przeglądania listy reguł, ale podczas usuwania grupy:
Oznacza to, że scenariusz był następujący: osoba atakująca tworzy regułę zapory sieciowej z „load” w nazwie, administrator po chwili zauważa to i inicjuje proces usuwania. I tu właśnie działa złośliwy JS.
Twórcom MCS w celu ochrony przed XSS w pobranych obrazach SVG (jeśli nie można ich porzucić) zespół Digital Security zalecił:
- Umieść pliki przesłane przez użytkowników w osobnej domenie, która nie ma nic wspólnego z „cookies”. Skrypt zostanie wykonany w kontekście innej domeny i nie będzie stanowić zagrożenia dla MCS.
- W odpowiedzi HTTP serwera wyślij nagłówek „Content-disposition: załącznik”. Następnie pliki zostaną pobrane przez przeglądarkę i nie zostaną wykonane.
Ponadto programiści mają obecnie wiele możliwości ograniczenia ryzyka związanego z wykorzystaniem XSS:
- używając flagi „Tylko HTTP”, możesz uniemożliwić dostęp do nagłówków sesji „Cookies” złośliwemu JavaScript;
- znacznie utrudni atakującemu wykorzystanie XSS;
- nowoczesne silniki szablonów, takie jak Angular czy React, automatycznie oczyszczają dane użytkownika przed wysłaniem ich do przeglądarki użytkownika.
Luki w zabezpieczeniach uwierzytelniania dwuskładnikowego
Aby poprawić bezpieczeństwo konta, użytkownikom zawsze zaleca się włączenie 2FA (uwierzytelnianie dwuskładnikowe). Rzeczywiście jest to skuteczny sposób zapobiegania uzyskaniu przez osobę atakującą dostępu do usługi, jeśli uwierzytelnienia użytkownika zostały naruszone.
Ale czy użycie drugiego czynnika uwierzytelniającego zawsze gwarantuje bezpieczeństwo konta? Implementacja 2FA wiąże się z następującymi problemami związanymi z bezpieczeństwem:
- Wyszukiwanie metodą brute-force kodu OTP (kody jednorazowe). Pomimo prostoty obsługi, duże firmy spotykają się także z błędami takimi jak brak zabezpieczenia przed brutalną siłą OTP: , .
- Słaby algorytm generowania, na przykład zdolność przewidywania kolejnego kodu.
- Błędy logiczne, takie jak możliwość zażądania jednorazowego hasła innej osoby na telefonie, takie jak ten z Shopify.
W przypadku MCS 2FA jest realizowane w oparciu o Google Authenticator i . Sam protokół został już przetestowany czasowo, jednak warto sprawdzić implementację weryfikacji kodu po stronie aplikacji.
MCS 2FA jest używany w kilku miejscach:
- Podczas uwierzytelniania użytkownika. Istnieje ochrona przed brutalną siłą: użytkownik ma tylko kilka prób wprowadzenia hasła jednorazowego, a następnie wprowadzenie hasła jest na chwilę blokowane. Blokuje to możliwość wyboru hasła jednorazowego metodą brute-force.
- Podczas generowania kodów zapasowych offline w celu wykonania 2FA, a także wyłączania go. Tutaj nie zaimplementowano żadnego zabezpieczenia przed brutalną siłą, co umożliwiło, jeśli posiadałeś hasło do konta i aktywną sesję, zregenerowanie kodów zapasowych lub całkowite wyłączenie 2FA.
Biorąc pod uwagę, że kody zapasowe znajdowały się w tym samym zakresie wartości ciągów, co te wygenerowane przez aplikację OTP, szansa na odnalezienie kodu w krótkim czasie była znacznie większa.
Proces wybierania hasła jednorazowego w celu wyłączenia 2FA za pomocą narzędzia „Burp: Intruder”.
Doświadcz mocnych i skutecznych rezultatów
Ogólnie rzecz biorąc, MCS wydaje się być bezpiecznym produktem. Podczas audytu zespołowi pentestującemu nie udało się uzyskać dostępu do maszyn wirtualnych klientów i ich danych, a wykryte luki zostały szybko naprawione przez zespół MCS.
Należy jednak zauważyć, że bezpieczeństwo to ciągła praca. Usługi nie są statyczne, stale się rozwijają. Niemożliwe jest opracowanie produktu całkowicie pozbawionego luk. Można je jednak znaleźć na czas i zminimalizować ryzyko ich ponownego wystąpienia.
Teraz wszystkie wymienione luki w MCS zostały już naprawione. Aby ograniczyć liczbę nowych do minimum i skrócić ich żywotność, zespół platformy nadal robi to:
- regularnie przeprowadzać audyty przez firmy zewnętrzne;
- wspierać i rozwijać uczestnictwo;
- angażować się w bezpieczeństwo. 🙂
Źródło: www.habr.com