Qué Hacer si Encuentras una Vulnerabilidad: Guía Profesional

Cómo asistir al propietario de la solución y dónde se establecen los límites.

Imagina la siguiente situación: has encontrado una vulnerabilidad y comprendes que es reproducible. Saber qué hacer si encuentras una vulnerabilidad es clave para actuar de forma profesional y segura. El objetivo es ayudar al propietario del servicio a cerrar la brecha de forma rápida y segura. Sin embargo, antes de establecer contacto, es crucial detenerse y analizar tus propias acciones de manera ponderada. Para que te sea más fácil orientarte “en el momento”, nosotros hemos recopilado en este texto los consejos y recomendaciones clave, siguiendo los principios del hacking ético.

¿Qué hacer si encuentras una vulnerabilidad?

1. Realiza una prueba de concepto (PoC) mínima para confirmar el fallo sin causar daño al sistema.
2. Documenta tus hallazgos detalladamente: hora, solicitudes, versiones y capturas de pantalla.
3. Prepara un informe de vulnerabilidad claro y conciso con los pasos para reproducir el problema.
4. Contacta al propietario del servicio a través de canales oficiales como el archivo security.txt.
5. Acuerda un canal seguro para transferir los detalles completos y colabora en la corrección del fallo.

En primer lugar, la demostración debe ser mínima. Es decir, la menor prueba de hecho que confirme el problema, pero sin modificar datos reales ni incrementar el riesgo para el entorno de producción.

Es importante tener en cuenta el aspecto legal del asunto: ningún ultimátum del tipo “paga o lo publico”. La conversación sobre una recompensa solo es pertinente en el marco de la política de divulgación del propietario o de un programa de bug bounty. Si la PoC (Proof of Concept, prueba de concepto) puede dañar el sistema, detente, documenta el resultado y procede a notificar al propietario.

Anteriormente, explicamos cómo surgió la práctica del bug bounty. En ese artículo encontrarás la historia de su desarrollo y detalles sobre cómo funciona en la actualidad.

Protocolo de Actuación: Qué Hacer y Qué Evitar

QUÉ HACER (DO)

• Demuestra el hecho, no el efecto. Un código de estado HTTP, diferencias en las cabeceras o una respuesta controlada del servidor son suficientes si demuestran inequívocamente el problema.
• Utiliza una cuenta de prueba o un entorno reproducible, si es posible.
• Realiza una única solicitud o una cadena corta de acciones que sea repetible y no cause daño.
• Registra la hora con la zona horaria, las solicitudes exactas, las versiones del cliente y del servidor, capturas de pantalla y sumas de verificación (checksums) de los artefactos. Esto sustituye una PoC voluminosa.
• Si necesitas datos, crea registros sintéticos (ficticios), no trabajes con PII (Información de Identificación Personal) real o datos de pago.
• Antes de cualquier prueba “de riesgo”, advierte al equipo y coordina el canal y el horario, si está permitido.

QUÉ NO HACER (DON’T)

• No extraigas datos reales de usuarios, no descargues documentos ajenos ni revises transacciones de pago. Esto es fundamental cuando te preguntas qué hacer cuando encuentras un exploit.
• No ejecutes escaneos masivos o agresivos ni aumentes la carga (patrones de DoS).
• No intentes acceder a zonas privilegiadas para “probar tu punto”, ni siquiera por verificación.
• No dejes credenciales, tokens o claves en la PoC, en los borradores del informe, ni en registros, repositorios de Git, capturas de pantalla o portapapeles.
• Algunas alternativas seguras. Reproduce el error localmente en un mirror o contenedor, o solicita acceso de prueba al propietario. Si no es posible, describe el comportamiento en detalle y solicita la coordinación de un canal para una PoC completamente funcional.

Cómo Hacer un Informe de Vulnerabilidad Efectivo

El informe debe ser útil, no efectista; no es necesario destruir la infraestructura. Proporciona a los especialistas los “botones” que puedan presionar de inmediato. Aprender cómo hacer un informe de vulnerabilidad de calidad es tan importante como el hallazgo mismo.

