Soekenjins is gebou om inhoud te indekseer. Aanvallers gebruik hulle egter om jou foute te indekseer. Die navraag allintext:login lêertipe:log mag dalk onskadelik lyk. In werklikheid is dit een van die eenvoudigste maniere om blootgestelde loglêers te ontdek wat verifikasievloei, geloofsbriewe, tokens en interne infrastruktuurdata bevat.
As Google daardie logs kan sien, kan aanvallers ook. Sodra dit geïndekseer is, word blootstelling onvermydelik. Boonop, wanneer geloofsbriewe in 'n publiek toeganklike lêer verskyn, is die oortreding reeds aan die gang.
1. Waarom allesintekst:login filetype:log is gevaarliker as wat dit lyk
'n Google-dork is 'n soektog wat gevorderde operateurs gebruik om sensitiewe of verkeerd gekonfigureerde inhoud op te spoor wat deur soekenjins geïndekseer is. Dit buit nie Google uit nie. In plaas daarvan buit dit jou blootstelling uit.
Hierdie navraag kombineer twee operateurs:
- allintext: gee bladsye terug waar alle terme in die liggaamsteks verskyn
- lêertipe:log beperk resultate tot
.loglêers
daarom:
Beteken: “Wys my loglêers wat die woord bevat login. "
Met die eerste oogopslag lyk dit triviaal. In die praktyk kom dit egter dikwels terug:
- Openbaar blootgestelde webbedienerlogboeke
- CI/CD logs opgelaai as artefakte
- Ontfoutingslogboeke per ongeluk commitna bewaarplekke
- Toepassingslogboeke met gewone teksbewyse
Dit is nie 'n soekenjinfout nie. Dit is eerder 'n kwesbaarheid vir datablootstelling veroorsaak deur verkeerde konfigurasie. Google het bloot geïndekseer wat publiek toeganklik was.
2. Wat aanvallers eintlik in blootgestelde loglêers vind
Wanneer aanvallers hardloop allintext:login lêertipe:log, hulle blaai nie lukraak nie. Hulle soek na verifikasiespore.
2.1 Gewone teks geloofsbriewe
Logboeke bevat gereeld inskrywings soos:
or
Of selfs SMTP-bewyse:
Die aanteken van verifikasievragte is een van die vinnigste maniere om produksiebewyse te lek. Gevolglik kan 'n enkele blootgestelde loglêer jou hele toegangsbeheermodel ongeldig maak.
2.2 Sessie-tokens en JWT's
Selfs wanneer wagwoorde nie aangeteken word nie, word tokens dikwels wel aangeteken.
Byvoorbeeld:
'n Geldige JWT- of sessiekoekie binne 'n .log lêer kan aktiveer:
- Sessie kaping
- Eskalasie van voorregte
- Laterale beweging oor interne stelsels
Met ander woorde, tokens in logs verander ontfouting-uitvoer in 'n verifikasie-omleidingsvektor.
2.3 CI/CD Artefakte
Boulogblokke is veral gevaarlik. Trouens, CI/CD Stelsels druk dikwels omgewingveranderlikes tydens boustappe.
Aanvallers ontdek gereeld:
Bevat lyne soos:
If CI/CD artefakte is publiek, dan is geheime publiek. Die Google-dork versnel bloot ontdekking.
2.4 Wolk- en infrastruktuurdata
Blootgestelde logs onthul dikwels:
- AWS-toegangsleutels
- Azure-bergingsverbindingsstringe
- Interne diens-URL'e
- Databasisbewyse
- Redis-eindpunte
Selfs al word geloofsbriewe later geroteer, beskik die aanvaller nou oor:
- Infrastruktuurkartering
- Noem konvensies
- Teikeninligting vir toekomstige aanvalle
Daarom bied blootgestelde logs beide toegang en verkenning.
3. Hoe hierdie logs in die eerste plek publiek word
Logboeke verskyn nie toweragtig in Google nie. Hulle word geïndekseer omdat hulle publiek toeganklik was.
3.1 Verkeerd gekonfigureerde webbedieners
Algemene patrone sluit in:
/logs/gidse toeganklik sonder verifikasie- Gidslys geaktiveer
- Nginx of Apache wat rou bedien word
.loglêers
As 'n log oor HTTP bereikbaar is, is dit indekseerbaar.
3.2 CI/CD Artefakblootstelling
Tipiese foute:
- Openbare artefakte geaktiveer in GitHub -aksies
- Logs opgelaai na oop S3-emmers
- Pipeline spore toeganklik sonder verifikasie
A pipeline wat logs in 'n publieke emmer stoor, publiseer effektief sy geheime.
3.3 Ontfoutingsmodus in produksie
Raamwerkverstekwaardes kan gevaarlik wees:
Daarbenewens kan oormatige versoeklogging druk:
- Headers
- tekens
- Volledige versoekliggame
Ontfoutingslogboeke in produksie transformeer jou toepassing in 'n geloofsbriewe-uitvoerder.
3.4 Docker- en houerlogboeke
Gehouerde omgewings stel nuwe blootstellingspaaie bekend:
- Logs gemonteer in gedeelde volumes
- Sykarre wat logs na onversekerde eindpunte uitvoer
- Meld dashboards met publieke toegang
As houerloglêers via HTTP of oop berging blootgestel word, is hulle deursoekbaar. Uiteindelik word hulle geïndekseer.
4. Realistiese Aanvalsvloei: Van Dork tot Break
'n Tipiese aanvalsketting lyk so:
Aanvaller hardloop:
- Vondste blootgestel
.loglêer - Uittreksels:
- JWT-teken
- Basiese Magtiging-opskrif
- Databasisverbindingstring
Pogings tot verifikasie teen:
- API-eindpunte
- Adminpanele
- Interne dienste
Indien verifikasie slaag, kan die aanvaller:
- Eskaleer voorregte
- Beweeg lateraal
- Toegang CI/CD
- Die voorsieningsketting in gevaar stel
Wat as 'n soektog begin het, word:
- Sessie kaping
- Interne geloofsbriewe vulsel
- Pipeline oorname
- Artefakvergiftiging
Alles vanaf 'n publiek geïndekseerde loglêer.
5. Waarom die aanteken van “te veel” 'n AppSec-probleem is
Logging is nie neutraal nie. In plaas daarvan skep dit 'n sekondêre databerging.
As jy sensitiewe data aanteken, skep jy effektief 'n tweede kopie van jou geheime.
Logboeke word egter dikwels van bedreigingsmodellering uitgesluit. Onder STRIDE word dit duidelik gekoppel aan:
Openbaarmaking van inligting
Daarom, Veilig SDLC praktyke behoort logs te hanteer as:
- Sekuriteitsrelevante artefakte
- Sensitiewe bates
- Infrastruktuurkomponente wat beskerming benodig
As jou bedreigingsmodel logs ignoreer, is dit onvolledig.
6. Hoe om geloofsbriewe-lekkasie in loglêers te voorkom
6.1 Stop die aanteken van geheime
Moet nooit aanteken nie:
- Wagwoorde
- tekens
- API-sleutels
- Sessie-ID's
- Magtigingsopskrifte
Selfs in ontfoutingsmodus.
Implementeer outomatiese redigering waar moontlik.
6.2 Gestruktureerde en Veilige Logging
Gebruik gestruktureerde logging met maskering en filtering.
Voorbeeld (Node.js):
Voorbeeld (Python):
Die sleutelbeginsel is eenvoudig: geheime mag nooit die houtwasbak bereik nie.
6.3 Sluit Logberging Toe
Sekuriteitsbeheermaatreëls moet insluit:
- Deaktiveer gidslys
- Beskerm
/logs/paaie met verifikasie - Beperk toegang tot emmer
- Pas behoudbeleide toe
- Enkripteer logs in rus
Logs moet nooit publiek toeganklik wees via HTTP nie.
6.4 CI/CD Guardrails
Handmatige hersienings is onvoldoende. Implementeer eerder outomatiese beheermaatreëls:
- Geheime skandering van logs voor artefaktepublikasie
- Misluk bouwerk as tokens opgespoor word
- Voorkom artefakoplaaie wat geloofsbriewe bevat
- Hash-validering vir artefakte
CI/CD moet blootstelling blokkeer voordat indeksering plaasvind.
7. Hoe Xygeni alles-in-teks voorkom:login lêertipe:log Voorvalle
Die probleem is nie die Google-seksueel nie. Die probleem is blootstelling. Daarom moet voorkoming plaasvind voor indeksering.
7.1 Geheime Opsporing in Logboeke en Artefakte
Xygeni-skanderings:
- Aansoek logs
- CI/CD werkspore
- Bou artefakte
- Docker-lae
- Geserialiseerde uitsette
As geloofsbriewe, tokens of sensitiewe waardes verskyn in .log lêers, merk Xygeni hulle onmiddellik.
7.2 CI/CD Guardrails Daardie Blokblootstelling
In plaas daarvan om op handmatige resensies staat te maak, Xygeni handhaaf sekuriteit by die pipeline vlak:
hierdie:
- Misluk bouwerk wanneer geheime in logboeke verskyn
- Blokkeer artefakpublikasie
- Voorkom toevallige openbare blootstelling
- Stop onveilige samesmeltings voordat dit hoof bereik
As 'n CI-taak 'n teken druk, die pipeline versuim.
Geen indeksering nie.
Geen blootstelling nie.
Geen voorval nie.
7.3 Shift-Links-beskerming voordat Google dit sien
Tydsberekening maak saak.
In plaas daarvan om te reageer op:
Xygeni stop die probleem:
- At commit tyd
- Tydens pull request bekragtiging
- Tydens pipeline uitvoering
- Voor artefakpublikasie
As die log nooit publiek word nie, indekseer Google dit nooit.
Finale gevolgtrekking: As Google dit kan indekseer, het aanvallers dit reeds gedoen
Loglêers is nie onskadelik nie. Trouens, hulle is selde tydelik. Standaard is hulle nie privaat nie. Daarom moet elke loglêer as 'n sekuriteitsrelevante bate behandel word, nie net as ontfoutingsuitvoer nie.
Indien sensitiewe data 'n .log lêer en word publiek toeganklik, dit verander onmiddellik in 'n aanvalsoppervlak. Boonop, sodra dit deur 'n soekenjin geïndekseer is, skaal die blootstelling buite jou beheer.
Die oplossing is nie om logging te stop nie. Dit is eerder om verantwoordelik te logging en streng beheermaatreëls rondom berging en verspreiding af te dwing. Met ander woorde, sekuriteit moet verder strek as die toepassing self en tot in die waarneembaarheidslaag.
In plaas daarvan:
- Hou op om geheime aan te teken
- Sluit logberging toe
- Dwing af pipeline guardrails
- Outomatiseer opsporing en beleidsafdwinging
uiteindelik, voorkoming gaan oor tydsberekening. Want een keer allintext:login lêertipe:log jou domein teruggee, het die voorval reeds begin.
