Como os três ocorrem na mesma versão do mesmo produto e na mesma classe de vulnerabilidade, foram agrupados em um único aviso e publicados sob um único ID de CVE. Em termos de impacto, o ponto nº 1 é o mais grave.

1. Página de Login — Parâmetro devam

Este é o mais crítico. O ponto de injeção está diretamente na própria tag HTML do formulário de autenticação.

O parâmetro devam carrega o endereço para o qual o usuário retornará após o login e chega codificado em hex — o valor 2f796f7264616d2f significa /yordam/. A aplicação decodifica esse valor de hex e o escreve na tag de abertura do formulário de login. Não há nenhuma operação de escape no meio:

Na saída, os caracteres <, > e aspas aparecem brutos. A única coisa que contém o payload é o fato de o atributo data-url estar entre aspas simples. Quando uma aspa simples é inserida na entrada, isso também termina: o atributo é fechado, a tag <form> é fechada e o HTML escrito pelo atacante substitui o formulário de autenticação da página.

O action do formulário é sequestrado. Aqui não é desenhado um formulário falso — o formulário da própria aplicação é deixado vazio e fechado, e imediatamente em seguida uma nova <form> com as mesmas classes CSS é aberta. Como os campos de nome de usuário, senha e código de verificação na página são todos do HTML original da aplicação, eles permanecem dentro desse novo formulário. O usuário vê o formulário real, preenche o formulário real; as informações inseridas vão para o servidor do atacante. Não há nenhuma diferença visualmente distinguível.

O ponto crítico: a injeção não ocorre em uma página aleatória, mas na página onde já se espera que o usuário digite sua senha. Em uma injeção refletida comum, o atacante precisa convencer a vítima; aqui, a própria interface da aplicação faz o trabalho de convencimento.

2. Atributo value de Campo de Formulário Oculto — Dupla Decodificação de URL

Na página de busca, os valores dos parâmetros GET são escritos em campos de formulário ocultos. Neste ponto, o escape é aplicado — mas na ordem errada.

O mesmo valor q é usado em três contextos diferentes dentro de uma única resposta, e cada um tem uma profundidade de decodificação diferente:

A sequência de operações é a seguinte:

Enquanto o filtro de entrada e o escape operam na primeira camada de decodificação, a saída é alimentada pela segunda camada. A diferença fica clara ao comparar as versões codificadas uma e duas vezes do mesmo payload:

A vulnerabilidade não é específica do parâmetro q. O bloco que gera campos ocultos itera sobre todos os parâmetros GET da requisição; também foi validado em tip e alan.

3. Atributo name de Campo de Formulário Oculto — Injeção no Nome do Parâmetro

O mesmo bloco gera a seguinte estrutura para cada parâmetro GET:

O escape é aplicado apenas ao lado do value. Não é aplicado ao lado do name. Neste ponto, também não há necessidade de codificação dupla — uma única codificação é suficiente, pois não há escape a ser contornado.

Um nome de parâmetro inventado é escrito diretamente e bruto no atributo name, e é possível sair do atributo. Como o nome do parâmetro está sob controle do atacante, não precisa ser um parâmetro reconhecido pela aplicação.

Os pontos nº 2 e nº 3 destes três pontos originam-se do mesmo bloco de código, e esse bloco se repete em seis formulários diferentes: dilForm, adetForm, siralaForm, tkForm, ekForm, tmForm. Ou seja, em uma única requisição, a injeção ocorre seis vezes.

A natureza dinâmica do bloco foi confirmada comparando a saída de duas requisições:

Os campos gerados não vêm de uma lista fixa, mas são derivados diretamente dos parâmetros da requisição. Portanto, tanto o conteúdo escrito no atributo name quanto no value está sob controle do atacante.

Impacto

A única coisa que o atacante precisa é de um link que a vítima abra. Não precisa estar autenticado nem ter uma conta.

