Se os israelenses chamaram atenção para essa falha agora pode apostar que já exploraram a exaustão.
Pelo que eu entendi, envolveria XSS contra o que estivesse hospedado em 0.0.0.0 que no caso é um endereço especial que simboliza todas as interfaces IPv4 da stack atual de rede. Só aí já temos requisitos para que isso ocorra:
- O sistema operacional deve ser Unix-based (Mac OS, Linux, FreeBSD e afins)
- O sistema deve ter algum daemon na porta 80 ou na 443
- O sistema deve ter um daemon que responda HTTP(s) nessa porta
- O serviço HTTP(s) deve ter
Access-Control-Allow-Originpermissivo - O serviço HTTP(s) deve ser uma API (seja REST ou SOAP, via XML)
- O daemon precisa estar rodando não sob um usuário e grupo de serviço mas sim de root (por exemplo, lighttpd tem um usuário e grupo de mesmo nome, que isola o daemon do ambiente root)
- O daemon precisa poder invocar comandos shell e/ou programas, ou então ter alguma conectividade com o DBus, ou ainda precisa poder executar tarefas que sejam destrutivas o suficiente para a rede local, como acessar e chamar zeroconf, Avahi, uPnP ou similares)
- O usuário precisa acessar uma página que use JavaScript pra internamente requisitar (possivelmente via fetch API ou manipulação de iframe, embora nesse caso precisa também de um cabeçalho
X-Frame-Optionspermissivo ou ausente, o que nesse último caso vai depender da política permissiva nas flags do chromium) - A API precisa ter falhas seríssimas como permitir chamadas sem autenticação, senha em branco, etc.
- (Edit: esqueci de citar o mais óbvio: ) A depender da stack usada, o daemon precisa estar ouvindo em todas as interfaces IPv4 (não pode ser um IPv6 only, portanto, e nem pode ser um daemon no 127.0.0.1 ou em uma interface específica)
Só aí já dá pra ver que trata-se de uma situação extremamente específica. Não é qualquer um que vai estar rodando *nix com um daemon na porta 80/443, em root ou com potencial pra fazer coisas (como permitir, por exemplo, que um site exploite um Proxy local de uma API de smart ar condicionado e leve o usuário à hipotermia, ou desativar o controle de corrente de um no-break a ponto de causar um estouro da bateria interna e incendiar a casa, e ainda assim teriam mais poréns pra isso acontecer). Já começa que é um usuário *nix com um daemon rodando, ou seja, não trata-se de um leigo. Pode ser um técnico bem despreocupado com a segurança de seu sistema, mas aí não há sistema de segurança que seja suficiente pra proteger um usuário avançado despreocupado.
EDIT 2: Fiz um teste aqui, com um código bem simples instanciando um Express.js (e retornando um JSON qualquer) e tentando requisitar 0.0.0.0 a partir do DevTools em algum domínio de internet, e, como eu deixo bem claro no comentário a especificidade de variáveis nesse tipo de exploração, não foi nada fácil conseguir que a requisição sucedesse de primeira. Além do Access-Control-Allow-Origin que eu mencionei, descobri outra header que desconhecia, Access-Control-Allow-Private-Network que precisa estar como true. Como a maioria dos sites são em HTTPS, HTTP-only definitivamente não funciona, exigindo um certificado para a conexão ocorrer. Como estamos falando de uma rede local, o certificado usado jamais terá validade para 127.0.0.1 e muito menos para 0.0.0.0 pois não existe certificado localhost confiável por autoridade certificadora, a menos que o certificado seja autoassinado e também importado no Certstore, caso contrário, o erro de ERR_CERT_AUTHORITY_INVALID impedirá que o Fetch/XHR retorne alguma coisa, porque a conexão será barrada. Novamente, muito se para que ocorra esse “acesso remoto”.
Os navegadores atuais, sobretudo o Chromium, possuem inúmeras travas e muitas vezes nós, que mexemos com desenvolvimento, temos que inicializar o browser a partir de linha de comando com flags bem específicas para permitir o ambiente de desenvolvimento funcionar. E, nesse ambiente, obviamente o desenvolvedor não vai ficar acessando qualquer site, porque é um ambiente de desenvolvimento e não um ambiente doméstico.
penso igual
muito boa a analise.