Ir al contenido
Todos los artículos

· por NetProtector Security Team

VPN de Check Point: inicio de sesión sin contraseña a través del obsoleto IKEv1

Ilustración: una vieja llave IKEv1 abre el moderno candado de la VPN, sin necesidad de contraseña

Los protocolos antiguos suelen seguir activos por un único motivo: algún cliente más antiguo todavía los necesita. En Check Point, precisamente eso se está convirtiendo ahora en una puerta de entrada. A través de la vulnerabilidad CVE-2026-50751, los atacantes establecen una conexión de Remote Access VPN sin conocer una contraseña válida, siempre que el gateway siga permitiendo el obsoleto procedimiento de intercambio de claves IKEv1. Check Point publicó la vulnerabilidad el 8 de junio de 2026 y observa ataques desde el 7 de mayo. En al menos un caso, detrás se encontraba un afiliado del grupo de ransomware Qilin. La agencia estadounidense CISA incluyó la vulnerabilidad ese mismo día en su catálogo de vulnerabilidades explotadas activamente.

De qué se trata

El fallo reside en la verificación de certificados durante el intercambio de claves IKEv1 para Remote Access VPN y Mobile Access. Un error lógico hace que el gateway permita una conexión VPN sin que el usuario se haya autenticado con una contraseña válida. Según Check Point, a continuación el atacante necesita dar más pasos para acceder a recursos internos o escalar sus privilegios, pero la conexión VPN en sí ya está establecida.

Datos clave según el aviso de Check Point sk185033:

  • Gravedad: CVSS 9.3 (crítica).
  • Afectados: Security Gateways con R81.20, R82 y R82.10, así como las versiones sin soporte R80.40, R81 y R81.10; además, los firewalls Spark con R80.20.X, R81.10.X y R82.00.X. Un gateway solo es vulnerable si se cumplen todas estas condiciones: Remote Access VPN o Mobile Access está activo, IKEv1 está permitido para Remote Access, el gateway acepta clientes de Remote Access antiguos y no exige un certificado de máquina.
  • Corregido en: hotfixes que Check Point pone a disposición para las versiones con soporte. Qué paquete corresponde a cada versión se indica en sk185033.
  • Requisito para el ataque: un gateway accesible desde Internet con la configuración descrita. El atacante no necesita credenciales.
  • Consecuencia: una sesión VPN sin contraseña válida, es decir, un acceso a la red en el que no intervienen ni la contraseña ni otros factores de autenticación.

Durante la investigación, Check Point encontró una segunda vulnerabilidad en el mismo procedimiento: CVE-2026-50752 (CVSS 7.4) permite, en determinadas circunstancias, ataques man-in-the-middle contra conexiones VPN site-to-site. Hasta ahora no se ha observado su explotación.

Por qué es urgente

Según Check Point, los ataques comenzaron a más tardar el 7 de mayo de 2026 y se intensificaron a principios de junio. Según el fabricante, están afectadas «algunas decenas» de organizaciones de todo el mundo seleccionadas de forma específica. Check Point atribuye con un nivel de confianza medio los ataques a un actor con motivación financiera que utiliza el ransomware Qilin. Tras obtener el acceso VPN, los atacantes intentaron descargar malware para Linux desde sus propios servidores.

La infraestructura resulta reveladora: los ataques procedían de servidores virtuales alquilados a proveedores de hosting, en parte en el mismo país que la víctima. Según la evaluación de Check Point, esa misma infraestructura también aprovecha vulnerabilidades publicadas en productos VPN de otros fabricantes. Por tanto, no se ataca un producto concreto, sino el acceso VPN como tal, independientemente de quién lo suministre.

Para los clientes de Check Point, el patrón no es nuevo. Ya en mayo de 2024, CVE-2024-24919 (CVSS 8.6) afectó a gateways con Remote Access VPN o Mobile Access: los atacantes podían leer archivos del gateway, entre ellos hashes de contraseñas de cuentas locales. La empresa de seguridad mnemonic detectó entonces ataques a partir del 30 de abril de 2024. También en ese caso, las cuentas antiguas que solo se autentican con contraseña corrían un riesgo especial. La lección de ambos casos: lo que sigue activo solo por motivos de compatibilidad acaba convirtiéndose tarde o temprano en objetivo de ataque.

