Zoekmachines zijn ontworpen om content te indexeren. Aanvallers gebruiken ze echter om je fouten te indexeren. De zoekopdracht allintext:login bestandstype:log Het lijkt misschien onschuldig. In werkelijkheid is het een van de eenvoudigste manieren om blootgestelde logbestanden te ontdekken die authenticatiestromen, inloggegevens, tokens en interne infrastructuurgegevens bevatten.
Als Google die logbestanden kan inzien, kunnen aanvallers dat ook. Zodra ze geïndexeerd zijn, is openbaarmaking onvermijdelijk. Bovendien, wanneer inloggegevens in een openbaar toegankelijk bestand verschijnen, is de inbreuk al in gang gezet.
1. Waarom allintext:login bestandstype:log is gevaarlijker dan het lijkt
Een Google dork is een zoekopdracht die gebruikmaakt van geavanceerde operators om gevoelige of verkeerd geconfigureerde content te vinden die door zoekmachines is geïndexeerd. Het misbruikt Google niet, maar maakt wel misbruik van jouw kwetsbaarheid.
Deze query combineert twee operatoren:
- allintext: retourneert pagina's waar alle termen in de hoofdtekst voorkomen.
- bestandstype:log beperkt de resultaten tot
.logbestanden
daarom:
Middelen: "Laat me logbestanden zien die het woord bevatten login. '
Op het eerste gezicht lijkt dat onbelangrijk. In de praktijk blijkt het echter vaak het volgende te zijn:
- Openbaar toegankelijke webserverlogboeken
- CI/CD logbestanden geüpload als artefacten
- Foutopsporingslogboeken per ongeluk committed naar repositories
- Applicatielogboeken met inloggegevens in platte tekst
Dit is geen fout in de zoekmachine. Het is in plaats daarvan een kwetsbaarheid voor blootstelling van gegevens Dit werd veroorzaakt door een verkeerde configuratie. Google indexeerde simpelweg wat publiekelijk toegankelijk was.
2. Wat aanvallers daadwerkelijk vinden in blootgestelde logbestanden
Wanneer aanvallers rennen allintext:login bestandstype:logZe browsen niet willekeurig. Ze zoeken naar authenticatiegegevens.
2.1 Referenties in platte tekst
Logboeken bevatten vaak vermeldingen zoals:
or
Of zelfs SMTP-gegevens:
Het vastleggen van authenticatiegegevens in logbestanden is een van de snelste manieren om inloggegevens voor productieomgevingen te lekken. Een enkel openbaar logbestand kan daardoor uw volledige toegangscontrolemodel ongeldig maken.
2.2 Sessietokens en JWT's
Zelfs als wachtwoorden niet worden geregistreerd, worden tokens dat vaak wel.
Bijvoorbeeld:
Een geldige JWT of sessiecookie in een .log Het bestand kan het volgende inschakelen:
- Sessie kaping
- Privilege-escalatie
- Laterale beweging door interne systemen
Met andere woorden: tokens in logbestanden veranderen de debug-output in een manier om de authenticatie te omzeilen.
2.3 CI/CD Artifacts
Buildlogs zijn bijzonder gevaarlijk. Sterker nog, CI/CD Systemen printen vaak omgevingsvariabelen tijdens de bouwstappen.
Aanvallers ontdekken vaak:
Bevat regels zoals:
If CI/CD Artefacten worden openbaar, dus geheimen worden ook openbaar. De Google-dork versnelt simpelweg de ontdekking.
2.4 Cloud- en infrastructuurgegevens
Uit blootgelegde logbestanden blijkt vaak het volgende:
- AWS-toegangssleutels
- Azure-opslagverbindingsreeksen
- Interne service-URL's
- Database-inloggegevens
- Redis-eindpunten
Zelfs als de inloggegevens later worden gewijzigd, beschikt de aanvaller nu over:
- Infrastructuurkartering
- Naamgevingsconventies
- Gerichte inlichtingen verzamelen voor toekomstige aanvallen
Daarom bieden openbaar toegankelijke logboeken zowel toegang als mogelijkheden tot verkenning.
3. Hoe deze logbestanden überhaupt openbaar worden
Logbestanden verschijnen niet zomaar in Google. Ze worden geïndexeerd omdat ze publiekelijk toegankelijk waren.
3.1 Verkeerd geconfigureerde webservers
Veel voorkomende patronen zijn onder meer:
/logs/mappen die toegankelijk zijn zonder authenticatie- Lijstweergave ingeschakeld
- Nginx of Apache serveert raw
.logbestanden
Als een logbestand via HTTP bereikbaar is, kan het worden geïndexeerd.
3.2 CI/CD Blootstelling van artefacten
Typische fouten:
- Openbare artefacten ingeschakeld in GitHub-acties
- Logbestanden geüpload naar open S3-buckets.
- Pipeline traceringen die toegankelijk zijn zonder authenticatie
A pipeline Een systeem dat logbestanden opslaat in een openbare bucket, publiceert in feite zijn geheimen.
3.3 Debugmodus in productie
De standaardinstellingen van het framework kunnen gevaarlijk zijn:
Bovendien kan overmatige logboekregistratie van verzoeken het volgende afdrukken:
- Headers
- tokens
- Volledige verzoeklichamen
Door debug-logging in een productieomgeving te gebruiken, verandert uw applicatie in een tool voor het exporteren van inloggegevens.
3.4 Docker- en containerlogboeken
Containeromgevingen introduceren nieuwe blootstellingspaden:
- Logbestanden zijn gekoppeld aan gedeelde volumes.
- Sidecars die logbestanden exporteren naar onbeveiligde eindpunten
- Log dashboardmet openbare toegang
Als containerlogs via HTTP of open opslag beschikbaar zijn, zijn ze doorzoekbaar. Uiteindelijk worden ze geïndexeerd.
4. Realistische aanvalsflow: van sukkel tot doorbraak.
Een typische aanvalsketen ziet er als volgt uit:
Aanvaller rent:
- Vondsten blootgelegd
.logfilet - extracten:
- JWT-token
- Basisauthenticatie-header
- Databaseverbindingsreeks
Authenticatiepogingen tegen:
- API-eindpunten
- Beheerpanelen
- Interne diensten
Als de authenticatie slaagt, kan de aanvaller het volgende doen:
- Escaleer rechten
- Zijwaarts bewegen
- Toegang CI/CD
- De toeleveringsketen in gevaar brengen
Wat begon als een zoekopdracht, wordt:
- Sessie kaping
- Interne credential stuffing
- Pipeline overnemen
- Artefactvergiftiging
Alles afkomstig uit een openbaar toegankelijk logbestand.
5. Waarom te veel loggen een AppSec-probleem is.
Het vastleggen van gegevens is niet neutraal. Integendeel, het creëert een secundaire gegevensopslag.
Als u gevoelige gegevens vastlegt, creëert u in feite een tweede kopie van uw geheimen.
Logbestanden worden echter vaak buiten beschouwing gelaten bij het modelleren van bedreigingen. Onder STRIDE vertaalt dit zich duidelijk naar:
Openbaarmakingsinformatie
Daarom, veilig SDLC Praktijken dienen logbestanden als volgt te behandelen:
- Beveiligingsrelevante artefacten
- Gevoelige activa
- Infrastructuuronderdelen die bescherming vereisen
Als uw dreigingsmodel geen rekening houdt met logbestanden, is het onvolledig.
6. Hoe voorkom je dat inloggegevens uitlekken in logbestanden?
6.1 Stop met het vastleggen van geheimen
Nooit loggen:
- wachtwoorden
- tokens
- API-sleutels
- Sessie-ID's
- Autorisatieheaders
Zelfs in debugmodus.
Implementeer waar mogelijk automatische anonimisering.
6.2 Gestructureerd en veilig loggen
Gebruik gestructureerde logboekregistratie met maskering en filtering.
Voorbeeld (Node.js):
Voorbeeld (Python):
Het kernprincipe is eenvoudig: geheimen mogen nooit in het logboek terechtkomen.
6.3 Vergrendel de opslag van logboeken
Beveiligingsmaatregelen moeten het volgende omvatten:
- Mapweergave uitschakelen
- Beschermen
/logs/paden met authenticatie - Beperk de toegang tot de bucket.
- Pas bewaarbeleid toe.
- Versleutel logbestanden in ruststand.
Logbestanden mogen nooit publiekelijk toegankelijk zijn via HTTP.
6.4 CI/CD Guardrails
Handmatige controles zijn onvoldoende. Implementeer in plaats daarvan geautomatiseerde controles:
- Geheime scan van logbestanden vóór publicatie van artefacten
- Builds mislukken als er tokens worden gedetecteerd.
- Voorkom dat artefacten met inloggegevens worden geüpload.
- Hashvalidatie voor artefacten
CI/CD Blootstelling moet worden geblokkeerd voordat indexering plaatsvindt.
7. Hoe Xygeni allintext voorkomt:login bestandstype:log Incidenten
Het probleem is niet de Google dork. Het probleem is de blootstelling. Daarom moet preventie plaatsvinden vóórdat er wordt geïndexeerd.
7.1 Detectie van geheimen in logbestanden en artefacten
Xygeni-scans:
- Applicatielogboeken
- CI/CD werksporen
- Bouw artefacten
- Docker-lagen
- Geserialiseerde uitgangen
Als inloggegevens, tokens of gevoelige waarden voorkomen in .log Xygeni markeert deze bestanden onmiddellijk.
7.2 CI/CD Guardrails Dat blokkeert blootstelling
In plaats van te vertrouwen op handmatige beoordelingen, Xygeni handhaaft de beveiliging bij de pipeline niveau:
Deze:
- Builds mislukken wanneer geheimen in de logbestanden verschijnen.
- Blokken artefact publicatie
- Voorkomt onbedoelde blootstelling van het publiek.
- Voorkomt onveilige samenvoegingen voordat de hoofdroute wordt bereikt.
Als een CI-taak een token afdrukt, dan... pipeline mislukt.
Geen indexering.
Geen blootstelling.
Geen incident.
7.3 Bescherming tegen Shift-Left voordat Google het ziet
Timing is belangrijk.
In plaats van te reageren op:
Xygeni lost het probleem op:
- At commit Time to
- Tijdens de Drooglegging in de jaren twintig van de twintigste eeuw boden verborgen deuren toegang tot geheime kroegen en ondergrondse clubs. pull request bevestiging
- Tijdens de Drooglegging in de jaren twintig van de twintigste eeuw boden verborgen deuren toegang tot geheime kroegen en ondergrondse clubs. pipeline uitvoering
- Vóór publicatie van het artefact
Als het logbestand nooit openbaar wordt gemaakt, wordt het ook nooit door Google geïndexeerd.
Conclusie: Als Google het kan indexeren, hebben aanvallers dat al gedaan.
Logbestanden zijn niet onschadelijk. Sterker nog, ze zijn zelden tijdelijk. Standaard zijn ze niet privé. Daarom moet elk logbestand worden beschouwd als een beveiligingsrelevant bestand, en niet zomaar als debug-output.
Als gevoelige gegevens een .log bestand en wordt openbaar toegankelijk, Het verandert onmiddellijk in een aanvalsoppervlak. Bovendien, zodra een artikel door een zoekmachine is geïndexeerd, neemt de zichtbaarheid ervan een oncontroleerbare omvang aan.
De oplossing is niet om te stoppen met loggen. Het gaat erom verantwoord te loggen en strikte controles af te dwingen met betrekking tot opslag en distributie. Met andere woorden, de beveiliging moet verder reiken dan de applicatie zelf en doordringen tot de observatielaag.
In plaats daarvan:
- Stop met het vastleggen van geheimen.
- Beveilig de logopslag.
- afdwingen pipeline guardrails
- Automatiseer detectie en handhaving van beleid
Tenslotte, Preventie draait om timing. Want zodra... allintext:login bestandstype:log Als uw domein wordt geretourneerd, is het incident al begonnen.
