Suchmaschinen wurden entwickelt, um Inhalte zu indexieren. Angreifer nutzen sie jedoch, um Ihre Fehler zu indexieren. Die Suchanfrage alltext:login Dateityp: Protokoll Es mag harmlos erscheinen. In Wirklichkeit ist es eine der einfachsten Methoden, um offengelegte Protokolldateien aufzuspüren, die Authentifizierungsabläufe, Anmeldeinformationen, Token und interne Infrastrukturdaten enthalten.
Wenn Google diese Protokolle einsehen kann, können Angreifer das auch. Sobald sie indexiert sind, ist eine Offenlegung unausweichlich. Erscheinen Zugangsdaten in einer öffentlich zugänglichen Datei, ist der Angriff bereits im Gange.
1. Warum allintext?login filetype:log ist gefährlicher als es aussieht.
Ein Google Dork ist eine Suchanfrage, die mithilfe erweiterter Operatoren sensible oder fehlerhaft konfigurierte Inhalte findet, die von Suchmaschinen indexiert werden. Er nutzt nicht Google aus, sondern Ihre eigene Sicherheit.
Diese Abfrage kombiniert zwei Operatoren:
- alltext: Gibt Seiten zurück, auf denen alle Begriffe im Fließtext vorkommen
- Dateityp: Protokoll beschränkt die Ergebnisse auf
.logDateien
Daher gilt:
allintext:login filetype:log
Bedeutet: "Zeige mir Protokolldateien, die das Wort enthalten login"
Auf den ersten Blick erscheint das trivial. In der Praxis kehrt es jedoch häufig zurück:
- Öffentlich zugängliche Webserver-Protokolle
- CI/CD Protokolle wurden als Artefakte hochgeladen
- versehentlich Debug-Protokolle commitan Repositories übertragen
- Anwendungsprotokolle mit Klartext-Anmeldeinformationen
Dies ist kein Fehler der Suchmaschine. Stattdessen handelt es sich um einen Schwachstelle im Zusammenhang mit Datenoffenlegung Verursacht durch eine Fehlkonfiguration. Google hat einfach nur das indexiert, was öffentlich zugänglich war.
2. Was Angreifer tatsächlich in offengelegten Protokolldateien finden
Wenn Angreifer fliehen alltext:login Dateityp: ProtokollSie surfen nicht wahllos. Sie suchen nach Authentifizierungsspuren.
2.1 Klartext-Anmeldeinformationen
Protokolle enthalten häufig Einträge wie:
POST /login username=admin password=SuperSecret123or
Authorization: Basic YWRtaW46cGFzc3dvcmQ=
Oder sogar SMTP-Zugangsdaten:
smtp_user=mailer
smtp_pass=ProdMailPass!Das Protokollieren von Authentifizierungsdaten ist eine der schnellsten Methoden, um Zugangsdaten für den Produktivbetrieb preiszugeben. Folglich kann eine einzige offengelegte Protokolldatei Ihr gesamtes Zugriffskontrollmodell ungültig machen.
2.2 Sitzungstoken und JWTs
Auch wenn Passwörter nicht protokolliert werden, werden Tokens häufig protokolliert.
Beispielsweise:
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Set-Cookie: session=abc123xyz789;
Generated API token: sk_live_ABC123SECRETEin gültiges JWT oder Session-Cookie innerhalb eines .log Datei kann Folgendes aktivieren:
- Hijacking-Sitzung
- Eskalation von Berechtigungen
- Seitliche Bewegung innerhalb interner Systeme
Mit anderen Worten: Tokens in Protokolldateien verwandeln Debugging-Ausgaben in einen Vektor zur Umgehung der Authentifizierung.
2.3 CI/CD Artifacts
Bauprotokolle sind besonders gefährlich. Tatsächlich CI/CD Systeme geben häufig während der Build-Schritte Umgebungsvariablen aus.
Angreifer entdecken häufig:
Enthält Zeilen wie:
AWS_ACCESS_KEY_ID=AKIA...
DATABASE_URL=postgres://admin:password@internal-db:5432/appIf CI/CD Wenn Artefakte öffentlich sind, sind auch Geheimnisse öffentlich. Die Google-Suche beschleunigt lediglich die Auffindung.
2.4 Cloud- und Infrastrukturdaten
Offengelegte Protokolle enthüllen oft:
- AWS-Zugriffsschlüssel
- Azure-Speicherverbindungszeichenfolgen
- Interne Service-URLs
- Datenbankanmeldeinformationen
- Redis-Endpunkte
Selbst wenn die Zugangsdaten später geändert werden, besitzt der Angreifer nun Folgendes:
- Infrastrukturkartierung
- Regeln der Namensgebung
- Zielinformationen für zukünftige Angriffe
Daher ermöglichen offengelegte Protokolle sowohl den Zugriff als auch die Aufklärung.
3. Wie diese Protokolle überhaupt erst öffentlich werden
Protokolldateien erscheinen nicht einfach so bei Google. Sie werden indexiert, weil sie öffentlich zugänglich waren.
3.1 Fehlkonfigurierte Webserver
Zu den gängigen Mustern gehören:
/logs/Verzeichnisse, auf die ohne Authentifizierung zugegriffen werden kann- Verzeichnisauflistung aktiviert
- Nginx oder Apache, die Rohdaten ausliefern
.logDateien
Wenn ein Log über HTTP erreichbar ist, ist es indexierbar.
3.2 CI/CD Artefaktenthüllung
Typische Fehler:
- Öffentliche Artefakte aktiviert in GitHub-Aktionen
- Protokolle wurden in offene S3-Buckets hochgeladen
- Pipeline Spuren, die ohne Authentifizierung zugänglich sind
A pipeline Wer Protokolle in einem öffentlichen Datenspeicher ablegt, gibt seine Geheimnisse faktisch preis.
3.3 Debug-Modus in der Produktion
Die Standardeinstellungen von Frameworks können gefährlich sein:
APP_DEBUG=trueDarüber hinaus kann die Protokollierung übermäßiger Anfragen Folgendes ausgeben:
- Headers
- Tokens
- Vollständige Anfragekörper
Die Debug-Protokollierung in der Produktionsumgebung verwandelt Ihre Anwendung in einen Anmeldeinformationsexporteur.
3.4 Docker- und Containerprotokolle
Containerisierte Umgebungen eröffnen neue Angriffswege:
- Protokolle in gemeinsam genutzte Volumes eingebunden
- Sidecars exportieren Protokolle an ungesicherte Endpunkte
- Log dashboards mit öffentlichem Zugang
Wenn Containerprotokolle über HTTP oder Open Storage zugänglich gemacht werden, sind sie durchsuchbar. Letztendlich werden sie indexiert.
4. Realistischer Angriffsablauf: Vom Anfänger zum Angreifer
Eine typische Angriffskette sieht folgendermaßen aus:
Angreifer läuft:
allintext:login filetype:log- Aufgedeckte Funde
.logDatei - Auszüge:
- JWT-Token
- Basic-Auth-Header
- Datenbankverbindungszeichenfolge
Authentifizierungsversuche gegen:
- API-Endpunkte
- Admin-Panels
- Interne Dienste
Wenn die Authentifizierung erfolgreich ist, kann der Angreifer:
- Privilegien eskalieren
- Seitlich bewegen
- Zugriff CI/CD
- Die Lieferkette gefährden
Was als Suchanfrage begann, wird zu Folgendem:
- Hijacking-Sitzung
- Internes Credential Stuffing
- Pipeline Übernahme
- Artefaktvergiftung
Alles aus einer öffentlich indizierten Protokolldatei.
5. Warum übermäßiges Protokollieren ein Problem der Anwendungssicherheit darstellt
Protokollierung ist nicht neutral. Stattdessen erzeugt sie eine sekundärer Datenspeicher.
Wenn Sie sensible Daten protokollieren, erstellen Sie effektiv eine zweite Kopie Ihrer Geheimnisse.
Protokolle werden jedoch häufig von der Bedrohungsmodellierung ausgeschlossen. Unter STRIDE entspricht dies eindeutig Folgendem:
Offenlegungsinformationen
Daher: Sicher SDLC Unternehmen sollten Protokolle wie folgt behandeln:
- Sicherheitsrelevante Artefakte
- Sensible Vermögenswerte
- Infrastrukturkomponenten, die Schutz benötigen
Wenn Ihr Bedrohungsmodell Protokolle ignoriert, ist es unvollständig.
6. Wie man das Auslesen von Anmeldeinformationen in Protokolldateien verhindert
6.1 Protokollierung von Geheimnissen einstellen
Niemals protokollieren:
- Passwörter
- Tokens
- API-Schlüssel
- Sitzungs-IDs
- Autorisierungsheader
Selbst im Debug-Modus.
Wann immer möglich, sollte eine automatische Schwärzung implementiert werden.
6.2 Strukturierte und sichere Protokollierung
Verwenden Sie strukturierte Protokollierung mit Maskierung und Filterung.
Beispiel (Node.js):
const logger = require('pino')({
redact: ['req.headers.authorization', 'body.password']
});Beispiel (Python):
class RedactFilter(logging.Filter):
def filter(self, record):
record.msg = record.msg.replace("password=", "password=***")
return TrueDas Grundprinzip ist einfach: Geheimnisse dürfen niemals in den Log-Senken gelangen.
6.3 Holzlagerung sichern
Die Sicherheitskontrollen sollten Folgendes umfassen:
- Verzeichnisauflistung deaktivieren
- Schützen
/logs/Pfade mit Authentifizierung - Bucket-Zugriff einschränken
- Aufbewahrungsrichtlinien anwenden
- Protokolle im Ruhezustand verschlüsseln
Protokolle dürfen niemals öffentlich über HTTP erreichbar sein.
6.4 CI/CD Guardrails
Manuelle Überprüfungen reichen nicht aus. Implementieren Sie stattdessen automatisierte Kontrollen:
- Geheime Überprüfung der Protokolle vor der Veröffentlichung der Artefakte
- Builds schlagen fehl, wenn Tokens erkannt werden
- Verhindern Sie das Hochladen von Artefakten, die Anmeldeinformationen enthalten.
- Hash-Validierung für Artefakte
CI/CD Die Offenlegung sollte vor der Indizierung verhindert werden.
7. Wie Xygeni den All-in-Text-Effekt verhindert:login Dateityp: Protokoll Vorfälle
Das Problem ist nicht der Google-Dork. Das Problem ist die Sichtbarkeit. Daher muss Prävention vor der Indexierung erfolgen.
7.1 Geheimniserkennung in Protokollen und Artefakten
Xygeni-Scans:
- Anwendungsprotokolle
- CI/CD Job-Traces
- Artefakte erstellen
- Docker-Schichten
- Serialisierte Ausgaben
Wenn Anmeldeinformationen, Token oder sensible Werte in .log Dateien werden von Xygeni sofort als solche markiert.
7.2 CI/CD Guardrails Diese Blockbelichtung
Statt sich auf manuelle Überprüfungen zu verlassen, Xygeni gewährleistet die Sicherheit am pipeline Niveau:
dotnet xygeni enforce --rules secrets,artifacts,logs --fail-on-riskDies:
- Der Build-Vorgang schlägt fehl, wenn Geheimnisse in den Protokollen auftauchen.
- Veröffentlichung von Blockartefakten
- Verhindert versehentliche öffentliche Präsentation
- Verhindert unsichere Zusammenführungen, bevor diese den Hauptzweig erreichen.
Wenn ein CI-Job ein Token ausgibt, pipeline fehlschlägt.
Keine Indizierung.
Keine Exposition.
Kein Zwischenfall.
7.3 Shift-Left-Schutz, bevor Google ihn erkennt
Auf das Timing kommt es an.
Statt zu reagieren auf:
allintext:login filetype:logXygeni löst das Problem:
- At commit Zeit
- pull request Validierungsprüfungen
- pipeline Ausführung
- Vor der Veröffentlichung des Artefakts
Wenn das Protokoll nie öffentlich wird, wird es von Google auch nie indexiert.
Fazit: Wenn Google es indexieren kann, haben Angreifer es bereits getan.
Protokolldateien sind nicht harmlos. Tatsächlich sind sie selten temporär. Standardmäßig sind sie nicht privat. Daher sollte jede Protokolldatei als sicherheitsrelevantes Gut und nicht nur als Debugging-Ausgabe behandelt werden.
Wenn sensible Daten in die Hände eines .log Datei und wird öffentlich zugänglich, Sie verwandelt sich sofort in eine Angriffsfläche. Darüber hinaus skaliert die Reichweite, sobald sie von einer Suchmaschine indexiert wurde, außerhalb Ihrer Kontrolle.
Die Lösung besteht nicht darin, die Protokollierung einzustellen. Vielmehr geht es darum, verantwortungsvoll zu protokollieren und strenge Kontrollen für Speicherung und Verteilung durchzusetzen. Anders ausgedrückt: Sicherheit muss über die Anwendung selbst hinaus bis in die Überwachungsschicht reichen.
Stattdessen:
- Hört auf, Geheimnisse zu protokollieren.
- Holzlager absperren
- Erzwingen pipeline guardrails
- Automatisierte Erkennung und Richtliniendurchsetzung
Letztlich, Prävention ist eine Frage des richtigen Zeitpunkts. Denn sobald alltext:login Dateityp: Protokoll Wenn Ihre Domain zurückkehrt, hat der Vorfall bereits begonnen.
