Links de segurança privados sem acesso público, será mesmo?
- Ferramentas populares de análise de malware/URL como urlscan.io, Hybrid Analysis e o scanner de URL do Cloudflare Radar armazenam grandes volumes de links para coleta e compartilhamento de informações.
- Não é amplamente conhecido que esses serviços estejam armazenando links privados e sensíveis que foram enviados por engano por usuários ou escaneados como dados públicos por scanners e extensões mal configurados.
Que tipo de links são esses?
- Arquivos compartilhados usando ferramentas de armazenamento em nuvem (
Dropbox, iCloud, Sync, Egnyte, Ionos Hidrive, AWS S3 etc.).
- Ferramentas de NAS conectadas à nuvem (
Western Digital Mycloud etc.).
- Comunicação corporativa (
Slido, Zoom, Onedrive, Airtable etc.).
- Links de redefinição de senha, links de login OAuth e outros.
- Esses serviços têm em comum o uso de um único link privado com identificadores aleatórios para permitir acesso ao serviço. Às vezes, também contam com proteção adicional por senha ou frase secreta; nesse caso, acessar o link não necessariamente resulta em exposição de dados.
Quem deve ser responsabilizado?
- Segundo os termos de uso do Hybrid Analysis e do urlscan.io, a responsabilidade pelo conteúdo enviado é do usuário, e não existe um mecanismo para revisar e remover links sensíveis.
- Implementar isso de forma automatizada também pode não ser algo simples.
- Como pesquisador de segurança, é difícil rastrear a origem desses links.
Somos caçadores de ameaças! Todos os links nos pertencem!
- O urlscan Pro permite que usuários/empresas pagantes acessem não apenas varreduras
Public, mas também Unlisted.
Unlisted não aparece em páginas públicas nem em resultados de busca, mas é visível para clientes da plataforma urlscan Pro.- Os Cortex-Analyzers do TheHive usam explicitamente a configuração
public:on no analisador do urlscan.io, fazendo com que os links apareçam como unlisted.
- Para usuários do urlscan Pro, os dados não são públicos, mas são acessíveis, o que aumenta o risco de vazamento de informações sensíveis.
Como remover links sensíveis?
- Urlscan e Hybrid Analysis permitem sinalizar links para remoção.
- No caso do Hybrid Analysis, todos os arquivos enviados para o sandbox público podem ser pesquisados e ficam públicos para o mundo todo.
Conclusão
- É certo que esse problema continuará existindo, mas manter as varreduras privadas por padrão pode ser a melhor solução, embora isso não esteja alinhado com o objetivo das práticas de compartilhamento de inteligência de ameaças e análise na comunidade de segurança.
- Ao usar esses serviços, é preciso prestar atenção à visibilidade das varreduras.
Isenção de responsabilidade
- Se você optar por acessar esses links/arquivos no banco de dados de URLs, tome cuidado com arquivos e links realmente maliciosos.
- Alguns podem ser simples tentativas de phishing e podem conter malware real.
- Recomenda-se o uso de um ambiente sandbox.
Links úteis
- SOAR spot do urlscan.io: Chatty security tools leaking private data (2022)
- urlscan.io Search API Reference
- Falcon Sandbox Public API
- Cloudflare Radar URL Scanner
Opinião do GN⁺
- Este artigo chama a atenção de pesquisadores de segurança e usuários em geral ao mostrar como ferramentas de segurança podem expor informações sensíveis por engano.
- Esse tipo de problema pode surgir por erro do usuário ou configuração incorreta das ferramentas, o que exige mais cuidado e responsabilidade no tratamento de informações sensíveis dentro da comunidade de segurança.
- O artigo também reforça a importância de quais medidas indivíduos e empresas devem tomar para proteger seus dados.
- Sob uma perspectiva crítica, esse tipo de vazamento pode representar uma ameaça grave à privacidade individual e à confidencialidade corporativa, levantando dúvidas sobre a confiabilidade de ferramentas e serviços de segurança.
- Outros projetos com funcionalidades semelhantes incluem plataformas de análise de malware como VirusTotal e Any.run, e ao usar esses serviços é sempre importante avaliar cuidadosamente se os dados serão públicos ou não.
1 comentários
Comentários do Hacker News
O problema fundamental é que o link não tem controle de acesso e se presume que seja privado porque não existe um índice público. Houve bastante repercussão no Hacker News sobre descobrir IDs de contas AWS por meio de buckets, e o consenso nos comentários foi que depender da privacidade de um identificador de conta como parte da segurança é uma abordagem equivocada. Isso é apenas mais um método de "dorking".
Para criar um link que possa ser compartilhado de forma privada, é preciso armazenar a informação secreta na parte de hash da URL. O hash não é incluído em consultas DNS nem em requisições HTTP. Por exemplo, um link no formato
links.com#<secret>não sai do navegador. É recomendável codificar os dados da parte de hash em uma string Base64 segura para URL.Sempre desconfiei de links "privados" que podem ser usados infinitamente. Isso é apenas segurança por obscuridade. É melhor quando há uma opção explícita, como no Google Docs, de "qualquer pessoa com a URL pode acessar". No sistema que o autor construiu, são usadas URLs assinadas de curta duração, e essas URLs não são mostradas diretamente ao usuário.
Qualquer link que não faça parte de um loop rápido de redirecionamento será copiado e compartilhado. URLs são universais e facilitam o acesso a recursos no protocolo. O controle de acesso para qualquer coisa com duração mais que breve deve acontecer fora da URL. Ao compartilhar um link por um canal sem e2ee, o primeiro agente a acessar a URL pode não ser o destinatário, mas o próprio serviço do canal. Ferramentas de scanner desse tipo provavelmente não melhorariam a UX se deixassem explícito ao usuário que o escaneamento é público.
A solução para o problema de "autenticação baseada em e-mail" é usar códigos de uso único que não causem problema mesmo se a URL for compartilhada por engano, sem exigir a etapa de criar conta e senha. Quando o usuário visita o link "privado", o site reenvia por e-mail um código temporário com limite de tempo, e o usuário digita esse código para confirmar que possui o e-mail.
Na internet, se uma URL não tiver proteção além de uma string aleatória, ela não é realmente privada. É a mesma história de encontrar webcams conectadas à internet. Já deveríamos saber disso. Por que isso não é mencionado na seção "quem deve ser responsabilizado"?
Fugindo um pouco do assunto, há um link dizendo que o Cloudflare Radar minera dados do 1.1.1.1. Eu achava que o 1.1.1.1 não usava dados de usuários para nenhuma finalidade.
Links de reunião do Zoom frequentemente adicionam a senha como parâmetro de consulta. Esse link é um link "privado e seguro"? Sem a senha, ele é um link "privado e seguro"?
Alguém pode explicar qual dos dois casos a seguir é mais seguro?
domain.com/loginusuário: John senha: senha aleatória de 5 caracteresdomain.com/URL aleatória de 12 caracteres Assumindo a mesma proteção por aleatoriedade/limitação de taxa em ambos os casos, ou nenhuma proteção, por que o caso 1 seria mais seguro que o caso 2?Todo o conteúdo de mídia/fotos enviado para apps privados do airtable.com vira link público, acessível sem autenticação por qualquer pessoa que conheça a URL.