[Retrospectiva] As 25 vulnerabilidades de software mais perigosas de 2025

A CISA, em parceria com a MITRE, lançou a lista com as 25 vulnerabilidades de software mais perigosas de 2025 ("Top 25 Most Dangerous Software Weaknesses"), segundo a CWE. Esta lista identifica as vulnerabilidades mais críticas de software, que os adversários exploram para comprometer sistemas, roubar dados ou interromper serviços.

Essa lista é atualizada anualmente e é baseada na Common Weakness Enumeration (CWE), um padrão de nomenclatura para vulnerabilidades de software, bem extensa e completa. Ela também indica quantas vulnerabilidades conhecidas (CVEs) foram exploradas por atacantes, e estão listadas no catálogo "Known Exploited Vulnerabilities" (KEV) - um indicador importante, que mostra que essa vulnerabilidade foi explorada por atacantes.

Segue a lista:

1. CWE-79 - Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
   CVEs no KEV: 7 - Posição no ano passado: 1
2. CWE-89 - Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
   CVEs in KEV: 4 - Posição no ano passado: 3 
3. CWE-352 - Cross-Site Request Forgery (CSRF)
   CVEs in KEV: 0 - Posição no ano passado: 4 
4. CWE-862 - Missing Authorization
   CVEs in KEV: 0 - Posição no ano passado: 9 
5. CWE-787 - Out-of-bounds Write
   CVEs in KEV: 12 - Posição no ano passado: 2 
6. CWE-22 - Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
   CVEs in KEV: 10 - Posição no ano passado: 5 
7. CWE-416 - Use After Free
   CVEs in KEV: 14 - Posição no ano passado: 8 
8. CWE-125 - Out-of-bounds Read
   CVEs in KEV: 3 - Posição no ano passado: 6 
9. CWE-78 - Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
   CVEs in KEV: 20 - Posição no ano passado: 7 
10. CWE-94 - Improper Control of Generation of Code ('Code Injection')
    CVEs in KEV: 7 - Posição no ano passado: 11 
11. CWE-120 - Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
    CVEs in KEV: 0 - Posição no ano passado: N/A
12. CWE-434 - Unrestricted Upload of File with Dangerous Type
    CVEs in KEV: 4 - Posição no ano passado: 10 
13. CWE-476 - NULL Pointer Dereference
    CVEs in KEV: 0 - Posição no ano passado: 21 
14. CWE-121 - Stack-based Buffer Overflow
    CVEs in KEV: 4 - Posição no ano passado: N/A
15. CWE-502 - Deserialization of Untrusted Data
    CVEs in KEV: 11 - Posição no ano passado: 16 
16. CWE-122 - Heap-based Buffer Overflow
    CVEs in KEV: 6 - Posição no ano passado: N/A
17. CWE-863 - Incorrect Authorization
    CVEs in KEV: 4 - Posição no ano passado: 18 
18. CWE-20 - Improper Input Validation
    CVEs in KEV: 2 - Posição no ano passado: 12 
19. CWE-284 - Improper Access Control
    CVEs in KEV: 1 - Posição no ano passado: N/A
20. CWE-200 - Exposure of Sensitive Information to an Unauthorized Actor
    CVEs in KEV: 1 - Posição no ano passado: 17 
21. CWE-306 - Missing Authentication for Critical Function
    CVEs in KEV: 11 - Posição no ano passado: 25 
22. CWE-918 - Server-Side Request Forgery (SSRF)
    CVEs in KEV: 0 - Posição no ano passado: 19 
23. CWE-77 - Improper Neutralization of Special Elements used in a Command ('Command Injection')
    CVEs in KEV: 2 - Posição no ano passado: 13 
24. CWE-639 - Authorization Bypass Through User-Controlled Key
    CVEs in KEV: 0 - Posição no ano passado: 30 
25. CWE-770 - Allocation of Resources Without Limits or Throttling
    CVEs in KEV: 0 - Posição no ano passado: 26 

Esta lista é muito útil para educar os times de desenvolvimento sobre os principais erros a serem evitados.

Para saber mais:

• 2025 CWE Top 25 Most Dangerous Software Weaknesses
• CWE Top 25 Most Dangerous Software Weaknesses
• Common Weakness Enumeration (CWE)
• Known Exploited Vulnerabilities Catalog (CISA)

[Segurança] Práticas inadequadas de segurança no desenvolvimento de produtos

A Cybersecurity and Infrastructure Security Agency (CISA), em parceria com o FBI, lançou uma atualização para a orientação conjunta "Product Security Bad Practices" (Práticas inadequadas de segurança em produtos) como parte da iniciativa "Secure by Design" da CISA. Esta orientação, recém atualizada, traz novas práticas ruins de segurança, coletadas de feedbacks da comunidade. Ela está disponível online, gratuitamente.

