U
M sistema computacional está sujeito a diversos riscos, que são ampli- ficados à medida que aumentam o número de conexões locais ou re- motas a esse sistema. Em termos gerais, define-sevulnerabilidade como sendo qualquer fraqueza ou falha em um sistema que permita a um invasor violar a integridade do sistema. O termo também pode ser aplicado para deficiências do sistema que impeçam sua rápida recuperação em caso de problemas nos equipamentos computacionais.Vulnerabilidades podem surgir em diversos elementos num sistema com- putacional, destacando-se principalmente: uso de senhas fracas pelos usuá- rios, sistemas computacionais mal projetados e bugs em software. O uso de senhas fracas facilita a descoberta das mesmas pelos invasores usando apli- cativos que testam automaticamente uma grande quantidade de senhas em pouco tempo de execução. Uma vez conseguido o acesso como usuário co- mum, os invasores passam a explorar outras falhas do sistema em busca de acesso privilegiado.
Infelizmente, a maioria das empresas e projetistas de software não tem adotado em nível adequado metodologias para desenvolvimento seguro de apli- cações. Várias aplicações contêm falhas críticas de segurança por causa de um projeto falho, seja para autenticar usuários ou validar dados de entrada
18Ver resultados em http://www.modernlifeisrubbish.co.uk/article/
em uma aplicação. A Microsoft, por exemplo, só mais recentemente apontou segurança como prioridade no desenvolvimento de aplicações19. A maioria das empresas prefere enfocar usabilidade e funcionalidades a aterem-se para a questão da segurança dos aplicativos.
Essa situação também pode ser verificada na área acadêmica: a maior parte dos textos acadêmicos sobre Engenharia de Software, por exemplo, não aborda o desenvolvimento seguro de aplicações, ou não faz um nível de de- talhes adequado. E alguns dos que incluem essa abordagem, só o fazem de maneira mais profunda em novas edições. O resultado é toda uma geração de profissionais sem uma visão mínima de metodologias de desenvolvimento seguro de aplicações. Até que essa situação se modifique na academia e no mercado, vários tipos de ataques, como injeção de código SQL em páginas Web, serão comuns na Internet.
Como se não bastasse a ausência de uma cultura de programação segura no desenvolvimento de software, esse processo é suscetível a falhas, como qualquer atividade humana. E mesmo o uso de metodologias adequadas não é capaz de garantir o desenvolvimento de um aplicativo completamente se- guro. Dessa maneira, mesmo que o aplicativo trate adequadamente entradas e permissões, por exemplo, ele pode possuir falhas (bugs) que poderiam ser exploradas por um invasor, fazendo com que o aplicativo execute ações não previstas ou forneça acesso privilegiado ao atacante.
Em geral, boa parte das vulnerabilidades de um software tornam-se pú- blicas após descobertas por especialistas da área de segurança ou mesmo hackers “bem intencionados”. Assim, existem repositórios públicos sobre vul- nerabilidades20 alguns inclusive com provas de conceito: aplicativos que ex-
ploram a vulnerabilidade, mostrando sua gravidade. Se esses repositórios auxiliam e muito o especialista de segurança a manter seus sites seguros, por outro lado oferece ao possível invasor informações preciosas sobre a fragili- dade de um determinado tipo de sistema computacional.
Inclusive, é importante destacar que diversas ferramentas utilizadas pe- los invasores, como Nessus ou Metasploit, são na verdade ferramentas de segurança, utilizadas por especialistas da área para verificar e validar a segu- rança em ambientes computacionais. Assim, por exemplo, um scanner como
19Ver, por exemplo, http://www1.folha.uol.com.br/folha/informatica/
ult124u14480.shtml e http://www.microsoft.com/brasil/corporativo/security/ sdl.mspx.
20Merecem destaque, entre esses repositórios o CVE (Common Vulnerabilities and Expo-
sure), disponível emhttp://cve.mitre.org/, e o repositório da SecurityFocus, disponível
o Nessus pode ser utilizado para verificar em que pontos um sistema está vul- nerável. Um programa de ataque de senha pode ser utilizado para checar se os usuários não estão utilizando senhas fáceis, o que facilitaria uma invasão. A relação um tanto quanto dúbia entre invasão de sistemas e segurança computacional fica evidente, inclusive, com o fato do Pentest (Penetration Test - Teste de Intrusão) ser uma das metodologias utilizadas cada vez mais em testes de segurança computacional. Essa metodologia, descrita em (HERZOG,
2008), consiste no uso de técnicas e ferramentas de invasão para avaliar a qualidade da segurança computacional de um dado sistema. E cada vez mais empresas tem contratado esse tipo de serviço, uma vez que é mais interessante receber um relatório com as falhas encontradas que uma invasão real com danos efetivos.
Em alguns casos, a vulnerabilidade afetada é descoberta não em software, mas em um protocolo, o que faz com que todos os aplicativos que implemen- tem aquele protocolo estejam vulneráveis. Recentemente, dois casos desses foram largamente noticiados na mídia da área de TI. O primeiro caso refere- se a uma falha no DNS, que permitia o envenenamento de cache21, fazendo
com que servidores DNS respondessem erroneamente às consultas. Invaso- res poderiam aproveitar dessa falha, por exemplo, para que os usuários de um servidor DNS recebessem endereços incorretos, acessando páginas forja- das. É importante destacar que apesar dessa falha do DNS ter vindo a público em julho/2008, ainda existiam, no momento de escrita desta tese, servido- res DNS, inclusive de grandes provedores, que não foram atualizados para evitarem essa falha22 .
O segundo caso de falha em protocolo noticiado pela mídia de TI foi uma vulnerabilidade recentemente descoberta por dois pesquisadores no protocolo e que permitiria executar com facilidade ataques de negação de serviço23. O ataque possibilitado por essa vulnerabilidade teria o impacto de fazer com com que diversos equipamentos de rede (incluindo servidores) fiquem sem co-
21Ver alerta em português no site da RNP: http://www.rnp.br/cais/alertas/2008/
uscert-vu8000113.html.
22Como noticiado em http://info.abril.com.br/aberto/infonews/112008/
14112008-47.shl, em novembro de 2008, um quarto dos servidores DNS ainda conti-
nua vulnerável e 24% dos profissionais entrevistados não sabiam como corrigir a falha em seus servidores. Além disso, eu mesmo pude verificar, em final de outubro de 2008, que alguns servidores DNS de um provedor banda larga não conseguiam encontrar diversos en- dereços, por problemas de envenenamento de cache. Ao utilizar um servidor DNS alternativo e mais seguro, os endereços puderam ser resolvidos normalmente.
23Ver detalhes em http://arstechnica.com/news.ars/post/
20081002-researchers-disclose-deadly-cross-platform-tcpip-flaws.html e http://www.computerworld.com.pt/site/content/view/5896/52/, por exemplo.
nexão, exigindo a reinicialização dos mesmos para voltarem a funcionar corre- tamente. Os detalhes dessa falha ainda não foram divulgados a público, até o momento de escrita desta tese, mas já teriam sido confirmadas por empresas da área de segurança.
De certa maneira, este tipo de vulnerabilidade ocorre porque a maior parte dos protocolos, especialmente os protocolos básicos da Internet, foram cria- dos em um período em que o controle simples de acesso, por endereço IP por exemplo, era suficiente para garantir a segurança dos serviços. O uso cres- cente da Internet e novos usos desses protocolos trouxeram à tona proble- mas não previstos durante o projeto desses padrões. Como eles são adotados em larga escala, é extremamente complexo a correção dessas vulnerabilida- des, que exigiriam mudanças significativas nesses protocolos ou mesmo a sua substituição. O IPv6, por exemplo, já tem mais de década de criação e sua adoção ainda é extremamente tímida, o que mostra a inércia na substituição desse tipo de padrão pelo mercado de TI.
Para que se tenha uma idéia da fragilidade dos protocolos básicos da In- ternet, em agosto de 2008, o CPNI (Centre for Protection of the National In- frastructure), órgão do governo britânico que se ocupa de segurança digital, apresentou a público um relatório apontando fragilidades nas especificações do TCP/IP24. O relatório aponta, entre outros riscos, que qualquer sistema construído tendo por base o TCP/IP pode reencarnar falhas de segurança que já foram corrigidas no passado (GONT, 2008). O relatório apresenta algumas melhorias de segurança que poderiam ser implementadas, mas alerta para a necessidade de uma rediscussão dos protocolos sob a ótica da segurança.