A História de um Bug: Tudo sobre Vulnerabilidades de Software
O que são vulnerabilidades de software (bugs) e de onde elas vêm?
Algumas definições são essenciais para fornecer contexto:
- Definição do Gartner®: “Um bug é um problema inesperado no software ou hardware. Esses tipos de problemas geralmente são resultado de uma interferência externa no desempenho do programa que não foi prevista pelo desenvolvedor”.
- O Mitre define uma vulnerabilidade como “um erro no software que pode ser explorado por hackers para obter acesso a sistemas ou redes”.
Bugs e vulnerabilidades podem ocorrer por diversos motivos, incluindo novas fraquezas de segurança, adoção de novas tecnologias e práticas de desenvolvimento, ou até mesmo a escassez de profissionais especializados. Em muitos casos, o erro humano é a principal causa, o que torna os bugs uma constante na tecnologia. Vamos explorar a vida de um bug e entender como lidar com ele.
Curiosidade sobre bugs:
O primeiro bug de computador foi uma mariposa que causou um curto-circuito no computador Mark II de Harvard em 1947. A mariposa foi retirada e colada no logbook do laboratório, marcando o nascimento do termo “bug” no contexto da computação.
Descobrindo bugs
Como as vulnerabilidades de software são encontradas?
A maioria dos bugs de software é encontrada por pesquisadores de segurança que chamamos carinhosamente de “caçadores de recompensas” de bugs (“bug bounty hunters”). Bug bounties são programas executados por fabricantes de software (e empresas de segurança externas) que geralmente pagam recompensas em dinheiro a pesquisadores de ameaças e hackers éticos que descobrem e reportam bugs que os fabricantes podem replicar e, por fim, fornecer uma “solução”, geralmente na forma de um patch ou instruções de mudança de configuração.
Os bugs também podem ser descobertos por hackers antiéticos ou “vilões” com objetivos menos honrosos. Quando esses malfeitores descobrem vulnerabilidades, ao contrário dos nossos amigos caçadores de recompensas, eles não as reportam aos fabricantes nem a ninguém. Eles as transformam em armas para seu próprio uso malicioso.
O Catálogo de Vulnerabilidades Exploradas é uma lista de vulnerabilidades conhecidas que foram exploradas com uma intenção maliciosa, geralmente como resultado da investigação de uma violação ou de uma série de violações.
Algumas das motivações menos éticas para realizar ataques cibernéticos incluem:[1]
- Ganho financeiro: Englobam práticas como ransomware, roubo direto de dados das vítimas e venda de informações confidenciais na dark web.
- Declarações políticas: Os “hacktivistas” atacam sistemas e sites para promover uma ideologia ou causar danos como forma de protesto.
- Vingança: Indivíduos insatisfeitos, como ex-funcionários ou clientes, podem invadir sistemas como forma de retaliação.
- Fama: Hackers em busca de reconhecimento.
- Roubo de propriedade intelectual: A motivação para o roubo de propriedade intelectual é especialmente perigosa para corporações e outras organizações, uma vez que essa categoria tende a incluir ataques patrocinados por estados e empresas contra diversos tipo propriedades intelectuais: de projetos de armamentos a patentes de produtos. Os hackers patrocinados pelo estado geralmente têm tempo e recurso ilimitados para encontrar uma maneira de invadir seu alvo.
O Mitre rastreia uma lista completa de grupos de ameaças. Exemplos desses agentes são grupos de Ameaça Persistente Avançada (APT)[2] como o DeputyDog da China (APT17), Buckeye (APT3) e o aterrorizante Double Dragon (APT41)[3].
O Gartner também expressou suas preocupações com a segurança afirmando: “Não é possível uma organização, em qualquer nível de maturidade de segurança, atingir zero vulnerabilidades no seu ambiente”.[4]
Curiosidade sobre bugs:
Muitos fabricantes de software exigem um acordo de não divulgação (NDA) para a participação em programas de recompensa por identificação de bugs para ajudar a evitar a divulgação prematura de vulnerabilidades e desencorajar os malfeitores a transformá-las em armas antes que os clientes tenham a chance de recuperar, testar e aplicar correções.[5]
Reconhecimento pelo fabricante de software
Como os fabricantes respondem aos bugs
Você sabe o que os fabricantes devem fazer quando bugs nos seus softwares são descobertos? Geralmente nada. E por que não? Porque o contrato de uso[6] que os clientes assinam geralmente protege o fabricante com isenções de garantias e recursos. Embora isso seja desanimador, os fabricantes geralmente:
- Revisam o envio do bug
- Reproduzem-no (por meio de instruções do caçador de recompensas)
- Validam o bug, identificam os produtos afetados e aceitam o bug para outras ações
- Desenvolvem um patch
- Adicionam o novo patch aos pacotes de atualização, como Oracle Critical Patch Updates (CPUs) ou SAP Security Patch Day
Esse processo pode demorar – variando de semanas a anos.
Curiosidade sobre bugs:
O NIST mantém um banco de dados de vulnerabilidades registradas, conhecido como NVD, que contém mais de 29.000 vulnerabilidades identificadas em 2023, e 2024 já está se aproximando dessa marca.[7]
Nomeando um bug
Como as vulnerabilidades e exposições comuns (CVE) são identificadas
Se os bugs de software tiverem nomes (ou melhor, números de identificação), facilita o processo. Felizmente, as autoridades de numeração de CVE, incluindo pesquisadores e fabricantes de software[8], atribuem IDs às CVE a partir de blocos de números reservados pré-alocados fornecidos pelo NIST.[9] Eles atribuem um registro de CVE por vulnerabilidade enviada para que os especialistas em segurança cibernética possam rastrear e reportar correções e mitigações de software.
Observação: A data em que o CVE é criado reflete a data em que o número foi emitido pela primeira vez para um fornecedor, o que pode diferir drasticamente da data em que a vulnerabilidade foi descoberta![10]
Curiosidade sobre bugs:
As listas de CVE são voluntárias e incompletas por definição, uma vez que os fabricantes não têm obrigação de reportar bugs em softwares novos ou antigos.[11] Além disso, embora o MITRE e o NIST forneçam diretrizes e padrões para envios de CVE para garantir consistência, os fabricantes não são obrigados a segui-los.
O que você pode fazer sobre vulnerabilidades de software
Como desenvolver uma resposta de gerenciamento de segurança e risco (SRM)
Se sua reação ao tomar conhecimento de um novo bug de software for “Ótimo! Outro bug! E outro patch!”, você não está sozinho.
No entanto, esse bug ou vulnerabilidade provavelmente está no software desde que ele foi desenvolvido pela primeira vez pelo desenvolvedor (a menos que tenha sido introduzido por um patch) e, como agentes mal-intencionados podem explorar um bug rapidamente, contar com um plano de defesa contra bugs é uma estratégia inteligente.
A aplicação de patches de fabricantes é uma defesa comum, porém trabalhosa, com etapas como:
- Escolher patches nas CPUs Oracle ou no dia do patch de segurança da SAP
- Agrupar patches e testá-los em um servidor que não esteja em ambiente de produção
- Confirmar se eles não afetam dados críticos, como saldos financeiros ou registros de saúde
- Programar o tempo de inatividade e colocar os sistemas de produção offline para a aplicação de patches
- Repetir todo o processo se o fabricante emitir novos patches em resposta ao feedback do usuário sobre os patches originais.
Curiosidade sobre bugs:
O tempo médio de exploit para os bugs é de apenas 4 dias em 2024 [12], representando uma queda em relação aos mais de 74 dias em 2014[13]
Enfrentando os bugs
Como abordar os patches de segurança
Embora manter-se atualizado sobre os patches de segurança dos fabricantes tenha sido uma forma tradicional de mitigar vulnerabilidades[14], não é incomum que as empresas tenham dificuldades com os patches[15], pois isso pode exigir:
- Recursos de TI altamente qualificados[16] e amplo planejamento, testes e tempo de inatividade do sistema.[17]
- Longas esperas — de meses ou até anos — para que vulnerabilidades de software sejam detectadas e patches sejam fornecidos, testados e instalados.[18]
- Atualizações de software potencialmente caras e com um ROI baixo para continuar recebendo novos patches de segurança dos fabricantes em versões de software que não recebem mais atualizações de segurança do fabricante de software.[19]
Uma estratégia baseada exclusivamente em patches enfrenta os seguintes desafios:
- Mitigar rapidamente todos os riscos de segurança cibernética.[20]
- Considerar configurações ou dados exclusivos do sistema.[21]
- Os patches dos fabricantes não são projetados especificamente para proteger o código personalizado desenvolvido por um cliente ou abordar o ambiente e a arquitetura exclusivos do cliente.
- O desenvolvimento e a aplicação de atualizações de segurança do fabricante podem levar um longo período para serem concluídos, atrasando a proteção contra ameaças conhecidas.
Além disso, uma quantidade considerável de tempo de inatividade é necessária para corrigir e atualizar os sistemas. Isso pode provocar atritos entre as equipes de segurança que tentam implantar todas as táticas disponíveis para reduzir o risco e as equipes de operações de TI encarregadas de administrar o tempo de atividade e da continuidade dos negócios.[22]
Curiosidade sobre bugs:
Não existe uma única solução que garanta que você encontre e corrija todas as vulnerabilidades.[23]
Superando os bugs
Como o Rimini Protect™ aborda as vulnerabilidades de software
Muitos sistemas de software corporativo impulsionaram os negócios para clientes há décadas e atualmente estão ultrapassando as datas de término do suporte do fabricante, o que implica que poucos ou nenhum patch de segurança novo está disponível para esses sistemas. Normalmente, os patches de segurança também não estão disponíveis quando um cliente deixa o suporte do fabricante.
A Rimini Street permite uma abordagem empresarial e baseada em dados para priorizar a mitigação de riscos. Nosso foco é melhorar as posturas de segurança e reduzir a exposição aos riscos de segurança sem a aplicação de patches de segurança fornecidos pelo fabricante ou a modificação do código do fabricante.
Muitas organizações já estabeleceram outras estratégias defensivas para proteger seu softwares corporativos por causa da disponibilidade limitada de patches de segurança. As soluções Rimini Protect são desenvolvidas sob medida para o ecossistema de um cliente visando complementar e aprimorar as estratégias de segurança existentes de nossos clientes para protegê-los contra ameaças e vulnerabilidades conhecidas (descobertas) e desconhecidas (não descobertas).
Perguntas frequentes sobre vulnerabilidades de software
Qual é a diferença entre um ponto fraco de software e uma vulnerabilidade?
Os pontos fracos são condições de software ou hardware que podem levar a uma vulnerabilidade. O Mitre mantém uma lista de pontos fracos conhecida como enumerações de pontos fracos comuns (CWEs). Uma vulnerabilidade é um “bug” ou erro que pode ser usado diretamente para explorar (obter acesso a) um sistema. O NIST mantém um banco de dados nacional de vulnerabilidades com enumerações de vulnerabilidades comuns (CVEs) conhecidas.
Quais são alguns exemplos de vulnerabilidades de software?
Pense nas vulnerabilidades como uma forma de aproveitar o contexto (ponto fraco) para explorar um sistema. Exemplos de vulnerabilidades de software incluem corrupção de memória (CVE-2021-28664), habilitação da capacidade de “escapar” de um ambiente de teste ou sandbox (CVE-2020-0041) etc.
Quais são alguns exemplos de pontos fracos de software?
Pense nos pontos fracos do software como o contexto da situação. Por exemplo, o CWE-787 é intitulado “Gravação fora dos limites”, o que é descrito como gravar dados antes ou depois da área de memória que o programa pretende acessar. Permitir que dados sejam gravados em áreas inesperadas da memória pode causar resultados imprevisíveis e representa um ponto fraco.
Qual é a diferença entre malware e vulnerabilidades de software?
O malware é um programa que pode ser instalado utilizando um exploit que visa comprometer a “confidencialidade, integridade ou disponibilidade dos dados, aplicações ou sistema operacional da vítima”. Vulnerabilidades de software são “bugs” que podem ser usados para explorar um sistema.
O que é um exploit?
Um exploit é um “agente mal-intencionado” que utiliza um programa ou pedaço de código para tirar proveito de uma vulnerabilidade de segurança. A CISA mantém uma lista de vulnerabilidades exploradas conhecidas, chamada de catálogo KEV.
Quais são alguns exemplos de exploits?
Alguns exemplos desses exploits incluem:
- Um indivíduo ou organização utilizando os métodos descritos no CVE-2021-28664 para escrever algum código que pode corromper o banco de dados de uma empresa.
- Um indivíduo ou organização que utiliza os métodos descritos no CVE-2020-0041 para escrever um código que permite o acesso não autorizado a arquivos em um computador para roubar informações de clientes ou segredos comerciais.
Por que os CWEs são importantes?
Mitigar um ponto fraco global geralmente pode tornar todos os CVEs mencionados em um CWE ineficazes. Isso também protege contra vulnerabilidades futuras que dependem do mesmo ponto fraco (proteção proativa). Essa estratégia é muito mais eficiente do que tentar resolver uma vulnerabilidade por vez.
[1] VMware https://blogs.vmware.com/security/2022/07/what-are-the-methods-and-motives-for-hacking.html
[2] APT https://www.cisa.gov/topics/cyber-threats-and-advisories/advanced-persistent-threats-and-nation-state-actors
[3] Mitre https://attack.mitre.org/groups/
[4] “How To Implement a Risk-Based Vulnerability Management Methodology” Gartner, publicado em 20 de abril de 2023 — ID G00777685
[5] Bug bounty platforms buy researcher silence, violate labor laws, critics say https://www.csoonline.com/article/569201/bug-bounty-platforms-buy-researcher-silence-violate-labor-laws-critics-say.html
[6] Sample End User License Agreement https://www.oracle.com/technetwork/licenses/eula-ofsc-mobile-ios-14-feb-18-4425385.pdf
[7] https://www.cvedetails.com/browse-by-date.php
[8] CVE Numbering Authorities (CNAs): https://www.cve.org/ProgramOrganization/CNAs
[9] Perguntas mais frequentes do NIST descrevendo registros CVE reservados: https://www.cve.org/ResourcesSupport/FAQs
[9] Perguntas mais frequentes do NIST O que um REGISTRO DE DATA CRIADO significa em um Registro CVE: https://www.cve.org/ResourcesSupport/FAQs
[11] Consulte a seção “when to give up” da OWASP Vulnerability Disclosure Cheat Sheet https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html
[12] Time to exploit a bug https://www.akamai.com/blog/security-research/2024-php-exploit-cve-one-day-after-disclosure
[4] “How To Implement a Risk-Based Vulnerability Management Methodology” Gartner, publicado em 20 de abril de 2023 — ID G00777685
[14] DarkReading: Microsoft started issuing patches in 2001 to fix security vulnerabilities. link CISA recommends installing patches/updates as soon as possible. link
[15] DarkReading: “Patching this tidal wave of vulnerabilities is an unattainable task.” link “…IT and security teams are stretched thin and cannot keep up with the task. It’s not humanly possible.” link
[16] DarkReading: “…where IT talent is hard to attract and retain.” link Deloitte: “Only 13 percent of employers surveyed say they can hire and retain the tech talent they need most.” link Ivanti: “A shortage of IT staff has reduced the ability to mitigate security issues promptly for many companies.” link Cisco: “Patch everything that could be bad (like everything CVSSv3 Medium and above), and you’ll achieve great coverage at the expense of a lot of unnecessary work that will tax your security team.” link
[17] Gartner: “…é bem sabido nas operações de TI que uma quantidade considerável de interrupções e tempo de inatividade é proveniente da tentativa de corrigir ou atualizar sistemas”. “Os patches quebram as coisas o tempo todo. É comum observar interrupções no sistema devido à aplicação de patches, mesmo em ambientes maduros com boas operações de TI e ferramentas de correção”.
[18] Gartner: “Há vários fabricantes que simplesmente não lançam patches em tempo hábil”. “Geralmente, há uma grande lacuna entre a descoberta de vulnerabilidades e os recursos disponíveis nas operações de TI para enfrentá-las no prazo em que os atacantes atuam”.
[19] Oracle Technology Global Price list: https://www.oracle.com/assets/technology-price-list-070617.pdf. Oracle Sustaining support includes PRE-EXISTING security alerts and updates. link
[20] Gartner: “Não é possível uma organização, em qualquer nível de maturidade de segurança, atingir zero vulnerabilidades no seu ambiente”. “Na realidade, evitar que vulnerabilidades sejam exploradas nem sempre é possível ou até mesmo viável apenas com a aplicação de patches para a maioria das organizações de usuários finais”. “As organizações continuarão lutando para corrigir sistemas ao mesmo tempo em que os agentes de ameaças atuam em grande escala”. Inteligência de segurança: “Isso faz com que os patches sejam uma solução completa de segurança cibernética? Embora a aplicação de patches seja um componente importante da segurança cibernética, outras soluções e estratégias de segurança devem complementá-la”. link
[21] NIST: “O ato de aplicar uma mudança no software instalado – como firmware, sistemas operacionais ou aplicações – que corrige problemas de segurança ou funcionalidade ou adiciona novos recursos”. link
[22] Página 4 & 5 “Como implementar uma metodologia de gerenciamento de vulnerabilidades baseada em riscos” Gartner, publicado em 20 de abril de 2023 — ID G00777685
[23] Gartner: “Não é possível uma organização, em qualquer nível de maturidade de segurança, atingir zero vulnerabilidades no seu ambiente”. Gartner, publicado em 20 de abril de 2023 —ID G00777685