Há três semanas, um sério problema de segurança no OS X 10.10.4 foi descoberto. Isso, por si só, não é particularmente interessante.
Vulnerabilidades de segurança em pacotes de software populares são descobertas o tempo todo e o OS X não é exceção. O OSVDB (Open Source Vulnerability Database) mostra pelo menos 1100 vulnerabilidades marcadas como "OS X". Mas o que é interessante é a maneira como essa vulnerabilidade em particular foi divulgada.
Em vez de contar à Apple e dar-lhes tempo para resolver o problema, o pesquisador decidiu publicar sua exploração na Internet para que todos pudessem ver.
O resultado final foi uma corrida armamentista entre a Apple e hackers negros. A Apple teve que lançar um patch antes que a vulnerabilidade fosse armada, e os hackers tiveram que criar um exploit antes que os sistemas em risco fossem consertados.
Você pode pensar que um 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 estranho e confuso mundo da divulgação de vulnerabilidades.
Divulgação completa e responsável
Existem duas formas populares de divulgar vulnerabilidades aos fornecedores de software.
O primeiro é chamado de divulgação completa . Assim como no exemplo anterior, os pesquisadores publicam imediatamente sua vulnerabilidade, deixando aos fornecedores absolutamente nenhuma oportunidade de liberar uma correção.
O segundo é chamado de 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 cronograma em que o pesquisador promete não publicar a vulnerabilidade, a fim de dar ao fornecedor uma oportunidade de criar e liberar uma correção. Esse período de tempo pode variar de 30 dias a um ano, dependendo da gravidade e da complexidade da vulnerabilidade. Algumas brechas de segurança não podem ser corrigidas facilmente e exigem que sistemas de software inteiros sejam reconstruídos a partir do zero.
Quando as duas partes estiverem satisfeitas com a correção produzida, a vulnerabilidade será divulgada e receberá um número CVE. Eles identificam de forma exclusiva cada vulnerabilidade e a vulnerabilidade é arquivada on-line no OSVDB.
Mas o que acontece se o tempo de espera expirar? Bem, uma das duas coisas. O fornecedor negociará uma extensão com o pesquisador. Mas se o pesquisador não estiver satisfeito com o modo como o fornecedor respondeu ou se comportou, ou se achar que o pedido de uma extensão não é razoável, ele pode simplesmente publicá-lo on-line sem nenhuma correção pronta.
No campo da segurança, há debates acalorados sobre qual método de divulgação é o melhor. Alguns pensam que o único método ético e preciso é a divulgação completa. Alguns pensam que é melhor dar aos fornecedores a oportunidade de resolver um problema antes de liberá-lo para a natureza.
Como se vê, existem alguns argumentos convincentes para os dois lados.
Os Argumentos em Favor da Divulgação Responsável
Vejamos um exemplo de como é melhor usar a divulgação responsável.
Quando falamos de infra-estrutura crítica no contexto da Internet, é difícil evitar falar sobre o protocolo DNS Como alterar seus servidores DNS e melhorar a segurança na Internet Como alterar seus servidores DNS e melhorar a segurança na Internet Imagine isso - você acorda um belo de manhã, sirva-se uma xícara de café e, em seguida, sente-se em seu computador para começar seu trabalho pelo dia. Antes de você realmente começar ... Leia Mais. Isso é o que nos permite traduzir endereços da Web legíveis por humanos (como o makeuseof.com) em endereços IP.
O sistema DNS é incrivelmente complicado e não apenas em nível técnico. Há muita confiança colocada neste sistema. Confiamos que, quando digitamos um endereço da Web, somos enviados para o lugar certo. Há simplesmente muita coisa sobre a integridade desse 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 que eles obtivessem seus dados bancários on-line. Eles podiam interceptar seus e-mails e tráfego on-line por meio de um ataque man-in-the-middle 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 muito respeitado, com um longo currículo de encontrar vulnerabilidades em softwares conhecidos. Mas ele é mais conhecido pela descoberta de 2008 da talvez mais severa vulnerabilidade do sistema DNS já encontrada. Isso permitiria que alguém executasse facilmente um ataque de envenenamento de cache (ou spoofing de DNS) 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 de liberar uma falha tão grave, decidiu divulgá-la aos fornecedores do software de DNS que são afetados por esse bug.
Houve vários produtos DNS afetados, incluindo aqueles construídos pela Alcatel-Lucent, BlueCoat Technologies, Apple e Cisco. O problema também afetou várias implementações de DNS que foram distribuídas com algumas distribuições Linux / BSD populares, incluindo as do Debian, Arch, Gentoo e FreeBSD.
Kaminsky deu a eles 150 dias para produzir uma correção e trabalhou com eles 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 seria incrivelmente imprudente divulgá-lo publicamente sem dar aos fornecedores a oportunidade de lançar um patch.
Aliás, a vulnerabilidade foi vazada por acidente pela empresa de segurança Matsano em um post no blog. O artigo foi retirado, mas foi espelhado, e um dia após a publicação, um exploit Isto é como eles te cortam: O mundo obscuro dos Kits de exploração Isto é como eles te atacam: O mundo obscuro dos Kits de exploração Os golpistas podem usar conjuntos 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? Leia mais foi criado.
A vulnerabilidade do DNS de Kaminsky finalmente resume o cerne do argumento em favor de uma divulgação responsável e desconcertada. Algumas vulnerabilidades - como vulnerabilidades de dia zero O que é uma vulnerabilidade de dia zero? [MakeUseOf explica] O que é uma vulnerabilidade de dia zero? [MakeUseOf Explains] Leia Mais - são tão significativos que liberá-los publicamente causariam danos significativos.
Mas há também um argumento convincente a favor de não dar aviso prévio.
O caso da divulgação completa
Ao liberar uma vulnerabilidade a céu aberto, você desbloqueia a caixa de uma Pandora onde indivíduos mal-intencionados são capazes de produzir exploits de maneira rápida e fácil, além de comprometer sistemas vulneráveis. Então, por que alguém escolheria fazer isso?
Existem algumas razões. Em primeiro lugar, os fornecedores costumam demorar muito para responder às notificações de segurança. Forçando efetivamente sua mão liberando uma vulnerabilidade na natureza, eles estão mais motivados para responder rapidamente. Pior ainda, alguns estão inclinados a não divulgar Por que as empresas que mantêm um segredo podem ser uma coisa boa Por que as empresas que mantêm um segredo podem ser uma coisa boa Com tantas informações on-line, todos nós 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? Leia mais o fato de que eles estavam enviando software vulnerável. A revelação completa força-os a serem honestos com seus clientes.
Aparentemente, o @PepsiCo não se importa com um vuln em seu site, não aceitando ajuda não solicitada. Já tem uma equipe de seg. Eu vou fazer divulgação completa
- Pacote Branco (@WhitePacket) 4 de setembro de 2015
Mas também permite que os consumidores façam uma escolha informada sobre se desejam continuar a usar um software específico e vulnerável. Eu imagino que a maioria não.
O que os fornecedores querem?
Os fornecedores realmente não gostam de divulgação completa.
Afinal, é incrivelmente ruim para eles, e isso coloca seus clientes em risco. Eles tentaram incentivar as pessoas a divulgar as vulnerabilidades de forma responsável, apesar dos programas de recompensas de bugs. Estes foram notavelmente bem-sucedidos, com o Google pagando US $ 1, 3 milhão em 2014 apenas.
Embora seja importante ressaltar que algumas empresas - como o Oracle, Oracle querem que você pare de enviá-los - por que isso é loucura O Oracle quer que você pare de enviá-los - por que isso é loucura? Mary Davidson. Essa 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 ... Leia Mais - desencoraje as pessoas a realizar pesquisas de segurança em seus softwares.
Mas ainda haverá pessoas que insistem em usar a divulgação completa, seja por razões filosóficas, seja por sua própria diversão. Nenhum programa de recompensas de bugs, por mais generoso que seja, pode conter isso.