City-Forum: Wie ein einzelner Server 17 Monate lang Daten aus Salesforce und ServiceNow abgriff – ganz ohne Sicherheitslücke

Seit mindestens 17 Monaten zapft ein unbekannter Angreifer weltweit Daten aus Salesforce Experience Cloud- und ServiceNow-Portalen ab – ohne eine einzige Sicherheitslücke auszunutzen, ohne gestohlene Zugangsdaten und ohne Authentifizierung zu umgehen. Der Angreifer nutzt lediglich das, was Unternehmen über die integrierten Gastzugänge (anonymer Zugriff) der Plattformen bereits öffentlich gemacht haben.

Die Sicherheitsfirma Reco hat diese anhaltende Kampagne nach der Domain city-forum.com benannt, die zur Infrastruktur des Angreifers gehört. Seit mindestens März 2025 sammelt ein einzelner gemieteter Server in Deutschland systematisch Daten von Telekommunikationsanbietern, Banken, Finanzdienstleistern, Unternehmenssoftware-Anbietern und öffentlichen Portalen.

Wie die Ausnutzung funktioniert: Keine Sicherheitslücke nötig

Sowohl Salesforce als auch ServiceNow verfügen über dauerhafte Gastbenutzerkonten für nicht authentifizierte Besucher. Diese Gastbenutzer können nicht gelöscht werden. Ihre Berechtigungen – welche Datensätze und Objekte sie lesen dürfen – werden von jeder Organisation konfiguriert. Wenn das Gastprofil Lesezugriff auf einen Datensatz hat, kann jeder im Internet ihn über völlig legitime API-Endpunkte abrufen.

Bei Salesforce (Aura-Framework):

• Das Tool sendet POST-Anfragen an den Endpunkt /aura oder /s/sfsites/aura.
• Es ruft zunächst HostConfigController.getConfigData auf, um aufzulisten, welche Objekte (Account, Contact, Case, Lead, User, ContentDocument usw.) für den Gast zugänglich sind.
• Anschließend verwendet es SelectableListDataProviderController.getItems, um seitenweise alle Datensätze jedes zugänglichen Objekts durchzugehen.
• Ein einzelnes stark betroffenes Ziel verzeichnete über 560.000 Ereignisse von der IP des Angreifers, fast ausschließlich Gast-Aufzählung über Aura.

Bei Salesforce (LWR-Framework – Lightning Web Runtime):

• Dies ist die erste im echten Einsatz beobachtete Ausnutzung der UI-API-Gastoberfläche von Salesforce auf LWR-Websites.
• Das Tool zielt auf einen GraphQL-Endpunkt unter

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

  , indem es zunächst das Schema über EntityDefinition auflistet und dann Datensätze mit cursor-basierter Seitenaufteilung ausliest.
• Es durchläuft nacheinander die API-Versionen v56.0 bis v66.0 gegen jede entdeckte LWR-Website.

Bei ServiceNow:

• Das Tool zielt auf den Endpunkt /api/now/sp/search – eine native Service Portal-Such-API, die weitgehend undokumentiert ist und für die es kaum Online-Dokumentation oder Open-Source-Tools gibt.
• Dieser Endpunkt ist von Haus aus öffentlich. Welche Daten er zurückgibt, hängt vollständig davon ab, welche Suchquellen an ein gastorientiertes Portal angebunden sind und ob diese Quellen Zugriffskontrollen durchsetzen.

Testen der Selbstregistrierung (Salesforce):

• Das Tool hängt /SiteRegister und /CommunitiesSelfReg an jeden entdeckten Experience Site-Pfad an, um zu testen, ob die Selbstregistrierung aktiviert ist. Ist dies der Fall, kann sich ein Gast zu einem authentifizierten externen Benutzer hochstufen und so auf weitaus mehr Daten zugreifen.

Das benutzerdefinierte Werkzeug und die Infrastruktur

• Quell-IP: 158.220.87.79, gehostet auf einem Contabo VPS (deutscher Hosting-Anbieter), aufgelöst zur Domain city-forum.com (eine 2002 registrierte, dann aufgegebene und wieder zweckentfremdete Domain).
• Dieselbe IP trägt seit März 2025 dieselbe Domain ohne Rotation – mindestens 17 Monate auf einer einzigen Adresse.
• Benutzerdefinierte Go-Binärdatei: Ein einzelnes in Go kompiliertes Tool, das Salesforce sowohl über Aura- als auch über LWR-Frameworks und gleichzeitig ServiceNow angreift – alles vom selben Server. Dies ist ein benutzerdefinierter Multiplattform-Werkzeugsatz, kein Standard-Tool wie AuraInspector.
• Das Tool verwendet den standardmäßigen Go-http-client-User-Agent, was es leicht in Protokollen identifizierbar macht.

