Leon Zlobecki

A restrição inadequada de referências a Entidades Externas XML (XXE) no componente Saxon do Apache Camel ocorre porque o `XQueryBuilder` no `camel-saxon` utiliza uma Configuração Saxon padrão que aceita declarações DOCTYPE e resolve entidades externas. Embora os conversores de tipo XML do Camel protejam corpos do tipo String, byte[] ou InputStream, corpos que já são um `javax.xml.transform.Source` (como aqueles criados via `convertBodyTo(Source.class)`) são passados ao Saxon sem alterações. Isso permite que um remetente externo forneça um corpo XML manipulado que pode ser usado para ler arquivos locais acessíveis pelo processo Camel ou forçar o processo a fazer requisições a hosts externos.

O componente `camel-hazelcast` não aplica um `JavaSerializationFilterConfig` às instâncias do Hazelcast criadas através de caminhos de configuração específicos. Isso ocorre quando o `ReplicatedHazelcastAggregationRepository` sobrescreve a função `doStart()` sem chamar o método super, e quando o `HazelcastDefaultComponent#getOrCreateHzClientInstance()` constrói um `ClientConfig` enquanto o `hazelcastMode` está definido como `client` sem um `ClientConfig` referenciado ou `hazelcastConfigUri`. Consequentemente, a desserialização Java permanece irrestrita. Um invasor capaz de publicar dados no cluster Hazelcast conectado pode disparar a desserialização de um objeto Java manipulado na camada de serialização, resultando em execução remota de código. Este risco é ampliado pois os clusters Hazelcast não habilitam autenticação ou TLS por padrão.

Existe um problema onde o endpoint `dynamic-router-control` permite a compilação de expressões em um Predicate sem uma lista de permissões ou mecanismo de opt-in. Ao processar solicitações de inscrição ou atualização, o `DynamicRouterControlProducer` extrai o predicado de inscrição e o nome da linguagem dos campos `predicate` e `expressionLanguage` de um corpo `DynamicRouterControlMessage`, ou dos cabeçalhos `CamelDynamicRouterPredicate` e `CamelDynamicRouterExpressionLanguage`. O `DynamicRouterControlService` então resolve a linguagem a partir do `CamelContext` e compila a expressão. Se uma rota encaminha mensagens de um transporte externo para este endpoint de controle, um invasor pode fornecer uma expressão arbitrária que é avaliada com os privilégios do processo Camel. Isso inclui a linguagem simple, que está sempre presente. A exploração requer a capacidade de enviar uma mensagem em um transporte que encaminhe para um endpoint `dynamic-router-control`.

A API REST do Metasploit Framework Web Service (msf-ws) contém uma falha onde o `Msf::WebServices::CredentialServlet` não impõe a autenticação para rotas específicas. Especificamente, os manipuladores `update credential` (PUT) e `delete credentials` (DELETE) para o endpoint '/api/v1/credentials' omitem a chamada de autenticação necessária. Como o `lib/ms/core/db manager/cred.rb` subjacente não realiza suas próprias verificações de autorização, qualquer cliente com acesso de rede ao listener padrão 0.0.0.0:8080 pode ler, modificar ou excluir permanentemente todos os registros de credenciais armazenados, incluindo senhas, hashes e chaves privadas.

Uma falha no `SourceProvider` permite que um invasor não autenticado realize a leitura remota de arquivos. Ao enviar um corpo XML especialmente criado contendo uma declaração DOCTYPE que referencia entidades externas para um endpoint que aceita `application/xml` e retorna `Source` ou `StreamSource`, o servidor pode resolver a entidade e incluir conteúdos de arquivos sensíveis na resposta HTTP. Isso ocorre porque a função `writeTo()` cria um SAXParser sem desativar a resolução de entidades externas, resultando em uma vulnerabilidade de Entidade Externa XML (XXE)—um tipo de ataque que interfere no processamento de dados XML de um aplicativo.

Existe um problema no componente Spring Redis do Apache Camel onde dados não confiáveis são desserializados. O método `RedisConfiguration.getSerializer` cria um `JdkSerializationRedisSerializer` por padrão quando nenhum serializador é configurado. Esta implementação utiliza um `ConfigurableObjectInputStream` sem um `java.io.ObjectInputFilter`, permitindo que um grafo de classes serializado arbitrário seja materializado e seu método `readObject()` seja executado. A função `RedisConsumer.setBody` aplica este serializador aos bytes brutos de mensagens publicadas em canais inscritos, permitindo que um invasor atinja o sumidouro de desserialização via um comando PUBLISH. Além disso, o `RedisTemplate` criado por `RedisConfiguration.createDefaultTemplate` e o `SpringRedisIdempotentRepository` usam o mesmo serializador padrão, afetando comandos de leitura do produtor como GET, HGET, HGETALL e HVALS. Configurar um `redisTemplate` personalizado não mitiga o caminho do consumidor porque `RedisConsumer.setBody` acessa `getSerializer` diretamente.

Existe um problema de validação inadequada de entrada no componente DAPR do Apache Camel, especificamente no `DaprPubSubConsumer`. O componente copia o nome do componente Pub/Sub e o tópico de CloudEvents recebidos para os cabeçalhos de Exchange `CamelDaprPubSubName` e `CamelDaprTopic`. Como o `DaprConfigurationOptionsProxy` prioriza esses cabeçalhos em relação ao destino configurado durante a republicação, um invasor capaz de publicar mensagens em um tópico assinado pode manipular esses valores. Isso permite que o invasor redirecione ou exfiltre mensagens para um componente e tópico Dapr Pub/Sub arbitrários, ignorando o roteamento pretendido e os controles de acesso ao nível de tópico. A exploração requer a capacidade de publicar no tópico ao qual a rota está inscrita.