As práticas ruins destacadas pela CISA são divididas em três categorias:

• Propriedades do produto, que descrevem as qualidades observáveis ​​relacionadas à segurança de um produto de software.
• Recursos de segurança, que descrevem as funcionalidades de segurança existentes em um produto.
• Processos e políticas organizacionais, que descrevem as ações tomadas por um fabricante de software para garantir forte transparência em sua abordagem de segurança.

Os treze itens destacados nesta lista de práticas ruins representam as práticas mais perigosas e urgentes que os fabricantes de software devem evitar:

1. O desenvolvimento de produtos em uma linguagem insegura em termos de memória ("memory-unsafe language"), como por exemplo, C ou C++
2. SQL Injection;
3. Injeção de comandos no sistema operacional;
4. Uso de senhas default, embutidas no produto;
5. O produto contém, no momento de seu lançamento, uma vulnerabilidade explorável conhecida, presente no Catálogo de Vulnerabilidades Exploradas Conhecidas (KEV) da CISA;
6. O produto inclui componentes de software de código aberto que possua vulnerabilidades críticas no momento de seu lançamento;
7. Uso de algoritmos criptográficos inseguros ou obsoletos, ou o produto não possui recursos de criptografia em trânsito ou no armazenamento de informações confidenciais;
8. A presença de credenciais ou segredos codificados no código-fonte;
9. Falta de suporte a autenticação de múltiplos fatores (MFA);
10. Não fornecer informações atuais e históricas para identificar tipos de intrusão comuns;
11. Não notificar vulnerabilidades, no mínimo para casos de impacto alto ou crítico;
12. Não ter uma política de divulgação de vulnerabilidades (Vulnerability Disclosure Policy , ou VDP);
13. Não comunicar claramente o período de suporte do produto.

Esta orientação tem caráter voluntário e é destinada a fabricantes de software que desenvolvem produtos e serviços de software em suporte à infraestrutura crítica. Ela também pode ser aplicada por todos os demais fabricantes de software, que são fortemente encorajados a evitar essas práticas ruins de segurança no desenvolvimento de produtos.

A CISA e o FBI pedem que os fabricantes de software reduzam o risco de seus clientes ao priorizarem a segurança em todo o processo de desenvolvimento do produto.

Para saber mais:

• CISA and FBI Release Updated Guidance on Product Security Bad Practices
• Product Security Bad Practices
• Known Exploited Vulnerabilities (KEV) Catalog

[Segurança] App vaza dados da Williams antes de lançamento do novo carro de F1

Esse é um caso interessante aonde uma falha em um app desenvolvido por terceiros impactou o lançamento de um carro de Formula 1 - mostrando uma relação importante entre segurança de aplicações e o negócio.

A Williams estava pronta para fazer um grande lançamento de seu novo carro de Fórmula 1 no dia 05 de Março deste ano, com o uso de um aplicativo de realidade virtual para que as pessoas "vissem" o seu novo carro para a temporada 2021.

Entretanto, uma pessoa conseguiu "invadir" o app na véspera do lançamento, permitindo acesso a imagens com os detalhes do carro, antes do lançamento.

As informações vazaram e as fotos do modelo 3D do novo carro foram compartilhados na Internet. O app de realidade virtual foi tirado do ar, causando uma situação embaraçosa para a Williams.

  

Não foi necessária uma invasão complexa. O incidente aconteceu pois uma pessoa fez uma rápida engenharia reversa do app de realidade virtual e encontrou o arquivo com os modelos em 3D. O atacante, identificado como Astorphobis, descreveu como conseguiu obter os dados:

Posts que não foram escritos

Artigo bem legal: "Como obtive dados de todos os participantes da maratona IBM Behind The Code"

• Resumindo: "Gere logs de erros para consumo interno dos desenvolvedores — Nunca exponha exceptions e stacktraces."

Artigo muito bom da The Hack: "Conhecendo um pouco mais sobre o serviço Amazon S3"

Sobre os vazamentos de dados do Banco Inter:

• 1o vazamento: Banco Inter é extorquido e dados de clientes são expostos; invasão é negada (nota: depois foi confirmada)
• 2o vazamento: Dados de 1,4 milhão de clientes do Banco Inter estavam expostos para acesso
• Banco Inter paga R$ 1,5 milhão e encerra processo sobre vazamento de dados
• Notícia no site do MPDFT: Banco Inter: acordo destinará R$ 1,5 milhão para caridade e combate a crimes cibernéticos

Análise interessante de um vazamento de dados que expos documentos internos do FBI: "Out of Commission: How the Oklahoma Department of Securities Leaked Millions of Files"

