La lección anterior terminó con una pregunta que ni el escáner de 05-01 ni la detección de 05-02 responden: ¿aguantaría de verdad? Un escáner comprueba versiones y una detección observa lo que ocurre, pero ninguno intenta encadenar tres debilidades pequeñas —una cabecera ausente, un límite de tasa que no existe y un identificador predecible— hasta convertirlas en un compromiso real. Eso es lo que hace un atacante, y eso es lo que simula una prueba de penetración. Esta lección te enseña a encargarla, acotarla, entenderla y aprovecharla, con un enfoque defensivo: verás qué se encontró en el entorno de Nimbus y, sobre todo, cómo se corrigió cada cosa.

⚠️ Advertencia legal — esta es la lección más delicada del curso

Ejecutar técnicas de intrusión sobre un sistema ajeno sin autorización escrita es un delito, no una travesura. En España:

• Art. 197 bis del Código Penal: acceder o facilitar el acceso al conjunto o a una parte de un sistema de información vulnerando las medidas de seguridad, o interceptar transmisiones no públicas, se castiga con pena de prisión. No hace falta causar daño ni copiar nada: basta con acceder.
• Art. 264 y siguientes: dañar, borrar, alterar o hacer inaccesibles datos o sistemas ajenos, con penas agravadas si afectan a infraestructuras críticas o a un número elevado de sistemas.
• Art. 197 ter: producir, facilitar o poseer herramientas concebidas para cometer esos delitos también es punible cuando se destinan a ello.

Consecuencias prácticas: «solo quería probar» no es eximente, la ausencia de daño no elimina el tipo penal, un nmap intrusivo contra un tercero ya puede constituir un intento, y la autorización debe ser escrita, previa, firmada por quien tiene capacidad para otorgarla y vigente en la fecha de la prueba. En la nube necesitas además la autorización del proveedor además de la del cliente.

Por eso esta lección no contiene exploits, ni payloads, ni comandos de explotación. Describe las fases de forma conceptual, muestra la verificación defensiva equivalente y desarrolla en detalle cómo se corrige lo hallado. El marco ético y legal completo —incluida la divulgación responsable y el porqué de estas normas— se desarrolla en 06-06. (Nota: la calificación penal concreta depende del caso; ante cualquier duda, validación jurídica previa.)

1. Qué es un pentest y qué no lo es
2. Modalidades: caja negra, gris y blanca
3. Alcance y reglas de enfrentamiento
4. Las fases metodológicas
5. Qué ocurre en cada fase, y su equivalente defensivo
6. Recorrido de una prueba autorizada sobre el entorno de Nimbus
7. El informe de pentest
8. Qué pasa después: remediación y retest
9. Divulgación responsable y bug bounty como alternativa continua
10. Cómo contratar un pentest siendo pequeño
11. Dónde practicar legalmente

Un pentest es una prueba autorizada en la que un profesional intenta comprometer un sistema usando las mismas técnicas que un atacante real, con un objetivo declarado y un informe como producto. Su valor no está en encontrar vulnerabilidades sueltas —para eso está 05-01— sino en demostrar el impacto encadenándolas.

Para Nimbus hoy, un red team sería tirar el dinero. Mide la capacidad de detección y respuesta, y en 05-02 acabamos de construir las primeras doce detecciones: se contrata cuando llevan un año funcionando. Lo que sí procede es un pentest anual de la aplicación y la infraestructura, que es donde vive el producto y el riesgo.

Y una diferencia que conviene tener clara: un pentest no demuestra que un sistema sea seguro. Demuestra que, en un plazo acotado y con un alcance acotado, una persona concreta encontró estas cosas. Un informe sin hallazgos suele significar que el alcance era estrecho o que el tiempo fue corto, no que el sistema sea inexpugnable.

