przez SeerLight
Budowa dowolnej usługi zawsze obejmuje stałą pracę nad bezpieczeństwem. Bezpieczeństwo to proces ciągły, obejmujący ciągłą analizę i poprawę zabezpieczeń produktu, monitorowanie wiadomości o lukach oraz wiele innych elementów. W tym także audyty. Audyty przeprowadza się zarówno własnymi siłami, jak i przy pomocy zewnętrznych ekspertów, którzy mogą w znaczący sposób pomóc w zapewnieniu bezpieczeństwa, ponieważ nie są zaangażowani w projekt i mają niezaślepione spojrzenie.
Artykuł dotyczy tego nietypowego spojrzenia zewnętrznych ekspertów, którzy pomogli zespołowi Mail.ru Cloud Solutions (MCS) przetestować usługi chmurowe, oraz tego, co odkryli. Jako „zewnętrzne siły” MCS wybrało firmę Digital Security, znaną ze swojego wysokiego poziomu ekspertyzy w kręgach bezpieczeństwa informacji. W artykule omówimy kilka interesujących luk, które zostały znalezione w ramach zewnętrznego audytu - abyście uniknęli podobnych pułapek, gdy będziecie tworzyć swoją usługę chmurową.
Opis produktu
to platforma do budowy wirtualnej infrastruktury w chmurze. Obejmuje IaaS, PaaS, rynek gotowych obrazów aplikacji dla programistów. Z uwagi na architekturę MCS należało zweryfikować bezpieczeństwo produktu w następujących obszarach:
- ochrona infrastruktury środowiska wirtualizacji: hipernadzory, routingi, zapory sieciowe;
- ochrona wirtualnej infrastruktury klientów: izolacja od siebie, w tym sieciowa, prywatne sieci w SDN;
- OpenStack i jego otwarte komponenty;
- S3 własnej produkcji;
- IAM: projekty wielodostępowe z modelem ról;
- Widzenie (machine vision): API i luki przy pracy z obrazami;
- interfejs internetowy i klasyczne ataki sieciowe;
- luki w komponentach PaaS;
- API wszystkich komponentów.
Cóż, chyba wszystko co istotne dla dalszej historii.
Jakie prace były przeprowadzane i po co są potrzebne?
Audyt bezpieczeństwa ma na celu zidentyfikowanie luk i błędów w konfiguracji, które mogą prowadzić do wycieku danych osobowych, modyfikacji wrażliwych informacji lub naruszenia dostępności usług.
Podczas prac, które zwykle trwają od 1 do 2 miesięcy, audytorzy powtarzają działania potencjalnych oszustów i szukają luk w klienckiej i serwerowej części wybranego serwisu. W kontekście audytu platformy chmurowej MCS określono następujące cele:
- Analiza uwierzytelniania w serwisie. Luki w tym komponencie mogłyby umożliwić natychmiastowy dostęp do cudzych kont.
- Badanie modelu ról i podziału dostępu między różnymi kontami. Dla oszusta możliwość uzyskania dostępu do cudzego wirtualnego systemu – to pożądany cel.
- Luki w części klienckiej. XSS/CSRF/CRLF/itd. Czy istnieje możliwość atakowania innych użytkowników za pośrednictwem złośliwych linków?
- Luki w części serwerowej: RCE i różnego rodzaju wstrzyknięcia (SQL/XXE/SSRF itd.). Luki serwerowe są zazwyczaj trudniejsze do znalezienia, ale prowadzą do kompromitacji wielu użytkowników jednocześnie.
- Analiza izolacji segmentów użytkowników na poziomie sieci. Dla oszusta brak izolacji znacznie zwiększa powierzchnię ataku na innych użytkowników.
- Analiza logiki biznesowej. Czy można oszukać biznes i tworzyć wirtualne maszyny za darmo?
W tym projekcie prace były prowadzone w modelu „Gray-box”: audytorzy interagowali z serwisem z uprawnieniami zwykłych użytkowników, ale częściowo mieli dostęp do kodu źródłowego API i mogli zadawać pytania programistom. Zwykle jest to model pracy najwygodniejszy, ale jednocześnie realistyczny: wewnętrzne informacje mogą być zbierane przez oszustów, to tylko kwestia czasu.
Znalezione luki
Zanim audytor zacznie wysyłać różne ładunki (payloady), które są wykorzystywane do ataku, należy zrozumieć, jak działa dany system i jaki jest jego funkcjonalność. Może się wydawać, że jest to bezcelowe zajęcie, ponieważ w większości zbadanych miejsc nie będzie żadnych luk. Jednak tylko zrozumienie struktury aplikacji i logiki jej działania pozwala odnaleźć najtrudniejsze wektory ataków.
Ważne jest znalezienie miejsc, które wydają się podejrzane lub znacznie różnią się od innych. A pierwsza niebezpieczna luka została znaleziona właśnie w ten sposób.
IDOR
Luki IDOR (Insecure Direct Object Reference, niebezpieczne bezpośrednie odwołania do obiektów) są jednymi z najczęstszych rodzajów luk w logice biznesowej, które w różny sposób umożliwiają dostęp do obiektów, do których faktyczny dostęp nie jest dozwolony. Luki IDOR stwarzają możliwość uzyskania informacji o użytkownikach o różnym stopniu krytyczności.
Jednym z wariantów IDOR jest wykonywanie działań na obiektach systemu (użytkownikach, kontach bankowych, produktach w koszyku) poprzez manipulacje identyfikatorami dostępu do tych obiektów. Może to prowadzić do najbardziej nieprzewidywalnych konsekwencji. Na przykład do możliwości podmiany konta nadawcy środków, co umożliwia kradzież środków od innych użytkowników.
W przypadku MCS audytorzy rzeczywiście odkryli lukę IDOR związaną z niesekuryzowanymi identyfikatorami. W panelu użytkownika do dostępu do dowolnych obiektów używano identyfikatorów UUID, które wydawały się, jak mówią specjaliści ds. bezpieczeństwa, niewzruszenie odporne na łamanie (to znaczy chronione przed atakiem brute force). Jednak dla pewnych jednostek odkryto, że do uzyskania informacji o użytkownikach aplikacji używane są zwykłe przewidywalne numery. Myślę, że domyślasz się, że można było zmienić ID użytkownika o jeden, ponownie wysłać żądanie i w ten sposób uzyskać informacje omijając ACL (access control list, zasady dostępu do danych dla procesów i użytkowników).
Server Side Request Forgery (SSRF)
Produkty OpenSource są dobre, ponieważ istnieje mnóstwo forów z szczegółowymi opisami problemów technicznych, a jeśli masz szczęście, także z opisami rozwiązań. Ale ta medalu ma swoją odwrotną stronę: równie szczegółowo opisane są znane luki. Na przykład na forum OpenStack znajdziesz świetne opisy luk. i , które jakoś nikt nie kwapi się naprawić.
Częstą funkcjonalnością aplikacji jest możliwość wysłania przez użytkownika na serwer linku, do którego serwer przechodzi (na przykład, aby załadować obrazek z podanego źródła). Przy niewystarczającym filtrowaniu linków lub odpowiedzi zwracanych przez serwer użytkownikom, taką funkcjonalność łatwo wykorzystują przestępcy.
Luki SSRF mogą znacznie przyspieszyć rozwój ataku. Napastnik może uzyskać:
- ograniczony dostęp do atakowanej lokalnej sieci, na przykład tylko do określonych segmentów sieci i według określonego protokołu;
- pełny dostęp do sieci lokalnej, jeśli możliwe jest przejście z poziomu aplikacji na poziom transportowy, a w konsekwencji pełna kontrola nad obciążeniem na poziomie aplikacji;
- dostęp do odczytu lokalnych plików na serwerze (jeśli obsługiwana jest schemat file://);
- i wiele więcej.
W OpenStack od dawna znana jest luka SSRF o „ślepym” charakterze: przy próbie kontaktu z serwerem nie otrzymujesz od niego odpowiedzi, ale zamiast tego uzyskujesz różne typy błędów/opóźnień w zależności od wyniku zapytania. Na tej podstawie można przeprowadzić skanowanie portów na hostach w wewnętrznej sieci, z wszystkimi wynikającymi konsekwencjami, których nie należy lekceważyć. Na przykład produkt może mieć API dla back-office'u dostępne tylko z sieci korporacyjnej. Dysponując dokumentacją (nie zapominajmy o osobach z wewnątrz), napastnik może za pomocą SSRF zgłosić się do wewnętrznych metod. Na przykład, jeśli uda się w jakiś sposób uzyskać przybliżoną listę użytecznych URL, to dzięki SSRF można po nich przejść i wykonać zapytanie — mówiąc w uproszczeniu, przelać pieniądze z konta na konto lub zmienić limity.
To nie pierwszy przypadek wykrycia luki SSRF w OpenStack. W przeszłości istniała możliwość ładowania obrazów ISO maszyn wirtualnych z bezpośrednim linkiem, co również prowadziło do podobnych konsekwencji. Na chwilę obecną ta funkcja została usunięta z OpenStack. Wygląda na to, że społeczność uznała to za najprostsze i najbezpieczniejsze rozwiązanie problemu.
A w W publicznie dostępnym raporcie z serwisu HackerOne (h1) wykorzystanie już nie „ślepej” SSRF z możliwością odczytu metadanych instancji prowadzi do uzyskania dostępu root do całej infrastruktury Shopify.
W MCS w dwóch miejscach o podobnej funkcjonalności wykryto luki SSRF, ale ich praktyczne wykorzystanie było prawie niemożliwe z powodu zapór sieciowych i innych zabezpieczeń. Tak czy inaczej, zespół MCS i tak poprawił ten problem, nie czekając na społeczność.
XSS zamiast ładowania „shelly”
Pomimo setek napisanych badań, rok po roku XSS (atak typu cross-site scripting) wciąż jest luką w sieci (lub ?).
Ładowanie plików to ulubione miejsce każdego badacza bezpieczeństwa. Często można załadować dowolny skrypt (asp/jsp/php) i wykonać polecenia systemu operacyjnego, w terminologii pentesterów mówiąc — „załadować shell”. Jednak popularność takich luk działa w obie strony: pamiętają o nich i opracowują środki przeciwdziałające, więc w ostatnim czasie prawdopodobieństwo "załadowania shell" dąży do zera.
Zespół atakujący (w osobie Digital Security) miał szczęście. OK, w MCS po stronie serwera sprawdzano zawartość przesyłanych plików, dozwolone były tylko obrazy. Ale SVG to także obraz. Jakie potencjalne zagrożenia mogą stwarzać obrazy SVG? To, że można w nich osadzać fragmenty JavaScript!
Okazało się, że przesyłane pliki są dostępne dla wszystkich użytkowników usługi MCS — co oznacza, że można zaatakować innych użytkowników chmury, a dokładniej — administratorów.
Przykład wstrzyknięcia przez atak XSS formularza phishingowego logowania.
Przykłady wykorzystania ataku XSS:
- Po co próbować ukraść sesję (zwłaszcza, że obecnie wszędzie są pliki cookie HTTP-Only, chronione przed kradzieżą za pomocą skryptów js), skoro załadowany skrypt może od razu zwracać się do API zasobu? W takim przypadku ładunek użyteczny może za pomocą zapytań XHR zmienić konfigurację serwera, np. dodać otwarty klucz SSH przestępcy i uzyskać dostęp SSH do serwera.
- Jeśli polityka CSP (polityka ochrony treści) zabrania wstrzykiwania JavaScript, przestępca może obejść się bez niego. Stworzyć fikcyjny formularz logowania na czystym HTML i wykradać hasło administratora za pomocą tak zaawansowanego phishingu: strona phishingowa dla użytkownika pojawia się pod tym samym URL, co utrudnia jej wykrycie przez użytkownika.
- W końcu przestępca może zorganizować — ustawić pliki cookie większe niż 4 KB. Użytkownik wystarczy, że raz otworzy link — a cała strona staje się niedostępna, dopóki nie zrozumie, aby specjalnie wyczyścić przeglądarkę: w zdecydowanej większości przypadków serwer WWW odmówi przyjęcia takiego klienta.
Rozważmy przykład jeszcze jednego wykrytego XSS, tym razem z bardziej wyrafinowanym wykorzystaniem. Usługa MCS pozwala na łączenie ustawień zapory ogniowej w grupy. XSS została odkryta w nazwie grupy. Jej szczególną cechą było to, że wektor aktywował się nie od razu, nie podczas przeglądania listy reguł, ale podczas usuwania grupy:
Scenariusz wyglądał następująco: przestępca tworzył regułę zapory z „obciążeniem” w nazwie, a administrator po pewnym czasie ją dostrzega, inicjując proces usunięcia. I właśnie w tym momencie złośliwy JS zaczyna działać.
Dla programistów MCS, aby chronić się przed XSS w przesyłanych obrazach SVG (jeśli nie można się ich pozbyć), zespół Digital Security zalecił:
- Umieszczenie plików przesyłanych przez użytkowników na oddzielnej domenie, która nie ma nic wspólnego z „ciasteczkami”. Skrypt będzie wykonywany w kontekście innej domeny i nie będzie stanowił zagrożenia dla MCS.
- W odpowiedzi HTTP serwera należy ustawić nagłówek „Content-disposition: attachment”. Pliki będą wtedy pobierane przez przeglądarkę, a nie wykonywane.
Ponadto dostępnych jest wiele sposobów łagodzenia ryzyk wykorzystywania XSS:
- za pomocą flagi „HTTP Only” można uczynić nagłówki sesji „Cookies” niedostępnymi dla złośliwego JavaScript;
- znacznie utrudni wykorzystywanie XSS przez przestępcę;
- nowoczesne silniki szablonów, takie jak Angular czy React, automatycznie oczyszczają dane użytkowników przed ich wystawieniem w przeglądarce użytkownika.
Luki w podwójnej autoryzacji
Aby zwiększyć bezpieczeństwo kont, użytkownikom zawsze zaleca się włączenie 2FA (podwójnej autoryzacji). Rzeczywiście jest to skuteczny sposób na uniemożliwienie przestępcom uzyskania dostępu do usługi, jeśli dane logowania użytkownika zostały skompromitowane.
Ale czy zawsze korzystanie z drugiego czynnika autoryzacji gwarantuje bezpieczeństwo konta? W implementacji 2FA mogą występować następujące problemy z bezpieczeństwem:
- Brute force OTP (jednorazowych kodów). Pomimo prostoty wykorzystania, takie błędy, jak brak ochrony przed brute force OTP, występują także w dużych firmach: , .
- Słaby algorytm generowania, na przykład możliwość przewidzenia następnego kodu.
- Błędy logiczne, na przykład możliwość zażądania kodu OTP należącego do innej osoby na swoim telefonie, jak to miało miejsce w Shopify.
W przypadku MCS 2FA jest realizowana w oparciu o Google Authenticator i . Sam protokół został już zweryfikowany w czasie, ale warto sprawdzić implementację weryfikacji kodu po stronie aplikacji.
W MCS 2FA jest używane w kilku miejscach:
- Podczas uwierzytelniania użytkownika. Tutaj zastosowano ochronę przed zgadywaniem: użytkownik ma tylko kilka prób wprowadzenia jednorazowego hasła, po czym wprowadzenie jest blokowane na pewien czas. Blokuje to możliwość przeprowadzenia ataku brute-force na OTP.
- Podczas generowania offline'owych kodów zapasowych w celu realizacji 2FA oraz ich wyłączenia. W tym przypadku ochrona przed zgadywaniem nie została wdrożona, co umożliwiało, przy posiadaniu hasła do konta i aktywnej sesji, ponowne generowanie kodów zapasowych lub całkowite wyłączenie 2FA.
Biorąc pod uwagę, że kody zapasowe mieściły się w tym samym zakresie wartości co wygenerowane aplikacją OTP, szansa na zgadnięcie kodu w krótkim czasie była znacznie wyższa.
Proces zgadywania OTP w celu wyłączenia 2FA za pomocą narzędzia „Burp: Intruder”.
Wynik
Ogólnie rzecz biorąc, MCS jako produkt okazał się bezpieczny. W trakcie audytu zespołowi pentesterów nie udało się uzyskać dostępu do klientowskich VM i ich danych, a znalezione podatności zostały szybko naprawione przez zespół MCS.
Warto jednak zauważyć, że bezpieczeństwo to ciągła praca. Usługi nie są statyczne, nieustannie się rozwijają. Opracowanie produktu całkowicie wolnego od podatności jest niemożliwe. Jednak można je na czas wykrywać i minimalizować szansę ich powtórzenia.
Obecnie wszystkie wymienione podatności w MCS zostały już naprawione. Aby zminimalizować liczbę nowych i skrócić ich czas istnienia, zespół platformy kontynuuje to:
- regularne przeprowadzanie audytów przez zewnętrzne firmy;
- wsparcie i rozwijanie udziału;
- dbanie o bezpieczeństwo. 🙂
Źródło: habr.com