Um vazamento de dados que mostra que não podemos confiar nem nos X-9s: "Thousands of people trusted Blind, an app-based “anonymous social network,” as a safe way to reveal malfeasance, wrongdoing and improper conduct at their companies. But Blind left one of its database servers exposed without a password, making it possible (for anyone who knew where to look) to access each user’s account information and identify would-be whistleblowers."

Treta sobre várias vulnerabilidades críticas no iPhone / iOS:

• Malicious websites silently hacked into iPhones for years

A propósito, o lançamento do iPhone 11 gerou muita zoeira...

[Evento] Encontro de Programadores C & C++ do Brasil

No dia 06 de Julho (sábado), o Grupo C/C++ Brasil (ccppbrasil) vai realizar seu 14° Encontro de Programadores C & C++ do Brasil, um evento direcionado a desenvolvedores e que cobre vários aspectos interessantes do uso das linguagens C e C++.

Olhando a página dos encontros anteriores, percebi que o nosso saudoso amigo Alberto Fabiano participou da organização dos primeiros encontros! Também é possível ver a diversidade de assuntos que já foram tratados.

Anota aí na sua agenda:

• Data: 06/07/2019 (sábado), das 8h as 18h
• Local: C6 Bank, Av. Nove de Julho, 3186, Auditório (8º andar)
• Site: http://ccppbrasil.github.io/encontros/proximo/
• Inscrições: R$ 30, através do PagSeguro
• Lista de discussão do grupo ccppbrasil no Google Groups
• Veja também o grupo de Telegram do ccppbrasil

[Segurança] DAST ou SAST

O infográfico abaixo explica de uma forma bem legal a diferença entre Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST), duas buzzwords que estão bem na modinha hoje em dia e que significam, simplesmente, teste estático ou dinâmico.

O teste de segurança de aplicações da forma estática (SAST, também conhecido como "white box") e o teste dinâmico (DAST, ou "black box") são métodos diferentes para teste de bugs e vulnerabilidades de segurança, mas ambos devem ser usados de forma que um complementa os resultados do outro. Eles devem ser usados em conjunto porque, de uma forma geral, enquanto o SAST identificará erros típicos de codificação, o DAST permite encontrar erros em tempo de execução.

Ah... e além de DAST e SAST, ainda existe o Interactive Application Security Testing (IAST) e o Run-time Application Security Protection (RASP)!

[Cyber Cultura] Fortran no Mainframe

O pessoal do Computer History Museum, nos EUA, recuperou um mainframe IBM 1401 fe 1959 e resolveu testar se ele ainda funciona.

Essa experiência foi gravada em um vídeo bem legal que está disponível no canal deles. Inicialmente a eles tiveram que carregar o compilador Fortran estava armazenado em uma fita magnética. O código fonte do programa foi lido através de cartões perfurados, aonde cada cartão continha uma linha do código-fonte. Tudo isso comandado a partir do painel mecânico do IBM 1401. Todas as informações sobre execução do programa (código fonte, os dados de entrada e o resultado) eram vistos através de uma impressora.

O vídeo é uma pequena viagem no tempo! Ele tem aproximadamente 25 minutos, onde nos primeiros 15 minutos eles mostram como foi a execução do programa, e no final eles mostram alguns detalhes de como toda experiência foi feita.

[Segurança] Custo de corrigir bugs em produção

Não há dúvidas que, quanto mais cedo um erro for descoberto no processo de criação de um produto, menor vai ser o custo para repará-lo. Um relatório clássico do Systems Sciences Institute da IBM mostrou que o custo para consertar um bug encontrado durante a implementação de im software foi cerca de 6 vezes mais caro do que um identificado durante o projeto. Consertar os bugs encontrados durante a fase de testes pode ser 15 vezes mais caro e 100x mais caro se for na fase de manutenção do software.

Segundo um estudo da empresa Tricentis, de 606 falhas de software identificadas em 2017, o impacto correspondeu a cerca de metade da população mundial (3,7 bilhões de pessoas), US$ 1,7 trilhão em ativos e 314 empresas.

Como exemplo, uma falha no sistema de gerenciamento da bateria do Samsung Note 7 custou a empresa cerca de 17 bilhões de dólares.

O custo de remediarão de um bug após o software ir para produção inclui muito mais elementos do que, apenas, as horas necessárias da equipe de desenvolvimento. A correção de um bug encontrado após a implantação de uma ferramenta (ou após ela ser lançada para o mercado) inclui custos adicionais que não são encontrado durante as fases de design, codificação e testes, tais como:

• Custo de testes de com integrações e ambientes específicos de clientes;
• Custo de recertificação da ferramenta (se isso se aplicar);
• Custo de nova implantação do software (ou custos de realizar o upgrade);
• Custos de suporte aos clientes antes e depois de implantar a nova versão da ferramenta;
• Custos indiretos por dedicar recursos da área de desenvolvimento para identificar, pesquisar e corrigir os bugs, em vez de implementar novas funcionalidades;
• Responsabilidade civil por danos causados pelo bug (se aplicável).

