Søgemaskiner blev bygget til at indeksere indhold. Angribere bruger dem dog til at indeksere dine fejl. Forespørgslen allintext:login filtype:log kan se harmløse ud. I virkeligheden er det en af de enkleste måder at finde eksponerede logfiler, der indeholder godkendelsesflows, legitimationsoplysninger, tokens og interne infrastrukturdata.
Hvis Google kan se disse logfiler, kan angribere også. Når de er indekseret, bliver eksponering uundgåelig. Desuden er bruddet allerede i gang, når legitimationsoplysninger vises i en offentligt tilgængelig fil.
1. Hvorfor allintext:login filetype:log er farligere end det ser ud til
En Google-nørd er en søgeforespørgsel, der bruger avancerede operatorer til at finde følsomt eller forkert konfigureret indhold, der er indekseret af søgemaskiner. Den udnytter ikke Google. I stedet udnytter den din eksponering.
Denne forespørgsel kombinerer to operatorer:
- allintext: returnerer sider, hvor alle termer optræder i brødteksten
- filtype:log begrænser resultaterne til
.logfiler
Derfor:
Betyder: "Vis mig logfiler, der indeholder ordet login".
Ved første øjekast virker det trivielt. Men i praksis vender det ofte tilbage:
- Offentligt eksponerede webserverlogfiler
- CI/CD Logfiler uploadet som artefakter
- Fejlfindingslogfiler ved et uheld committil arkiver
- Applikationslogfiler med klartekstlegitimationsoplysninger
Dette er ikke en søgemaskinefejl. Det er snarere en sårbarhed over for dataeksponering forårsaget af fejlkonfiguration. Google indekserede blot det, der var offentligt tilgængeligt.
2. Hvad angribere rent faktisk finder i eksponerede logfiler
Når angribere løber allintext:login filtype:log, de browser ikke tilfældigt. De leder efter autentificeringsspor.
2.1 Klartekstlegitimationsoplysninger
Logfiler indeholder ofte poster som:
or
Eller endda SMTP-legitimationsoplysninger:
Logføring af godkendelsesdata er en af de hurtigste måder at lække produktionsoplysninger. Derfor kan en enkelt eksponeret logfil ugyldiggøre hele din adgangskontrolmodel.
2.2 Sessionstokens og JWT'er
Selv når adgangskoder ikke logges, bliver tokens ofte det.
For eksempel:
En gyldig JWT- eller sessionscookie i en .log filen kan aktivere:
- Session kapring
- Privilegieoptrapning
- Lateral bevægelse på tværs af interne systemer
Med andre ord, tokens i logfiler omdanner fejlfindingsoutput til en vektor for bypass af godkendelse.
2.3 CI/CD Artifacts
Byggelogfiler er særligt farlige. Faktisk, CI/CD Systemer udskriver ofte miljøvariabler under byggetrin.
Angribere opdager ofte:
Indeholder linjer som:
If CI/CD Artefakter er offentlige, så er hemmeligheder offentlige. Google-nørden fremskynder simpelthen opdagelsen.
2.4 Cloud- og infrastrukturdata
Eksponerede logfiler afslører ofte:
- AWS adgangsnøgler
- Azure Storage-forbindelsesstrenge
- Interne tjeneste-URL'er
- Databaseoplysninger
- Redis-slutpunkter
Selv hvis legitimationsoplysninger roteres senere, besidder angriberen nu:
- Kortlægning af infrastruktur
- Navnekonventioner
- Målrettet efterretning til fremtidige angreb
Derfor giver eksponerede logfiler både adgang og rekognoscering.
3. Hvordan disse logfiler overhovedet bliver offentlige
Logfiler vises ikke magisk i Google. De bliver indekseret, fordi de er offentligt tilgængelige.
3.1 Forkert konfigurerede webservere
Almindelige mønstre inkluderer:
/logs/mapper tilgængelige uden godkendelse- Katalogliste aktiveret
- Nginx eller Apache serverer rå
.logfiler
Hvis en log kan nås via HTTP, er den indekserbar.
3.2 CI/CD Artefakteksponering
Typiske fejl:
- Offentlige artefakter aktiveret i GitHub -handlinger
- Logfiler uploadet til åbne S3-buckets
- Pipeline spor tilgængelige uden godkendelse
A pipeline der gemmer logs i en offentlig bucket, offentliggør effektivt sine hemmeligheder.
3.3 Fejlfindingstilstand i produktion
Standardindstillinger i rammeværket kan være farlige:
Derudover kan overdreven anmodningslogning udskrive:
- Headers
- Tokens
- Fuld anmodningstekst
Fejlfindingslogning i produktion omdanner din applikation til en eksportør af legitimationsoplysninger.
3.4 Docker- og containerlogfiler
Containeriserede miljøer introducerer nye eksponeringsstier:
- Logfiler monteret på delte volumener
- Sidecars eksporterer logfiler til usikrede slutpunkter
- Log dashboardmed offentlig adgang
Hvis containerlogfiler eksponeres via HTTP eller åben lagring, er de søgbare. Til sidst indekseres de.
4. Realistisk angrebsflow: Fra nørd til gennembrud
En typisk angrebskæde ser sådan ud:
Angriberen løber:
- Fund afsløret
.logfil - Uddrag:
- JWT-token
- Grundlæggende godkendelsesheader
- Databaseforbindelsesstreng
Forsøg på godkendelse mod:
- API-endepunkter
- Administrationspaneler
- Interne tjenester
Hvis godkendelsen lykkes, kan angriberen:
- Eskaler privilegier
- Flyt dig sidelæns
- Adgang CI/CD
- Kompromitter forsyningskæden
Det, der startede som en søgeforespørgsel, bliver til:
- Session kapring
- Intern udfyldning af legitimationsoplysninger
- Pipeline overtage
- Artefaktforgiftning
Alt fra en offentligt indekseret logfil.
5. Hvorfor det er et AppSec-problem at logge "for meget"
Logning er ikke neutral. I stedet skaber den en sekundært datalager.
Hvis du logger følsomme data, opretter du effektivt en anden kopi af dine hemmeligheder.
Logfiler er dog ofte udelukket fra trusselsmodellering. Under STRIDE relaterer dette sig tydeligt til:
Oplysningsinformation
Derfor, sikker SDLC Praksis bør behandle logfiler som:
- Sikkerhedsrelevante artefakter
- Følsomme aktiver
- Infrastrukturkomponenter, der kræver beskyttelse
Hvis din trusselsmodel ignorerer logfiler, er den ufuldstændig.
6. Sådan forhindrer du lækage af legitimationsoplysninger i logfiler
6.1 Stop med at logge hemmeligheder
Log aldrig:
- Nulstilling/ændring af adgangskoder
- Tokens
- API-nøgler
- Sessions-id'er
- Autorisationsoverskrifter
Selv i debug-tilstand.
Implementer automatisk redigering, når det er muligt.
6.2 Struktureret og sikker logføring
Brug struktureret logføring med maskering og filtrering.
Eksempel (Node.js):
Eksempel (Python):
Hovedprincippet er enkelt: Hemmeligheder må aldrig nå ned i brændevasken.
6.3 Låsning af logopbevaring
Sikkerhedskontroller bør omfatte:
- Deaktiver katalogliste
- Beskyt
/logs/stier med godkendelse - Begræns adgang til bucket
- Anvend opbevaringspolitikker
- Krypter logfiler i hvile
Logfiler må aldrig være offentligt tilgængelige via HTTP.
6.4 CI/CD Guardrails
Manuelle gennemgange er utilstrækkelige. Implementer i stedet automatiserede kontroller:
- Hemmelig scanning af logfiler før offentliggørelse af artefakter
- Mislykkede builds, hvis der registreres tokens
- Forhindr upload af artefakter, der indeholder legitimationsoplysninger
- Hashvalidering for artefakter
CI/CD bør blokere eksponering, før indeksering sker.
7. Sådan forhindrer Xygeni all-intext:login filtype:log Hændelser
Problemet er ikke Google-nørden. Problemet er eksponering. Derfor skal forebyggelse ske før indeksering.
7.1 Hemmelighedsdetektion i logfiler og artefakter
Xygeni-scanninger:
- Applikationslogfiler
- CI/CD jobspor
- Byg artefakter
- Docker-lag
- Serialiserede udgange
Hvis legitimationsoplysninger, tokens eller følsomme værdier vises i .log filer, markerer Xygeni dem med det samme.
7.2 CI/CD Guardrails Den blokerende eksponering
I stedet for at stole på manuelle anmeldelser, Xygeni håndhæver sikkerheden ved pipeline niveau:
Det her:
- Mislykkes med builds, når hemmeligheder vises i logfiler
- Blokerer artefaktpublicering
- Forhindrer utilsigtet offentlig eksponering
- Stopper usikre sammenføjninger før de når hovedmenuen
Hvis et CI-job udskriver et token, pipeline mislykkes.
Ingen indeksering.
Ingen eksponering.
Ingen hændelse.
7.3 Shift-venstre-beskyttelse før Google ser det
Timing er vigtig.
I stedet for at reagere på:
Xygeni stopper problemet:
- At commit tid
- Under pull request validering
- Under pipeline udførelse
- Før offentliggørelse af artefakter
Hvis loggen aldrig bliver offentlig, indekserer Google den aldrig.
Konklusion: Hvis Google kan indeksere det, har angribere allerede gjort det
Logfiler er ikke harmløse. Faktisk er de sjældent midlertidige. Som standard er de ikke private. Derfor bør hver logfil behandles som et sikkerhedsrelevant aktiv, ikke blot som fejlfindingsoutput.
Hvis følsomme data når frem til en .log filen og bliver offentligt tilgængelig, den forvandles øjeblikkeligt til en angrebsflade. Desuden, når den først er indekseret af en søgemaskine, skaleres eksponeringen ud over din kontrol.
Løsningen er ikke at stoppe logging. Det er snarere at logge ansvarligt og håndhæve strenge kontroller omkring lagring og distribution. Med andre ord skal sikkerheden række ud over selve applikationen og ind i observerbarhedslaget.
I stedet:
- Stop med at logge hemmeligheder
- Lås opbevaring af logfiler
- Gennemtving pipeline guardrails
- Automatiser detektion og håndhævelse af politikker
Ultimativt, forebyggelse handler om timing. Fordi når allintext:login filtype:log returnerer dit domæne, er hændelsen allerede begyndt.