• Descripción breve: qué está exactamente roto y a qué consecuencias conduce.
• Evaluación del impacto: con precisión, sin dramatizar; qué componentes están en riesgo, qué datos corren el riesgo de ser afectados.
• Descripción del entorno: dominio, rol de usuario, cabeceras HTTP importantes, versiones de software y parámetros de configuración relevantes.
• Pasos para la reproducción: pasos secuenciales y detallados (las utilidades estándar deberían ser suficientes), una PoC mínima: una única solicitud o una cadena corta de acciones que demuestre el problema de manera fiable y no rompa el sistema.
• Medidas de mitigación temporal: una lista de acciones rápidas que se pueden aplicar de inmediato (restringir tipos de solicitudes, desactivar la función problemática, filtrar en el perímetro, etc.).
• Recomendaciones para la corrección: dónde añadir una validación, qué permisos restringir, qué externalizar a la configuración. No es un manual, sino una dirección a seguir.
• Cronograma y datos de contacto: cuándo se detectó el problema y cuándo estás listo para compartir los detalles. Indica un contacto y un método de cifrado si es necesario.

Algunos consejos sobre el tono y la precisión:

• Evita palabras emocionales en la descripción del impacto; los hechos y la especificidad son más importantes.
• Minimiza la PoC; tu objetivo es demostrar la existencia de la vulnerabilidad, no explotarla.
• Verifica con antelación la legislación aplicable y la política de divulgación segura del propietario del servicio (si tienes dudas, indica que solo puedes proceder con la divulgación tras su aprobación).

Contacto Inicial: Cómo Reportar una Vulnerabilidad de Seguridad

Comienza por los canales oficiales. La empresa puede tener una dirección de correo electrónico del equipo de seguridad de la información, una página con su política de divulgación responsable o un archivo como /.well-known/security.txt, donde se indican los contactos y las claves. El estándar security.txt es una práctica recomendada para facilitar este contacto. Si no encuentras nada, escribe a la dirección general y solicita que reenvíen el mensaje al equipo de seguridad de la información.

El estilo del correo debe ser profesional, enfocado en ser útil. En el asunto, indica “Posible vulnerabilidad: “. En el cuerpo del mensaje, describe brevemente lo que has descubierto, el riesgo que identificas y sugiere un método conveniente y seguro para transferir los detalles. Este primer paso es crucial para un proceso exitoso de divulgación responsable.

Envía los detalles completos (informe completo y PoC) solo después de acordar el canal de transmisión. Si la empresa tiene una clave pública, cifra el archivo (PGP/S/MIME). Si disponen de un formulario seguro para incidentes, utilízalo.

Evita transferir datos sensibles a través de servicios de almacenamiento en la nube públicos o mensajeros; dichos canales no garantizan la confidencialidad y podrían comprometer la información sobre la vulnerabilidad.

Gestión del Proceso: Plazos, Comunicación y Escalado

Para alinear las expectativas, establece plazos orientativos: confirmación de recepción, evaluación inicial, plazos aproximados para la corrección. En la correspondencia, apégate a los hechos y a formulaciones breves: un correo, una pregunta y el siguiente paso esperado.

Algunas observaciones de la práctica:

La confirmación suele llegar en un par de días, la evaluación inicial en una semana. La corrección de errores críticos depende del ciclo de lanzamientos y puede llevar más tiempo.

• A veces es útil mantener una tabla con el estado de tus informes. Esto ayuda a seguir los plazos y a hacer recordatorios oportunos, especialmente si trabajas con varias empresas simultáneamente.
• Si el equipo muestra progreso, ajusta los plazos de manera conjunta. Si no hay reacción: un recordatorio → un canal alternativo (security.txt / formulario) → contactos de fuentes públicas → escalamiento a los CERT del sector o centros de respuesta. Si es la primera vez que oyes estos términos, lo explicamos más abajo.
• La divulgación pública antes de la corrección es una medida extrema y puede ser interpretada como la difusión no autorizada de información sobre medidas de protección, lo que conlleva responsabilidad penal. Publica solo con el consentimiento del propietario del sistema o del coordinador, sin detalles de explotación y priorizando la protección de los usuarios. La divulgación independiente de una vulnerabilidad, incluso con buenas intenciones, puede ser tipificada bajo artículos sobre delitos informáticos.

Si deseas profundizar en el tema de los plazos y los SLA, te recomendamos estudiar la norma ISO/IEC 29147 sobre la divulgación coordinada de vulnerabilidades, que detalla los cronogramas recomendados para diferentes tipos de vulnerabilidades.

Organismos de Coordinación: CERTs y Centros de Respuesta

• INCIBE-CERT (España): El Centro de Respuesta a Incidentes de Seguridad de referencia para ciudadanos y entidades de derecho privado en España, gestionado por el Instituto Nacional de Ciberseguridad.
  • Cuándo es adecuado: Incidentes que afecten a empresas, ciudadanos o infraestructuras en España, especialmente cuando el propietario no responde.
  • Cómo contactar: Disponen de formularios y correos de contacto en su sitio web oficial para el reporte de incidentes.
