Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Nowa kampania przypisywana grupie ShinyHunters pokazuje, że w środowiskach SaaS zagrożeniem nie musi być wyłącznie podatność typu zero-day. W praktyce równie groźne bywają błędne konfiguracje kontroli dostępu, szczególnie w publicznie wystawionych portalach opartych o Salesforce Experience Cloud. W tym przypadku wektor ataku koncentruje się na nieautoryzowanym odpytywaniu interfejsów Aura przez profile gościnne z nadmiernymi uprawnieniami.
W skrócie
Salesforce potwierdził kampanię wymierzoną w klientów korzystających z Experience Cloud. Według producenta atakujący nie wykorzystują luki w samej platformie, lecz zmodyfikowaną wersję narzędzia Aura Inspector do masowego skanowania publicznych witryn i sprawdzania, czy anonimowy użytkownik może pobierać dane przez endpointy Aura.
Jeżeli profil gościa ma zbyt szerokie uprawnienia, możliwe staje się odczytywanie obiektów CRM bez logowania. Pozyskane informacje mogą następnie posłużyć do dalszych operacji socjotechnicznych, vishingu lub szantażu związanego z wyciekiem danych.
Kontekst / historia
ShinyHunters od dłuższego czasu pojawia się w kontekście kampanii ukierunkowanych na dane przechowywane w usługach chmurowych i aplikacjach biznesowych. W omawianym scenariuszu grupa twierdzi, że kompromitacje środowisk z niebezpieczną konfiguracją dostępu w Experience Cloud prowadzi od września 2025 roku, a od stycznia 2026 roku zaczęła wykorzystywać zmodyfikowaną wersję narzędzia Aura Inspector.
Istotne jest to, że sam producent platformy podkreśla brak dowodów na eksploatację podatności w rdzeniu Salesforce. Oznacza to, że problem leży po stronie ekspozycji danych przez niewłaściwie skonfigurowane mechanizmy dostępu dla użytkowników niezalogowanych. To klasyczny przykład sytuacji, w której bezpieczne domyślne założenia platformy mogą zostać osłabione przez wyjątki biznesowe, zbyt szerokie udostępnianie rekordów albo błędy implementacyjne w komponentach i kontrolerach.
Analiza techniczna
Techniczny przebieg kampanii można sprowadzić do kilku etapów. Najpierw operatorzy identyfikują publicznie dostępne witryny Experience Cloud. Następnie sondują endpoint /s/sfsites/aura, czyli interfejs wykorzystywany przez framework Aura do komunikacji aplikacji z backendem. Celem jest ustalenie, czy anonimowy kontekst użytkownika może wykonywać zapytania do obiektów i metod, które nie powinny być dostępne bez uwierzytelnienia.
Jeżeli konfiguracja profilu gościa jest zbyt liberalna, atakujący mogą odpytywać obiekty CRM i pozyskiwać dane bez zakładania sesji użytkownika. Według opisu incydentu szczególnie narażone są środowiska, w których:
- rekordy zostały nadmiernie udostępnione użytkownikowi gościnnemu,
- dostęp przez API dla użytkowników niezalogowanych nie został odpowiednio ograniczony,
- możliwa jest enumeracja użytkowników wewnętrznych,
- pozostawiono aktywną funkcję samorejestracji mimo braku potrzeby biznesowej.
Z perspektywy architektury bezpieczeństwa kluczowe jest rozróżnienie między podatnością a nadużyciem funkcjonalności. Aura Inspector został opublikowany jako narzędzie defensywne do audytu błędnych konfiguracji w środowiskach opartych o Aura. Jednak po modyfikacji może zostać użyty ofensywnie do automatycznego wykrywania źle zabezpieczonych instancji na dużą skalę. Tego typu narzędzia podwójnego zastosowania stają się coraz większym problemem, ponieważ przyspieszają zarówno pracę administratorów, jak i rozpoznanie po stronie napastnika.
Dodatkowym ryzykiem są niuanse modelu bezpieczeństwa Salesforce. Dokumentacja producenta wskazuje, że dostęp gościnny oraz komponenty Aura i Lightning wymagają ścisłego egzekwowania zasad CRUD, FLS oraz reguł sharing. W przeciwnym razie kod lub konfiguracja mogą ujawnić dane, które w interfejsie użytkownika wydają się ograniczone. Szczególnie niebezpieczne są scenariusze, w których logika aplikacyjna działa szerzej niż wynika to z oczekiwanego modelu uprawnień.
Konsekwencje / ryzyko
Najbardziej bezpośrednią konsekwencją jest wyciek danych z publicznie dostępnych portali. Według dostępnych informacji często chodzi o informacje takie jak imiona, nazwiska i numery telefonów, ale praktyczny zakres ekspozycji zależy od konkretnej konfiguracji obiektów, pól i reguł udostępniania.
Ryzyko biznesowe wykracza jednak poza sam odczyt danych:
- skradzione dane mogą wspierać ukierunkowany phishing i vishing,
- możliwa jest dalsza eskalacja przez rozpoznanie użytkowników oraz procesów biznesowych,
- organizacja może zostać objęta próbą wymuszenia okupu pod groźbą publikacji danych,
- incydent może uruchomić obowiązki regulacyjne związane z naruszeniem ochrony danych osobowych,
- publiczne portale Experience Cloud mogą stać się trwałym punktem ekspozycji, jeśli konfiguracja nie zostanie skorygowana globalnie.
Z punktu widzenia obrońcy szczególnie niepokojące jest to, że atak nie wymaga klasycznego przełamania zabezpieczeń konta. W wielu przypadkach wystarcza wykorzystanie anonimowego dostępu, który miał służyć wygodzie użytkowników lub realizacji określonego procesu biznesowego.
Rekomendacje
Organizacje korzystające z Salesforce Experience Cloud powinny potraktować ten scenariusz jako pilny przegląd konfiguracji ekspozycji danych. Priorytetem powinny być następujące działania operacyjne:
- przeprowadzenie audytu wszystkich publicznie dostępnych witryn Experience Cloud,
- weryfikacja uprawnień profilu gościa zgodnie z zasadą najmniejszych uprawnień,
- ograniczenie dostępu wyłącznie do rekordów jawnie i świadomie udostępnionych,
- wyłączenie publicznych zapytań API tam, gdzie nie są niezbędne,
- zablokowanie możliwości enumeracji użytkowników wewnętrznych,
- wyłączenie samorejestracji, jeśli nie jest wymagana przez proces biznesowy,
- przegląd komponentów Aura i Apex pod kątem poprawnego egzekwowania CRUD, FLS i reguł sharing,
- analiza logów monitoringu zdarzeń Aura pod kątem nietypowych zapytań, skoków ruchu z nieznanych adresów IP i aktywności poza standardowymi godzinami,
- uruchomienie procesu threat hunting dla publicznych endpointów i historycznego dostępu anonimowego,
- przygotowanie procedury eskalacji do wsparcia producenta w przypadku podejrzenia naruszenia.
W praktyce warto też potraktować wszystkie funkcje dostępne dla użytkowników niezalogowanych jako strefę podwyższonego ryzyka. Każdy wyjątek od domyślnego modelu ograniczeń powinien być uzasadniony biznesowo, udokumentowany i regularnie testowany. Dobrą praktyką jest również okresowe wykorzystanie narzędzi audytowych do wykrywania nadmiernych uprawnień jeszcze przed tym, zanim zrobią to napastnicy.
Podsumowanie
Kampania przypisywana ShinyHunters przeciwko środowiskom Salesforce Experience Cloud podkreśla znaczenie bezpiecznej konfiguracji dostępu anonimowego. Według dostępnych informacji nie chodzi o nową lukę w platformie, lecz o masowe wykorzystywanie źle skonfigurowanych uprawnień użytkowników gościnnych i endpointów Aura. To sprawia, że obrona zależy przede wszystkim od higieny konfiguracji, audytu ekspozycji danych oraz monitorowania nietypowej aktywności w publicznych portalach.
Dla zespołów bezpieczeństwa jest to wyraźny sygnał, że błędne ustawienia w SaaS mogą być równie niebezpieczne jak klasyczne podatności aplikacyjne.
Źródła
- Help Net Security — https://www.helpnetsecurity.com/2026/03/11/shinyhunters-salesforce-aura-data-breach/
- Salesforce Developers — Allow Guest Access — https://developer.salesforce.com/docs/platform/lightning-component-reference/guide/ltng-allow-guest-access.html
- Salesforce Developers — Secure Apex Classes — https://developer.salesforce.com/docs/platform/lwc/guide/apex-security
- Salesforce Developers — Guest User Security Restrictions — https://developer.salesforce.com/docs/industries/cme/guide/comms-guest-user-security-restrictions.html