CVE-2021-34371

Neo4j con el shell server habilitado expone un servicio RMI que deserializa cualquier objeto Java que se le entregue, por ejemplo a través de setSessionVariable. Esa es la trampa clásica de deserialización insegura: como existen cadenas de gadgets explotables en las dependencias, un atacante que pueda alcanzar el puerto RMI envía una carga útil serializada manipulada y obtiene ejecución remota de código en el host de la base de datos. No autenticado, remoto, sin interacción: la deserialización es todo el exploit.

Los fallos de deserialización de Java son una clase de ataque madura y con buenas herramientas; existen cargas útiles de cadenas de gadgets listas para usar y se reutilizan, así que la weaponización es rápida una vez que se encuentra un listener alcanzable. La precondición crítica, y es real, es que el shell server tiene que estar habilitado y su puerto RMI accesible. Eso reduce considerablemente la exposición —muchos despliegues no lo ejecutan—, pero cualquier instancia que sí lo haga, con el puerto en una red accesible, es un objetivo directo de RCE para cualquiera que rastree servicios RMI expuestos.

Para nosotros, esto es una búsqueda de accesibilidad y configuración más que un barrido de versiones. Identificaríamos las instancias de Neo4j en 3.4.18 o inferior, y luego verificaríamos las dos cosas que realmente lo condicionan: ¿está habilitado el shell server y ese puerto RMI está expuesto más allá de localhost o un segmento confiable? Un listener expuesto es una emergencia; un shell server deshabilitado o un puerto protegido por firewall hace caer la misma versión muy abajo en la lista. Bloquear el puerto RMI es un parche virtual inmediato donde la actualización se retrasa.