La caja gris da más valor por euro, y en un SaaS multi-tenant la diferencia es abismal. El motivo es directo: en Nimbus, el riesgo principal no es que un desconocido entre, sino que un cliente legítimo vea los datos de otro —el IDOR de 01-04 es exactamente eso—. Un pentest de caja negra jamás lo habría encontrado, porque para probarlo hay que estar dentro con dos cuentas de dos tenants distintos. Pagar por que alguien dedique tres días a descubrir lo que un nmap da en diez minutos es un mal uso del presupuesto.

Recomendación para Nimbus: caja gris con dos cuentas de prueba de dos clínicas ficticias distintas y una cuenta de rol soporte, más acceso de lectura a la documentación de la API.

Las reglas de enfrentamiento (rules of engagement) son el documento que convierte una intrusión en un servicio profesional. Sin ellas, la prueba es legalmente frágil para ambas partes y operativamente peligrosa.

Cinco cláusulas merecen énfasis. El punto 3 protege al auditor tanto como al cliente: Nimbus no puede autorizar pruebas sobre la pasarela de pago porque no es suya, y hacerlo sería exactamente el delito de la advertencia inicial. La autorización del proveedor cloud (punto 1) es obligatoria y muchos la olvidan: el proveedor tiene una política de pruebas y saltársela puede suspender la cuenta. El punto 5 es el que evita convertir una auditoría en una brecha: si preproducción tiene datos reales —recuerda A-22, «clasificación a revisar»—, descargarlos crea el incidente que se quería prevenir. El punto 6c existe porque ocurre: a veces el auditor encuentra que ya hay alguien dentro, y ahí la prueba se detiene y se activa el plan de 04-05. Y el punto 8 es lo que separa un servicio útil de un informe póstumo: si el día 2 alguien encuentra la forma de leer los datos de todas las clínicas, no se espera dos semanas.

Las metodologías reconocidas —PTES, OSSTMM y, para aplicaciones web, la OWASP Web Security Testing Guide (WSTG)— coinciden en la estructura. La WSTG es además una lista de comprobación pública y gratuita: si contratas un pentest de aplicación, pedir cobertura WSTG es la forma más simple de comparar ofertas.

Dos avisos sobre el diagrama. El primero: la fase 4 no es el objetivo, es la prueba. Explotar sirve para demostrar que la vulnerabilidad es real y medir su impacto; un auditor profesional explota lo justo para documentarlo y se detiene. El segundo: la fase 7 es la que casi todo el mundo omite, y sin ella no sabes si pagaste por una lista de deberes que nadie hizo.

Sobre las herramientas nombradas, con la precisión que exige el enfoque de esta lección: nmap y testssl.sh son de reconocimiento y verificación y los usas tú a diario; ZAP y Burp son proxies de intercepción que permiten ver y modificar las peticiones que tu propio navegador envía —su uso legítimo es contra tu aplicación—; ffuf y gobuster prueban listas de rutas y ficheros contra un servidor propio para descubrir lo que quedó publicado sin querer; hydra prueba credenciales, y solo tiene un uso admisible aquí: comprobar sobre tus propias cuentas de prueba que el bloqueo por intentos fallidos y el límite de tasa funcionan, que es una verificación defensiva; y Metasploit es un marco que empaqueta módulos de explotación de vulnerabilidades conocidas y cuyo uso queda dentro del alcance autorizado y nunca en este material.

Una observación que ahorra dinero: casi todo lo que un pentest encuentra de verdad valioso en un SaaS es manual y de lógica de negocio. El IDOR, el flujo de recuperación de contraseña que permite enumerar usuarios, el endpoint de informes que ignora el rol. Ninguna herramienta lo automatiza, y por eso se paga por horas de una persona con criterio.

Marta contrata cinco días de caja gris sobre preproducción, con las reglas del §3. Estos son los cinco hallazgos y su corrección.

El WHERE tenant_id se aplicó en los endpoints de reservas y clientes, pero el módulo de informes se escribió después y consulta con una vista agregada que nadie revisó. Con la cuenta de la clínica Alfa, cambiando un identificador de la petición, se obtenían totales de facturación de la clínica Beta.

