Divulgação total ou responsável: como são divulgadas as vulnerabilidades de segurança

Propaganda

Três semanas atrás, um sério problema de segurança no OS X 10.10.4 foi descoberto. Isso, por si só, não é particularmente interessante.

Descobertas vulnerabilidades de segurança em pacotes de software populares o tempo todoe o OS X não é exceção. O banco de dados de vulnerabilidades de código aberto (OSVDB) mostra pelo menos 1100 vulnerabilidades marcadas como "OS X". Mas o que é interessante é a maneira pela qual essa vulnerabilidade específica foi divulgada.

Em vez de contar à Apple e dar a eles tempo para resolver o problema, o pesquisador decidiu publicar sua exploração na Internet para que todos vissem.

O resultado final foi uma corrida armamentista entre a Apple e hackers de chapéu preto. A Apple teve que lançar um patch antes que a vulnerabilidade fosse armada, e os hackers tiveram que criar uma exploração antes que os sistemas em risco fossem corrigidos.

Você pode pensar que esse método específico de divulgação é irresponsável. Você pode até chamar de antiético ou imprudente. Mas é mais complicado que isso. Bem-vindo ao mundo estranho e confuso da divulgação de vulnerabilidades.

Divulgação Completa vs Responsável

Existem duas maneiras populares de divulgar vulnerabilidades para fornecedores de software.

O primeiro é chamado transparência completa. Assim como no exemplo anterior, os pesquisadores publicam imediatamente sua vulnerabilidade na natureza, dando aos fornecedores absolutamente nenhuma oportunidade de lançar uma correção.

O segundo é chamado divulgação responsável, ou divulgação escalonada. É aqui que o pesquisador entra em contato com o fornecedor antes que a vulnerabilidade seja liberada.

Ambas as partes concordam com um prazo em que o pesquisador promete não publicar a vulnerabilidade, a fim de dar ao fornecedor a oportunidade de criar e liberar uma correção. Esse período pode variar de 30 dias a um ano, dependendo da gravidade e complexidade da vulnerabilidade. Algumas falhas de segurança não podem ser corrigidas facilmente e exigem que sistemas de software inteiros sejam reconstruídos do zero.

Depois que as duas partes estiverem satisfeitas com a correção produzida, a vulnerabilidade é divulgada e recebida uma Número CVE. Eles identificam exclusivamente cada vulnerabilidade, e a vulnerabilidade é arquivada online no OSVDB.

Mas o que acontece se o tempo de espera expirar? Bem, uma de duas coisas. O fornecedor negociará uma extensão com o pesquisador. Porém, se o pesquisador não estiver satisfeito com a forma como o fornecedor respondeu ou se comportou, ou se achar que a solicitação de uma extensão não é razoável, poderá simplesmente publicá-la on-line sem uma solução pronta.

No campo da segurança, há debates acalorados sobre qual o melhor método de divulgação. Alguns pensam que o único método ético e preciso é a divulgação total. Alguns acham que é melhor dar aos fornecedores a oportunidade de corrigir um problema antes de liberá-lo para a natureza.

Como se vê, existem alguns argumentos convincentes para os dois lados.

Os argumentos a favor da divulgação responsável

Vejamos um exemplo de onde era melhor usar a divulgação responsável.

Quando falamos de infraestrutura crítica no contexto da Internet, é difícil evitar falar sobre o protocolo DNS Como alterar seus servidores DNS e melhorar a segurança da InternetImagine o seguinte: você acorda em uma bela manhã, serve uma xícara de café e senta-se no computador para começar o trabalho do dia. Antes que você realmente ... consulte Mais informação . É isso que nos permite traduzir endereços da Web legíveis por humanos (como makeuseof.com) em endereços IP.

O sistema DNS é incrivelmente complicado, e não apenas em nível técnico. Há muita confiança depositada neste sistema. Confiamos que, quando digitamos um endereço da Web, somos enviados ao lugar certo. Simplesmente há muita coisa a ver com a integridade deste sistema.

Se alguém foi capaz de interferir ou comprometer uma solicitação de DNS, há muito potencial para danos. Por exemplo, eles poderiam enviar pessoas para páginas bancárias on-line fraudulentas, permitindo assim obter seus detalhes bancários on-line. Eles poderiam interceptar seu e-mail e tráfego online através de um ataque do tipo intermediário e ler o conteúdo. Eles poderiam minar fundamentalmente a segurança da Internet como um todo. Coisas assustadoras.