Betroffene Organisationen

Reco berichtet, dass die Hauptziele umfassen:

• Telekommunikationsbetreiber
• Banken und Finanzdienstleister
• Unternehmenssoftware-Anbieter (einschließlich Sicherheits- und Datenschutzunternehmen)
• Öffentliche Portale

Warum Standard-Prüfprotokolle nicht zeigen können, welche Daten abgeflossen sind

Für ServiceNow: Die Transaktionsprotokolle der Plattform (syslog_transaction) zeichnen den POST-Body von /api/now/sp/search-Anfragen nicht auf. Verteidiger können sehen, dass automatisierte Suchen stattfanden und wie viele Daten zurückgegeben wurden (über die Spalte Ausgabelänge), aber nicht die genauen Suchbegriffe oder welche spezifischen Datensätze abgerufen wurden.

Für Salesforce: Der Gast-Aufzählungsverkehr besteht aus legitimen, protokollkonformen API-Aufrufen, die wie normaler Seitenverkehr aussehen. Während Ereignisüberwachung das Volumen von AuraRequest- und Sites-Ereignissen von Gastbenutzern anzeigen kann, zeigen die Protokolle, dass Daten angefordert wurden, aber nicht den spezifischen Inhalt dessen, was in den GraphQL- oder Aura-Antworten zurückgegeben wurde.

Mit anderen Worten: Man kann sehen, dass der Angreifer da war und wie viel er abgezogen hat, aber man kann nicht genau rekonstruieren, welche Datensätze oder Felder extrahiert wurden.

Empfohlene Abhilfemaßnahmen

Für Salesforce (Empfehlungen von Reco):

1. Gast-Freigaberegeln verschärfen – die wirksamste Kontrolle mit der größten Hebelwirkung. Entfernen Sie alle Freigaberegeln, die Datensätze für den Gastbenutzer über das hinaus freigeben, was die Site öffentlich bereitstellen muss.
2. Objekt- und Feldberechtigungen aus dem Gastprofil entfernen. Entfernen Sie den Lesezugriff auf Objekte, die die Site nicht für anonyme Besucher benötigt.
3. Die Berechtigung „Access Activities" aus dem Gastprofil entfernen (macht Tasks und Events sichtbar).
4. „API Enabled" für den Gastbenutzer deaktivieren.
5. Selbstregistrierung deaktivieren, es sei denn, die Site benötigt sie wirklich.
6. Gast-Dateizugriff und Mitgliedersichtbarkeit deaktivieren, sodass Gäste keine ContentDocument-Dateien abrufen oder andere Site-Mitglieder auflisten können.
7. Nur für LWR-Sites: Im Experience Builder → Arbeitsbereiche → Verwaltung → Einstellungen die Option „Allow guest users to access public APIs" deaktivieren. Dies schließt GraphQL und die UI-API-REST-Endpunkte in einem Schritt.

Für ServiceNow (Empfehlungen von Reco):

1. Gastorientierte Portale ihren Suchquellen zuordnen. Überprüfen Sie die Tabellen sp_portal, m2m_sp_portal_search_source und sp_search_source. Trennen Sie jede Suchquelle, die ein öffentliches Portal nicht benötigt.
2. Die Logik jeder Suchquelle überprüfen – insbesondere is_scripted_source, data_fetch_script und ob sie GlideRecordSecure (ACL-erzwingend) oder einfaches GlideRecord (das dies nicht tut) verwendet.
3. Die Wissensdatenbank-Kriterien „Can Read" für Benutzer überprüfen – achten Sie auf uneingeschränkten „Any User"-Zugriff, der sensible Wissensdatenbanken über die Gästesuche offenlegt.
4. Fehlerhafte kb_uc_can_read_mtom-Verknüpfungen trennen, anstatt blind Freigaberegeln zu bearbeiten.

Erkennungshinweise:

• Salesforce-Ereignisüberwachung: Achten Sie auf hohe Volumina von getItems und getConfigData von

  USER_TYPE = 'Guest'

  , Version-Sweeps von /webruntime/.../vNN.0/graphql und Treffer auf /SiteRegister und /CommunitiesSelfReg.
• ServiceNow syslog_transaction: Achten Sie auf /api/now/sp/search-Anfragen, die als Gast getätigt werden. Sortieren Sie nach Ausgabelänge – Zeilen, die deutlich mehr als die kleine leere Ergebnis-Baseline zurückgeben, deuten auf Suchen hin, die Inhalt zurückgegeben haben.