Os motores de busca foron creados para indexar contido. Non obstante, os atacantes úsanos para indexar os teus erros. A consulta allintext:login tipo de ficheiro: rexistro pode parecer inofensivo. En realidade, é unha das formas máis sinxelas de descubrir ficheiros de rexistro expostos que conteñen fluxos de autenticación, credenciais, tokens e datos de infraestrutura interna.
Se Google pode ver eses rexistros, os atacantes tamén poden. Unha vez indexados, a exposición faise inevitable. Ademais, cando as credenciais aparecen nun ficheiro de acceso público, a violación xa está en marcha.
1. Por que allintext:login tipo de ficheiro:log é máis perigoso do que parece
Un dork de Google é unha consulta de busca que emprega operadores avanzados para localizar contido sensible ou mal configurado indexado polos motores de busca. Non explota Google. En vez diso, explota a túa exposición.
Esta consulta combina dous operadores:
- allintext: devolve páxinas onde todos os termos aparecen no corpo do texto
- tipo de ficheiro: rexistro restrinxe os resultados a
.logarquivos
Polo tanto:
Significa: “Móstrame os ficheiros de rexistro que conteñan a palabra login. "
Á primeira vista, iso parece trivial. Non obstante, na práctica, a miúdo devolve:
- Rexistros do servidor web expostos publicamente
- CI/CD rexistros cargados como artefactos
- Depurar rexistros accidentalmente committed a repositorios
- Rexistros de aplicacións con credenciais de texto sen formato
Isto non é un erro do motor de busca. En cambio, é un vulnerabilidade de exposición de datos causado por unha configuración incorrecta. Google simplemente indexou o que era accesible publicamente.
2. Que atopan realmente os atacantes nos ficheiros de rexistro expostos
Cando os atacantes corren allintext:login tipo de ficheiro: rexistro, non navegan ao chou. Buscan rastros de autenticación.
2.1 Credenciais de texto sen formato
Os rexistros adoitan conter entradas como:
or
Ou mesmo credenciais SMTP:
Rexistrar cargas útiles de autenticación é unha das formas máis rápidas de filtrar credenciais de produción. En consecuencia, un único ficheiro de rexistro exposto pode invalidar todo o modelo de control de acceso.
2.2 Tokens de sesión e JWT
Mesmo cando os contrasinais non se rexistran, os tokens adoitan rexistrarse.
Por exemplo:
Unha cookie de sesión ou JWT válida dentro dun .log O ficheiro pode activar:
- Secuestro de sesión
- Escalada de privilexios
- Movemento lateral a través dos sistemas internos
Noutras palabras, os tokens nos rexistros converten a saída de depuración nun vector de omisión de autenticación.
2.3 CI/CD Artefactos
Os rexistros de compilación son especialmente perigosos. De feito, CI/CD Os sistemas adoitan imprimir variables de ambiente durante os pasos de compilación.
Os atacantes descobren con frecuencia:
Contén liñas como:
If CI/CD Se os artefactos son públicos, entón os segredos son públicos. O parvo de Google simplemente acelera o descubrimento.
2.4 Datos na nube e na infraestrutura
Os rexistros expostos adoitan revelar:
- Claves de acceso de AWS
- Cadeas de conexión de almacenamento de Azure
- URL de servizo interno
- Credenciais da base de datos
- Puntos finais de Redis
Mesmo se as credenciais se rotan máis tarde, o atacante agora posúe:
- Mapeo de infraestruturas
- Convencións de nomenclatura
- Intelixencia dirixida para futuros ataques
Polo tanto, os troncos expostos proporcionan tanto acceso como recoñecemento.
3. Como se fan públicos estes rexistros en primeiro lugar
Os rexistros non aparecen por arte de maxia en Google. Indéxanse porque eran accesibles publicamente.
3.1 Servidores web mal configurados
Os patróns comúns inclúen:
/logs/directorios accesibles sen autenticación- Listaxe no directorio activada
- Nginx ou Apache servindo en bruto
.logarquivos
Se un rexistro é accesible a través de HTTP, é indexable.
3.2 CI/CD Exposición a artefactos
Erros típicos:
- Artefactos públicos activados en Accións de GitHub
- Rexistros subidos a buckets de S3 abertos
- Pipeline rastros accesibles sen autenticación
A pipeline que almacena rexistros nun bucket público publica os seus segredos de forma eficaz.
3.3 Modo de depuración en produción
Os valores predefinidos do marco de traballo poden ser perigosos:
Ademais, o rexistro excesivo de solicitudes pode imprimir:
- Cabeceiras
- tokens
- Corpos completos das solicitudes
O rexistro de depuración en produción transforma a túa aplicación nun exportador de credenciais.
3.4 Rexistros de Docker e contedores
Os entornos contedores introducen novas vías de exposición:
- Rexistros montados en volumes compartidos
- Exportación de rexistros a puntos finais non seguros por parte de sidecars
- Rexistro dashboardcon acceso público
Se os rexistros do contedor se expoñen mediante HTTP ou almacenamento aberto, pódense buscar neles. Finalmente, indexanse.
4. Fluxo de ataque realista: de parvo a brecha
Unha cadea de ataque típica ten este aspecto:
O atacante corre:
- Achados expostos
.logarquivo - Extractos:
- Token de JWT
- Cabeceira de autenticación básica
- Cadea de conexión á base de datos
Tenta a autenticación contra:
- Puntos finais da API
- Paneis de administración
- Servizos internos
Se a autenticación ten éxito, o atacante pode:
- Escalar privilexios
- Mover lateralmente
- acceso CI/CD
- Comprometer a cadea de subministración
O que comezou como unha consulta de busca convértese en:
- Secuestro de sesión
- Recheo interno de credenciais
- Pipeline adquisición
- Intoxicación por artefactos
Todo desde un ficheiro de rexistro indexado publicamente.
5. Por que rexistrar "demasiado" é un problema de AppSec
A explotación forestal non é neutral. Pola contra, crea un almacén de datos secundario.
Se rexistras datos confidenciais, creas de feito unha segunda copia dos teus segredos.
Non obstante, os rexistros adoitan excluírse da modelización de ameazas. En STRIDE, isto correlacionase claramente con:
Divulgación de información
Polo tanto, seguro SDLC As prácticas deberían tratar os rexistros como:
- Artefactos relevantes para a seguridade
- Activos sensibles
- Compoñentes de infraestrutura que requiren protección
Se o teu modelo de ameazas ignora os rexistros, está incompleto.
6. Como evitar a fuga de credenciais nos ficheiros de rexistro
6.1 Segredos para deter o rexistro
Nunca rexistrar:
- Contrasinais
- tokens
- Claves API
- ID de sesión
- Cabeceiras de autorización
Mesmo en modo de depuración.
Sempre que sexa posible, implementa a redacción automática.
6.2 Rexistro estruturado e seguro
Usar rexistro estruturado con enmascaramento e filtrado.
Exemplo (Node.js):
Exemplo (Python):
O principio clave é simple: os segredos nunca deben chegar ao sumidoiro de troncos.
6.3 Almacenamento de rexistros con bloqueo
Os controis de seguridade deben incluír:
- Desactivar a listaxe de directorios
- Protexer
/logs/rutas con autenticación - Restrinxir o acceso ao depósito
- Aplicar políticas de retención
- Cifrar rexistros en repouso
Os rexistros nunca deben ser accesibles publicamente a través de HTTP.
6.4 CI/CD Guardrails
As revisións manuais son insuficientes. No seu lugar, implementa controis automatizados:
- Escaneado secreto de rexistros antes da publicación de artefactos
- Falla a compilación se se detectan tokens
- Impedir as subidas de artefactos que conteñan credenciais
- Validación hash para artefactos
CI/CD debería bloquear a exposición antes de que se produza a indexación.
7. Como impide Xygeni allintext:login tipo de ficheiro: rexistro de incidentes
O problema non é o parvo de Google. O problema é a exposición. Polo tanto, a prevención debe ocorrer antes da indexación.
7.1 Detección de segredos en rexistros e artefactos
Escaneos Xygeni:
- Rexistros de aplicacións
- CI/CD rastros de traballo
- Construír artefactos
- Capas de Docker
- Saídas serializadas
Se aparecen credenciais, tokens ou valores confidenciais en .log ficheiros, Xygeni márcaos inmediatamente.
7.2 CI/CD Guardrails Esa exposición de bloque
En lugar de depender de revisións manuais, Xygeni aplica a seguridade no pipeline nivel:
Isto:
- Falla as compilacións cando aparecen segredos nos rexistros
- Bloquea a publicación de artefactos
- Evita a exposición accidental ao público
- Detén as fusións inseguras antes de chegar ao elemento principal
Se unha tarefa de CI imprime un token, o pipeline falla.
Sen indexación.
Sen exposición.
Sen incidentes.
7.3 Protección contra maiúsculas á esquerda antes de que Google a vexa
O tempo importa.
En lugar de reaccionar a:
Xygeni detén o problema:
- At commit tempo
- Durante pull request validación
- Durante pipeline execución
- Antes da publicación do artefacto
Se o rexistro nunca se fai público, Google nunca o indexa.
Conclusión final: se Google pode indexalo, os atacantes xa o fixeron
Os rexistros non son inofensivos. De feito, raramente son temporais. Por defecto, non son privados. Polo tanto, cada ficheiro de rexistro debe tratarse como un activo relevante para a seguridade, non só como saída de depuración.
Se os datos sensibles chegan a un .log ficheiro e se fai accesible publicamente, convértese inmediatamente nunha superficie de ataque. Ademais, unha vez indexado por un motor de busca, a exposición escala fóra do teu control.
A solución non é deter o rexistro. Pola contra, trátase de rexistrar de forma responsable e aplicar controis estritos sobre o almacenamento e a distribución. Noutras palabras, a seguridade debe estenderse máis alá da propia aplicación e ata a capa de observabilidade.
No seu lugar:
- Deixar de rexistrar segredos
- Bloquear o almacenamento de rexistros
- Cumprir pipeline guardrails
- Automatizar a detección e a aplicación de políticas
En última instancia, a prevención ten que ver co momento oportuno. Porque unha vez allintext:login tipo de ficheiro: rexistro devolve o teu dominio, o incidente xa comezou.