Qué debe hacer ahora

  1. Instale el hotfix. Instale cuanto antes el hotfix correspondiente de sk185033. Los gateways con versiones sin soporte deberían migrarse a una versión con soporte.
  2. Desactive los procedimientos antiguos si no es posible aplicar el hotfix de inmediato: deje de admitir clientes antiguos, limite Remote Access VPN a IKEv2 en la configuración global y haga obligatorios los certificados de máquina. Compruebe antes qué clientes y casos de uso dependen todavía de IKEv1.
  3. Active IPS y cargue las firmas más recientes. Esto ayuda en la detección, pero no sustituye al hotfix.
  4. Revise los logs desde el 7 de mayo. Compare las conexiones con las direcciones IP de la lista de indicadores de Check Point, que se ha ampliado varias veces tras su publicación. Preste atención a sesiones VPN con usuarios desconocidos o IP de origen inusuales.
  5. En caso de sospecha, parta de que se ha producido un compromiso: finalice las sesiones, restablezca las credenciales y compruebe si desde el gateway se han descargado archivos o se ha accedido a sistemas internos. Check Point ofrece asistencia para ello a través de su soporte.

Qué significa esto para la protección de firewalls

CVE-2026-50751 muestra una faceta incómoda de la seguridad de redes: el propio firewall, con su acceso VPN, es un servicio accesible públicamente. Una vulnerabilidad en él anula todo lo que se ha construido detrás en forma de reglas y procedimientos de autenticación. En este caso, entre el primer ataque y el hotfix transcurrió aproximadamente un mes.

NetProtector complementa el firewall en este punto con una capa de protección propia. El appliance se instala en línea delante del firewall y evalúa el tráfico antes de que llegue al gateway VPN:

  • Las fuentes de ataque conocidas se quedan fuera. Ataques como este se realizan a través de servidores que los mismos actores utilizan una y otra vez contra distintos objetivos. Las direcciones que ya se han identificado como atacantes en la red de sensores de NetProtector se bloquean antes de que lleguen a su gateway.
  • Lo sospechoso se hace visible. NetProtector detecta como anomalías los escaneos en busca de servicios VPN, los intentos de conexión acumulados o los patrones de acceso atípicos. Las alertas pueden enviarse a sistemas existentes, como un SIEM o un sistema de tickets, para que su equipo de seguridad las vea allí donde ya trabaja.
  • Una capa adicional, no un sustituto. NetProtector no sustituye ni al hotfix ni al cambio de configuración, y no revierte una sesión de atacante ya establecida. Pero reduce los ataques que llegan siquiera al gateway hasta que se aplica el parche.
Respuesta automatizada
Playbooks opcionales ante amenazas detectadas
ContenerBloquear conexiones sospechosas, aislar los sistemas afectados.
Preservar pruebasRecopilar registros y capturas de red para el análisis.
CorregirBloquear servidores C2, poner el malware en cuarentena.
RecuperarApoyar la vuelta a un funcionamiento seguro.
Integraciones
Encaja en su entorno de seguridad actual
SIEMAlertas vía syslog, CEF o STIX/TAXII
SOARAPI REST y webhooks para playbooks
EDR / XDRContexto para la protección de endpoints
Sistemas firewallAjustar reglas en tiempo real
TicketingIncidentes convertidos en tickets
Dashboard e informesSituación en tiempo real e informes de dirección

Qué respuestas puede automatizar NetProtector y cómo se integra en las herramientas de seguridad existentes se explica en la página Cómo funciona NetProtector.

Nuestra valoración

Este caso es menos una cuestión del fabricante que de la herencia técnica. IKEv1 se considera obsoleto desde hace años, pero sigue activo en muchas redes porque en algún lugar todavía depende de él un cliente antiguo. Cada una de estas excepciones es superficie de ataque. Por ello, quien quiera proteger sus accesos VPN debería comprobar periódicamente qué protocolos y métodos de autenticación se necesitan realmente, aplicar las actualizaciones con rapidez, supervisar los inicios de sesión y añadir delante del firewall una capa que impida que los atacantes conocidos lleguen siquiera al gateway.

Fuentes