Por conta dos fatores acima, o custo direto e indireto de encontrar e corrigir um bug após a ferramenta estar pronta pode ser muito maior comparado aos custos de corrigir um bug nas fases iniciais do ciclo desenvolvimento de um software.

Esse artigo, bem interessante, mostra como o uso de desenvolvimento ágil pode reduzir o impacto a longo prazo nos custos para correção e manutenção de software. O autor argumenta que, como no método Agil os ciclos de feedback são mais curtos, esse custo a longo prazo tende a ser menor do que nas metodologias convencionais de desenvolvimento.

Nesse artigo do Louis Cremen, ele também cita a diferença de custo em identificar bugs maus cedo no processo de desenvolvimento de software, e usa o diagrama abaixo, atribuído ao Defense Systems Management College, em 1993:

Para saber mais:

• Defect Prevention: Reducing Costs and Enhancing Quality
• Financial Cost of Software Bugs
• Minimizing Code Defects to Improve Software Quality and Lower Development Costs - paper meio acadêmico e meio marketeiro da IBM, porém mesmo assim interessante e frequentemente citado.
• How much could software errors be costing your company?
• The True Cost of a Software Bug: Part One - artigo que fala mais do mesmo do que os acima, mas que tem 3 exemplos interessantes.
• Introducing the InfoSec colour wheel — blending developers with red and blue security teams - artigo com vários insights bem legais sobre o envolvimento da segurança no desenvolvimento de software.

Post atualizado em 20/12/2022.

[Segurança] Projeto OWASP Top 10 2017

O pessoal do projeto OWASP lançou recentemente uma nova versão da sua lista de 10 principais vulnerabilidades de aplicações web para 2017, conhecida simplesmente como "OWASP TOP 10". A lista divulgada este mês é uma "release candidate", ou seja, uma versão rascunho (quase final), e traz as vulnerabilidades mais críticas que podem ser encontradas em aplicações web. O documento categoriza e descreve cada uma delas, incluindo uma explicação do risco e suas formas de mitigação.

O projeto da lista "Top 10" foi lançado inicialmente em 2003, com o objetivo de conscientizar sobre segurança em aplicações web através da identificação dos riscos mais críticos. A última versão, de 2013, também está disponível em Português.

Para 2017, a lista "OWASP Top 10 Most Critical Web Application Security Risks" (nessa versão "Release Candidate") é formada pelas seguintes categorias de ataques:

• A1 Injection
• A2 Broken Authentication and Session Management
• A3 Cross-Site Scripting (XSS)
• A4 Broken Access Control
• A5 Security Misconfiguration
• A6 Sensitive Data Exposure
• A7 Insufficient Attack Protection
• A8 Cross-Site Request Forgery (CSRF)
• A9 Using Components with Known Vulnerabilities
• A10 Underprotected APIs

O blog SegInfo destacou que essa nova versão apresenta duas novas categorias de ataques:

• A7 – Insufficient Attack Protection: A maioria das aplicações e APIs não possuem qualquer capacidade de detectar, prevenir e responder a ataques manuais e automatizados. A proteção contra ataques vai muito além da validação de entradas e envolve detecção, registro, resposta e até mesmo bloqueio de tentativas de invasão. Além disso, as empresas também precisam ser capazes de implantar correções rapidamente para proteger contra ataques;
• A10 – Underprotected APIs: As aplicações atuais geralmente disponibilizam APIs e utilizam APIs externas, tais como aplicações rich client, como JavaScript no navegador e aplicativos móveis, que se conectam a algum tipo de API (SOAP/XML, REST/JSON, RPC, GWT etc.). Estas APIs são frequentemente desprotegidas e contêm inúmeras vulnerabilidades. A popularização do uso de APIs tornou necessário promover esse assunto a um tópico exclusivo na lista de Top ameaças. 

A imagem abaixo indica o que mudou da versão 2013 para a nova do OWASP Top 10:

O uso de "listas de principais assuntos" sempre gera uma certa polêmica, ainda mais na área de segurança, que adora polemizar com tudo. Há aqueles que defendem que ese tipo de lista simplifica muito o problema e causa uma certa "miopia" no mercado, que foca em apenas alguns tópicos em vez de tratar todo o problema. Mas, por outro lado, como a quantidade de alvos potenciais na Internet é muito grande, e como prevalece a existência de sites e serviços vulneráveis, qualquer pessoa que fizer o básico já estará muito mais protegida que a grande maioria. Em minha opinião, esse tipo de lista serve, inicialmente, para educar e dar um norte sobre as principais ações a serem focadas em um primeiro momento, Elas representam o nível mínimo de segurança que qualquer um deveria ter.

