Link da Maquina: https://www.vulnhub.com/entry/nullbyte-1,126/
Scan/Enumeracao
Host Discovery
Com o arp-scan descobrimos que o nosso alvo esta no ip 192.168.110.5
1
sudo arp-scan -I eth1 192.168.110.0/24
Port Discovery
Com o parametro “-p-“ do nmap varremos todas as portas possiveis do nosso alvo e encontramos 03 delas abertas. 80, 111, 777 e 48169
1
sudo nmap -n -T5 -p- 192.168.110.5
Port Scan
Agora com o parametro “-A” do nmap vamos descobrir mais informacoes sobre essas portas abertas do nosso alvo
1
sudo nmap -n -T5 -A -p 80,111,777,48169 192.168.110.5
- Porta 80: Apache httpd 2.4.10 ((Debian))
- Porta 111: rpcbind 2-4 (RPC #100000)
- Porta 777: OpenSSH 6.7p1 Debian 5 (protocol 2.0)
- Porta 48169: 1 (RPC #100024)
Web - Porta 80
Inspecao Visual - Browser
Acessando a pagina web
Nikto
Vamos enumerar a web com a ferramente “Nikto”. Achamos um diretorio “/phpmyadmin/”
Fuzzy de Diretorios - Gobuster
Paralelamente ao nikto deixamos rodando o gobuster para enumerar os diretorios e/ou arquivos existentes. Encontramos as paginas /uploads, /javascript e /phpmyadmin
Accesando /uploads nao temos nada por enquanto
Acessando /javascript, codigo 403, forbidden
Rodamos o gobuster novamente para tentar pegar algum diretorio recursivo, encontramos o diretorio /jquery, porem nao conseguimos accesa-lo, codigo 403
Rodamos o gobuster recursivamente no 192.168.110.5/javascript/jquery e encontramos
- Acessando as paginas encontradas temos
- Nao temos nada alem disso… Vamos continuar em frente…
Acessando a /phpmyadmin temos a aplicacao phpMyAdmin
Tentamos algumas senhas obvias como a padrao da aplicacao, porem nao obtivemos resultado positivo
Rodamos o gobuster revursivamente, encontramos varios diretorios e arquivos padroes da aplicacao, porem nada de interessante por enquanto…
Imagem - “index.gif”
Depois de quebrar a cabeca com o phpMyAdmin voltamos para a pagina principal e baixamos a imagem para examina-la com mais precisao
Exiftool
Verificando os metadados da imagem encontramos um comentario que pode ser util: “P-): kzMb5nVYJw”
- Tentamos verificar se era algum tipo de hash, ou se era a senha mas nao deu certo em nenhum caso
192.168.110.5/kzMb5nVYJw
Ao verificar se existia esse diretorio na web obtivemos um resoltado positivo!
Como e de praste, verificando o codigo fonte da aplicacao tem um comentario interessante que fala que o formulario nao esta conectado ao banco, ou seja, a autenticacao deve ser feita diretamente na aplicacao. Diz tambem que a senha nao e muito dificil…
- Testamos algumas senhas que sao padrao mas nao conseguimos nada. Entao o que nos resta e um bruteforce
BruteForce
Para realizar o ataque de forca burta contra a aplicacao web, temos que saber como esta sendo enviado o formulario de autenticacao. Pode ser pelo metodo GET, sendo passado via URL, ou pelo metodo POST. Para saber como esta sendo feito, podemos olhar na ferramente do desenvolvedor do navegador ou se quiser ter uma experiencia mais performatica pode ser utilizado o BurpSuite para isso.
BurpSuite
Para capturar o trafego iniciamos o Burp e navegamos ate a aba “Proxy” e deixamos a opcao “Intercept is on”. Depois disso configuramos no nosso navegador o proxy do Burp. Nesse caso estou utilizando o Firefox e a extensao “FoxyProxy”
Feita a configuracao conseguimos capturar a requisicao da aplicacao e constatamos que esta sendo enviado pelo metodo POST
WFUZZ
Montamos o comando com o POST da requisicao da aplicacao para realizar um bruteforce com o WFUZZ. Coseguimos achar a senha “elite”
1
wfuzz -c --hl 8 -w /usr/share/wordlists/SecLists/Passwords/Most-Popular-Letter-Passes.txt -d "key=FUZZ" http://192.168.110.5/kzMb5nVYJw/index.php
SQLinjection
Conseguimos acessar a pagina com a senha que encontramos
Sem passar nenhum parametro no formulario, apenas apertando “ENTER”, conseguimos interagir com o banco, que nos mostou um resultado interessante…
BurpSuite
Para deixar a nossa experiencia mais performatica vamos abrir o Burp, interceptar a requisicacao e jogar para o repeater…
Depois de um bom tempo conseguimos montar uma requisicao para o banco. O primeiro passo para o SQLi e saber quantas colunas da tabelas estao sendo usadas pela aplicacao. Para isso usamos o comando “order by”
- Quando estamos lidando com requisicoes GET temos que ter a preocupacao com os caracteres que podem quebrar a requisicao. Depois de alguns testes verificamos que o caractere “#” nao e interpretado pela aplicacao, por isso tivemos que codifica-lo para URL (%23). O caractere “espaco” teve que ser codificado tambem (%20)
1
usrtosearch="%20order%20by%204%23
- O nosso payload pode ser montado da seguinte forma, tambem:
1
usrtosearch="+order+by+3+--+-
A string
-- -tem o mesmo efeito do#no SQL. Comenta o que vem em seguida…
Agora conseguimos extrair informacoes… Nessa requisicao conseguimos extrair a versao do SGBD, Banco de Dados em uso e usuario
1
usrtosearch="union+select+version(),database(),user()%23
Listamos os Bancos de Dados existentes na maquina
1
usrtosearch="union+select+1,schema_name,3+from+information_schema.schemata%23
Listamos as tabelas do bando de dados “seth”
1
usrtosearch="union+select+9,table_name,9+from+information_schema.columns+where+table_schema=database()%23
Listamos as colunas da tabela “user” do banco “seth”
1
usrtosearch="union+select+9,column_name,9+from+information_schema.columns+where+table_schema=database()%23
Listamos as colunas “user”, “pass” e “position” da tabela “users” do banco “seth”
1
usrtosearch="union+select+user,pass,position+from+users+%23
- YzZkNmJkN2ViZjgwNmY0M2M3NmFjYzM2ODE3MDNiODE
Usuario Ramses
Shell Reverso
hashes.com
Achamos um hash de senha na exploracao SQLi, decodificando temos a string “omega”
- YzZkNmJkN2ViZjgwNmY0M2M3NmFjYzM2ODE3MDNiODE:c6d6bd7ebf806f43c76acc3681703b81
- c6d6bd7ebf806f43c76acc3681703b8:omega
SSH
Conseguimos logar com a credencial ramses:omega no SSH na porta 777
Escalando Privilegio
History
Uma boa pratica na metodologia para escalar privilegio e olhar o historico do usuario atual… No historico do usuario ramses podemos observar que ele executa um arquivo procwacth no diretorio /var/www/backup/
PROCWATH
Verificando o arquivo que encontramos observamso que ele tem permissao especial, SUID. Ou seja, podemos executar ele com os mesmos privilegios do dono. Nesse caso podemos observar que o dono e o root
Executando o arquivo temos, aparentemente, a listagem de processos do terminal (comando “ps” puro)
Note a semelhanca do binario e do comando “ps”
Sequestro de PATH
Bom, sabemos que o binario provavelmente esta executando o comando “ps” e tem permissao SETUID. Entao podemos realizar um sequestro de PATH, que consiste em criar um script com o mesmo nome do binario que esta sendo chamado pelo procwatch (ps) e acrescentar o diretorio onde esta esse script na variavel PATH do usuario. Quando executamos um binario da maquina ele procura nos diretorios do PATH e executa da esquerda para a direita, fazendo com que o nosso payload seja executado no lugar do binario correto
Script - HereDoc
Vamos utilizar a tecnica “HereDoc” para escrever esse script. Mas na verdade poderiamos escrever de varias otras formas. Essa tecnica e utilizada para escrever documentos quando nao temos um shell interativo
1
2
3
4
cat << SAIR > ps
> #!/bin/sh
> /bin/sh
> SAIR
PATH
Agora vamos sequestrar o PATH do usuario, para isso incluimos o diretorio onde esta o nosso script na variavel PATH do usuario
1
export PATH=/var/www/backup:$PATH
Root
Agora executamos o binario e coneguimos virar root
Flag - Root
Conseguimos pegar a flag de ROOT