La corrección de fondo no es la línea cambiada: es que el identificador de cliente deja de ser un parámetro de entrada en toda la API. Además se activó RLS en la vista agregada, que ya protegía las tablas base pero no la vista (03-07). La generalización de este patrón a toda la aplicación se desarrolla en 05-05.

El auditor comprobó que se podían enviar 4.000 intentos de autenticación en cinco minutos sin bloqueo ni ralentización: la puerta abierta al credential stuffing de 02-02.

Y en la aplicación, bloqueo por cuenta además de por IP, porque el password spraying usa una IP distinta por intento: tras 10 fallos sobre la misma cuenta en 15 minutos, se exige segundo factor o se retrasa exponencialmente. Ambos alimentan la detección D-01 de 05-02.

Faltaba Content-Security-Policy en la SPA, lo que convertía cualquier XSS en un robo de sesión completo. Se desplegó primero en modo informe para no romper la aplicación:

Tras revisar los informes y ajustar dos orígenes legítimos, se cambió a Content-Security-Policy en modo bloqueante. El conjunto completo de cabeceras y el porqué de cada una está en 05-05.

El reconocimiento encontró pruebas-2019.nimbusreservas.example, servido por un host que aceptaba TLS 1.0 y suites con RC4, y apuntando a una IP que ya no estaba bajo control de Nimbus: candidato a toma de control de subdominio (05-04).

Corrección: eliminar el registro DNS —no parchear un host que debe desaparecer, como ya concluimos en 05-01— y añadir al inventario una revisión trimestral de la zona DNS.

Un panel de administración de colas, desplegado «temporalmente» hace ocho meses, respondía en /flower con admin/admin y sin autenticación en el proxy. Desde ahí se veían los identificadores y correos de las tareas en curso.

El acceso pasa a hacerse por túnel SSH a través del bastión. Este hallazgo es el más instructivo de los cinco: no es una vulnerabilidad de software, no tiene CVE, ningún escáner de 05-01 lo habría marcado como crítico y llevaba ocho meses expuesto. Es el mismo patrón que el python -m http.server: lo temporal que se queda.

El informe es el producto. Un auditor que entrega un volcado de herramienta con 80 páginas de salida sin priorizar no ha hecho el trabajo, y esa es la señal más fiable para no repetir con ese proveedor.

Los elementos que lo hacen accionable son los mismos de 05-01, con dos añadidos propios del pentest: la reproducción paso a paso —sin ella, el desarrollador no puede confirmar la corrección— y el criterio de verificación del retest, que fija de antemano qué se considerará arreglado.

El error clásico es archivar el informe. El ciclo correcto es corto y tiene dueños:

1. Reunión de entrega con el auditor, Marta, Lucía e Iván. Se discute cada hallazgo hasta que el equipo lo entiende; un informe que se entrega por correo y no se explica pierde la mitad de su valor.
2. Plan de remediación con dueño y fecha, usando la política de plazos de 05-01: críticas en 7 días, altas en 30. Cada hallazgo se convierte en un issue con criterio de aceptación.
3. Actualización del registro de riesgos de 04-01. El IDOR residual no es un hallazgo suelto: modifica el riesgo R-04 (fuga de datos entre clientes), cuyo residual estaba calculado asumiendo que el control C-05 estaba implantado. Estaba implantado a medias, que es la lección de 04-03 sobre implantado frente a eficaz.
4. Retest, incluido en el contrato original y no como servicio aparte. Es un ejercicio corto —normalmente uno o dos días— que solo comprueba los hallazgos corregidos y produce un anexo con el estado final. Sin retest, el pentest mide el pasado.
5. Lecciones estructurales. Si aparecieron dos IDOR, el problema no son dos líneas: es que la autorización se decide en cada ruta. La corrección estructural —la dependencia común— evita el tercero.

