Getty Images 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 un parche está 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 publicó un parche el 10 de octubre. Repito: esto no es un simulacro. Los ataques se han intensificado 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. Anuncio 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 de los puntos finales /oauth/idp/.well-known/openid-configuration y /oauth/rp/.well-known/openid-configuration 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. iVar3 original = snprintf(print_temp_rule,0x20000, «{\»emisor\»: \»https://%.*s\», \»authorization_endpoint\»: \»https://%.*s/oauth/ idp /login\», \»token_endpoint\»: \»https://%.*s/oauth/idp/token\», \»jwks_uri\»: \»https://%.*s/oauth/idp /certs\», \»tipos_de_respuesta_compatibles\»: [\»code\», \»toke n\», \»id_token\»]\»id_token_signing_alg_values_supported\»: [\»RS256\»]\»end _session_endpoint\»: \»https://%.*s/oauth/idp/logout\», \»frontchannel_logout_sup ported\»: verdadero, \»scopes_supported\»: [\»openid\», \»ctxs_cc\»]\»edición de Claims_support\»: [\»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); uVar7 parcheado = snprintf( print_temp_rule,0x20000, «{\»emisor\»: \»https://%.*s\», \»authorization_endpoint\»: \»https://%.*s/oauth/ idp/login\», \»token_endpoint\»: \»https://%.*s/oauth/idp/token\», \»jwks_uri\»: \»https://%.*s/oauth/idp/certs\», \»tipos_de_respuesta_compatibles\»: [\»code\», \»toke n\», \»id_token\»]\»id_token_signing_alg_values_supported\»: [\»RS256\»]\»end _session_endpoint\»: \»https://%.*s/oauth/idp/logout\», \»frontchannel_logout_sup ported\»: verdadero, \»scopes_supported\»: [\»openid\», \»ctxs_cc\»]\»edición de Claims_support\»: [\»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, se envía la respuesta inmediatamente. En la versión parcheada, la respuesta solo se envía si snprintf devuelve un valor inferior a 0x20000. La vulnerabilidad se produce porque el valor de retorno de snprintf se utiliza para determinar cuántos bytes se envían al cliente mediante ns_vpn_send_response. Esto es un problema porque snprintf no devuelve cuántos bytes escribió en el búfer, snprintf devuelve cuántos bytes habría escrito en el búfer si el búfer fuera lo suficientemente grande. Para explotar esto, todo lo que teníamos que hacer era descubrir cómo obtener la respuesta. para exceder 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 búfer print_temp_rule. ‍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, proviene del encabezado HTTP Host. También tuvimos la suerte de que NetScaler inserta 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 encabezado del host o toda la solicitud eran demasiado largos. Armamos la siguiente solicitud y la enviamos a nuestra instancia de NetScaler. OBTENER /oauth/idp/.well-known/openid-configuration HTTP/1.1 Host: a Conexión: cerrar Recibimos la respuesta que se muestra a continuación con los caracteres no imprimibles eliminados. HTTP/1.1 200 OK Opciones de tipo de contenido X: nosniff Protección X-XSS: 1; modo = bloque Longitud del contenido: 147441 Control de caché: sin caché, sin almacenamiento, debe revalidar Pragma: sin caché Tipo de contenido: aplicación/json; charset=utf-8 Aplicación X-Citrix: Receiver para Web {«emisor»: «https://aaaaa…… aaaaaaaaaaaaaaaaí§¡ ð í§¡-ª¼tÙÌåDx013.1.48.47à d98cd79972b2637450836d4009793b100c3a01f2245525d5f4f58455e445a4a42HTTP/1.1 200 OK Longitud del contenido: @@@@@ Codificación: @@@ Control de caché: sin caché Pragma: tipo de contenido sin caché : texto/html Establecer cookies: NSC_AAAC=@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@@@@@@@@@@@@@@@@;Secure;HttpOnly;Path=/ {«categorías»:[],»recursos»:[],»subscriptionsEnabled»:false,»username»:null} ð å å PÏÏ H¡ éÒÏ eGÁ»RDEFAULT ò #pack200-gzip compressdeflategzip dentity þÿÿÿÿÿ ©VPN_GLOBALÿÿÿÿÿÿ è»AAA_PARAMí Pudimos ver claramente una gran cantidad de memoria filtrada inmediatamente después 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, otra vulnerabilidad de divulgación de información crítica 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, cifrado claves, 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í.

Source link