• Roubo de credenciais. Pelo ponto nº 1, o alvo action do formulário de login é redirecionado para o atacante. Confirmado.
• Conteúdo falso com a identidade da instituição. Na barra de endereço permanecem o domínio próprio da instituição e um certificado TLS válido. É possível inserir avisos falsos, campanhas falsas e textos informativos falsos.
• Adulteração de conteúdo e redirecionamento. A aparência da página pode ser alterada e o usuário pode ser levado a um endereço externo.

Como a plataforma afetada armazena credenciais e dados pessoais de usuários da biblioteca, é possível acessar os registros de membros por meio de contas comprometidas.

Por Que as Proteções Existentes Não Impedem

A aplicação usa CSP, e script-src e object-src são baseados em nonce; ou seja, o XSS clássico baseado em script não funciona nessas páginas. À primeira vista, isso parece reduzir o achado ao nível de "apenas adulteração de conteúdo".

A política completa é a seguinte:

Não há form-action. Também não há default-src — portanto, não há um padrão para o qual recorrer para diretivas não definidas. Resultado: o navegador não bloqueia de forma alguma o formulário de fazer POST para o servidor do atacante.

Para roubar credenciais, não é necessário executar JavaScript. HTML simples é suficiente, e o CSP não bloqueia HTML simples.

Fraquezas Relacionadas

Primária

• CWE-79 — Neutralização Incorreta de Entrada Durante a Geração de Páginas Web ('Cross-site Scripting')

Relacionadas

• CWE-116 — Codificação ou Escape Incorreto de Saída
• CWE-174 — Decodificação Dupla dos Mesmos Dados
• CWE-172 — Erro de Codificação
• CWE-451 — Apresentação Incorreta de Informações Críticas na Interface do Usuário (IU)

No registro do CVE, a fraqueza primária é classificada como CWE-79. No nível da causa raiz, a CWE-116 é mais explicativa: a causa dos três pontos é o escape de saída não aplicado ou aplicado na ordem errada.

Deve-se observar que não há execução de script neste produto — a política script-src baseada em nonce enviada pelo próprio produto não permite isso, e o valor do nonce não pode ser lido entre origens. O impacto real não é a execução de script, mas a injeção de HTML e o sequestro do formulário de login. O mapeamento CAPEC-148 (Content Spoofing) foi feito por esse motivo.

A CWE-174 aplica-se especialmente ao ponto nº 2 — a decodificação dos mesmos dados uma segunda vez após o escape.

Gravidade

Médio — Pontuação Base CVSS 3.1 6.1 (AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N)

O atacante não precisa de nenhuma permissão; como a vítima precisa abrir o link preparado, a interação do usuário é Necessária. O Scope foi definido como Changed porque o conteúdo injetado é processado no contexto de segurança do navegador.

Os três pontos correspondem à mesma pontuação. Em termos de impacto, o ponto nº 1 é o mais grave: como a injeção ocorre diretamente na própria tag do formulário de autenticação, é possível o sequestro do alvo action do formulário e o roubo de credenciais.

Versões Afetadas

A validação foi realizada na v22.1. As vulnerabilidades não decorrem de erro de configuração específico da instituição, mas de componentes comuns da interface do produto; afetam todas as instalações da mesma família de versões. A situação das versões mais antigas precisa ser avaliada pelo fabricante.

Como as instalações são on-premise, mesmo que o fabricante tenha publicado a correção, as instalações que não aplicarem a atualização continuarão afetadas.

Componente Afetado

Os pontos nº 2 e nº 3 originam-se do mesmo bloco gerador de campos ocultos; o bloco se repete nos formulários dilForm, adetForm, siralaForm, tkForm, ekForm e tmForm.

Solução

As vulnerabilidades foram corrigidas pelo fabricante. A aplicação deve ser atualizada para a versão v22.2 ou superior.

Registro do CVE

Fabricante: Yordam Bilgi Teknolojileri Danışmanlık Eğitim ve Elektronik Sistemler Sanayi ve Ticaret A.Ş.

Descobridor

Alkım Coşkun – Netlore Security

Cronograma de Divulgação