Cloudflare – firma zajmująca się bezpieczeństwem sieciowym – ujawniła w czwartek, iż „ugrupowanie zagrażające” wykorzystało skradzione dane uwierzytelniające, by uzyskać dostęp do niektórych jej systemów wewnętrznych.
Incydent wykryto 23 listopada, dziewięć dni po tym, jak hakerzy, prawdopodobnie sponsorowani przez państwo, użyli danych uwierzytelniających naruszonych w wyniku hakowania Okty w październiku, aby uzyskać dostęp do wewnętrznego repozytorium wiedzy (wiki) i bazy danych błędów Cloudflare. O ataku na Oktę pisaliśmy tutaj.
Skradzione dane logowania, token dostępu i trzy dane uwierzytelniające konta usług nie uległy rotacji po incydencie w Okcie, co umożliwiło atakującym sondowanie i przeprowadzanie rekonesansu systemów Cloudflare od 14 listopada, jak możemy przeczytać w wyjaśnieniach złożonych przez firmę.
Według Cloudflare atakującym udało się uzyskać dostęp do środowiska AWS, a także Atlassian Jira i Confluence, ale segmentacja sieci uniemożliwiła im dostęp do instancji Okty i pulpitu nawigacyjnego Cloudflare.
Mając dostęp do pakietu Atlassian, ugrupowanie zagrażające zaczęło szukać informacji w sieci Cloudflare, przeszukując wiki pod kątem „takich rzeczy jak dostęp zdalny, dostępy klienta, openconnect, cloudflared i token”. W sumie uzyskano dostęp do 36 biletów Jira i 202 stron wiki.
16 listopada napastnicy utworzyli konto Atlassian, aby uzyskać stały dostęp do środowiska, a cztery dni później wrócili, by sprawdzić, czy przez cały czas go mają.
22 listopada ugrupowanie zainstalowało Sliver Adversary Emulation Framework, uzyskując stały dostęp do serwera Atlassian, który był następnie używany do bocznego przenoszenia. Próbowali również uzyskać dostęp do nieprodukcyjnego serwera konsoli w centrum danych w São Paulo w Brazylii.
Napastnicy przejrzeli 120 repozytoriów kodów i pobrali 76 z nich na serwer Atlassian, ale ich nie eksfiltrowali.
„76 repozytoriów kodu źródłowego zawierało dane związane głównie ze sposobem działania kopii zapasowych, konfiguracją i zarządzaniem sieci globalnej, działaniem tożsamości w Cloudflare, dostępem zdalnym oraz korzystaniem przez nas z Terraform i Kubernetes. Niewielka liczba repozytoriów zawierała zaszyfrowane sekrety, które natychmiast podlegały rotacji, mimo iż same były silnie zaszyfrowane” – zauważa Cloudflare.
Napastnicy wykorzystali konto usługi Smartsheet, aby uzyskać dostęp do pakietu Atlassian Cloudflare, a konto zostało zamknięte 23 listopada, w ciągu 35 minut od wykrycia nieautoryzowanego dostępu. Konto użytkownika utworzone przez atakującego zostało znalezione i dezaktywowane 48 minut później.
Cloudflare twierdzi, iż wdrożyło również reguły zapory sieciowej blokujące znane adresy IP atakujących oraz iż 24 listopada usunięto platformę Sliver Adversary Emulation Framework. „W tym czasie podmiot zagrażający próbował uzyskać dostęp do wielu innych systemów w Cloudflare, ale nie udało mu się to z powodu naszej kontroli dostępu, reguł zapory sieciowej i twardych kluczy bezpieczeństwa wymuszonych przy użyciu naszych własnych narzędzi Zero Trust – twierdzi firma.
Według Cloudflare nie znaleziono żadnych dowodów na to, by hakerzy uzyskali dostęp do globalnej sieci, bazy danych klientów, informacji konfiguracyjnych, centrów danych, kluczy SSL, pracowników wdrożonych przez klientów lub jakichkolwiek innych informacji poza „danymi w pakiecie Atlassian i serwerze, na którym działa firmowy Atlassian”.
24 listopada Cloudflare zleciło także licznym pracownikom technicznym poprawę bezpieczeństwa i sprawdzenie, czy ugrupowanie zagrażające nie może już uzyskać dostępu do systemów firmy.
„Ponadto przez cały czas badaliśmy każdy system, konto i logi, aby upewnić się, iż hakerzy nie mieli stałego dostępu oraz iż w pełni rozumiemy, jakich systemów atak dotyczył i do których aplikacji przestępcy próbowali uzyskać dostęp” – zauważa firma.
Według Cloudflare po incydencie zmieniono ponad 5000 indywidualnych danych uwierzytelniających do produkcji, poddano segregacji blisko 5000 systemów, fizycznie podzielono systemy testowe i pomostowe, a na każdej maszynie w globalnej sieci Cloudflare wykonano ponowny obraz i ponownie uruchomiono.
Sprzęt w centrum danych w São Paulo, mimo iż nie był dostępny, został odesłany do producentów w celu sprawdzenia i wymieniony, chociaż nie wykryto żadnych dowodów na to, by doszło do naruszenia bezpieczeństwa. Cloudflare twierdzi, iż celem ataku było uzyskanie informacji o infrastrukturze firmy, które prawdopodobnie umożliwiłyby zdobycie głębszej pozycji. CrowdStrike przeprowadził osobne dochodzenie w sprawie incydentu, ale nie znalazł żadnych dowodów na dodatkowe naruszenia.
