Por uma série de razões, os desenvolvedores não têm exercido um grande protagonismo no tocante à segurança da informação. Podemos atribuir isso a questões históricas, mas também a uma grande polarização que sempre se evidenciou entre os profissionais de TI, além da falta de capacitação adequada. Isso representa um grande problema, uma vez que o Software representa a primeira e a última das barreiras de segurança. Dessa forma, uma atuação mais ativa dos desenvolvedores junto a esta disciplina é chave para se alcançar a maturidade que precisamos. Esta palestra tem por objetivo abordar toda esta problemática do Software inseguro e incentivar os futuros desenvolvedores a devotarem suas carreiras no desenvolvimento de um Software seguro, resiliente e pronto para as demandas de nossos dias e também do futuro.

1. DESENVOLVEDORES, A
SEGURANÇA PRECISA DE
VOCÊS!
Vinícius Oliveira Ferreira
vinicius.olifer@gmail.com

2. Vinicius Ferreira
■ Desenvolvedor de Aplicações e Subject Matter
Expert nas áreas de Redes e Segurança.
■ Professor de Graduação e Pós-Graduação
■ Entusiasta de Desenvolvimento Seguro.
■ Mestre em Ciência da Computação pela Unesp e o
Lab. ACME! de pesquisa em Cibersegurança.
■ Certificado Security+
Agradecimento especial a Raphael Campos Silva ( ) pelas contribuições a este trabalho.

3. Disclaimer
■ Todas as declarações
nesta apresentação
são de minha
responsabilidade,
portanto, não falo pelo
meu empregador.

4. Sim, o SW continua inseguro
Gráfico extraído de https://nvd.nist.gov/vuln/search/statistics

5. Priests vs
Acolytes
No MIT, reduto dos primeiros
Hackers, a operação do novo IBM
704 (The Hulking Giant) era quase
que Ritualística:
ACOLYTE: Oh machine, would you
accept my offer of information so
you may run my program and
perhaps give me a computation?
PRIEST: (on behalf of the
machine): We will try. We promise
nothing.

6. Priests vs Acolytes
■ Os Acolytes (ou desenvolvedores)
praticamente não possuíam acesso a
Maquina em si. Eles submetiam seus
programas ao Computador e esperavam
por horas, e talvez até dias, pelo resultado
de seus programas.
■ Eram em sua maioria Cientistas, de modo
que todas as políticas de acesso aos
Computadores eram pensadas pelos
Priests (Administradores de Sistemas).
– Assim a Segurança começara a ser
pensada por esses profissionais.

7. Phone Phreaking
■ Foi com o Phone Phreaking que a
atividade Hacker alcançou o grande
público, trazendo grande pressão
aos os profissionais de Redes e
Telecomunicações que também
passaram exercer grande
protagonismo em Segurança.
■ Dessa maneira, a Segurança passou
a se desenvolver de acordo com a
visão de seus protagonistas:
Administradores de Rede e
Sistemas.

8. Worm de Morris
• Considerado o primeiro Worm a
se disseminar na Internet – 2
de Novembro de 1988.
• Se propagava de maquina em
maquina por meio de uma
vulnerabilidade buffer-overflow
de um programa chamado
fingerd.
• Infectou cerca de 10% da
recém-nascida Internet.
• De $10-100M em prejuízos.

9. Worm de Morris
■ Com o Worm de Morris, testemunhamos o mais
emblemático incidente decorrente de uma
vulnerabilidade em Software, até então.
■ Diante disso, qual teria sido a resposta da
comunidade?
– Procurar entender melhor os riscos associados a uma
vulnerabilidade no Software?
– Esforço para o desenvolvimento de melhores práticas
para o desenvolvimento de Software?
– Iniciativas de disseminação de conhecimento sobre
vulnerabilidades em Software?

10. Worm de Morris
■ Não se tem notícias sobre iniciativas em torno do
Desenvolvimento Seguro a partir desta época.
■ O que se observou foi a adaptação de um conceito de
Redes para uso em Segurança, o Firewall.
– O Firewall passou a ser utilizado na computação no início dos
anos 80, para impedir que o comportamento errôneo de uma
rede, devido à má configuração, se disseminasse pelas outras
Redes1.
– No fim dos anos 80, começaram-se os esforços para o
estabelecimento do Firewall como conhecemos hoje2: uma
barreira de filtragem entre duas redes com diferentes níveis de
confiabilidade.
[1] https://www.cisco.com/c/en/us/about/press/internet-protocol-journal/back-issues/table-contents-1/ipj-
archive/article09186a00800c85ae.html
[2] http://www.darkreading.com/who-invented-the-firewall/d/d-id/1129238

11. Segurança de Perímetro

12. O QUE É O
PERÍMETRO
HOJE?

13. As Ferramentas que Protegem o Perímetro são SW!
1/3 das vulnerabilidades nos sistemas do governo americano foram encontradas em
sistemas de segurança. Via @dotMudge.

14. A primeira e
última das
barreiras
• A boa Segurança é feita em
Camadas (Segurança em
Profundidade).
• Combina-se múltiplas barreiras, de
modo que se uma é transpassada,
existirá outra para conter o
ataque.
• Ex: Firewall + SIEM + Antivirus.
• Visto que tais camadas são
implementadas com Software, ele
representa a PRIMEIRA e a ÚLTIMA
destas camadas.

17. Vulnerabilidades

