City-Forum: Sådan har en enkelt server stjålet data fra Salesforce og ServiceNow i 17 måneder uden at udnytte en sårbarhed

Sådan fungerer udnyttelsen: Ingen sårbarhed påkrævet

Både Salesforce og ServiceNow leveres med permanente gæstebrugerkonti til uautentificerede besøgende. Disse gæstebrugere kan ikke slettes. Deres tilladelser – hvilke data og objekter de må læse – konfigureres af den enkelte organisation. Hvis gæsteprofilen har læseadgang til en post, kan alle på internettet hente den via helt legitime API-endepunkter.

På Salesforce (Aura-rammeværket):

• Værktøjet sender POST-anmodninger til /aura eller /s/sfsites/aura-endepunktet.
• Det kalder først HostConfigController.getConfigData for at finde ud af, hvilke objekter (Account, Contact, Case, Lead, User, ContentDocument osv.) der er tilgængelige for gæsten.
• Derefter bruger det SelectableListDataProviderController.getItems til at bladre igennem alle poster på hvert tilgængeligt objekt.
• Det mest aktive enkelte mål loggede over 560.000 hændelser fra angriberens IP, næsten udelukkende gæste-Aura-enumeration.

På Salesforce (LWR – Lightning Web Runtime):

• Dette er første gang, man i virkeligheden har set udnyttelse af Salesforce UI-API-gæsteoverfladen på LWR-sites.
• Værktøjet angriber et GraphQL-endepunkt på

  POST /webruntime/api/services/data/{version}/graphql?asGuest=true

  , først ved at kortlægge skemaet via EntityDefinition og derefter læse poster med cursor-baseret paginering.
• Det scanner API-versionerne v56.0 til v66.0 i rækkefølge mod hvert opdaget LWR-site.

På ServiceNow:

• Værktøjet angriber endepunktet /api/now/sp/search – en indbygget Service Portal-søge-API, der er stort set udokumenteret og næsten ikke har nogen online dokumentation eller open source-værktøjer, der refererer til den.
• Dette endepunkt er offentligt af design. Hvilke data det returnerer, afhænger helt af, hvilke søgekilder der er tilknyttet en gæsteportal, og om disse kilder håndhæver adgangskontrol.

Selvregistreringstest (Salesforce):

• Værktøjet tilføjer /SiteRegister og /CommunitiesSelfReg til alle opdagede experience site-stier for at teste, om selvregistrering er aktiveret. Hvis det er, kan en gæst opgradere sig selv til en autentificeret ekstern bruger og få adgang til langt flere data.

Det tilpassede værktøjssæt og infrastrukturen

• Kilde-IP: 158.220.87.79, hostet på en Contabo VPS (tysk hostingudbyder), som peger på domænet city-forum.com (et domæne registreret i 2002, forladt og derefter genbrugt).
• Den samme IP har haft det samme domæne siden marts 2025 uden rotation – mindst 17 måneder på én adresse.
• Tilpasset Go-binær: Et enkelt Go-kompileret værktøj, der angriber Salesforce via både Aura- og LWR-rammeværkerne og samtidig angriber ServiceNow – alt sammen fra den samme server. Dette er et tilpasset tværplatformsværktøjssæt, ikke et standardværktøj som AuraInspector.
• Værktøjet bruger Go's standard Go-http-client User-Agent-streng, hvilket gør det let at identificere i logfiler.

Målorganisationer

Reco rapporterer, at de primære mål omfatter:

• Teleselskaber
• Banker og finansielle virksomheder
• Softwareleverandører (herunder sikkerheds- og databeskyttelsesvirksomheder)
• Offentlige portaler

Hvorfor standardrevisionslogge ikke kan afsløre, hvilke data der blev stjålet

For ServiceNow: Platformens transaktionslogge (syslog_transaction) registrerer ikke POST-brødteksten i /api/now/sp/search-anmodninger. Forsvarere kan se, at automatiserede søgninger fandt sted, og hvor mange data der blev returneret (via output-længde-kolonnen), men kan ikke fastslå de præcise søgetermer eller hvilke specifikke poster, der blev hentet.

For Salesforce: Gæsteenumerations-trafikken består af legitime, protokol-kompatible API-kald, der ligner normal sitetrafik. Selvom Event Monitoring kan vise mængden af AuraRequest- og Sites-hændelser fra gæstebrugere, viser loggene, at data blev anmodet, men ikke det specifikke indhold af, hvad der blev returneret i GraphQL- eller Aura-svarene.

Med andre ord: Du kan se, at angriberen var der, og hvor meget de hentede, men du kan ikke rekonstruere præcis, hvilke poster eller felter de udtog.

Anbefalede afhjælpningstrin

For Salesforce (Reco-anbefalinger):

1. Stram delingsregler for gæster – den enkeltstående kontrol med størst effekt. Fjern alle delingsregler, der deler poster med gæstebrugeren ud over, hvad sitet reelt har brug for at vise offentligt.
2. Fjern objekt- og felttilladelser fra gæsteprofilen. Fjern læseadgang til objekter, som sitet ikke har brug for til anonyme besøgende.
3. Fjern tilladelsen "Access Activities" fra gæsteprofilen (blotter opgaver og begivenheder).
4. Deaktiver "API Enabled" på gæstebrugeren.
5. Deaktiver selvregistrering, medmindre sitet reelt kræver det.
6. Deaktiver gæsteadgang til filer og medlemssynlighed, så gæster ikke kan hente ContentDocument-filer eller liste andre medlemmer af sitet.
7. For LWR-sites kun: I Experience Builder → Workspaces → Administration → Preferences, fjern fluebenet ved "Allow guest users to access public APIs." Dette lukker GraphQL og UI-API REST-endepunkterne på én gang.

For ServiceNow (Reco-anbefalinger):

1. Kortlæg gæsteportaler til deres søgekilder. Tjek tabellerne sp_portal, m2m_sp_portal_search_source og sp_search_source. Fjern alle søgekilder, som en offentlig portal ikke har brug for.
2. Gennemgå hver søgekildes logik – især is_scripted_source, data_fetch_script, og om den bruger GlideRecordSecure (ACL-håndhævende) vs. almindelig GlideRecord (som ikke er det).
3. Gennemgå vidensbasens "Kan læse"-brugerkriterier – se efter ubegrænset "Enhver bruger"-adgang, der blotter følsomme vidensbaser gennem gæstesøgning.
4. Fjern dårlige kb_uc_can_read_mtom-links i stedet for at redigere delingsregler blindt.

Detektionsvejledning:

• Salesforce Event Monitoring: Se efter store mængder af getItems og getConfigData fra

  USER_TYPE = 'Guest'

  , /webruntime/.../vNN.0/graphql-versionsscanninger og hits på /SiteRegister og /CommunitiesSelfReg.
• ServiceNow syslog_transaction: Se efter /api/now/sp/search-anmodninger udført som gæst. Sortér efter output-længde – rækker, der returnerer markant mere end den lille baseline for tomme resultater, indikerer søgninger, der returnerede indhold.