• CISA (EE. UU.): La Agencia de Ciberseguridad y Seguridad de Infraestructuras de Estados Unidos. Actúa como coordinador para vulnerabilidades en software y sistemas de control industrial a nivel global.
  • Cuándo es adecuado: Vulnerabilidades en productos de software de amplio uso o en infraestructuras críticas, especialmente si el proveedor es estadounidense o no responde.
  • Cómo contactar: CISA gestiona una plataforma de [ENLACE_EXTERNO url=”https://www.cisa.gov/report” anchor=”divulgación de vulnerabilidades (VDP)”] donde se pueden reportar los hallazgos de forma segura.
• FIRST (Forum of Incident Response and Security Teams): Una confederación global de equipos de respuesta a incidentes de ciberseguridad.
  • Cuándo es adecuado: Cuando necesitas encontrar el equipo de respuesta a incidentes (CSIRT) adecuado para un país o sector específico. Su directorio es una referencia mundial.
  • Cómo contactar: El sitio web de FIRST proporciona un directorio público de equipos miembros para facilitar el contacto con la entidad correcta.
• CERT/CC (Coordination Center): Creado por la DARPA, es el centro de coordinación de vulnerabilidades pionero.
  • Cuándo es adecuado: Para vulnerabilidades de alto impacto o que no tienen un punto de contacto claro. Actúan como un coordinador de confianza para asegurar que la información llegue a los proveedores afectados.
  • Cómo contactar: A través de su sitio web, donde ofrecen guías y un formulario para el envío de informes de vulnerabilidad.

Fase Final: Corrección, Publicación y Reconocimiento

Cuando la vulnerabilidad esté cerrada, solicita confirmación de que las correcciones han sido desplegadas en producción y aclara el criterio de “finalizado”. Acuerda la fecha y el formato de la publicación. La publicación debe centrarse en el proceso de investigación, la PoC mínima y las lecciones aprendidas, sin datos privados ni claves reales. Una historia técnica y objetiva se percibe mejor que un relato dramático.

Si la empresa tiene una página de agradecimientos, envía con antelación la ortografía correcta de tu alias y un enlace. Las cuestiones de recompensa se resuelven según las reglas del programa (si existe). Errores comunes: publicación prematura, disputas sobre la cantidad fuera de las reglas del programa y tokens dejados accidentalmente en el texto. Por lo tanto, realiza una revisión final muy atenta.

No te apresures a cerrar el canal de comunicación: después del despliegue de la corrección o durante una auditoría posterior, a menudo surgen preguntas aclaratorias, comentarios sobre la descripción o la necesidad de reescribir la nota y realizar un post-mortem. Deja en el informe un contacto y especifica durante qué período estás disponible para responder (por ejemplo, 7-14 días). Esto facilitará la resolución de cualquier asunto pendiente.

Casos Especiales: Open Source, Cloud y Sectores Regulados

Con proyectos de código abierto, es conveniente trabajar a través de tickets privados o contactando directamente a los mantenedores. Es útil preparar un pull request breve con la corrección y una prueba; incluso una versión preliminar acelerará la verificación.

Con las plataformas en la nube, los procesos suelen estar más formalizados: páginas de seguridad, formularios y SLA. En los sectores fintech y médico, propone desde el principio un canal cifrado y formulaciones precisas; en estos ámbitos, la rigurosidad y los marcos claros son especialmente valorados.

Actuación Responsable: Un Proceso Clave

La divulgación responsable funciona cuando el proceso se mantiene simple y respetuoso. Basta con una PoC mínima, pasos de reproducción claros y un tono profesional. Las prioridades son: primero, la seguridad de los usuarios; segundo, la rapidez de la corrección; y solo después, la publicación. Si mantienes esta secuencia y no complicas el proceso, la vulnerabilidad se cierra más rápido, el equipo receptor está más dispuesto a agradecer, y la nota final resulta útil tanto para ellos como para la comunidad.

La transparencia del proceso beneficia a todos: el propietario del servicio obtiene un escenario predecible para eliminar la amenaza sin pánico ni filtraciones, y el investigador minimiza los riesgos legales y fortalece su reputación profesional. Los acuerdos claros sobre plazos y canales de comunicación protegen a ambas partes de malentendidos y posibles conflictos, lo cual es la base de la confianza entre la comunidad de seguridad y el sector empresarial.