Podcast Segurança Legal, episodio #421 — Alerta da Defesa Civil. Este artículo se deriva del episodio #421 del podcast Segurança Legal, presentado por Guilherme Goulart y Vinícius Serafim, y fue producido con apoyo de IA. Mira el episodio completo en YouTube.
Entre el 19 y el 20 de junio de 2026, alguien con credenciales legítimas de agentes de la Defensa Civil disparó cerca de diez alertas falsas por el Sistema Nacional de Defensa Civil de Brasil, que usa la infraestructura de cell broadcast para alcanzar todos los teléfonos móviles de una región. Aproximadamente 30 millones de personas recibieron avisos de nivel extremo en la madrugada del sábado. La falla central no fue sofisticada: un sistema de alto impacto estaba protegido solo por usuario y contraseña, sin segundo factor y sin control de acceso adecuado.
El caso interesa menos por el autor y más por lo que expone sobre la seguridad de los sistemas públicos críticos. Vamos a separar lo que es ruido de lo que es lección técnica.
Qué ocurrió, en términos técnicos
El cell broadcast es un canal diseñado para emergencias: inundaciones, deslizamientos, tornados, situaciones en las que el mensaje necesita sobreponerse a cualquier otra cosa en el aparato, incluso en modo silencioso. Es la misma tecnología que, en Europa, avisa a poblaciones enteras antes de una catástrofe climática. Por naturaleza, una alerta de ese tipo presume que lo que se está comunicando es lo bastante serio como para justificar la interrupción.
En el incidente, ese canal fue usado para disparar alertas falsas, algunas acompañadas de avisos de deslizamiento y tornado, otras con contenido de broma. El sistema fue retirado del aire alrededor de la 1 de la madrugada. Durante el ataque, el equipo bloqueó credenciales y se usaron nuevas credenciales para reanudar los disparos, lo que apunta al compromiso de más de un acceso. La Policía Federal investiga la autoría, sin descartar la participación de usuarios autorizados.
La falla no fue sofisticada: faltó lo básico de control de acceso
Por las informaciones públicas, dos problemas se destacan, ambos en el terreno más básico de la seguridad de aplicaciones, lo que OWASP trata como control de acceso.
El primero es la ausencia de segundo factor de autenticación. Si el compromiso de una única credencial fue suficiente para disparar mensajes a 30 millones de personas, entonces no había una capa adicional entre la contraseña y el disparo. Para un sistema con ese alcance, usuario y contraseña son insuficientes, por mejor que sea la contraseña. Un código de una aplicación autenticadora, o incluso un factor más débil enviado por otro canal, ya habría elevado bastante el costo del ataque.
El segundo es la falta de segregación por alcance. Un reportaje técnico sobre el caso indica que una misma cuenta no debería poder enviar alertas a más de una región. Si esa regla existía pero se incumplió, es probable que no estuviera codificada en el sistema, dependiendo de una configuración manual. Cuando una regla de integridad es crítica, el propio sistema debe impedir su violación, no confiar en quien hace la atribución de accesos. Hay relatos de que existía un captcha, pero del tipo que pide el resultado de una operación matemática, trivial de sortear e irrelevante frente a la falla de autenticación.
La causa raíz: modelado de amenazas que no se hizo
Fallas así rara vez son un olvido puntual. Indican que la etapa anterior al desarrollo no ocurrió: el modelado de amenazas. Modelar amenazas es, antes de escribir código, mapear lo que puede salir mal en un sistema, cuáles son los actores capaces de atacarlo, cuál es el impacto de cada escenario y, a partir de eso, especificar qué mecanismos de seguridad son obligatorios. Solo después vienen la implementación y la prueba efectiva de esos mecanismos.
Un sistema que alcanza a 30 millones de personas, por un canal cuya entrega el destinatario no puede rechazar, y cuyo propósito es comunicar un riesgo de vida, tiene un perfil de impacto altísimo. Un modelado de amenazas mínimamente hecho habría colocado la autenticación fuerte y la segregación de privilegios como requisitos no negociables. La ausencia de esos controles sugiere que el modelado se hizo mal o simplemente no existió. Sin él, la implementación queda suelta, guiada por la intuición de quien está codificando en ese momento.
El problema es estructural, no aislado
Este no es un punto fuera de la curva. El Tribunal de Cuentas de la Unión (TCU) de Brasil viene señalando desde hace años baja madurez de seguridad en los órganos públicos. En una fiscalización sobre servicios de alojamiento web, correo electrónico y DNS, el TCU concluyó que la mayoría de los índices de prácticas de seguridad presenta un nivel de madurez bajo o intermedio, dejando a la mayoría de las organizaciones y a sus clientes expuestos a ataques. Las causas identificadas fueron directas: falta de recursos o inversión, de personal y de capacitación, además de baja efectividad en la implementación de las normas.
El volumen de incidentes acompaña ese diagnóstico. Considerando los órganos del Ejecutivo federal, el TCU registró un aumento de 3.402 incidentes de seguridad de la información en 2022 a 5.302 en 2024. Es el mismo patrón que encontramos en campo. Cuando hacemos un pentest, es común que el equipo del cliente crea que el sistema está seguro, y no por incompetencia: el entendimiento de quien desarrolla está orientado a la funcionalidad y a la entrega, no a las formas en que aquello puede romperse. Esa es justamente la brecha que una mirada externa y especializada cubre.
La investigación de seguridad no es lo mismo que la intrusión
Vale la pena separar dos cosas que la cobertura del caso suele mezclar. Encontrar una falla y explotarla para causar impacto, disparando alertas falsas, es un delito, y el autor responde por ello. Eso es diferente de la investigación de seguridad hecha de buena fe, en la que se identifica una vulnerabilidad, se notifica al responsable por los canales oficiales, no se explota la falla para causar daño y, agotado un plazo razonable sin corrección, se comunica el problema con la debida prueba de que hubo un intento de aviso. La primera conducta destruye la confianza en un sistema que puede salvar vidas. La segunda ayuda a corregirlo antes de que alguien malintencionado llegue allí.
Preguntas frecuentes
¿Qué causó el ataque al sistema de alertas de la Defensa Civil?
Por las informaciones públicas, el compromiso de credenciales legítimas de agentes, combinado con la ausencia de segundo factor de autenticación y de segregación de privilegios por región. Una única credencial comprometida fue suficiente para disparar alertas a escala nacional, lo que indica fallas básicas de control de acceso.
¿Qué es el modelado de amenazas y por qué importa aquí?
El modelado de amenazas es el análisis, hecho antes del desarrollo, de lo que puede salir mal en un sistema, de quién puede atacarlo y del impacto de cada escenario, para entonces definir los controles de seguridad obligatorios. En el caso de la Defensa Civil, un modelado adecuado habría convertido la autenticación fuerte y la segregación de acceso en requisitos innegociables, dado el alcance del sistema.
¿Un segundo factor de autenticación habría evitado el ataque?
No hay garantía absoluta, pero habría elevado mucho el costo del ataque. Si el compromiso de una sola contraseña permitió disparar mensajes a millones de personas, una capa adicional de verificación habría roto la cadena más probable del ataque. Para sistemas de alto impacto, la autenticación de factor único es inadecuada.
¿Es un problema solo del sector público?
La baja madurez es más visible en los sistemas públicos por las restricciones de recursos y personal, señaladas en auditorías del TCU. Pero el patrón de subestimar el riesgo por falta de una visión de seguridad aparece también en el sector privado, siempre que la prioridad es la entrega de la funcionalidad y la seguridad queda para después.
Evalúa la exposición de tus sistemas críticos
Si tu organización opera sistemas de alto impacto y aún no ha pasado por un modelado de amenazas o por una prueba independiente de seguridad, podemos conversar sobre el alcance. Hacemos modelado de amenazas y pentest para identificar, antes de un incidente, qué necesita estar protegido y cómo.
Vinícius Serafim es socio y consultor de BrownPipe Consultoria, especialista en pentest y seguridad de aplicaciones. BrownPipe actúa desde 2012 en seguridad de la información y protección de datos. Este contenido fue producido con apoyo de IA y se deriva del episodio #421 – Alerta da Defesa Civil del podcast Segurança Legal, presentado por Guilherme Goulart y Vinícius Serafim. Mira el episodio completo en YouTube: youtu.be/MxZVb6xFl6c.