Un pentest anual es una foto; los investigadores externos miran todo el año. Para una PYME hay tres escalones, y el primero es gratuito y obligatorio:

Advertencia de gestión: un bug bounty sin capacidad de responder es peor que no tenerlo. Si llegan 40 informes y nadie los tría en 48 horas, la comunidad lo publica y la reputación (A-20) sufre más que con el fallo original. La ética de la divulgación, los plazos razonables y el conflicto entre investigador y empresa se desarrollan en 06-06.

Qué pedir en la petición de oferta, y son cinco cosas concretas: metodología declarada (PTES o WSTG), perfil y certificaciones nominales de quien ejecutará (no de la empresa), días-persona reales dedicados —la variable que determina la calidad—, retest incluido, y un informe de ejemplo anonimizado, que es el mejor predictor de lo que recibirás.

Precio orientativo en España para una PYME: 4.000-8.000 € por una aplicación web con API, en caja gris, 5 días-persona con informe y retest; 8.000-15.000 € si se añaden infraestructura cloud y aplicación móvil. Cadencia razonable: anual, más una prueba adicional ante cambios arquitectónicos importantes (nuevo módulo con datos sensibles, cambio de proveedor de identidad, migración de infraestructura). Con 18.000 €/año, Nimbus puede permitirse un pentest anual de aplicación si acepta que ese es el mayor desembolso único del presupuesto, y la decisión es defendible: A-04 es el producto.

Tres señales de alarma al comparar ofertas: precio cerrado sin conocer el alcance, «pentest automatizado» (eso es un escaneo con otro nombre y otro precio), y negarse a entregar un informe de ejemplo.

Practicar explotación es necesario para entender la defensa, y solo hay un sitio donde hacerlo: entornos diseñados para ello.

La regla, sin matices: si el sistema no es tuyo y no tienes autorización escrita, no es un laboratorio. No lo son la web de tu antigua empresa, ni la de un proveedor que «seguro que lo agradece», ni la de un familiar. Los laboratorios de la tabla existen precisamente para que nunca haya excusa. Y en un entorno profesional, esa práctica se hace además en una red aislada, con instantáneas y sin conexión a la red corporativa.

• Encargar un pentest sin autorización escrita ni reglas de enfrentamiento. Expone legalmente a las dos partes y deja sin marco lo que ocurre si algo se cae.
• Elegir caja negra por «realismo». En un SaaS multi-tenant pagas reconocimiento en lugar de profundidad, y el riesgo principal —fuga entre clientes— se queda sin probar.
• Probar contra producción sin necesidad. Si preproducción es equivalente, se prueba allí; y si no lo es, arreglar esa diferencia es más urgente que el pentest.
• No excluir a los terceros. No puedes autorizar pruebas sobre la pasarela de pago ni sobre la consultora: no son tuyos.
• Contratar sin retest. Sin verificación, el informe describe un sistema que ya no existe y nadie sabe si se corrigió.
• Tratar los hallazgos como incidencias sueltas. Dos IDOR no son dos errores: son un patrón de diseño de la autorización.
• Consejo: pásale al auditor el resultado de 05-01. Si ya has corregido lo que un escáner encuentra, sus cinco días se van a lo que ninguna herramienta ve. Es la forma más directa de multiplicar el valor de lo que pagas.
• Consejo: publica hoy tu security.txt. Cuesta media hora, es gratis y determina si el próximo fallo que alguien encuentre llega a tu buzón o a otro sitio.
• Consejo: avisa a tu propia guardia. Con las detecciones de 05-02 activas, un pentest generará alertas. Que salten y se atiendan es, de hecho, una prueba gratuita de que la detección funciona: anótalo como verificación.

Un proveedor envía este resumen de alcance. Identifica al menos seis problemas y reescribe las cláusulas afectadas.

Nimbus lanza en septiembre un módulo de teleconsulta con vídeo y notas clínicas. Marta dispone de 9.000 € para seguridad ofensiva este año y pregunta qué contratar.

