Els motors de cerca es van crear per indexar contingut. Tanmateix, els atacants els utilitzen per indexar els vostres errors. La consulta allintext:login tipus de fitxer: registre pot semblar inofensiu. En realitat, és una de les maneres més senzilles de descobrir fitxers de registre exposats que contenen fluxos d'autenticació, credencials, testimonis i dades d'infraestructura interna.
Si Google pot veure aquests registres, els atacants també poden. Un cop indexats, l'exposició esdevé inevitable. A més, quan les credencials apareixen en un fitxer d'accés públic, la bretxa ja està en marxa.
1. Per què allintext:login tipus de fitxer:log és més perillós del que sembla
Un Google dork és una consulta de cerca que utilitza operadors avançats per localitzar contingut sensible o mal configurat indexat pels motors de cerca. No explota Google. En canvi, explota la teva exposició.
Aquesta consulta combina dos operadors:
- allintext: retorna pàgines on tots els termes apareixen al text del cos
- tipus de fitxer: registre restringeix els resultats a
.logarxius
Per tant:
Significa: “Mostra'm els fitxers de registre que continguin la paraula login".
A primera vista, això sembla trivial. Tanmateix, a la pràctica, sovint retorna:
- Registres del servidor web exposats públicament
- CI/CD registres carregats com a artefactes
- Registres de depuració accidentals committed a repositoris
- Registres d'aplicacions amb credencials de text sense format
Això no és un error del motor de cerca. En canvi, és un vulnerabilitat d'exposició de dades causat per una mala configuració. Google simplement va indexar allò que era accessible públicament.
2. Què troben realment els atacants en els fitxers de registre exposats
Quan els atacants corren allintext:login tipus de fitxer: registre, no naveguen aleatòriament. Busquen rastres d'autenticació.
2.1 Credencials de text sense format
Els registres sovint contenen entrades com ara:
or
O fins i tot credencials SMTP:
Registrear les càrregues útils d'autenticació és una de les maneres més ràpides de filtrar les credencials de producció. En conseqüència, un únic fitxer de registre exposat pot invalidar tot el model de control d'accés.
2.2 Tokens de sessió i JWT
Fins i tot quan les contrasenyes no es registren, els tokens sovint sí que ho fan.
Per exemple:
Una galeta JWT o de sessió vàlida dins d'un .log El fitxer pot habilitar:
- Segrest de la sessió
- Escalada de privilegis
- Moviment lateral a través dels sistemes interns
En altres paraules, els tokens dels registres converteixen la sortida de depuració en un vector d'evitació d'autenticació.
2.3 CI/CD Els artefactes
Els registres de compilació són especialment perillosos. De fet, CI/CD Els sistemes sovint imprimeixen variables d'entorn durant els passos de compilació.
Els atacants sovint descobreixen:
Conté línies com ara:
If CI/CD Si els artefactes són públics, aleshores els secrets són públics. El ximple de Google simplement accelera el descobriment.
2.4 Dades al núvol i a la infraestructura
Els registres exposats sovint revelen:
- Claus d'accés d'AWS
- Cadenes de connexió d'emmagatzematge de l'Azure
- URL de servei intern
- Credencials de la base de dades
- Punts finals de Redis
Fins i tot si les credencials es roten més tard, l'atacant ara posseeix:
- Cartografia d'infraestructures
- Convencions de denominació
- Intel·ligència objectiu per a futurs atacs
Per tant, els troncs exposats proporcionen tant accés com reconeixement.
3. Com es fan públics aquests registres en primer lloc
Els registres no apareixen màgicament a Google. S'indexen perquè eren accessibles públicament.
3.1 Servidors web mal configurats
Els patrons comuns inclouen:
/logs/directoris accessibles sense autenticació- Llistat de directoris activat
- Nginx o Apache servint en brut
.logarxius
Si un registre és accessible a través d'HTTP, és indexable.
3.2 CI/CD Exposició d'artefactes
Errors típics:
- Artefactes públics habilitats a Accions de GitHub
- Registres carregats a buckets S3 oberts
- Pipeline traces accessibles sense autenticació
A pipeline que emmagatzema registres en un bucket públic publica els seus secrets de manera efectiva.
3.3 Mode de depuració en producció
Els valors per defecte del marc de treball poden ser perillosos:
A més, un registre excessiu de sol·licituds pot imprimir:
- Capçaleres
- Fitxes
- Cossos complets de les sol·licituds
El registre de depuració en producció transforma l'aplicació en un exportador de credencials.
3.4 Registres de Docker i contenidors
Els entorns contenidoritzats introdueixen noves vies d'exposició:
- Registres muntats en volums compartits
- Exportació de registres a punts finals no segurs per a sidecars
- Sessió dashboards amb accés públic
Si els registres del contenidor s'exposen mitjançant HTTP o emmagatzematge obert, es poden cercar. Finalment, s'indexen.
4. Flux d'atac realista: de Dork a Breach
Una cadena d'atac típica té aquest aspecte:
L'atacant corre:
- Troballes exposades
.logfile - Extractes:
- Token JWT
- Capçalera d'autenticació bàsica
- Cadena de connexió de base de dades
Intenta autenticació contra:
- Punts finals de l'API
- Panells d'administració
- Serveis interns
Si l'autenticació té èxit, l'atacant pot:
- Escalar privilegis
- Moure's lateralment
- Accés CI/CD
- Comprometre la cadena de subministrament
El que va començar com una consulta de cerca esdevé:
- Segrest de la sessió
- Farciment intern de credencials
- Pipeline presa de possessió
- Intoxicació per artefactes
Tot des d'un fitxer de registre indexat públicament.
5. Per què registrar "massa" és un problema d'AppSec
La tala d'arbres no és neutral. En canvi, crea una magatzem de dades secundari.
Si registreu dades sensibles, creeu una segona còpia dels vostres secrets.
Tanmateix, els registres sovint s'exclouen del modelatge d'amenaces. Sota STRIDE, això es correspon clarament amb:
Divulgació d'informació
Per tant, segur SDLC Les pràctiques haurien de tractar els registres com a:
- Artefactes rellevants per a la seguretat
- Actius sensibles
- Components d'infraestructura que requereixen protecció
Si el vostre model d'amenaces ignora els registres, està incomplet.
6. Com evitar la filtració de credencials als fitxers de registre
6.1 Aturar els secrets de registre
No registrar mai:
- Contrasenyes
- Fitxes
- Claus API
- Identificadors de sessió
- Capçaleres d'autorització
Fins i tot en mode de depuració.
Sempre que sigui possible, implementa la redacció automàtica.
6.2 Registre estructurat i segur
Utilitzeu el registre estructurat amb emmascarament i filtratge.
Exemple (Node.js):
Exemple (Python):
El principi clau és simple: els secrets no han d'arribar mai a la pica de troncs.
6.3 Emmagatzematge de registre bloquejat
Els controls de seguretat han d'incloure:
- Desactiva la llista de directoris
- Protegir
/logs/camins amb autenticació - Restringeix l'accés al cub
- Aplica polítiques de retenció
- Xifra els registres en repòs
Els registres no han de ser mai accessibles públicament via HTTP.
6.4 CI/CD Guardrails
Les revisions manuals són insuficients. En comptes d'això, implementeu controls automatitzats:
- Escaneig secret dels registres abans de la publicació dels artefactes
- Falla la compilació si es detecten tokens
- Impedir la càrrega d'artefactes que continguin credencials
- Validació hash per a artefactes
CI/CD hauria de bloquejar l'exposició abans que es produeixi la indexació.
7. Com Xygeni evita allintext:login tipus de fitxer: registre d'incidents
El problema no és el ximple de Google. El problema és l'exposició. Per tant, la prevenció s'ha de fer abans de la indexació.
7.1 Detecció de secrets en registres i artefactes
Escaneigs Xygeni:
- Registres d'aplicacions
- CI/CD rastres de treball
- Construir artefactes
- Capes de Docker
- Sortides serialitzades
Si apareixen credencials, testimonis o valors sensibles a .log fitxers, Xygeni els marca immediatament.
7.2 CI/CD Guardrails Aquesta exposició de bloqueig
En lloc de confiar en revisions manuals, Xygeni reforça la seguretat a pipeline nivell:
Això:
- Falla la compilació quan apareixen secrets als registres.
- Bloqueja la publicació d'artefactes
- Evita l'exposició accidental al públic
- Atura les fusions no segures abans d'arribar al mòdul principal
Si una tasca de CI imprimeix un token, el pipeline falla.
Sense indexació.
Sense exposició.
Cap incident.
7.3 Protecció contra Majúscules a l'esquerra abans que Google la vegi
El temps importa.
En lloc de reaccionar a:
Xygeni atura el problema:
- At commit temps
- Durant pull request validació
- Durant pipeline execució
- Abans de la publicació de l'artefacte
Si el registre no es fa públic, Google no l'indexarà mai.
Conclusió final: si Google ho pot indexar, els atacants ja ho han fet
Els registres no són inofensius. De fet, rarament són temporals. Per defecte, no són privats. Per tant, cada fitxer de registre s'ha de tractar com un actiu rellevant per a la seguretat, no només com a sortida de depuració.
Si les dades sensibles arriben a un .log fitxer i esdevé accessible públicament, es converteix immediatament en una superfície d'atac. A més, un cop indexat per un motor de cerca, l'exposició augmenta més enllà del vostre control.
La solució no és aturar el registre. Més aviat, és registrar de manera responsable i aplicar controls estrictes sobre l'emmagatzematge i la distribució. En altres paraules, la seguretat ha d'estendre's més enllà de la pròpia aplicació i fins a la capa d'observabilitat.
En lloc d'això:
- Deixa de registrar secrets
- Bloquejar l'emmagatzematge de registres
- Fer complir pipeline guardrails
- Automatitzar la detecció i l'aplicació de polítiques
finalment, la prevenció és qüestió de temps. Perquè un cop allintext:login tipus de fitxer: registre retorna el teu domini, l'incident ja ha començat.
