Klienci wypowiadają się na temat reakcji Okty na najnowsze naruszenie

Firmy zajmujące się bezpieczeństwem cybernetycznym Poza zaufaniem I Cloudflare skrytykowali specjalistę ds. zarządzania tożsamością i dostępem (IAM). Okta po tym, jak obaj zostali usidleni w kolejnym cyberataku na systemy tego ostatniego.

– stwierdził BeyondTrust wykrył atak skoncentrowany na tożsamości na wewnętrzne konto administratora Okta w dniu 2 października 2023 r., w którym wykorzystano ważny plik cookie sesji skradziony Okta. Stwierdziła, że ​​jej własne systemy były w stanie odciąć napastnika, zanim nastąpiło jakiekolwiek uderzenie, dodała jednak, że reakcja dostawcy nie była trafna.

„2 października 2023 r. agent wsparcia Okta poprosił administratora BeyondTrust Okta o wygenerowanie pliku HAR w celu pomocy w rozwiązaniu bieżącego problemu wsparcia, nad którym pracował administrator. Pliki HAR to archiwa HTTP, które mogą być generowane przez przeglądarkę internetową w celu rejestrowania interakcji ze stroną internetową, w tym przypadku używanych do debugowania problemu z witryną” – powiedział BeyondTrust.

„Administrator spełnił żądanie i wygenerował plik HAR zawierający żądanie API i plik cookie sesji, który został przesłany do portalu wsparcia Okta.

„W ciągu 30 minut od przesłania pliku przez administratora do portalu pomocy technicznej Okta osoba atakująca wykorzystała plik cookie sesji z tego zgłoszenia pomocy technicznej, próbując wykonać działania w środowisku BeyondTrust Okta.”

BeyondTrust stwierdziło, że zablokowały je własne zasady dostępu do konsoli administracyjnej, po czym ugrupowanie zagrażające próbowało przejść na korzystanie z działań administracyjnego interfejsu API, co umożliwiło mu utworzenie konta użytkownika backdoora. Teraz zaalarmowana o tej aktywności firma BeyondTrust była w stanie szybko stłumić tę sytuację, zanim intruz zdążył przedostać się dalej. Stwierdził, że nie widzi dowodów na inną nieregularną aktywność innych uprzywilejowanych użytkowników Okta. Dodała, że ​​próba najwyraźniej miała miejsce z adresu IP w Malezji, o którym wiadomo, że jest powiązany z usługami VPN/anonimizującymi proxy.

Stwierdziła, że ​​chociaż jej początkowa reakcja na incydent wyraźnie wskazywała na kompromis ze strony agenta obsługi klienta Okta lub osoby mogącej uzyskać dostęp do danych obsługi klienta, to jednak nie otrzymała żadnego potwierdzenia w ramach swojego początkowego podejścia i musiała podejmować kolejne próby eskalacji do 19 października, 17 dni później, gdy Okta powiadomiła ją, że została dotknięta naruszeniem.

Rozmawiamy z siostrzanym tytułem Computer Weekly Bezpieczeństwo TechTargetdyrektor techniczny BeyondTrust, Marc Maiffret, ubolewał nad powolną reakcją Okty, którą częściowo przypisał rozpraszaniu zespołów firmy przez konferencji użytkowników Oktane w USAi powiedział, że miał trudności z przekonaniem dostawcy, że ponownie doszło do naruszenia bezpieczeństwa.

„Na początku nie mieliśmy wrażenia, że ​​uznali za prawdopodobne, że to mogą być oni. Chciałbym, żeby od początku byli bardziej otwarci na ten pomysł. Prowadziłem ostatnią rozmowę z nimi, zanim zadzwonili i poinformowali nas, że coś się stało. Dręczyło mnie to, bo zacząłem czuć się trochę jak szaleniec, jakby coś nam umknęło” – powiedział.

W rozmowie z redakcją TechTarget Maiffret stwierdził również, że w dziennikach obsługi klienta, o przejrzenie których poprosił Oktę, wystąpiły rozbieżności, co jeszcze bardziej nadszarpnęło jego pewność siebie.

Tymczasem Cloudflareodkrył, że został zaatakowany 18 października tą samą metodą. Stwierdził, że wykrył konto 24 godziny przed poinformowaniem go przez Oktę, ale jego własna architektura zerowego zaufania zapobiegła jakimkolwiek dalszym skutkom.

