Nowe obejście App-Bound Encryption w Google Chrome pozwala kraść cookies i tokeny sesyjne - Security Bez Tabu

Nowe obejście App-Bound Encryption w Google Chrome pozwala kraść cookies i tokeny sesyjne

Cybersecurity news

Wprowadzenie do problemu / definicja

Mechanizm App-Bound Encryption (ABE) został wprowadzony przez Google po to, aby utrudnić złośliwemu oprogramowaniu kradzież wrażliwych danych przechowywanych przez przeglądarkę Chrome, takich jak ciasteczka sesyjne, zapisane hasła czy tokeny uwierzytelniające. Kluczowa idea tego rozwiązania polega na powiązaniu procesu odszyfrowania danych z samą aplikacją przeglądarki, a nie wyłącznie z kontem użytkownika zalogowanego do systemu Windows.

Najnowsze obserwacje pokazują jednak, że cyberprzestępcy potrafią ominąć tę ochronę bez klasycznego łamania kryptografii. Zamiast atakować sam algorytm, wykorzystują moment, w którym przeglądarka musi odsłonić chronione dane lub materiał kryptograficzny w pamięci operacyjnej, aby normalnie z nich skorzystać.

W skrócie

Nowa technika została powiązana z rodziną malware VoidStealer i dotyczy Chrome oraz innych przeglądarek opartych na Chromium. Obejście polega na przechwyceniu klucza szyfrującego lub jego użytecznej reprezentacji z pamięci procesu w chwili, gdy przeglądarka odszyfrowuje dane chronione przez ABE.

  • Atak nie wymaga klasycznej eskalacji uprawnień do poziomu systemowego.
  • Wykorzystywany jest legalny mechanizm debugowania procesów.
  • Celem są cookies, hasła, tokeny i inne artefakty sesyjne.
  • Ryzyko dotyczy zarówno użytkowników indywidualnych, jak i środowisk firmowych.

Kontekst / historia

W systemie Windows przez lata ochrona danych przeglądarki opierała się głównie na mechanizmach takich jak DPAPI. Rozwiązanie to dobrze zabezpieczało dane zapisane na dysku, ale miało ograniczoną skuteczność wobec malware działającego w kontekście legalnie zalogowanego użytkownika. W praktyce infostealery mogły często odczytywać cenne dane bez potrzeby przełamywania zaawansowanych barier kryptograficznych.

Google wdrożył ABE jako próbę ograniczenia tego problemu. Założenie było proste: nawet jeśli napastnik działa na koncie użytkownika, nie powinien łatwo odszyfrować danych przeglądarki poza zaufanym procesem Chrome. Z czasem okazało się jednak, że atakujący i badacze bezpieczeństwa znajdują kolejne sposoby na obchodzenie tego modelu ochrony.

Wcześniejsze analizy opisywały metody oparte na uruchamianiu bezplikowym, process hollowing, bezpośrednich wywołaniach systemowych czy podszywaniu się pod legalną aktywność przeglądarki. Najnowsze obejście pokazuje kolejny etap ewolucji tych technik: skupienie się na bardzo krótkim oknie czasowym, w którym sekret musi zostać ujawniony w pamięci procesu.

Analiza techniczna

Istota problemu wynika z ograniczeń praktycznej ochrony sekretów „w użyciu”. Dane mogą być poprawnie zabezpieczone na dysku, lecz w chwili, gdy aplikacja musi z nich skorzystać, muszą zostać odszyfrowane do postaci użytecznej. To właśnie ten moment staje się celem ataku.

W opisywanym scenariuszu malware przyłącza się do procesu przeglądarki jako debugger. Nie jest to egzotyczna funkcja systemowa, lecz legalny i powszechnie stosowany mechanizm wykorzystywany przez programistów oraz analityków. Dzięki temu atak może wyglądać mniej podejrzanie niż klasyczne techniki iniekcji kodu lub agresywnej eskalacji uprawnień.

Następnie złośliwe oprogramowanie identyfikuje właściwy moment wykonania, w którym Chrome odszyfrowuje dane chronione przez ABE. Gdy materiał kryptograficzny pojawia się w pamięci w formie możliwej do dalszego wykorzystania, proces zostaje zatrzymany, a pamięć przechwycona. W efekcie napastnik nie łamie samego mechanizmu szyfrowania, lecz wykorzystuje fakt, że przeglądarka musi czasowo „odsłonić” sekret, aby działać zgodnie ze swoim przeznaczeniem.