1. ¿Pentest, red team, auditoría o bug bounty? Justifícalo.
2. Modalidad y alcance concretos, incluyendo qué cuentas y qué se excluye.
3. Cómo repartir los 9.000 € y qué se hace con lo que sobre.

Durante la prueba, el auditor descubre que el flujo de recuperación de contraseña responde "Correo no registrado" cuando la dirección no existe y "Te hemos enviado un enlace" cuando sí, permitiendo enumerar qué correos son clientes de cada clínica. En un SaaS usado por clínicas de fisioterapia, saber que una dirección es cliente ya es información sensible.

1. Redacta la ficha del hallazgo con el formato del §7, asignando severidad con criterio.
2. Escribe la corrección en python explicando por qué funciona.
3. Indica cómo se verificaría en el retest y qué detección de 05-02 lo cubriría.

Ejercicio 1

Ejercicio 2

(1) Pentest, sin duda. Red team queda descartado porque mide detección y respuesta, y las detecciones de 05-02 llevan meses, no años: mediría un fracaso previsible por un precio muy alto. La auditoría de cumplimiento responde a otra pregunta y se tratará en 06-04. El bug bounty exige capacidad de respuesta que Nimbus aún no tiene. Y el momento es el correcto: un módulo con vídeo y notas clínicas es datos de salud, es una superficie nueva y es exactamente cuando conviene probar, antes del lanzamiento y no después.

(2) Modalidad y alcance. Caja gris, con dos cuentas de clínicas distintas, una cuenta de paciente y una de soporte, más la documentación de la API y del flujo de vídeo. Alcance: el módulo de teleconsulta completo (creación de sala, control de acceso a la sala, notas clínicas, adjuntos y su cifrado campo a campo de 03-07) más los endpoints de la API que toca, en preproducción. Excluidos: producción, el proveedor de vídeo, la pasarela, el correo transaccional y toda ingeniería social. Se pide cobertura OWASP WSTG y API Top 10 (05-05), con dos preguntas explícitas para el auditor: ¿puede un paciente entrar en la sala de otro? y ¿puede una clínica ver las notas de otra?

(3) Reparto. ~6.500 € en 5 días-persona de caja gris con informe y retest incluido; ~1.000 € reservados para una segunda vuelta corta si aparecen críticas que exijan rediseño; y ~1.500 € sin gastar hasta después del informe. Lo que sobre no se gasta en más ofensiva: se gasta en corregir. El error más caro del sector es consumir el presupuesto en encontrar y quedarse sin nada para arreglar. Además, gratis: publicar el security.txt y ejecutar 05-01 sobre el módulo antes de que llegue el auditor, para que sus días se dediquen a la lógica de negocio.

Ejercicio 3

(1) Ficha:

La severidad Media y no Baja es el juicio importante: el CVSS base la trata como fuga menor de información, pero el grupo ambiental de 05-01 la sube por el contexto de negocio. Es justo lo que un escáner no puede calcular.

(2) Corrección:

Funciona porque elimina las tres vías por las que se filtra la diferencia: el mensaje, el código de estado y el tiempo. La tercera es la que se olvida: sin la nivelación temporal, enviar un correo real tarda 300 ms más y el atacante mide esa diferencia con precisión. El mismo razonamiento se aplica al registro de cuentas y al cambio de correo, que son los otros dos puntos donde este fallo reaparece.

(3) Verificación y detección. En el retest se envían 200 peticiones alternando direcciones válidas e inválidas y se comparan cuerpo, código y distribución de tiempos: si la latencia media de los válidos difiere de forma consistente, el hallazgo sigue abierto. La detección que lo cubre es una variante de D-01: más de 20 peticiones a /auth/recuperar desde una IP en 5 minutos, o más de 100 correos distintos probados en una hora, con severidad S3 y bloqueo automático por fail2ban —una de las acciones que 05-02 clasificó como seguras de automatizar por ser reversibles—.

