Saltar a contenido

Instructivo — Pentester / QA de seguridad

Tu objetivo es encontrar vulnerabilidades en la aplicación de Mercado Mayor corriendo en mm-testserver (Tailscale IP 100.116.16.34). Tenés luz verde para atacar los servicios dentro del scope.

Scope — qué podés atacar

En scope:

  • Frontend: http://100.116.16.34:3000 (Next.js, todo lo que expone al cliente)
  • Backend API: http://100.116.16.34:3002 (Express + TypeScript)
  • AI service: http://100.116.16.34:8010 (FastAPI) — accesible directo si estás en el host, o via /api/ai/* a través del backend

Vulnerabilidades de interés:

  • OWASP Top 10 (inyección, XSS, CSRF, SSRF, broken auth, broken access control, etc.)
  • Auth / session handling (JWT, cookies, refresh tokens)
  • API abuse (rate limiting, mass assignment, IDOR)
  • Business logic (precios, cantidades, carritos, flujos de compra)
  • Upload / file handling
  • LLM prompt injection en el chat del AI service

Fuera de scope:

  • El host macOS en sí (no escalation, no persistence, no abuso de el servidor)
  • Tailscale como servicio (atacar tailscale.com queda fuera)
  • Ataques de DoS / volumétricos (saturar el server no aporta)
  • Engeniería social hacia el equipo (obvio) jajaja

Si encontrás algo fuera del scope "por accidente", reportalo pero no lo profundices.

Paso 1 — Instalar Tailscale

El server no está expuesto al internet. Se accede solo por Tailscale.

  1. Descargá el cliente desde https://tailscale.com/download.
  2. Logueate con el mail que te invitó el admin.
  3. Confirmá que ves mm-testserver (IP 100.116.16.34) en tu lista de dispositivos.

Tu laptop ahora resuelve mm-testserver via MagicDNS y llega a los puertos 3000/3002/8010.

Paso 2 — Verificar acceso

```bash

Frontend (debería devolver 200)

curl -sI http://100.116.16.34:3000 | head -1

Backend health

curl -s http://100.116.16.34:3002/api/health

AI service

curl -s http://100.116.16.34:8010/health ```

Si los tres responden ok, estás dentro. Si no, confirmá que Tailscale esté activo.

Paso 3 — (Opcional) SSH para ver logs / BD

Si tu engagement requiere ver logs del server o inspeccionar la BD, el admin te crea tu propio user Unix (ej. luis-pt) con permisos acotados:

  • Lee el proyecto en /Users/Shared/MercadoMayor (no escribe — read-only por ACL de grupo mmpentest).
  • Lee los logs en /Users/Shared/MercadoMayor/logs/.
  • No puede modificar código, .env, ni el stack.
  • No tiene sudo (excepto los wrappers mm-restart-* si los necesita).

Conexión:

```bash ssh @mm-testserver

o con IP:

ssh @100.116.16.34 ```

Para queries sobre la BD, psql está instalado en el server (también podés instalarlo en tu laptop y conectarte remoto via Tailscale):

```bash

Desde el server (SSH-eás y corrés):

PGPASSWORD=pentest_ro_local psql -h localhost -p 5433 -U pentest_ro -d cargo_db

Desde TU laptop con Tailscale activo (sin SSH-ear, directo al puerto expuesto):

PGPASSWORD=pentest_ro_local psql -h mm-testserver -p 5433 -U pentest_ro -d cargo_db

Ejemplo de exploración:

PGPASSWORD=pentest_ro_local psql -h mm-testserver -p 5433 -U pentest_ro -d cargo_db \ -c "SELECT count(*) FROM mm_productos WHERE estado='activo'" ```

El user pentest_ro tiene solo SELECT sobre todas las tablas de cargo_db. Cualquier INSERT/UPDATE/DELETE/DDL falla con permission denied. Si encontrás forma de escribir siendo pentest_ro, eso es un finding de privilege escalation.

Paso 4 — Herramientas recomendadas

Todas corren desde tu laptop apuntando al server. No instalás nada en el server.

Herramienta Uso
nmap Reconocimiento de puertos
Burp Suite Proxy, replay, fuzzing, scanner
OWASP ZAP Alternativa libre a Burp
sqlmap Pruebas de SQL injection
ffuf / dirsearch Fuzzing de paths y parámetros
nuclei Scan de CVEs conocidos
Postman / httpie Pruebas manuales de API

Ejemplos rápidos

```bash

Port scan dirigido

nmap -sV -p 3000,3002,8010 100.116.16.34

Crawl del API

ffuf -u http://100.116.16.34:3002/api/FUZZ -w /usr/share/seclists/Discovery/Web-Content/api/api-endpoints.txt

Forzar el flujo de login (usar endpoints del backend)

curl -X POST http://100.116.16.34:3002/api/mm/auth/login \ -H 'Content-Type: application/json' \ -d '{"email":"test@mercadomayor.com","password":"..."}' ```

Paso 5 — Datos de test disponibles

La BD tiene ~16.450 productos y varios usuarios de testing. Pedile al admin un "kit de cuentas":

  • Usuario comprador
  • Usuario vendedor
  • Usuario admin
  • Organización con usuarios y roles

Así podés probar flujos de autenticación y autorización con cuentas reales (todas ficticias).

Paso 6 — Reportar findings

Cada hallazgo va como issue en el repo privado (el admin te da acceso) con este formato:

``` Título: [severidad] descripción corta ej: [High] IDOR en GET /api/mm/pedidos/:id

Resumen: Qué se puede hacer con esto en 2-3 líneas.

Pasos para reproducir: 1. Login como user A (token X) 2. GET /api/mm/pedidos/123 (que es de user B) 3. Devuelve la orden de user B

Impacto: Lectura no autorizada de pedidos de otros usuarios.

Evidencia: curl/screenshot/HAR

Sugerencia de fix: Agregar chequeo de ownership en el controller. ```

Severidades (guía): Critical / High / Medium / Low / Info.

Reglas de la casa

  • No dejes el server caído. Si pensás correr algo que puede tumbar la app (fuzz a -t 500, DoS, etc.), avisá primero.
  • No exfiltres datos. Son fake, pero igual. Si los necesitás como evidencia, ofuscá.
  • No agregues usuarios ni datos basura a la BD sin avisar — eso dificulta el trabajo de otros.
  • Un ataque por vez. Si hay varios pentesters activos, coordinen por el grupo para no pisarse.