Jaka piękna katastrofa! W tej historii jest wszystko: infekcja nie jednego, a dwóch niezbyt roztropnych pracowników różnych “technicznych” firm. Przeskok z jednej zainfekowanej infrastrukry na drugą, bo żadna z firm nie korzystała z zasady minimalnych przywilejów a można odnieść wrażenie, że w ogóle z żadnych mechanizmów bezpieczeństwa. I wreszcie grupa atakujących, która kradnie tożsamość innej grupie oraz plujący jadem internetowi przeciwnicy vibecodingu, którzy z widłami poszli na firmę, bo przecież wiadomo, że “każdy programista AI to debil”. A okazało się, że AI nie miało z tym atakiem niczego wspólnego.Od czego się zaczęło?19 kwietnia na znanym hackerskim forum pojawiła się informacja o tym, że popularna wśród vibecoderów platforma Vercel została zhackowana. Atakujący podpisujący się jako ShinyHunters wystawili na sprzedaż klucze i dostępy do bazy danych firmy. Zrobiło się gorąco w środowisku, bo Vercel stoi też za narzędziem v0 oraz popularną biblioteką Next.js, a to od razu przywołało ostatnie głośne ataki supply chain.Na początku oczywiście spekulowano, że przełamanie zabezpieczeń to wynik użycia beztroskiego vibecodingu do budowy i konfiguracji mechanizmów bezpieczeństwa Vercela. Bo firma z vibecodingiem jest kojarzona. Ale prawda okazała jeszcze bardziej bolesna. Źródłem ataku był łańcuch dwóch pracowników. Pierwszy to pracownik zewnętrznej firmy — Contex.ai, który pobierał …cheaty do gry Roblox zainfekowane infostealerem Lumma. Dzięki temu atakujący mieli dostęp do infrastruktury firmy Contex.ai oraz danych jej klientów. Dwa miesiące temu 17 lutego. Poniżej widok tego, co infostealer wystawiał z jego hosta:Drugi to pracownik Vercela, który korzystał z narzędzi Contex.ai, ale zalogował się do nich ze swojego służbowego konta Google Workspace, dając im poprzez OAuth pełne uprawnienia (“allow all”) do środowiska Vercela.Infekcja pierwszego pracownika dała atakującym dostęp do jego uprawnień w różnych usługach (Supabase, Datadog, Authkit) oraz do skrzynki support@contex.ai, dzięki której udało się im “zpivotować” do infrastruktury Vercela. Żadnego przejęcia hasła. Żadnego phishingu. Żadnego exploita. Kurtyna. Jeśli nie chcesz, by jeden nieostrożny pracownik albo błędnie skonfigurowane środowisko pracy rozłożyło Twoją firmę na łopatki, to zapisz swój zespół na nasze szkolenie z bezpieczeństwa dla programistów lub administratorów! Pokazujemy na takim szkoleniu w praktyce, jakich błędów uniknąć, żeby nie znaleźć się na czołówkach gazet i nie musieć wysyłać zgłoszeń do RODO oraz listów z frazą “bezpieczeństwo jest dla nas najważniejsze, ale…” do Klientów ;)Żeby było weselej, grupa ShinyHunters stwierdziła na swoim kanale na Telegramie, że ktoś się pod nich podszywa (zapewne aby podnieść wiarygodność swojego ogłoszenia) a oni żadnych dostępów do Vercela nie sprzedają. Jak sprawdzić, czy nie macie takich pracowników u siebie w firmie?Jeśli korzystacie z Google Workspace, sprawdźcie czy też przypadkiem nie macie “zbyt szerokich dostępów” wpiętych po OAuth do swojej infrastruktury. W tym celu zaloguj się do panelu Google Admin Console i wejdź w sekcję Security. A potem Access and Data Control -> API Controls -> Manage app access -> Accessed Apps. Tu widać wszystkie aplikacje mające dostęp do Waszego środowiska. Warto sprawdzić, czy nie ma wśród nich dokładnie tej, która “zhackowała” Vercela. Aby to zrobić, wystarczy przefiltrować listę po ID aplikacji: "110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent[.]com"Jeśli zobaczysz tę aplikację na liście — oznacza to, że Twój firmowy Workspace może mieć nieproszonych gości. Należy niezwłocznie usunąć dostępy, rozpocząć procedurę analizy logów audytowych i zrotować adekwatne tokeny i hasła.Może warto też na przyszłość ograniczyć możliwość uwierzytelniania się po OAuth niektórym pracownikom/aplikacjom? Jest więcej niż pewne, że Wasi współpracownicy korzystają z kont służbowych do logowania się w usługach firm trzecich, zostawiając tam tokeny, które mogą dać komuś dostęp do Waszej infrastruktury… Nie mówiąc już o naruszeniach umów o poufność i wysyłaniu danych osobowych poza EOG. Jeśli zarządzasz IT w jakiejś firmie, warto to (i nie tylko to) ryzyko zaadresować jak najszybciej, a my możemy w tym pomóc. Jeśli nie wiesz od czego zacząć albo jak poprawnie ułożyć cyberbezpieczeństwo w firmie od zera, daj nam znać — pomożemy!A jeśli korzystasz z Vercela, to dobrym pomysłem będzie rotacja wszystkich sekretów, “sensitive variables” i rozważenie korzystania z zewnętrznych Secret Managerów na przyszłość. Vercel informuje klientówW sieci pojawiła się wypowiedź CEO Vercela z opisem ich ustaleń. Są też gorzkie słowa ze strony Contex.ai:Vercel is not a Context customer, but it appears that at least one employee enabled “allow all” on all requested Google Workspace permissions using their Vercel Google Workspace account. These permissions were intended to grant AI agents the ability to perform Google Workspace actions such as writing emails or creating documents on the grantee’s behalf.Nie zwalajcie winy na AI (w tym przypadku)Opisywany incydent idealnie wpisuje się w to, co omawialiśmy niedawno w artykule pt. To nie AI jest największym zagrożeniem. Mimo że w nagłówkach portali królują dziś przerażające hasła o “śmiercionośnych skutkach korzystania z AI”, to tu wektorem ataku był błąd pracownika (dlatego warto ich edukować pod kątem dobrych praktyk cyberbezpieczeństwa) — zaniedbanie, połączone z trywialnym złośliwym oprogramowaniem i brakiem egzekwowania reguły najmniejszych uprawnień (Least Privilege) oraz detekcji tego typu infekcji i braku kontrolowania “shadow IT / shadow AI”. Narzędzia bazujące na sztucznej inteligencji, z których coraz częściej korzystają firmy działają “w chmurze” dokładnie tak, jak nieejajowe konta usługowe. I tak samo jak w przypadku wszystkich innych usług firm trzecich, bezwzględnie wymagają pełnej kontroli, audytu logów i zasady ograniczonego zaufania. Tu odsyłany do naszego cyklu poświęconego budowie SOC, który takie nadużycia pomaga wychwytywać.