Ahora sabes qué es y qué no es un pentest: una prueba autorizada que demuestra impacto encadenando debilidades, distinta del escaneo (superficie conocida), de la auditoría (conformidad) y del red team (capacidad de detección), con su duración, su coste orientativo y el criterio para elegir cada uno —y con la conclusión de que para Nimbus hoy un red team sería tirar el dinero—. Sabes que un pentest no demuestra que un sistema sea seguro, y que un informe sin hallazgos casi siempre significa alcance estrecho o tiempo corto. Conoces las tres modalidades y por qué la caja gris da más valor por euro en un SaaS multi-tenant: el riesgo principal no es que entre un desconocido, sino que un cliente legítimo vea los datos de otro, y eso solo se prueba desde dentro con dos cuentas.

Te llevas la plantilla de acuerdo de alcance y reglas de enfrentamiento con sus cláusulas críticas: activos excluidos —no puedes autorizar pruebas sobre terceros—, autorización del proveedor cloud, ventana e intensidad, prohibición de descargar datos reales, condición de parada por compromiso preexistente, contacto de emergencia 24/7 y aviso en caliente de hallazgos críticos. Conoces las fases metodológicas de PTES/OSSTMM/WSTG y qué ocurre en cada una, siempre con su equivalente defensivo: enumera tus propios subdominios, ejecuta testssl.sh, corrige lo que un escáner ve antes de que llegue el auditor y mide tu segmentación tú mismo. Y sabes lo que ahorra dinero: lo verdaderamente valioso en un SaaS es manual y de lógica de negocio.

Has recorrido una prueba autorizada real sobre preproducción con sus cinco hallazgos y sus correcciones: el IDOR residual en informes, resuelto haciendo que el tenant_id deje de ser un parámetro de entrada en toda la API; el límite de tasa ausente, con limit_req en Nginx y bloqueo por cuenta para el password spraying; la CSP faltante, desplegada primero en Report-Only; el subdominio olvidado con TLS obsoleto, que se elimina en lugar de parchearse; y la credencial por defecto del panel de colas, el hallazgo más instructivo porque no tiene CVE, ningún escáner lo habría priorizado y es el mismo patrón que el http.server: lo temporal que se queda. Sabes qué debe contener el informe, cómo se redacta un hallazgo con reproducción paso a paso y criterio de retest, y por qué entregar un volcado de herramienta es la señal para cambiar de proveedor. Sabes qué pasa después: reunión de entrega, plan con dueños y plazos, actualización del riesgo R-04 en el registro de 04-01, retest incluido en el contrato y corrección estructural en lugar de parche puntual. Y sabes encuadrar la divulgación responsable —publica hoy tu security.txt, cuesta media hora— y el bug bounty como escalón posterior que no debe abrirse sin capacidad de respuesta, con el tratamiento ético y legal completo esperándote en 06-06. Por último, sabes contratar: qué pedir, qué acreditan OSCP y CREST, cuánto cuesta, cada cuánto hacerlo y en qué laboratorios —Juice Shop, DVWA, TryHackMe, HackTheBox— se practica la explotación, que son el único sitio donde practicarla.

Fíjate en cuántos de los cinco hallazgos eran, en el fondo, problemas de red y de exposición: un panel publicado en la interfaz externa del host, un subdominio que apuntaba a una IP ajena, un servicio accesible desde donde no debía. Y recuerda lo que sigue pendiente desde 05-01: PostgreSQL escuchando en 0.0.0.0:5432, SSH abierto a todo Internet y la consultora con acceso permanente. En Seguridad en Redes (05-04) dibujamos la red de Nimbus tal como está, la rediseñamos por zonas, cerramos esos tres agujeros con grupos de seguridad y bastión, montamos el acceso remoto con WireGuard, arreglamos la wifi de invitados y el DNS, y —lo más importante— comprobamos con pruebas de conectividad que la segmentación funciona de verdad, porque un diseño no probado es solo un dibujo bonito.