Os mecanismos de busca foram criados para indexar conteúdo. No entanto, os atacantes os utilizam para indexar seus erros. A consulta todo o texto:Conecte-se tipo de arquivo:log Pode parecer inofensivo. Na realidade, é uma das maneiras mais simples de descobrir arquivos de log expostos que contêm fluxos de autenticação, credenciais, tokens e dados de infraestrutura interna.
Se o Google consegue ver esses registros, os invasores também conseguem. Uma vez indexados, a exposição torna-se inevitável. Além disso, quando as credenciais aparecem em um arquivo de acesso público, a violação já está em andamento.
1. Por que usar apenas o texto?Conecte-se O tipo de arquivo "log" é mais perigoso do que parece.
Um dork do Google é uma consulta de pesquisa que usa operadores avançados para localizar conteúdo sensível ou mal configurado indexado pelos mecanismos de busca. Ele não explora o Google, mas sim a sua vulnerabilidade.
Esta consulta combina dois operadores:
- todo o texto: Retorna páginas onde todos os termos aparecem no corpo do texto.
- tipo de arquivo:log restringe os resultados a
.logarquivos
Assim sendo:
allintext:Conecte-se filetype:log
Significa: "Mostre-me os arquivos de log que contêm a palavra Conecte-se. "
À primeira vista, isso parece trivial. No entanto, na prática, muitas vezes resulta em:
- Registros de servidor web expostos publicamente
- CI/CD Registros enviados como artefatos
- Registros de depuração acidentalmente committed para repositórios
- Registros de aplicativos com credenciais em texto simples
Isso não é um bug do mecanismo de busca. Em vez disso, é um vulnerabilidade de exposição de dados causado por uma configuração incorreta. O Google simplesmente indexou o que estava publicamente acessível.
2. O que os atacantes realmente encontram nos arquivos de log expostos
Quando os atacantes fogem todo o texto:Conecte-se tipo de arquivo:logEles não estão navegando aleatoriamente. Estão procurando por rastros de autenticação.
2.1 Credenciais em texto simples
Os registros frequentemente contêm entradas como:
POST /Conecte-se username=admin password=SuperSecret123or
Authorization: Basic YWRtaW46cGFzc3dvcmQ=
Ou até mesmo credenciais SMTP:
smtp_user=mailer
smtp_pass=ProdMailPass!Registrar os dados de autenticação é uma das maneiras mais rápidas de vazar credenciais de produção. Consequentemente, um único arquivo de log exposto pode invalidar todo o seu modelo de controle de acesso.
2.2 Tokens de Sessão e JWTs
Mesmo quando as senhas não são registradas, os tokens geralmente são.
Por exemplo:
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Set-Cookie: session=abc123xyz789;
Generated API token: sk_live_ABC123SECRETUm JWT válido ou um cookie de sessão dentro de um .log O arquivo pode habilitar:
- Seqüestro de sessão
- Escalonamento de privilégios
- Movimento lateral através de sistemas internos
Em outras palavras, os tokens nos registros transformam a saída de depuração em um vetor para burlar a autenticação.
2.3 CI/CD Artefatos
Os registros de compilação são especialmente perigosos. Na verdade, CI/CD Os sistemas frequentemente imprimem variáveis de ambiente durante as etapas de compilação.
Os atacantes frequentemente descobrem:
Contendo frases como:
AWS_ACCESS_KEY_ID=AKIA...
DATABASE_URL=postgres://admin:password@internal-db:5432/appIf CI/CD Se os artefatos são públicos, então os segredos também são públicos. O dork do Google simplesmente acelera a descoberta.
2.4 Dados de Nuvem e Infraestrutura
Os registros expostos frequentemente revelam:
- Chaves de acesso da AWS
- Cadeias de conexão do armazenamento do Azure
- URLs de serviço interno
- Credenciais do banco de dados
- Pontos de extremidade do Redis
Mesmo que as credenciais sejam rotacionadas posteriormente, o atacante agora possui:
- Mapeamento de infraestrutura
- Convenções de nomeação
- Informações sobre alvos para ataques futuros
Portanto, os registros expostos fornecem tanto acesso quanto reconhecimento.
3. Como esses registros se tornam públicos em primeiro lugar
Os registros não aparecem magicamente no Google. Eles são indexados porque estavam publicamente acessíveis.
3.1 Servidores Web mal configurados
Os padrões comuns incluem:
/logs/diretórios acessíveis sem autenticação- Listagem de diretório ativada
- Nginx ou Apache servindo raw
.logarquivos
Se um registro de logs for acessível via HTTP, ele é indexável.
3.2 CI/CD Exposição de Artefatos
Erros típicos:
- Artefatos públicos habilitados em Ações do GitHub
- Registros enviados para buckets S3 abertos.
- Pipeline rastros acessíveis sem autenticação
A pipeline Quem armazena registros em um bucket público está, na prática, publicando seus segredos.
3.3 Modo de depuração em produção
As configurações padrão do framework podem ser perigosas:
APP_DEBUG=trueAlém disso, o registro excessivo de solicitações pode imprimir:
- Cabeçalhos
- Tokens
- Corpos de solicitação completos
O registro de depuração em produção transforma seu aplicativo em um exportador de credenciais.
3.4 Logs do Docker e de contêineres
Os ambientes conteinerizados introduzem novos caminhos de exposição:
- Registros montados em volumes compartilhados
- Sidecars exportando logs para endpoints não seguros
- Folhas para dashboards com acesso público
Se os registros do contêiner forem expostos via HTTP ou armazenamento aberto, eles poderão ser pesquisados. Eventualmente, serão indexados.
4. Fluxo de Ataque Realista: Da Base à Invasão
Uma cadeia de ataque típica se parece com isto:
O atacante executa:
allintext:Conecte-se filetype:log- Descobre exposto
.loglima - extratos:
- Token JWT
- Cabeçalho de autenticação básica
- Cadeia de conexão do banco de dados
Tentativas de autenticação contra:
- Endpoints API
- Painéis de administração
- Serviços internos
Se a autenticação for bem-sucedida, o atacante poderá:
- Escalar privilégios
- Mova-se lateralmente
- Acesso a CI/CD
- Comprometer a cadeia de suprimentos
O que começou como uma consulta de pesquisa se transforma em:
- Seqüestro de sessão
- Inserção interna de credenciais
- Pipeline assumir o controle
- envenenamento por artefato
Tudo isso a partir de um arquivo de log indexado publicamente.
5. Por que registrar informações em excesso é um problema de segurança de aplicativos
O registro de logs não é neutro. Em vez disso, cria um armazenamento de dados secundário.
Ao registrar dados confidenciais, você cria efetivamente uma segunda cópia de seus segredos.
No entanto, os registros de logs são frequentemente excluídos da modelagem de ameaças. No contexto do STRIDE, isso se traduz claramente em:
Divulgação de informação
Portanto, Seguro SDLC As práticas devem tratar os registros como:
- Artefatos relevantes para a segurança
- Ativos sensíveis
- Componentes de infraestrutura que requerem proteção
Se o seu modelo de ameaças ignora os registros, ele está incompleto.
6. Como evitar o vazamento de credenciais em arquivos de log
6.1 Pare de Registrar Segredos
Nunca faça Conecte-se:
- senhas
- Tokens
- Chaves API
- IDs de sessão
- Cabeçalhos de autorização
Mesmo em modo de depuração.
Sempre que possível, implemente a redação automática.
6.2 Registro Estruturado e Seguro
Utilize registro estruturado com mascaramento e filtragem.
Exemplo (Node.js):
const logger = require('pino')({
redact: ['req.headers.authorization', 'body.password']
});Exemplo (Python):
class RedactFilter(logging.Filter):
def filter(self, record):
record.msg = record.msg.replace("password=", "password=***")
return TrueO princípio fundamental é simples: os segredos nunca devem chegar ao local de registro de eventos.
6.3 Armazenamento de logs de bloqueio
Os controles de segurança devem incluir:
- Desativar listagem de diretórios
- Proteja
/logs/caminhos com autenticação - Restringir o acesso ao bucket
- Aplicar políticas de retenção
- Criptografar registros em repouso
Os registros nunca devem ser acessíveis publicamente via HTTP.
6.4 CI/CD Guardrails
As revisões manuais são insuficientes. Em vez disso, implemente controles automatizados:
- Análise secreta de registros antes da publicação do artefato
- As compilações falharão se forem detectados tokens.
- Impedir o envio de artefatos que contenham credenciais.
- Validação de hash para artefatos
CI/CD deve bloquear a exposição antes que a indexação ocorra.
7. Como o Xygeni impede o allintext:Conecte-se tipo de arquivo: log Incidentes
O problema não é o dork do Google. O problema é a exposição. Portanto, a prevenção deve ocorrer antes da indexação.
7.1 Detecção de segredos em logs e artefatos
Exames Xygeni:
- Logs de aplicativos
- CI/CD rastros de trabalho
- Construir artefatos
- Camadas do Docker
- Saídas serializadas
Se credenciais, tokens ou valores confidenciais aparecerem em .log Os arquivos são sinalizados imediatamente pelo Xygeni.
7.2 CI/CD Guardrails Essa exposição ao bloqueio
Em vez de depender de revisões manuais, Xygeni reforça a segurança em pipeline nível:
dotnet xygeni enforce --rules secrets,artifacts,logs --fail-on-riskEste:
- A compilação falha quando segredos aparecem nos registros.
- Publicação de artefatos de blocos
- Previne a exposição acidental do público.
- Impede fusões inseguras antes de chegar à linha principal.
Se um trabalho de CI imprimir um token, o pipeline falha.
Sem indexação.
Sem exposição.
Sem incidentes.
7.3 Proteção contra deslocamento à esquerda antes que o Google a veja
O tempo é importante.
Em vez de reagir a:
allintext:Conecte-se filetype:logXygeni resolve o problema:
- At commit tempo
- durante pull request validação
- durante pipeline execução
- Antes da publicação do artefato
Se o registro nunca se tornar público, o Google nunca o indexará.
Conclusão final: se o Google consegue indexar, os atacantes já o fizeram.
Os registros não são inofensivos. Na verdade, raramente são temporários. Por padrão, não são privados. Portanto, todo arquivo de registro deve ser tratado como um recurso relevante para a segurança, e não apenas como uma saída de depuração.
Se dados sensíveis forem atingidos por um .log e torna-se publicamente acessível, Ela se transforma imediatamente em uma superfície de ataque. Além disso, uma vez indexado por um mecanismo de busca, a exposição fica fora do seu controle.
A solução não é parar de registrar logs. Em vez disso, é registrá-los de forma responsável e impor controles rigorosos em relação ao armazenamento e à distribuição. Em outras palavras, a segurança deve ir além do próprio aplicativo e alcançar a camada de observabilidade.
Em vez de:
- Pare de registrar segredos
- Bloquear armazenamento de registros
- aplicar pipeline guardrails
- Automatize a detecção e a aplicação de políticas.
Em última análise, A prevenção tem a ver com o momento certo. Porque uma vez que... todo o texto:Conecte-se tipo de arquivo:log Ao retornar seu domínio, o incidente já começou.
