Jak włamano się do Ubera i dlaczego najwyraźniej nie było to trudne

dodał 16 września 2022 o 12:20 w kategorii Info, Włamania  z tagami:
Jak włamano się do Ubera i dlaczego najwyraźniej nie było to trudne

W ostatnich godzinach doszło do poważnego ataku na infrastrukturę Ubera. Włamywacz uzyskał szeroki dostęp do wewnętrznych narzędzi firmy i jej środowisk chmurowych, po czym… ogłosił to w internecie. Kto mógł stać za atakiem i dlaczego tak dobrze mu poszło?

Poranny przegląd Twittera przyniósł dzisiaj ciekawe wpisy. Ktoś zaczął publikować zrzuty ekranu wskazujące na to, że ma dostęp administracyjny do środowisk chmurowych AWS i Google Cloud firmy Uber. Uber szybko potwierdził, że walczy z incydentem, tymczasem pojawiło się sporo informacji na temat przebiegu i zakresu samego włamania. Opiszmy zatem, jak do niego doszło.

Inżynieria społeczna zawsze w modzie.

Etap pierwszy – wejście

Użytkownik Twittera o nicku @hacker_ opublikował zrzut ekranu z rozmowy z włamywaczem, z którym skontaktował się przez Telegrama.

Z tej rozmowy wynika, że pierwszym etapem ataku było zalogowanie się na konto pracownika firmy. Jak do tego doszło? Jeśli historie analogicznych incydentów mogą być tutaj jakąś wskazówką, to zapewne przez phishing lub zakup ciasteczek uwierzytelniających. W tym pierwszym wypadku dodatkowym krokiem było nakłonienie pracownika, by pomógł w pokonaniu dwuskładnikowego uwierzytelnienia (Uber podobno korzysta z rozwiązań Duo), w drugim można było otrzymać „gotowy” dostęp.

Aktualizacja: wygląda na to, że użyto wariantu pierwszego, czyli spamu MFA zmuszającego użytkownika do akceptacji.

Etap drugi – podnoszenie uprawnień

Etap drugi to dostęp do infrastruktury firmy przez VPN-a i skanowanie sieci wewnętrznej. Tu robi się ciekawie, bo według włamywacza pozwoliło to na zlokalizowanie udziału sieciowego, w którym znajdowały się skrypty PowerShella. W skryptach z kolei włamywacz podobno znalazł dane uwierzytelniające administratora rozwiązania firmy Thycotic do zarządzania dostępem uprzywilejowanym – czyli de facto klucze do królestwa.

Rozwiązania klasy PAM służą do bezpiecznego (o ironio) przechowywania danych uwierzytelniających do kont uprzywilejowanych. Włamywacz znalazł dzięki temu dostępy do środowisk AWS, Google Cloud, Onelogin, DUO czy Active Directory. Na dowód tych twierdzeń można znaleźć wiele różnych zrzutów ekranu. Zobaczmy zatem, gdzie buszował włamywacz i co przeskrobał.

Etap trzeci – buszowanie

Włamywacz ogłosił włamania na firmowym Slacku Ubera. Pracownicy potraktowali to jako żart.

Włamywacz przejął konto Ubera w programie bug bounty HackerOne i wysłał komunikat do jego uczestników.

Włamywacz przejął kontrolę nad:

vSphere

Google Workplace

(zajęty nieco ponad 1 petabajt)

AWS

Slackiem

konsolą SentinelOne (system monitorowania i eliminowania zagrożeń…)

systemem rozliczania służbowych wydatków

Etap czwarty – szybki finisz

Uber nie jest przypadkową firmą bez działu bezpieczeństwa – wygląda na to, że incydent został szybko zidentyfikowany i zatrzymany, pracownicy zostali odcięci od wielu systemów, a włamywacz wyrzucony z sieci. Całość zdarzenia prawdopodobnie zamknęła się w kilku godzinach. To jednak stawia zupełnie nowe wyzwania przed zespołami bezpieczeństwa. W przypadku „tradycyjnych” napastników ich celem do tej pory było utrzymanie dostępu i zbieranie informacji. Wykrycie takiego ataku w ciągu kilku godzin i jego zatrzymanie było dużym sukcesem obrońców.

Gdy jednak napastnik jest szybki, zwinny i pożądający sławy, okazuje się, że kilka godzin to bardzo dużo czasu, by utracić reputację i wpakować się w problemy, także z regulatorem, o kosztach obsługi incydentu nie wspominając (pomyślcie, co trzeba sprawdzić w firmie tej skali po kilku godzinach wizyty kogoś, kto miał dostęp DO WSZYSTKIEGO). Ostatnio widzimy coraz więcej podobnych ataków – słuchacze podcastu ADAM 13:37 zapewne kojarzą ataki LAPSUS$-a czy niedawne problemy Okty i kilkudziesięciu innych firm. Pozostaje zastanowić się, czy wasza firma może być celem podobnego ataku i czy jest nań przygotowana.