Introdução
Quando considerado o mundo computacional integrado que se encontra presente na realidade, uma das novas questões que aparecem com o progressivo armazenamento de informações privadas e sensíveis é a segurança dos sistemas entregues através da internet [1]. Dentro desse contexto, este trabalho propõe-se a demonstrar um exemplo de como funciona o executar do pensamento dentro da área da segurança. Para isso, será feito uso do OpenSSL, uma biblioteca robusta de uso geral para fornecimento de primitivas e operações criptográficas [2], com a finalidade de analisar suas possíveis vulnerabilidades, ativos, adversários, contramedidas e custo-benefício.
Ativos
Devido a sua natureza de biblioteca (sendo em geral considerada um componente integrante de um sistema), o OpenSSL está normalmente vulnerável a ataques diretamente aos algoritmos criptográficos, problemas na implementação e ataques de supply-chain. Esse tipo de ataque pode ser definido como um ataque no código de componentes com a finalidade de contaminar sistemas que executam sobre os mesmos [3].
Evidencia-se também a existência de vulnerabilidades na própria programação, como o Heartbleed, uma falha que permitia a extração de informações diretamente da memória do servidor, fazendo com que um possível atacante pudesse ter a capacidade de impersonificar o serviço; este problema apareceu justamente no OpenSSL [4]. Ainda é possível que algoritmos criptográficos quebrados sejam explorados (apesar de esta ser a parte mais robusta de um sistema), um exemplo é o algoritmo MD5 que foi demonstrado inseguro [5].
Um ativo essencial quando se trata de uma biblioteca é o seu próprio código, apesar de não ser diretamente aquilo que constituiria um ativo no senso mais estrito da palavra, é este que inicia os ataques de supply-chain [6] e, por conseguinte, a contaminação em cascata do resto dos ativos [3]. Desta forma, o primeiro ativo que se pode discutir é a biblioteca em si. Neste sentido, um ataque o qual afetou boa parte dos computadores Linux foi o CVE-2024-3094 [7]. Este ataque foi construído a partir da biblioteca de código aberto libzlma, onde contribuidores inseriram, a partir de testes, um backdoor pelo qual seria possível abrir uma conexão remota no computador do infectado [7].
Ainda dentro do OpenSSL, pode-se discutir outros aspectos relacionados diretamente aos ativos afetados por um ataque ao componente. O servidor HTTP mais usado na atualidade é o NGINX, com quase 33% de uso pelos sites disponíveis na internet [8]. O próprio servidor NGINX utiliza por padrão para a implementação do protocolo TLS e de certificados o OpenSSL [9]. A partir disso, é possível concluir que pequenas vulnerabilidades no código da biblioteca podem implicar em problemas disseminados em parte considerável dos websites disponíveis na internet.
Em adição ao que já foi apresentado, o uso do OpenSSL encontra-se não somente na parte do servidor, mas também na parte do cliente. Grande parte das distribuições do GNU/Linux oferece binários pré-compilados do OpenSSL usados para o TLS, gerenciador de pacotes e outros tipos de comunicação com criptografia [10]. Fazendo assim, com que usuários finais, imagens Docker e servidores estejam todos nessa superfície de ataque.
Adversários
Quando pensa-se dentro da área de segurança, o delimitar dos possíveis adversários pode trazer informações sobre futuros ataques e o raciocínio do atacante [11]. Assim, dentro da análise desenvolvida sobre o OpenSSL, os atacantes mais óbvios podem ser definidos, em geral, como agentes que pretendem extrair informações privadas de conexões TLS, agentes que pretendem a extração de informações de servidores públicos e particulares, assim como infectar máquinas quaisquer que contenham a biblioteca. Percebe-se então, que delimitar com precisão os beneficiados é de considerável complexidade, uma vez que qualquer um que consiga explorar uma falha no software poderia, em tese, expor grande parte da internet e dos usuários clientes.
Descrevendo possíveis atacantes, uma das entidades de ataque bastante provável são as agências de espionagem. Para exemplificar, vale o caso de Edward Snowden que divulgou os dados sobre a espionagem do governo dos Estados Unidos da América contra os próprios cidadãos [12]. Com isso, pode-se colocar que um dos atacantes que pode procurar as vulnerabilidades para coleta de informações é o próprio governo.
A partir do estabelecimento de backdoors pode-se realizar escalada de privilégios para a execução de múltiplos tipos de ataques contra sistemas computacionais [13], nesse sentido, novos tipos de atacantes aparecem na análise. Pode-se então afirmar que agentes que buscam dinheiro via ameaça, coleta de dados sigilosos ou ainda que impersonificam autoridades para auferir ganho próprio são todos plausíveis dentro desse contexto.
Apesar da naturalidade em se imaginar os atacantes que buscam obter lucro, expressa-se a existência também dos invasores que buscam criar o caos. OpenSSL é amplamente utilizado para implementação do TLS em servidores [9], fazendo com que o vazamento de dados privados com algum tipo de vulnerabilidade durante o handshake possa gerar múltiplos prejuízos não só financeiros como sociais. Conclui-se então que empresas concorrentes, agências e entidades que queiram vender seus próprios provedores criptográficos possam ser colocadas como possíveis atacantes.
Gerenciamento de Risco
Para realizar o gerenciamento de risco em uma biblioteca de amplo uso como o OpenSSL, uma técnica simples é a identificação dos vetores de ataque através da análise do processo de desenvolvimento. Para tal, a primeira vulnerabilidade autoevidente nos processos de contribuição em bibliotecas de código aberto advém de tentativas de inserção de código malicioso por fontes normalmente não confiáveis. Esse tipo de contribuição costuma aparecer depois de tempo considerável o qual o atacante dedicou com contribuições legítimas, assim como no caso do liblzma [7].
Para além das contribuições de índole duvidosa, outro aspecto fundamental dos riscos presentes no OpenSSL são problemas na implementação dos algoritmos criptográficos. Um exemplo são ataques de timing; estes ataques exploram possíveis galhos no código para conseguir determinar propriedades e extrair informações, podendo levar até à quebra de chaves criptográficas [14]. Estes ataques aparecem a partir de códigos que não executam na mesma quantidade de tempo.
A parte fundamental quando considerada a relação da biblioteca com a ciência da computação são os algoritmos. Esses procedimentos são basilares para o funcionamento do OpenSSL. Nesse sentido, qualquer descoberta e abuso das inconsistências oferece grande risco para o bom funcionamento da biblioteca. Gerenciar o uso e mudanças no cenário científico torna-se essencial para evitar qualquer problemática relacionada.
De acordo com o exposto nesta seção e o desenvolvido a partir dos possíveis adversários e ativos, conclui-se que gerenciar os riscos em uma biblioteca como o OpenSSL é importante para a identificação das vulnerabilidades e problemas futuros. Ainda sobre esses riscos, tem-se que pensar como um profissional de segurança traz os fundamentos para que se possa manter o ambiente de desenvolvimento de código aberto mais seguro.
Contramedidas
Dentro das vulnerabilidades exploradas, o passo após a identificação para a gerência dos riscos é a elaboração de contramedidas para que se possa minimizar as chances de acontecimentos de grande impacto. Assim como colocado anteriormente, um dos aspectos mais importantes no desenvolvimento de software de código aberto é a revisão e a reputação dos contribuidores do projeto. Portanto, elaborar boas metodologias integra uma contramedida muito importante para a garantia de segurança nesse tipo de componente [15].
Prevenir problemas na implementação dos algoritmos é tarefa a qual exige reflexão sobre os múltiplos tipos de ataque possíveis, como os de timing e side channel attacks [16]. Entende-se a partir disto, que proteger implementações contra as fraquezas do software necessita de esforço tanto no entendimento do pensamento do adversário quanto à busca constante pelos tipos de potenciais problemas. A CVE é uma instituição que identifica, define e cataloga diferentes tipos de ataques cibernéticos públicos [17]. Tornando o conhecimento dela e dos últimos ataques importantes para os desenvolvedores desse tipo de biblioteca, para que se possa remediar problemas já conhecidos ou vulnerabilidades recentes que afligiram outras bibliotecas.
Além do já colocado, outras contramedidas importantes dizem respeito à mitigação de problemas com os próprios algoritmos criptográficos. Um exemplo de grande impacto recente que pode ser dado refere-se à especificação de algoritmos pós-quânticos. Esses algoritmos devem ser resistentes a propriedades de computação demonstradas pelos computadores quânticos [18]. No entanto, um dos algoritmos candidatos à padronização, o Rainbow, foi demonstrado inseguro e que computadores de baixa capacidade conseguiam quebrar a criptografia [19]. Com esse acontecimento, nota-se a necessidade de esperar e fazer uso de algoritmos tanto na implementação das bibliotecas quanto na escolha dentro de software que tenham passado por um processo rigoroso de testes e publicações demonstrando sua ou não efetividade. Isso por si só e o conservadorismo nas escolhas tornam-se fundamentais quando se trata de bibliotecas de amplo uso como o OpenSSL.
Outra fundamentação possível é refletir sobre como os sistemas afetados podem mitigar esse tipo de problema. Apesar de estarem fazendo uso da biblioteca, verificar a versão de uso [20], ter a capacidade de trocar de provedor criptográfico e um planejamento de ação no caso de vazamentos de dados é crucial para um bom planejamento estratégico na área de segurança [21].
Custo Benefício
Existem múltiplas facetas de custo-benefício no desenvolvimento de software. Um dos primeiros pontos de decisão é no que tange às contribuições, se devem ser permitidas incorporações de código por fontes que não detêm reputação considerável dentro da comunidade de software aberto. Aceitar contribuições externas aumenta a velocidade de produção, mas cria peso sobre os revisores e abre brechas de segurança [22].
Outro balanço a ser feito é sobre a inserção de novos algoritmos dentro da biblioteca. Com a evolução constante da criptografia e dos computadores, surgem novos procedimentos criptográficos, existe um balanço entre a inserção destes na biblioteca para torná-la mais moderna, ou evitá-los para que se tenha uma linha mais conservadora na instituição de novas funções. No contexto da implementação pós-quântica, o OpenSSL optou por esperar a padronização do NIST (Instituto Americano de Padronização) para que se tivesse mais segurança antes da integração final na biblioteca [23]. Todas essas decisões são balanços muitas vezes qualitativos que levam em conta a segurança contra as novas funcionalidades.
Para verificar o custo-benefício existe, em adição, os aspectos de usabilidade. Utilização de chaves usando os componentes embutidos do processador é prático. No entanto, na maior parte das vezes seria ideal que as operações criptográficas dos servidores (neste caso, os clientes da biblioteca) fizessem uso sempre de hardware específico para segurança. Apesar do OpenSSL suportar operações externas, por quesitos de usabilidade não há obrigatoriedade da geração em hardware [24].
Ao avaliar todos esses aspectos, em geral qualitativos tanto da questão do usuário como do desenvolvedor, determina-se quais decisões são as de maior prioridade dentro do domínio tratado. Dentro da biblioteca OpenSSL, assim como colocado anteriormente, várias decisões foram tomadas com o intuito de aumentar a robustez e evitar vulnerabilidades. Problemas em uma biblioteca que está em uso nessa escala têm impactos de grande abrangência que devem ser evitados.
Conclusão
A partir deste trabalho, fez-se a discussão das múltiplas visões dentro do âmbito da segurança computacional utilizando-se para isso o OpenSSL. Valendo-se dos ativos, adversários, vulnerabilidades, gerenciamento de risco, contramedidas e custo-benefício, foi possível dissertar sobre as interações das vulnerabilidades e problemas que afetam ou podem afetar a biblioteca a partir do proposto. Demonstrando como múltiplos aspectos do sistema interagem e constituem a conjuntura geral da segurança.