O Open Web Application Security Project (OWASP) é um projeto muito interessante para quem se interessa por segurança no desenvolvimento de software, e para quem já é especialista em uma área (Segurança ou Desenvolvimento) e quer ter um entendimento sobre a outra. Eles são uma comunidade aberta, dedicada a capacitar as organizações a desenvolver, adquirir e manter aplicações confiáveis. Eles tem diversos projetos que são tocados por voluntários de todo o mundo.

[Cyber Cultura] Extreme Go Horse (XGH)

Quem é fã da Programação Orientada a Gambiarra (POG) vai gostar do Extreme Go Horse (XGH), uma metodologia de desenvolvimento que, aparentemente, é muito utilizada por aí pelo pessoal mais preocupado com o prazo do que com a qualidade do software.

O XGH é tão sério que é definido através de 22 Axiomas:

1- Pensou, não é XGH.
XGH não pensa, faz a primeira coisa que vem à mente. Não existe segunda opção, a única opção é a mais rápida.

2- Existem 3 formas de se resolver um problema, a correta, a errada e a XGH, que é igual à errada, só que mais rápida.
XGH é mais rápido que qualquer metodologia de desenvolvimento de software que você conhece (Vide Axioma 14).

3- Quanto mais XGH você faz, mais precisará fazer.
Para cada problema resolvido usando XGH, mais uns 7 são criados. Mas todos eles serão resolvidos da forma XGH. XGH tende ao infinito.

4- XGH é totalmente reativo.
Os erros só existem quando aparecem.

5- XGH vale tudo, só não vale dar o toba.
Resolveu o problema? Compilou? Commit e era isso.

6- Commit sempre antes de update.
Se der merda, a sua parte estará sempre correta.. e seus colegas que se fodam.

7- XGH não tem prazo.
Os prazos passados pelo seu cliente são meros detalhes. Você SEMPRE conseguirá implementar TUDO no tempo necessário (nem que isso implique em acessar o BD por um script malaco).

8- Esteja preparado para pular fora quando o barco começar a afundar… ou coloque a culpa em alguém ou algo.
Pra quem usa XGH, um dia o barco afunda. Quanto mais o tempo passa, mais o sistema vira um monstro. O dia que a casa cair, é melhor seu curriculum estar cadastrado na APInfo, ou ter algo pra colocar a culpa.

9- Seja autêntico, XGH não respeita padrões.
Escreva o código como você bem entender, se resolver o problema, commit e era isso.

10- Não existe refactoring, apenas rework.
Se der merda, refaça um XGH rápido que solucione o problema. O dia que o rework implicar em reescrever a aplicação toda, pule fora, o barco irá afundar (Vide Axioma 8).

11- XGH é totalmente anárquico.
A figura de um gerente de projeto é totalmente descartável. Não tem dono, cada um faz o que quiser na hora que os problemas e requisitos vão surgindo (Vide Axioma 4).

12- Se iluda sempre com promessas de melhorias.
Colocar TODO no código como uma promessa de melhoria ajuda o desenvolvedor XGH a não sentir remorso ou culpa pela cagada que fez. É claro que o refactoring nunca será feito (Vide Axioma 10).

13- XGH é absoluto, não se prende à coisas relativas.
Prazo e custo são absolutos, qualidade é totalmente relativa. Jamais pense na qualidade e sim no menor tempo que a solução será implementada, aliás… não pense, faça!

14- XGH é atemporal.
Scrum, XP… tudo isso é modinha. O XGH não se prende às modinhas do momento, isso é coisa de viado. XGH sempre foi e sempre será usado por aqueles que desprezam a qualidade.

15- XGH nem sempre é POG.
Muitas POG’s exigem um raciocínio muito elevado, XGH não raciocina (Vide Axioma 1).

16- Não tente remar contra a maré.
Caso seus colegas de trabalho usam XGH para programar e você é um coxinha que gosta de fazer as coisas certinhas, esqueça! Pra cada Design Pattern que você usa corretamente, seus colegas gerarão 10 vezes mais código podre usando XGH.

17- O XGH não é perigoso até surgir um pouco de ordem.
Este axioma é muito complexo, mas sugere que o projeto utilizando XGH está em meio ao caos. Não tente por ordem no XGH (Vide Axioma 16), é inútil e você pode jogar um tempo precioso no lixo. Isto fará com que o projeto afunde mais rápido ainda (Vide Axioma 8). Não tente gerenciar o XGH, ele é auto suficiente (Vide Axioma 11), assim como o caos.