Powołując się na doświadczenie BeyondTrust, Cloudflare wezwała swojego dostawcę do rozważenia podjęcia kroków w celu wzmocnienia swoich praktyk w zakresie bezpieczeństwa wewnętrznego.

„Wzywamy Oktę do rozważenia wdrożenia następujących najlepszych praktyk, w tym takich jak poważne traktowanie wszelkich zgłoszeń naruszeń i natychmiastowe podjęcie działań w celu ograniczenia szkód – w tym przypadku Okta została po raz pierwszy powiadomiona 2 października 2023 r. przez BeyondTrust, ale osoba atakująca nadal miała dostęp do swoje systemy wsparcia przynajmniej do 18 października” – napisano w poście na blogu.

Cloudflare stwierdziło, że Okta powinna również: „Dostarczać swoim klientom w odpowiednim czasie odpowiedzialne informacje, gdy zidentyfikujesz, że dotknęło ich naruszenie Twoich systemów; [and] wymagają kluczy sprzętowych do ochrony wszystkich systemów, w tym zewnętrznych dostawców pomocy technicznej.

„Uważamy, że przestrzeganie tych najlepszych praktyk jest najważniejsze dla tak ważnego dostawcy usług bezpieczeństwa, jak Okta” – stwierdził.

Okta CISO David Bradbury powiedział: „Okta Security zidentyfikowała wrogie działanie, które wykorzystywało dostęp do skradzionych danych uwierzytelniających w celu uzyskania dostępu do systemu zarządzania zgłoszeniami pomocy technicznej Okta.

„Aktor atakujący mógł przeglądać pliki przesłane przez niektórych klientów Okta w ramach ostatnich zgłoszeń do pomocy technicznej. Należy zauważyć, że system zarządzania sprawami pomocy technicznej Okta jest odrębny od produkcyjnej usługi Okta, która jest w pełni funkcjonalna i nie ma na nią wpływu. Ponadto incydent ten nie ma wpływu na system zarządzania sprawami Auth0/CIC.

„Takie ataki podkreślają, jak ważne jest zachowanie czujności i wypatrywanie podejrzanych działań” – stwierdził.

Bradbury powiedział, że Okta dodatkowo zaleciła oczyszczenie wszystkich danych uwierzytelniających oraz plików cookie i tokenów sesji w pliku HAR przed jego udostępnieniem.

Komentując najnowszy atak, jaki spotkał klientów Okta, Tyler Reese, Netwrix dyrektor ds. zarządzania produktami powiedział, że ponieważ incydent dotyczył wrażliwych tokenów znajdujących się w posiadaniu Okty, klienci nie mieli rozsądnej możliwości proaktywnego ich unieważnienia, co wymagało dodatkowych środków ochronnych.

„Pierwszy zestaw zabezpieczeń powinien obejmować silne uwierzytelnianie sprzętowe dla kont uprzywilejowanych i działanie z zaufanego systemu. W przypadkach udokumentowanych przez oba Poza zaufaniem I Cloudflarekorzystali ze sprzętowych tokenów FIDO2, które umożliwiały zespołom ds. bezpieczeństwa wykluczenie potencjalnych naruszeń danych uwierzytelniających” – powiedział Reese.

„Drugim zestawem zabezpieczeń powinien być solidny audyt i wykrywanie kont uprzywilejowanych z systemów tożsamości. W jednym z raportów wspomniano, że nawet przy użyciu FIDO2 skompromitowany token może być nadal używany do wykonywania uprzywilejowanych wywołań API. Osoba atakująca próbowała utworzyć konto uprzywilejowane udające konto usługi”.

Reese dodał: „Ogólnie rzecz biorąc, największym wyzwaniem w przypadku ataków na łańcuch dostaw jest nieprzewidywalność: po naruszeniu dostawcy trudno jest przewidzieć, dokąd atakujący skieruje się ze swoimi uprawnieniami. Jeśli jest dostawcą oprogramowania, może chcieć wprowadzić luki w oprogramowaniu. Jeśli jest dostawcą usług finansowych, może chcieć wydobyć dane w celu wymuszenia.

„Najlepsze, co organizacje mogą zrobić, to przyjąć koncepcje podejścia zerowego zaufania, które zachęca do monitorowania, zerowych przywilejów oraz silnej postawy i integralności zasobów cybernetycznych organizacji”.