Etiqueta: Network Security

  • CISA advierte de que un fallo crítico de MikroTik RouterOS puede permitir ejecutar código como root sin autenticación

    CISA advierte de que un fallo crítico de MikroTik RouterOS puede permitir ejecutar código como root sin autenticación

    La Agencia de Ciberseguridad y Seguridad de las Infraestructuras de Estados Unidos ha divulgado una vulnerabilidad crítica en MikroTik RouterOS a la que se puede acceder antes de la autenticación. Identificado como CVE-2026-84411, el problema afecta a la gestión del cuerpo de las solicitudes HTTP en el servicio de administración web y tiene una puntuación CVSS v3 de 9.8.

    Una única solicitud manipulada puede alcanzar la ruta vulnerable

    CISA describe el fallo como un desbordamiento negativo de enteros que un atacante de red no autenticado puede activar con una solicitud manipulada. Una explotación exitosa podría producir la ejecución de código arbitrario con privilegios de root o una situación de denegación de servicio. La agencia afirmó que, cuando se emitió el aviso, no se había informado de ninguna explotación pública conocida dirigida específicamente contra esta vulnerabilidad. Esta distinción es importante porque la divulgación se refiere a una capacidad técnica grave, no a la confirmación de una campaña activa.

    Reducir la exposición del plano de administración

    Los administradores deben aplicar las actualizaciones compatibles de RouterOS identificadas por MikroTik y CISA, y mantener las interfaces de administración fuera del alcance de redes que no sean de confianza. CISA también recomienda colocar las redes de control y los dispositivos remotos detrás de cortafuegos, aislarlos de las redes empresariales y utilizar tecnología VPN actualizada para el acceso remoto. Los equipos deben revisar la exposición de la administración antes y después de aplicar los parches, en lugar de tratar la actualización de software como el único control. Las actualizaciones adicionales sobre seguridad de redes se organizan en el archivo de noticias tecnológicas de SectechMedia.

    Fuentes

  • WatchGuard corrige una vulnerabilidad crítica de inyección de código en Fireware OS

    WatchGuard corrige una vulnerabilidad crítica de inyección de código en Fireware OS

    WatchGuard ha publicado actualizaciones de Fireware OS que abordan quince vulnerabilidades, incluida una vulnerabilidad crítica de inyección de código en la gestión del cliente BOVPN sobre TLS. La vulnerabilidad, CVE-2026-86131, podría permitir que un atacante que controle el servidor VPN remoto ejecute comandos con privilegios root en un dispositivo Firebox que se conecte.

    La actualización cubre múltiples vías de ataque remoto

    WatchGuard corrigió el problema crítico en Fireware OS 2026.3.2, 2026.2.3, 12.12.3 y 12.5.21. El mismo conjunto de versiones aborda vulnerabilidades de gravedad alta relacionadas con ejecución de código, omisión de autorización, denegación de servicio, acceso SSLVPN no autorizado y lectura de archivos locales. Otras actualizaciones independientes para puntos de acceso también resuelven debilidades críticas de la API interna que podrían proporcionar una sesión no autenticada o permitir la ejecución de comandos.

    Los dispositivos deben actualizarse como infraestructura de seguridad controlada

    Los operadores deben identificar las versiones afectadas de Firebox y de los puntos de acceso, realizar copias de seguridad de la configuración, verificar las rutas de actualización compatibles y probar la VPN, el enrutamiento, la autenticación y el registro después del despliegue. Las interfaces de gestión deben permanecer restringidas mientras se preparan las actualizaciones. WatchGuard afirma no tener conocimiento de explotación en entornos reales, pero los dispositivos de seguridad expuestos a Internet siguen siendo objetivos atractivos y no deben esperar a que se confirmen ataques. La guía de SectechMedia sobre redundancia de red y conmutación por error explica cómo mantener el servicio mientras se actualiza la infraestructura crítica.

    Fuentes

  • Cisco advierte de una omisión de autenticación explotada activamente en SD-WAN Manager

    Cisco advierte de una omisión de autenticación explotada activamente en SD-WAN Manager

    Cisco ha publicado correcciones para una vulnerabilidad explotada activamente en Catalyst SD-WAN Manager. Identificada como CVE-2026-76504, la vulnerabilidad crítica puede permitir que un atacante remoto no autenticado eluda una comprobación de autenticación de la API e interactúe con el sistema de gestión como usuario administrador.

    Las solicitudes manipuladas pueden atravesar el límite de gestión

    Cisco afirma que el problema se debe a una gestión inadecuada de la codificación de URI en una solicitud HTTP. Un atacante capaz de acceder a la API de Manager puede enviar una solicitud manipulada que eluda la restricción prevista. El rol administrativo predeterminado puede realizar todas las operaciones, por lo que una explotación exitosa genera un riesgo de alto impacto para el plano de gestión. Cisco informó de que tenía conocimiento de una explotación activa, pero no reveló el número de organizaciones afectadas ni describió la actividad observada tras el compromiso.

    Actualizar y revisar los registros de acceso

    Hay versiones corregidas disponibles y Cisco afirma que no existe ninguna solución alternativa. Los operadores deben actualizar de acuerdo con la rama de versión afectada, restringir el acceso de gestión a hosts de confianza e inspeccionar las ubicaciones de registro identificadas en el aviso para detectar solicitudes de inicio de sesión codificadas inusuales. La aplicación del parche debe ir acompañada de una evaluación de compromiso, porque una actualización no demuestra por sí sola que no se haya producido un acceso no autorizado previo. La guía de SectechMedia sobre verificación de la segmentación de red explica cómo se puede comprobar y reducir la exposición del plano de gestión.

    Fuentes

  • Verificación de la segmentación de red en sistemas de seguridad física

    Verificación de la segmentación de red en sistemas de seguridad física

    Los diagramas de red suelen mostrar los sistemas de seguridad física en zonas cuidadosamente separadas, pero un diagrama no demuestra que los controles funcionen. La deriva de los cortafuegos, las reglas temporales de mantenimiento, los servidores conectados a dos redes y los conmutadores no gestionados pueden volver a conectar redes que debían permanecer aisladas. La verificación de la segmentación prueba las rutas desplegadas en lugar de confiar en el documento de diseño.

    Definir zonas y flujos permitidos

    Comience por zonas funcionales como dispositivos de campo, controladores, grabación, gestión, clientes de operador, servicios de integración y soporte remoto. Para cada par de zonas, documente el origen, destino, protocolo y propósito empresarial exactos permitidos. Todo lo demás debe denegarse de forma predeterminada cuando la arquitectura lo permita.

    Incluya dependencias que es fácil pasar por alto: DNS, NTP, inscripción de certificados, servicios de directorio, repositorios de software, retransmisores de correo electrónico y supervisión. Una lista de permitidos incompleta puede empujar a los equipos a implantar reglas de emergencia amplias que después se vuelven permanentes.

    Verificar desde puntos finales representativos

    Las pruebas deben originarse en clases reales de dispositivos o equivalentes seguros. Un análisis desde la red de TI no puede demostrar a qué puede acceder una cámara o un controlador integrado. Confirme las conexiones previstas y después intente recorrer rutas prohibidas de forma controlada. Revise tanto el resultado del cliente como el registro del cortafuegos o conmutador para poder distinguir entre descartes silenciosos y fallos de enrutamiento.

    Las directrices de NIST sobre seguridad de tecnología operativa recomiendan la segmentación y las rutas de comunicación controladas como medidas centrales de reducción de riesgos. Las redes de seguridad física comparten muchas de las mismas limitaciones: dispositivos de larga vida útil, protocolos de proveedores, requisitos de disponibilidad y protección limitada de los puntos finales.

    Probar por separado el acceso de gestión y de proveedores

    Las rutas administrativas merecen una validación más estricta que el tráfico ordinario de eventos. Confirme que la gestión de dispositivos esté limitada a servidores de salto aprobados, usuarios identificados y sesiones supervisadas. Compruebe si el acceso VPN de proveedores solo puede llegar a los sistemas contratados y si se desactiva fuera de las ventanas aprobadas.

    Compruebe si existen rutas alternativas a través de Wi-Fi, módems celulares, interfaces de red secundarias y portátiles de servicio. Un controlador aislado en la interfaz principal podría seguir exponiendo un servicio de gestión a través de un canal pasado por alto. El artículo de SectechMedia sobre refuerzo de la ciberseguridad del control de acceso aborda controles relacionados con dispositivos y credenciales.

    Incluir estados de fallo y recuperación

    La segmentación puede cambiar durante una conmutación por error. Pruebe cortafuegos redundantes, enlaces de respaldo, sitios de recuperación ante desastres y el enrutamiento temporal utilizado durante el mantenimiento. Confirme que un dispositivo de seguridad averiado no establezca de forma predeterminada una ruta sin restricciones y que las configuraciones restauradas conserven la política aprobada.

    Registre capturas de paquetes o pruebas de los registros para las pruebas críticas. Una simple hoja de trabajo de aprobado o suspenso es insuficiente cuando una regla cambia posteriormente o un equipo de incidentes necesita conocer la accesibilidad histórica.

    Gestionar las excepciones como riesgos con vencimiento

    Cada excepción debe identificar el responsable, el motivo, los controles compensatorios y la fecha de vencimiento. Vuelva a realizar pruebas después de actualizaciones de firmware, migraciones de VMS, sustituciones de controladores y rediseños de red. Haga seguimiento de rutas accesibles inesperadas, reglas obsoletas y activos fuera de su zona asignada. El resultado debe ser un programa de verificación vivo que detecte la deriva arquitectónica antes de que un atacante o una interrupción la ponga de manifiesto.

    Fuentes de referencia