18. Falhas de Injeção
■ Ocorrem todas as vezes em que é possível a injeção de
código por um canal destinado a receber dados do
usuário.
■ A História tem nos mostrado que a mistura de dados e
controle é fatal.
– Exemplos:
■ AT&T 2600 Hertz
■ SQL Injection
■ Cross-Site Scripting
■ ...
■ Buffer-Overflow

19. Encontre a Falha
CVE 2006-6563: (ProFTPD before 1.3.1rc1)
read(origem, buffer, qtd_bytes)

20. Smashing the Stack
Preenchimento de um Buffer
High memory
Low memory
argv
EBP
ret
EBP - old
buffer
ESP
char buffer[8]
AAA0
AAAA

21. Sobrescrevendo o endereço de retorno (i)
High memory
Low memory
argv
EBP
ret
EBP - old
buffer
ESP
char buffer[8]
AAAA
AAAA
AAAA
AAA0
Smashing the Stack

22. Sobrescrevendo o endereço de retorno (ii)
High memory
Low memory
argv
EBP
ret
EBP - old
buffer
ESP
char buffer[8]
AAAA
AAAA
AAAA
x21x38x04x08
0x08043821
apocalipse_zumbi()
0
Smashing the Stack

23. Retornando para o shellcode
High memory
Low memory
argv
EBP
ret
EBP - old
buffer
ESP
Shellcode
xbfxffxf4x37
0
Smashing the Stack

24. Correção
CVE 2006-6563 (Patch)
1
Tamanho informado
é checado antes de
realizar a cópia do
conteúdo.

25. Conclusão
■ Para se evitar a vulnerabilidade CVE 2006-6563, não era
necessário um conhecimento muito esotérico sobre técnicas
de exploração, corrupção de memória, entre outros.
■ Um conhecimento sobre melhores práticas de codificação
segura, além de um entendimento básico sobre as classes de
vulnerabilidades serviria.
■ Isso expõe outra questão fundamental do problema
apresentado. A falta de Capacitação em Codificação Segura
ou sobre aquilo que poder errado.

26. O Ensino de
Segurança
Quando se analisa a ementa
dos cursos de Ciência da
Computação e Correlatos das
grandes Universidades, quase
não se encontra conteúdo de
Segurança.
• Quando existe, são matérias
optativas ou de
especialização oferecidas no
término do curso.

27. O Ensino de
Segurança
Quando se analisa a ementa
dos cursos de Ciência da
Computação e Correlatos das
grandes Universidades, quase
não se encontra conteúdo de
Segurança.
• Quando existe, são matérias
optativas ou de
especialização oferecidas no
término do curso.

28. [1] How to Prevent Security Afterthought Syndrome. https://www.youtube.com/watch?v=iLiQqii0c9E.
Acesso em 01/10/2018.
O Ensino de Segurança
■ Ensinar a Segurança no fim gera dois efeitos:
1. The Afterthough Syndrome1.
– É quase que uma prática de mercado se
pensar a Segurança como algo isolado que se
insere nas últimas etapas de desenvolvimento.

29. O Ensino de Segurança

30. Imagem extraída de https://www.conviso.com.br/. Acesso em 01/10/2018.

31. O Ensino de Segurança
■ Ensinar a Segurança no fim gera dois efeitos:
2. Reforça a tese de que Segurança é somente para
especialistas.
– Do que adianta somente formar especialistas se a
grande maioria dos bugs são inseridos pelos
profissionais de formação regular (em segurança)?
Quando se trata de Segurança de Software, os
profissionais de Segurança NÃO são os agentes de
mudança.

32. A Segurança é Interdisciplinar
■ Questões de Segurança permeiam todas as áreas
da Computação.
– Do Hardware ao Software, passando pelos mecanismos
de Comunicação.
■ Questões de Segurança deveriam ser tratadas com
naturalidade dentro das disciplinas tradicionais: Engenharia
de Software, Sistemas Operacionais, Banco de Dados,
Programação, entre outros.
– Ex: o estudo sobre técnicas como Modelagem de
Ameaças e Corrupção de Memória só enriquecem as
ementas tradicionais dos cursos de Eng. de SW e SO,
respectivamente.

33. Tendências ...
■ O Livro “Software Engineering”
por Ian Sommerville é um dos
mais utilizados nas disciplinas
de Engenharia de Software e
teve sua primeira edição escrita
em 1982.
■ Desde sua 9° edição (2010)
passou a contemplar toda uma
parte destinada a assuntos de
Confiabilidade e Segurança dos
Sistemas.

34. Tendências ...
■ ACM (Association for Computing Machinery) que desde os
anos 60 estabelece diretrizes para o currículo de cursos de
Ciência da Computação, contemplou a Segurança como uma
área de conhecimento pela primeira vez em 20131.
[1] https://www.acm.org/education/curricula-recommendations

35. Tendências ...
■ Em 2015 foi formada uma força tarefa (the Joint Task Force on
Cybersecurity Education - JTF)1 com o objetivo de desenvolver orientação
curricular para a educação em Cibersegurança junto as universidades.
[1] https://cybered.hosting.acm.org/wp/

36. Iniciativas em
Segurança de
Aplicações
■ Writing Secure Code -
Michael Howard e David
Leblanc (2001);
■ Building Secure
Software - Gary McGraw
e John Viega (2001);
■ Bill Gates's Trustworthy
Computing memo
(2002).

37. Iniciativas em Segurança de
Aplicações
ISO/IEC 27034

38. Conclusões
■ O problema da exploração de
vulnerabilidades será resolvido pelos
Desenvolvedores? Ou esta é uma questão
para os Cientistas da Computação?

39. @viniciusofer
Vinicius Oliveira Ferreira
vinicius.olifer@gmail.com