Dan Kaminsky é um pesquisador de segurança bem respeitado, com um longo currículo de localização de vulnerabilidades em softwares conhecidos. Mas ele é mais conhecido pela descoberta de 2008 talvez do vulnerabilidade mais grave no sistema DNS já encontrado. Isso permitiria que alguém executasse facilmente um envenenamento de cache (ou falsificação de DNS) ataque em um servidor de nomes DNS. Os detalhes mais técnicos dessa vulnerabilidade foram explicados na conferência Def Con de 2008.

Kaminsky, ciente das conseqüências da liberação de uma falha tão grave, decidiu divulgá-la aos fornecedores do software DNS afetado por esse bug.

Vários produtos principais de DNS foram afetados, incluindo aqueles criados pela Alcatel-Lucent, BlueCoat Technologies, Apple e Cisco. O problema também afetou várias implementações de DNS fornecidas com algumas distribuições populares de Linux / BSD, incluindo aquelas para Debian, Arch, Gentoo e FreeBSD.

Kaminsky deu a eles 150 dias para produzir uma correção e trabalhou em segredo para ajudá-los a entender a vulnerabilidade. Ele sabia que esse problema era tão grave e os danos potenciais tão grandes que teria sido incrivelmente imprudente divulgá-lo publicamente sem dar aos fornecedores a oportunidade de emitir um fragmento.

Aliás, a vulnerabilidade era vazou por acidente pela empresa de segurança Matsano em uma postagem no blog. O artigo foi retirado, mas foi espelhado, e um dia após a publicação uma exploração É assim que eles o cortam: o mundo obscuro dos kits de exploraçãoOs golpistas podem usar pacotes de software para explorar vulnerabilidades e criar malware. Mas o que são esses kits de exploração? De onde eles vêm? E como eles podem ser parados? consulte Mais informação foi criado.

A vulnerabilidade de DNS de Kaminsky, em última análise, resume o cerne do argumento em favor de uma divulgação responsável e escalonada. Algumas vulnerabilidades - como vulnerabilidades de dia zero O que é uma vulnerabilidade de dia zero? [MakeUseOf explica] consulte Mais informação - são tão significativos que divulgá-los publicamente causaria danos significativos.

Mas há também um argumento convincente a favor de não dar um aviso prévio.

O Caso de Divulgação Completa

Ao liberar uma vulnerabilidade em campo aberto, você abre a caixa de uma pandora, onde indivíduos desagradáveis ​​são capazes de produzir explorações rápida e facilmente e comprometem sistemas vulneráveis. Então, por que alguém escolheria fazer isso?

Existem algumas razões. Em primeiro lugar, os fornecedores costumam demorar bastante para responder às notificações de segurança. Forçando efetivamente suas mãos, liberando uma vulnerabilidade à natureza, eles ficam mais motivados a responder rapidamente. Pior ainda, alguns estão inclinados não divulgar Por que as empresas que mantêm uma violação de segredo podem ser uma coisa boaCom tantas informações on-line, todos nos preocupamos com possíveis violações de segurança. Mas essas violações podem ser mantidas em segredo nos EUA para protegê-lo. Parece loucura, então o que está acontecendo? consulte Mais informação o fato de estarem enviando software vulnerável. A divulgação completa obriga a ser honesto com seus clientes.

Mas também permite que os consumidores façam uma escolha informada sobre se desejam ou não continuar usando um software vulnerável. Eu imagino que a maioria não faria.

O que os fornecedores querem?

Os fornecedores realmente não gostam da divulgação completa.

Afinal, é incrivelmente ruim para eles e coloca seus clientes em risco. Eles tentaram incentivar as pessoas a divulgar vulnerabilidades de forma responsável por meio de programas de recompensas por bugs. Estes foram notavelmente bem-sucedidos, com o Google pagando US $ 1,3 milhão só em 2014.

Embora valha a pena ressaltar que algumas empresas - como Oracle Oracle quer que você pare de enviá-los erros - eis por que isso é loucuraA Oracle está na água quente por causa de uma postagem de blog equivocada da chefe de segurança, Mary Davidson. Esta demonstração de como a filosofia de segurança da Oracle se afasta do mainstream não foi bem recebida na comunidade de segurança ... consulte Mais informação - desencorajar as pessoas a realizar pesquisas de segurança em seus softwares.

Mas ainda haverá pessoas que insistem em usar a divulgação completa, por razões filosóficas ou por diversão. Nenhum programa de recompensa de bugs, por mais generoso que seja, pode combater isso.