Este mes se publicó en línea un código de prueba de explotación para dos vulnerabilidades de Apache Solr, lo que indica que los ataques probablemente están en camino, ya que los piratas informáticos encontrarán formas de armar las dos vulnerabilidades dentro de sus botnets.
De los dos errores, uno recibió un parche durante el verano, mientras que el segundo aún no ha sido abordado por el equipo de Solr.
Es possible que ocurran ataques, ya que Apache Solr es una herramienta avanzada que a menudo se usa dentro de las redes empresariales para admitir potentes funciones de búsqueda de datos, lo que es un truco perfecto para los piratas informáticos que buscan formas dentro de redes de alto valor o en servidores con acceso a grandes recursos computacionales.
El primer mistake: CVE-2019-12409
El primer mistake es un problema que se informó y solucionó durante el verano. El error, rastreado como CVE-2019-12409, se refiere a una configuración predeterminada en el archivo de configuración solr.in.sh que se incluye con todas las nuevas instancias de Solr.
De acuerdo con el reporte, Las versiones de Solr 8.1.1 y 8.2. se enviaron con la opción Allow_Remote_JMX_OPTS establecida en habilitada, que, a su vez, expuso el puerto 18983 a conexiones remotas.
En el momento en que se informó, el equipo de Apache Solr no vio el problema como un gran problema, y los desarrolladores pensaron que un atacante solo podía acceder a los datos de monitoreo de Solr, y nada más.
Sin embargo, código de prueba de concepto se publicó la semana pasada mostrando cómo un atacante podría abusar de este error para cargar código malicioso a través del puerto expuesto y hacerse cargo de las instancias vulnerables de Solr.
La solución de este problema debería ser tan basic como cambiar el parámetro Empower_Remote_JMX_OPTS a «falso» en el archivo solr.in.sh, o actualizar Solr a la versión 8.3., lanzada el mes pasado.
El equipo de Solr dijo que solo las versiones de Solr que se ejecutan en Linux se vieron afectadas por este problema.
Segundo mistake: el día cero (aún no CVE)
Pero los errores más peligrosos de los dos es uno para el que aún no hay una solución oficial. Según un análisis realizado por el equipo de Tenable, este mistake afecta a todas las versiones de Apache Solr entre 7.7.2 y 8.3., la versión actual.
Este mistake puede explotarse colocando una solicitud HTTP mal formada a través del puerto 3839 del servidor Solr que usa un mistake en la API de configuración para alternar una opción en el archivo de configuración solrconfig.xml a verdadero.
Imagen: Tenable
Una vez que esta opción (params.useful resource.loader.enabled) se ha establecido en verdadero, un atacante puede cargar archivos de plantilla de Apache Velocity en el servidor Solr y ejecutar código malicioso para secuestrar el servidor.
Este segundo problema salió a la luz a fines de octubre cuando un usuario publicó código de prueba de concepto en GitHub mostrando cómo un atacante podría abusar del mistake.
Un segundo, código de prueba de concepto más refinado fue publicado en línea dos días después, haciendo que los ataques sean aún más fáciles de ejecutar.
No se detectaron ataques, pero se esperan
La buena noticia es que al momento de escribir esto, no se han detectado ataques en la naturaleza. Sin embargo, esto es solo cuestión de tiempo.
Las instancias de Apache Solr generalmente tienen acceso a grandes recursos computacionales y, históricamente, han sido muy buscadas por las bandas de malware.
Por ejemplo, CVE-2017-12629 y CVE-2019-0193 fueron atacados por piratas informáticos semanas después de que los detalles de vulnerabilidad y el código de explotación se hicieran públicos. En ambos casos, los atacantes utilizaron las dos vulnerabilidades para obtener acceso a los servidores Solr y plantar malware de minería de criptomonedas en servidores sin parches.
Como sabemos que estos dos nuevos errores de Solr pueden conducir a la ejecución remota de código y tenemos un código de explotación público fácilmente disponible, los expertos esperan que esta falla de seguridad esté bajo ataques activos en días o semanas.
Artículo actualizado el 26 de noviembre para agregar detalles sobre el segundo error de Solr. La mayor parte del artículo fue reescrito desde cero para dejar en claro que hay dos errores. El titular fue enarbolado en consecuencia.