18- O XGH é seu brother, mas é vingativo.
Enquanto você quiser, o XGH sempre estará do seu lado. Mas cuidado, não o abandone. Se começar um sistema utilizando XGH e abandoná-lo para utilizar uma metodologia da moda, você estará fudido. O XGH não permite refactoring (vide axioma 10), e seu novo sistema cheio de frescurites entrará em colapso. E nessa hora, somente o XGH poderá salvá-lo.

19- Se tiver funcionando, não rela a mão.
Nunca altere, e muito menos questione um código funcionando. Isso é perda de tempo, mesmo porque refactoring não existe (Vide Axioma 10). Tempo é a engrenagem que move o XGH e qualidade é um detalhe desprezível.

20- Teste é para os fracos.
Se você meteu a mão num sistema XGH, é melhor saber o que está fazendo. E se você sabe o que está fazendo, vai testar pra que? Testes são desperdício de tempo, se o código compilar, é o suficiente.

21- Acostume-se ao sentimento de fracasso iminente.
O fracasso e o sucesso andam sempre de mãos dadas, e no XGH não é diferente. As pessoas costumam achar que as chances do projeto fracassar utilizando XGH são sempre maiores do que ele ser bem sucedido. Mas sucesso e fracasso são uma questão de ponto de vista. O projeto foi por água abaixo mas você aprendeu algo? Então pra você foi um sucesso!

22- O problema só é seu quando seu nome está no Doc da classe.
Nunca ponha a mão numa classe cujo autor não é você. Caso um membro da equipe morra ou fique doente por muito tempo, o barco irá afundar! Nesse caso, utilize o Axioma 8.

Claro que isso tudo é uma piada, que ilustra como desenvolvedores devem se preocupar com a qualidade do seu código - e isso, certamente, impacta na segurança do software.

[Segurança] Homenagem ao Alberto Fabiano no TDC 2014

O Vida de Programador fez uma charge representando os principais profissionais de TI que participaram da organização do The Developers Conference (TDC), e lá há uma pequena homenagem ao Alberto Fabiano:

• Ver a imagem grande
• Ver a imagem grande com os nomes das pessoas

Achou ele? Não? Ele está lá no canto superior da charge, com a sua eterna camiseta do 2600:

O Alberto faleceu em julho do ano passado, poucos dias após participar do TDC, do qual era frequentador assíduo e criador da trilha de Segurança. Mas ele deixou um legado: o Garoa Hacker Clube participou do evento este ano, com uma "barraquinha" na área dedicada para startups e makers:

[Segurança] Open Source é realmente seguro?

O bug do Heartbleed foi um tapa na cara da comunidade Open Source.

Muito se fala que os softwares de código aberto são mais seguro do que os softwares proprietários pois permitem que a comunidade audite o código e identifique mais rapidamente bugs e backdoors. Mas, no caso do Heartbleed, descobrimos que o OpenSSL tinha um bug grave por cerca de 2 anos, justamente uma solucão extremamente popular para servidores web e utilizado por milhares de empresas e grandes sites. Sobrou até para o OpenVPN...

Desde as revelações do Edward Snowden sobre o imenso aparato de ciber espionagem do governo americano, muito se fala que o uso de softwares Open Source é uma forma de evitar programas com backdoors colocados por governos com objetivo de facilitar a espionagem. O principal argumento em favor das ferramentas Open Source é que, como o código fonte está totalmente disponível, a comunidade pode analisá-lo e identificar qualquer backdoor ou vulnerabilidade plantada intencionalmente.

Mas este mito da "comunidade que verifica e garante" mostrou-se ineficaz: o bug do Heartbleed afetou um software Open Source muito usado e estava presente há cerca de 2 anos (o bug surgiu na versão 1.0.1, de Março de 2012).

Se os softwares Open Source são mais seguros, como é possível que um software extremamente popular e muito usado ficasse vulnerável por tanto tempo?

Conversando com alguns colegas da área e juntando minhas opiniões pessoais, eu vejo vários motivos que, em conjunto, podem levar a este tipo de situação:

• Criptografia é algo complicado: Simples assim. Algoritmos criptográficos são complexos e exigem um grande conhecimento teórico e muito específico de matemática (incluindo teoria dos números, álgebra, corpos finitos, aritimética modular, e várias outras coisas que eu poderia colocar aqui para encher linguiça). Além de conhecimentos no protocolo específico. Ou seja, nem todo mundo consegue entender, desenvolver ou auditar algoritmos criptográficos;
• Nem todo programador é um bom programador: escrever código exige conhecimento técnico, conhecimento lógico, criatividade, experiência e talento específico. Se vários programadores se debruçarem sobre um mesmo problema, provavelmente cada um criará um programa totalmente diferente para resolver o mesmo problema. Assim como qualquer projeto de software, um projeto de software aberto inclui programadors excelentes e programadores medíocres. E a qualidade do software pode variar;
• Poucos programadores conhecem princípios de desenvolvimento seguro: Nós que trabalhamos na área de segurança da informação achamos que todo programador deveria ter conhecimento sobre como desenvolver um código de forma a evitar bugs de segurança. Existem livros, sites e muita informação sobre boas práticas de desenvolvimento. Uma ótima referência sobre este assunto é o projeto OWASP. Mas, mesmo assim, poucos desenvolvedores conhecem estas práticas. E muito bug de segurança poderia ser evitado, mas não é. Isso inclui checagem de parâmetros, validação do tamanho dos dados e dos campos, etc;
• Nem todo programador documenta muito bem o que fez no código: isso é um problema que atrapalha qualquer pessoa que tente entender um algoritmo feito por outra pessoa; 
• Nem todo mundo audita o código: Nem todo mundo gosta ou sabe auditar um código, ainda mais se for de um software complexo (em termos de quantidade de linhas de código ou de complexidade do assunto em si). Aí vale a lei do menor esforço: se um problema está resolvido, muita gente prefere focar em trabalhar em outras áreas do projeto do que ficar revisando o que foi feito por outro programador. Desenvolver um código seguro, confiável e estável exige testes e auditorias constantes (e diversos tipos diferentes de testes);
• Há programadores que escrevem código complicado de propósito: Segundo um profissional que conheço, há desenvolvedores que escrevem código de forma complicada justamente para "ficarem donos" daquele código. Assim, eles garantem que o projeto vá depender deles, já que são os únicos que entendem o que aquele pedaço de código faz. 

A nossa falta de capacidade de auditar softwares de código aberto também não quer dizer que eles são mais ou menos seguros do que softwares proprietários. Pelo menos, no caso do Open Source, o código está disponível para qualquer pessoa analisar. No caso de uma ferramenta proprietária, somente a empresa que a desenvolveu sabe exatamente o que se passa nas entranhas do software. e, aí sim, um bug ou backdoor pode ficar muito tempo sem ser descoberto.

No ano passado o Rodrigo Rubira Branco (BSDaemon) escreveu um artigo excelente sobre este assunto no site da 4Linux, entitulado "Segurança de Software: código aberto versus fechado faz diferença quando tratamos de vulnerabilidades em programas?". O artigo sobre o Heartbleed na Wikipedia também possui uma seção que discute as prováveis causas e consequências do bug. Ambos valem muito a leitura !!!

[Cyber Cultura] Hackathons

Cada vez mais comuns, os Hackathons são "maratonas de hacking", ou seja, encontros de programadores que desenvolvem, sozinhos ou coletivamente, novos aplicativos para resolver problemas específicos de forma inovadora.

O interessante é que os Hackathons estão ajudando a desmistificar o aspecto negativo muitas vezes associado ao termo hacker, pois os Hackathons estão diretamente relacionados a valores como a criatividade e a inovação.

O primeiro Hackathon foi organizado pelo Yahoo em 2005 e popularizado através de diversas competições promovidas pelos gigantes da tecnologia, como Facebook e Google. Neste ano, já existem mais de 1.500 hackthons programados para acontecer em todo o mundo. Durante essas maratonas, equipes de programadores e desenvolvedores de software se reúnem voluntariamente e por prazer durante várias horas ao redor de seus computadores, com objetivo de criar novas aplicações e aplicativos, normalmente para a plataforma Web e para smartphones. Ao final do evento, um júri seleciona os vencedores, que ganham prêmios.

[Cyber Cultura] Programação Orientada a Gambiarra

Esta é uma ótima apresentação sobre Programação Orientada a Gambiarra (POG), uma técnica milenar de desenvolvimento de código usada mundialmente.

Programação Orientada a Gambiarra from Josenaldo de Oliveira Matos Filho

A POG surge quando os desenvolvedores utilizam artimanhas inesperadas ou ineficientes para resolver ou corrigir programas, de forma deselegante ou até mesmo incompreensível para outros programadores. Ela inclui diversas técnicas, que são mostradas na apresentação acima.

Mas acalme-se, a Programação Orientada a Gambiarra não é uma técnica de verdade, ou seja, não é séria. Foi criada como uma sátira as más práticas de programação, geralmente fruto de programadores com baixa capacitação ou projetos mal especificados, elaborados e documentados. O maior problema da POG, para nós que trabalhamos com segurança da informação, é que um software mal desenvolvido tende a ter mais frequência de bugs e vulnerabilidades.

[Cyber Cultura] Coding Dojo

Recentemente realizamos no Garoa Hacker Clube o nosso primeiro Coding Dojo, uma atividade muito interessante e divertida, aonde um grupo de pessoas escolhe um problema e desenvolve um pequeno programa coletivamente e passo-a-passo. O processo de desenvolvimento permite que todos participem e ajudem na criação do código, o que torna a experiência muito rica e instrutiva. O mais interessante é que mesmo pessoas com pouca prática em programação podem participar.