To rozróżnienie ma duże znaczenie. Nie mamy tu do czynienia z klasycznym złamaniem kryptografii, ale z nadużyciem momentu operacyjnego, w którym bezpieczeństwo ustępuje funkcjonalności. Tego typu ataki coraz częściej pojawiają się tam, gdzie systemy dobrze chronią dane „w spoczynku”, lecz mają ograniczone możliwości obrony przed przechwyceniem sekretów z pamięci procesu.

Konsekwencje / ryzyko

Najpoważniejszą konsekwencją takiego obejścia jest możliwość kradzieży aktywnych artefaktów uwierzytelniających. W praktyce oznacza to, że napastnik może przejąć sesję użytkownika bez znajomości hasła, a w części przypadków również ominąć część zabezpieczeń wieloskładnikowych, jeśli uwierzytelnienie zostało już wcześniej zakończone sukcesem.

Problem ma szczególne znaczenie dla organizacji korzystających intensywnie z usług SaaS, paneli administracyjnych, poczty firmowej, narzędzi DevOps i środowisk chmurowych. W takich warunkach przeglądarka staje się centralnym punktem dostępu do kluczowych zasobów. Przechwycenie cookies lub tokenów może więc prowadzić nie tylko do kompromitacji jednego konta, ale także do dalszego ruchu lateralnego i eskalacji incydentu.

Dodatkowym wyzwaniem po stronie obrońców jest fakt, że atak nadużywa legalnego mechanizmu debugowania. Sama obecność działań związanych z debuggerem nie musi oznaczać aktywności złośliwej. Znaczenia nabiera więc analiza kontekstu: które procesy inicjują attach do przeglądarki, na jakich stacjach roboczych, o jakiej porze i czy zachowanie to odpowiada normalnemu profilowi pracy użytkownika.

Rekomendacje

Organizacje powinny traktować przeglądarki internetowe jako zasób wysokiego ryzyka, porównywalny z klientami poczty, narzędziami zdalnego dostępu czy aplikacjami obsługującymi poświadczenia. Sama ochrona danych zapisanych w przeglądarce nie jest wystarczająca, jeśli przeciwnik potrafi przechwycić je w pamięci podczas użycia.

  • Wdrożyć monitoring EDR/XDR pod kątem nietypowego debugowania procesów Chrome i innych przeglądarek Chromium.
  • Ograniczyć możliwość uruchamiania niezatwierdzonego oprogramowania poprzez allowlisting i kontrolę skryptów.
  • Minimalizować przechowywanie haseł bezpośrednio w przeglądarce.
  • Stosować dedykowane menedżery haseł klasy enterprise.
  • Skracać czas życia sesji i tokenów tam, gdzie jest to możliwe.
  • Tworzyć reguły detekcji skupione na kradzieży cookies i tokenów, a nie wyłącznie na dumpingu poświadczeń systemowych.
  • Po wykryciu infekcji szybko unieważniać sesje, resetować poświadczenia i rotować tokeny dostępu.

W praktyce warto również ograniczać lokalne uprawnienia administracyjne, blokować zbędne narzędzia developerskie na stacjach roboczych użytkowników biznesowych oraz monitorować dostęp do pamięci procesów obsługujących dane uwierzytelniające. Ochrona przeglądarki powinna stać się integralnym elementem strategii bezpieczeństwa tożsamości i dostępu.

Podsumowanie

Nowa technika obejścia App-Bound Encryption pokazuje, że nawet dobrze zaprojektowane zabezpieczenia przeglądarki mają naturalną słabość w momencie operacyjnego użycia sekretów. VoidStealer nie tyle łamie samą kryptografię, ile wykorzystuje chwilę, w której Chrome musi ujawnić materiał kryptograficzny lub dane sesyjne w pamięci.

Dla zespołów bezpieczeństwa to wyraźny sygnał, że obrona nie może kończyć się na szyfrowaniu danych zapisanych na dysku. Kluczowe stają się monitoring procesu przeglądarki, wykrywanie nadużyć debugowania, ograniczanie wartości przechowywanych sesji oraz szybka reakcja na oznaki działania infostealerów.

Źródła

  1. https://www.darkreading.com/endpoint-security/yet-another-way-bypass-google-chromes-encryption-protection
  2. https://security.googleblog.com/2024/07/improving-security-of-chrome-cookies-on-windows.html
  3. https://www.kaspersky.com/blog/chrome-app-bound-encryption-how-it-works/52614/
  4. https://www.cyberark.com/resources/threat-research-blog/c4-bomb-blowing-up-chromes-appbound-cookie-encryption/
  5. https://github.com/xaitax/Chrome-App-Bound-Encryption-Decryption