- Serviços de análise de URLs/malware como urlscan.io, Hybrid Analysis e Cloudflare Radar URL Scanner armazenam links para compartilhamento de inteligência de ameaças, mas links sensíveis podem acabar como dados públicos devido a erro do usuário ou scanners mal configurados
- Serviços em que a própria URL funciona como uma forma de autorização de acesso, como Dropbox, iCloud, AWS S3, Zoom, OneDrive, Airtable, links de redefinição de senha e links de login OAuth, podem ser especialmente afetados
- Nem todos os links ficam expostos imediatamente, mas materiais como documentos fiscais, faturas, fotos, comunicações de trabalho, segredos compartilhados via onetimesecret, gravações de smart home e de reuniões foram de fato encontrados
- O urlscan Pro mostra a clientes pagos não apenas scans Public, mas também scans Unlisted, e pode haver caminhos em que links são enviados involuntariamente como unlisted, como na configuração do Cortex-Analyzers do TheHive
- Nas últimas 24 horas, os volumes de scans no urlscan.io foram 398.563 Public, 328.147 Unlisted e 955.432 Private; em um experimento com tokens canário, também foi confirmado acesso até 1 hora após o envio, indicando a necessidade de gerenciar a visibilidade dos scans
Links sensíveis que ficam em serviços de análise de URLs
- urlscan.io, Hybrid Analysis e Cloudflare Radar URL Scanner armazenam muitos links para análise de URLs e malware
- O problema é que links privados e sensíveis também podem entrar nesses repositórios
- Usuários enviam links sensíveis para análise sem saber que eles se tornarão informação pública
- Scanners ou extensões mal configurados enviam, como dados públicos, links privados escaneados em e-mails
Links e materiais que podem ser expostos
- Os links encontrados incluem URLs de compartilhamento de vários serviços e URLs relacionadas a autenticação
- Compartilhamento de arquivos em armazenamento em nuvem como Dropbox, iCloud, Sync, Egnyte, Ionos Hidrive e AWS S3
- NAS conectados à nuvem, como Western Digital Mycloud
- Ferramentas de comunicação corporativa como Slido, Zoom, OneDrive e Airtable
- Links de redefinição de senha e links de login OAuth
- Esses serviços muitas vezes permitem acesso, por questões de segurança, por meio de um único link privado que contém um identificador aleatório
- Alguns links têm proteção adicional por senha ou passphrase, portanto apenas acessar o link nem sempre expõe os dados de imediato
- Conteúdos sensíveis encontrados na prática incluem:
- Arquivos privados como documentos fiscais, faturas, fotos e comunicações de trabalho
- Segredos compartilhados pelo onetimesecret
- Gravações de dispositivos de smart home
- Gravações de reuniões armazenadas na nuvem
Caminhos de envio e lacunas de responsabilidade
- Muitos envios verificados no urlscan.io tinham a tag falconsandbox, o que levou a ampliar a análise também para o Hybrid Analysis
- O Cloudflare Radar também pode ser usado de forma mais ampla e já inclui alguns links privados como dados públicos
- Os termos do Hybrid Analysis afirmam que conteúdos enviados por usuários podem ser analisados, publicados e compartilhados, e que o serviço não se responsabiliza por informações incluídas acidentalmente em envios ou relatórios gerados automaticamente
- Os termos do urlscan.io também afirmam que o serviço não se responsabiliza por conteúdo ou ações dos usuários, e que conteúdos e atividades publicados sob uma conta são responsabilidade do usuário
- Não parece haver um mecanismo claro para revisar conteúdo existente e marcar ou remover links sensíveis, e automatizar isso talvez não seja simples
- A análise da Positive Security usou tokens canário contra o urlscan.io para detectar origens automatizadas e aborda a possibilidade de que ferramentas de segurança que escaneiam links maliciosos em e-mails sejam a causa
- O mesmo comportamento também foi validado com links canário
Scans Unlisted e acesso pelo urlscan Pro
- O urlscan Pro oferece a usuários pagos e empresas acesso a um escopo mais amplo de scans, incluindo não só Public, mas também scans Unlisted
- No urlscan.io, Unlisted não aparece em páginas públicas nem em resultados de busca, mas fica visível para clientes da plataforma urlscan Pro
- A documentação informa que clientes do urlscan Pro são limitados a pesquisadores de segurança verificados ou empresas de boa reputação
- O Cortex-Analyzers do TheHive é um exemplo que mostra um caminho de exposição não intencional
- O analisador do urlscan.io usa explicitamente a configuração
public:on - Por causa dessa configuração, mesmo que a visibilidade da conta no urlscan seja Private, o link pode aparecer como unlisted
- O código relacionado está em urlscan.py do Cortex-Analyzers
- O analisador do urlscan.io usa explicitamente a configuração
- Nesse caso, ainda que os dados não sejam totalmente públicos, eles podem ser vistos por usuários do urlscan Pro, mantendo a possibilidade de exposição de informações mais sensíveis
Volume de scans e resultados com tokens canário
- O volume de scans no urlscan.io nas últimas 24 horas foi:
Public: 398.563Unlisted: 328.147Private: 955.432
- Os resultados de acesso verificados com tokens canário foram:
- Um link enviado ao urlscan.io como
unlistedrecebeu 12 acessos até 1 hora após o envio - Um link enviado ao Hybrid Analysis via
API, e não por navegador, recebeu 10 acessos até 1 hora após o envio - Alguns endereços IP acessaram simultaneamente links únicos enviados aos dois serviços e usavam serviços de anonimização de IP de origem
- Um link enviado ao urlscan.io como
- A lista desses endereços IP foi publicada em um arquivo separado
Remoção de links sensíveis e cuidados de uso
- urlscan.io e Hybrid Analysis oferecem procedimentos para denunciar e remover links
- No Hybrid Analysis, remoção e escopo de compartilhamento são mais complexos
- Todos os arquivos enviados ao Public Sandbox são pesquisáveis e disponibilizados globalmente
- Mesmo ao marcar a caixa “Do not share my sample with the community”, capturas de tela e o relatório real continuam disponíveis
- “do not share” se aplica apenas à amostra de entrada propriamente dita
- Ao usar esses serviços, é preciso verificar primeiro a visibilidade do scan
- Ao acessar links ou arquivos nesses bancos de dados de URLs, você pode encontrar tentativas de phishing, arquivos realmente maliciosos e links maliciosos
- Se o acesso for necessário, ele deve ser feito em um ambiente de sandbox
1 comentários
Opiniões no Hacker News
O problema fundamental é que links sem controle de acesso são considerados privados só porque não há um índice público de identificadores
No mês passado, uma discussão sobre encontrar IDs de contas da AWS por meio de buckets também fez bastante sucesso no HN[0], e o consenso nos comentários foi que é errado contar com segurança baseada na premissa de que identificadores de conta são privados
O mesmo conceito se aplica aqui; não é exatamente uma nova questão de segurança, mas apenas mais um método de exploração baseada em operadores de busca (dorking)
[0]: https://news.ycombinator.com/item?id=39512896
Em teoria, um link hexadecimal de 256 caracteres, ou seja, 1024 bits, é muito mais difícil de adivinhar do que um nome de usuário de 32 caracteres e uma senha de 32 caracteres
https://site.com/[256chars] tem 2^1024 combinações, então força bruta é praticamente impossível
Já https://site,com/[32chars] e uma senha de 32 caracteres têm 2^256 combinações, o que também é quase impossível, mas ainda mais provável do que o primeiro caso
É como ver algo do tipo https://site,com/[32chars][32chars]
Ainda assim, mesmo que o primeiro seja mais difícil de acertar, URLs vazam muito mais do que senhas
Aqui, mensagem inclui amplamente e-mails, DMs e até links colados em documentos
Fiquei desconfortável e acabei escolhendo outra abordagem, mas continuei pensando em quão diferente é, na prática, ter o “segredo” dentro da URL versus ter o segredo em um token enviado ao fazer a requisição da URL
Minha conclusão é que tokens podem ser emitidos por cliente, e você pode monitorar logs de acesso para detectar comportamento suspeito e revogá-los
Como outras pessoas disseram, também há uma diferença de mentalidade sobre quão importante você considera manter a lista de nomes de arquivos em segredo
Na escala das coisas em que a Amazon pode errar, expor acidentalmente a lista de nomes de arquivos de um bucket público parece algo com que 99% dos usuários não se importariam, então a prioridade parece baixa
Naturalmente, nossa empresa perdeu essa disputa
Desde então, ficou a pequena lição de que, sempre que uso AWS, normalmente nomeio buckets no formato -
Se precisa ser realmente privado, basta criptografar também o nome do projeto e fornecer um script que liste os buckets com nomes “amigáveis”
Serviços de hospedagem sempre têm compromissos estranhos, e é bem provável que a abordagem tecnicamente perfeita, com identificadores totalmente aleatórios, gere uma carga operacional muito maior do que a abordagem imperfeita de nomes descritivos
Bitwarden Send cria um link que pode ser enviado a outra pessoa, com uma longa string aleatória depois do
#Uso isso regularmente e gostaria de saber se há algum problema de segurança
Pelo menos o link pode ser revogado e também expirar automaticamente depois de alguns dias, enquanto senhas comuns normalmente não funcionam assim
Para criar um link de compartilhamento privado, basta armazenar o valor privado na parte de hash da URL
O hash não é enviado em consultas DNS nem em requisições HTTP
Por exemplo, ao visitar links.com?token=, esse link é enviado incluindo os parâmetros de busca e pode ser armazenado por intermediários como a Cloudflare
Já ao visitar links.com#, a parte de hash não sai do navegador
Ao lidar com dados na parte de hash, é conveniente codificá-los como uma string Base64 URL Safe
Ou seja, o fluxo é JS Object ↔ JSON String ↔ URL Safe Base 64 String
O restante está certo; eu só queria acrescentar essa nuance da criptografia HTTPS
Colocar no fragmento ajuda, mas não é perfeito
Não estou falando só idealmente; já vi tokens privados em fragmentos vazarem dessa forma várias vezes na prática
[https://example.com?token=](<https://example.com?token=<secret>>;) deveria gerar uma consulta DNS apenas para “example.com”
Bots que seguem links em e-mails executam JavaScript? Existe o risco de que um POST induzido por JavaScript acione uma ação real?
Links que não fazem parte de um loop rápido de redirecionamento inevitavelmente serão copiados e colados para compartilhamento
URLs foram criadas para isso: são universais e facilitam o acesso a recursos oferecidos por algum protocolo
Controle de acesso para algo que não tenha vida curta deve ser feito fora da URL
Se você compartilha um link por um canal que não tem criptografia de ponta a ponta, o primeiro agente a acessar essa URL não é o destinatário, mas o serviço do canal
Pode ser legítimo, como o Bitwarden buscando favicons por causa da experiência do usuário, ou malicioso, como um crawler do Facebook Messenger querendo saber mais sobre o que é compartilhado em mensagens privadas
Essas ferramentas de scanner não vão tornar a experiência do usuário melhor
Se deixarem explícito que os resultados da varredura serão públicos, alguns usuários vão pensar duas vezes antes de usar o serviço, e isso é ruim para o negócio, sejam usuários gratuitos ou usuários com licença Pro
Links “privados” que podem ser usados sem limite sempre me pareceram um pouco suspeitos
No fim, é segurança baseada em obscuridade
Ao compartilhar algo como um documento do Google, pelo menos existe uma opção que deixa explícito: “qualquer pessoa com o URL pode acessar”
Quando precisei desse tipo de coisa em sistemas que criei, normalmente usei URLs assinadas com duração de apenas alguns minutos
Em geral, o URL é um detalhe de implementação e não é mostrado diretamente ao usuário, mas pode ser visto nas telas de debug do navegador
Se, na internet, algo assim não é protegido por nada além de uma string aleatória dentro do URL, então, na prática, não é privado
É a mesma história das webcams conectadas à internet que aparecem quando você procura
Isso já não era sabido? Não entendo por que a seção “quem é o responsável” não trata disso de forma alguma
Nem tudo precisa do nível máximo de segurança e, em alguns casos, basta uma barreira contra compartilhamento amplo
Por exemplo, se em uma galeria de fotos você clica em “criar compartilhamento por link” para enviar o link de uma foto a alguém, você não quer que essa pessoa precise digitar uma senha
Ao abrir o link, a foto deve aparecer, e para esse uso está tudo bem
Um dos exemplos aqui é exatamente esse caso, e ele se encaixa nesse caso de uso
Mesmo do ponto de vista de preocupações com privacidade, ainda que houvesse um processo de login, o usuário final poderia, naquele momento, compartilhar de novo uma captura de tela
A segurança é adequada ao caso de uso
É uma situação em que o usuário agora tem o link da foto e também poderia compartilhá-lo novamente, mas você confia que ele não fará isso intencionalmente
O grande problema aqui não é tanto o link em si, mas o fato de ferramentas de análise de segurança escanearem todos os links que o usuário recebeu por email e os tornarem acessíveis também a outros usuários daquela comunidade
Isso é um recompartilhamento muito maior do que eu pretendia ao enviar uma foto a alguém
Uma forma de contornar esse problema de autenticação baseada em email, sem chegar à criação de uma conta com senha, é usar um código temporário de uso único
Assim, se o URL for compartilhado por engano, isso não vira um grande problema
Fugindo do assunto, mas o link leva ao Cloudflare Radar, e esse serviço apparently parece minerar dados do 1.1.1.1
Eu achava que o 1.1.1.1 não usava dados dos usuários para nenhum fim
Gostaria que alguém mais inteligente explicasse. Qual é a diferença entre estes dois?
Supondo que ambos tenham a mesma proteção contra força bruta ou limitação de taxa, ou que nenhum dos dois tenha, por que 1 é mais seguro que 2?
Na prática, há diferença
Segredos baseados em posse e segredos baseados em conhecimento são diferentes
Um URL é algo que você possui; se você o deixar em um lugar acessível, ele pode ser tomado
Uma senha é algo que você sabe e, se bem administrada, não pode ser tomada. Exceto em um ataque com cano de chumbo
Outro tipo é o baseado em biometria, como escaneamento de retina ou impressão digital
Em (1), para autenticação, é necessária uma informação por um caminho separado, e é uma informação que as pessoas estão acostumadas a guardar com segurança
Já o URL de (2) é tratado como URL
URLs são frequentemente registrados em logs, gravados, compartilhados e repassados por aí
Por exemplo, se o firewall de uma empresa registrasse o nome de usuário e a senha usados para entrar em algum serviço, isso seria obviamente ruim, mas registrar os URLs acessados provavelmente pareceria aceitável
Este último é apenas um exemplo; por causa das garantias fim a fim do TLS, nenhum dos dois deveria ser acessível
Além disso, se domain.com/12-char-password for solicitado sem HTTPS, mesmo que haja redirecionamento, a primeira requisição é enviada sem criptografia, permitindo ataque man-in-the-middle
Já em uma página de login há mais formas de garantir que o envio da senha ocorra somente via HTTPS
Um dos grandes problemas é que muitos aplicativos de logging registram o URL completo em algum lugar, o que, na prática, faz a “senha” ir parar nos logs
Todas as mídias e fotos enviadas para apps privados do airtable.com são links públicos
Se você souber o URL, consegue acessá-las sem autenticação
Uma tag de imagem comum não permite definir um cabeçalho Authorization contendo um token na requisição, como se faz com fetch() em chamadas de API
As únicas opções possíveis são adicionar um token ao URL ou usar autenticação por cookies
Autenticação por cookies só funciona quando o CDN está no mesmo domínio, e até subdomínios podem causar problemas em muitos casos
Concordo que pode ser potencialmente problemático
Links de reunião do Zoom muitas vezes incluem a senha como parâmetro de consulta
Esse link é um link de “segurança por não divulgação”? Um link sem a senha é um link de “segurança por não divulgação”?
porque, quando a URL aparecer em outro lugar, essa reunião provavelmente já terá terminado e desaparecido
Mas, na prática, ninguém se importa com isso e todos querem “clicar para entrar”, sem precisar digitar um monte de coisas
O método anterior de “usar só o ID da reunião” era fácil demais de adivinhar