Base de CVEs

In Znuny through 7.3.6, an attacker can bypass specific standard login procedures and gain unauthorized access to sensitive system functions by manipulating a specific HTTP request header. Because the application incorrectly trusts this header, an attacker can impersonate any user, including administrators, without requiring a password. This grants full access to confidential data and system controls. More specifically, the HTTPBasicAuth modules for the agent (Kernel::System::Auth::HTTPBasicAuth) and customer (Kernel::System::CustomerAuth::HTTPBasicAuth) interfaces read the username to log in not only from $ENV{REMOTE_USER} (set by the web server after successful authentication), but also, as a fallback, from $ENV{HTTP_REMOTE_USER}, which is populated directly from an attacker-controllable "Remote-User" request header. On systems where HTTPBasicAuth was configured as the authentication backend, this allowed an attacker to log in as any existing user by sending a request with a forged Remote-User header, without providing any credentials.

Foi identificado um problema no Canonical ADSys nas versões upstream até a v0.16.2. Durante o auto-registro de certificados do Active Directory Certificate Services (AD CS) por meio do script cliente Samba vendorizado (internal/policies/certificate/python/vendor_samba/gp/gp_cert_auto_enroll_ext.py), o ADSys utiliza uma conexão HTTP sem criptografia (http://) em vez de uma conexão HTTPS segura (https://) para solicitar o certificado da CA ao servidor AD CS (GetCACert). Um atacante de rede não autenticado posicionado entre o host Ubuntu gerenciado e o nome de host da CA configurada no AD CS pode realizar um ataque de Man-in-the-Middle (MITM). Ao interceptar a requisição HTTP em texto claro, o atacante pode fornecer um certificado de Root CA arbitrário, controlado por ele. Como o sistema aceita automaticamente esse certificado e o registra no repositório de confiança local do sistema via update-ca-certificates, isso resulta em envenenamento do repositório de confiança de todo o sistema. Consequentemente, clientes TLS que utilizam o repositório de confiança do sistema operacional na máquina afetada aceitarão certificados falsos para domínios arbitrários, permitindo a descriptografia e interceptação persistentes de conexões TLS subsequentes. Este problema foi resolvido na versão v0.16.3.

ProxySQL é um proxy para MySQL e seus forks, bem como para PostgreSQL. Nas versões 2.0.0 até 3.0.8, o frontend MySQL do ProxySQL aceita o frame PP1 `PROXY UNKNOWN <addr> <addr> <port> <port>\r\n` como um cabeçalho de protocolo PROXY bem formado. A especificação do protocolo PROXY v1 do HAProxy afirma que, quando o token de protocolo é `UNKNOWN`, o receptor DEVE ignorar quaisquer campos de endereço que o seguem, porque o proxy declarou que não consegue determinar a identidade do cliente. O ProxySQL analisa esses campos de endereço mesmo assim, via `sscanf`, e grava o endereço de origem forjado no campo `addr.addr` da sessão. Dali ele flui diretamente para o avaliador de regras de consulta, onde o predicado `client_addr` decide roteamento e ACL. Quando `mysql-proxy_protocol_networks = '*'` (o padrão), qualquer peer TCP pode enviar um frame PP1 e escolher qualquer alegação de IP de origem. Com isso, qualquer linha de `mysql_query_rules` fixada a um valor de `client_addr` pode ser forjada: o atacante escreve o endereço que deseja casar na linha PP1, e o ProxySQL roteia sua consulta como se viesse desse endereço. Na prática, trata-se de bypass de roteamento e de ACL. Implantações reais usam `client_addr` para separação de leitura e escrita (aplicações internas vão ao primário, tráfego público para réplicas de leitura), fixação de schema por aplicação e regras de filtro de consultas (DDL permitido somente a partir de CIDR administrativo, consultas públicas com padrões perigosos bloqueadas). Um atacante que consiga alcançar a porta do frontend pode forjar seu caminho para qualquer uma dessas rotas. A versão 3.0.9 corrige este problema.