No nosso primeiro encontro no Garoa, criamos um programa para converter um número para seu equivalente na numeração romana (exemplo: o programa recebe 8 e deve retornar VIII).

O vídeo abaixo é de uma apresentação da Localweb que explica como funciona um Coding Dojo. Há mais informações também no site www.codingdojo.org

[Segurança] Os 25 erros mais comuns em aplicações

O SANS Institute, junto com um grupo formado por mais de 30 empresas e entidades relacionados ao mercado de segurança, publicou nesta semana o documento "CWE/SANS TOP 25 Most Dangerous Programming Errors", uma lista com os 25 erros de programação de software "mais perigosos" para a segurança dos sistemas.

Entre as empresas e entidades que fizeram parte deste esforço, destacam-se a Symantec, Microsoft, Oracle, Secunia, VeriSign, RSA, Red Hat, a NSA (National Security Agency), o DHS (US Department of Homeland Security), o OWASP, a University of California at Davis e a Purdue University. O MITRE e o SANS Institute foram responsável por coordenar a iniciativa.

São falhas normalmente cometidas pelos desenvolvedores de software que causam os principais problemas de segurança nas aplicações web. A lista está disponibilizada no site do SANS, juntamente com as orientações sobre o que são e como evitar estes erros. Os 25 principais problemas selecionados pelos especialistas, divididos em 3 categorias, são os seguintes:

• CATEGORY: Insecure Interaction Between Components
  
  • CWE-20: Improper Input Validation
    
  • CWE-116: Improper Encoding or Escaping of Output
    
  • CWE-89: Failure to Preserve SQL Query Structure (aka 'SQL Injection')
    
  • CWE-79: Failure to Preserve Web Page Structure (aka 'Cross-site Scripting' - XSS)
    
  • CWE-78: Failure to Preserve OS Command Structure (aka 'OS Command Injection')
    
  • CWE-319: Cleartext Transmission of Sensitive Information
    
  • CWE-352: Cross-Site Request Forgery (CSRF)
    
  • CWE-362: Race Condition
    
  • CWE-209: Error Message Information Leak
  
  
• CATEGORY: Risky Resource Management
  
  • CWE-119: Failure to Constrain Operations within the Bounds of a Memory Buffer [Buffer overflows]
    
  • CWE-642: External Control of Critical State Data
    
  • CWE-73: External Control of File Name or Path
    
  • CWE-426: Untrusted Search Path
    
  • CWE-94: Failure to Control Generation of Code (aka 'Code Injection')
    
  • CWE-494: Download of [third-party] Code Without Integrity Check
    
  • CWE-404: Improper Resource Shutdown or Release
    
  • CWE-665: Improper Initialization
    
  • CWE-682: Incorrect Calculation [over the inputs that are used in numeric calculations]
  
  
• CATEGORY: Porous Defenses
  
  • CWE-285: Improper Access Control (Authorization)
    
  • CWE-327: Use of a Broken or Risky Cryptographic Algorithm
    
  • CWE-259: Hard-Coded Password
    
  • CWE-732: Insecure Permission Assignment for Critical Resource
    
  • CWE-330: Use of Insufficiently Random Values
    
  • CWE-250: Execution with Unnecessary Privileges
    
  • CWE-602: Client-Side Enforcement of Server-Side Security

Esta lista, apresentada com detalhes no site do SANS pode ser de grande utilidade para auxiliar desenvolvedores e auditores de código. Esta não é a primeira nem a única tentativa de orientar os desenvolvedores sobre como desenvolver metodologias de codificação segura (ou pelo menos apresentar algum recurso simples e didático para orientá-los sobre as principais falhas que costumam ocasionar bugs de segurança). Uma ótima fonte de informações, que eu já comentei anteriormente, é o projeto OWASP (Open Web Application Security Project).

[Segurança] Frase interessante do Kevin Mitnick

Estava lendo uma reportagem sobre o Kevin Mitnick no site da Forbes ("Reformed Hacker Looks Back") quando vi uma frase muito interesante dele, quando respondeu a pergunta "What do you see as the biggest threats to cybersecurity today?":

Cybersecurity used to be about the network or operating system. Now it's more at the application layer. Companies and their contractors build their own applications hosted on a public Web site, and the people who write them aren't trained in secure coding. The mistakes they make can be leveraged to break the system.

Como ele diz, o foco dos principais ataques hoje em dia são as aplicações, e não mais as redes ou os servidores. Muitos desenvolvedores de aplicação não tem noções básicas sobre desenvolvimento de código seguro e, consequentemente, temos milhares de sites e aplicações vulneráveis.