Artsploit

**Nome do software vulnerável e versões afetadas** Versões do pac4j anteriores à 4.0.0 **Descrição** A vulnerabilidade é um problema de desserialização em Java que afeta sistemas que armazenam valores controlados externamente nos atributos da classe `UserProfile` do pac4j-core. Ela pode ser explorada fornecendo um atributo que contenha um objeto Java serializado com um prefixo especial `{#sb64}` e codificação Base64, o que pode levar à execução remota de código (RCE). Embora um `RestrictedObjectInputStream` esteja em vigor, ele ainda permite uma ampla gama de pacotes Java e é potencialmente explorável com diferentes cadeias de gadgets. **Recomendações** Para resolver o problema, atualize para a versão 4.0.0 ou posterior do pac4j. Como solução temporária, considere restringir o uso da classe `UserProfile` do pac4j-core para minimizar o risco de exploração. Evite usar a versão do `pac4j-core` anterior à 4.0.0 até que um patch esteja disponível.

**Nome do software vulnerável e versões afetadas** Versões 3.5.10 a 3.5.11 do Reposilite **Descrição** O problema está relacionado a uma vulnerabilidade de leitura arbitrária de arquivos por meio de traversal de caminho durante o serviço de arquivos javadoc expandidos. Isso ocorre porque a rota `GET /javadoc/{repository}/<gav>/raw/<resource>` usa o parâmetro de caminho `<resource>` para localizar o arquivo no diretório `javadocUnpackPath` e retorna seu conteúdo ao usuário. O parâmetro de caminho `<resource>` pode conter caracteres de traversal de caminho, permitindo que um invasor leia arquivos fora do diretório `javadocUnpackPath`. Isso pode levar à exposição de informações confidenciais, incluindo senhas e hashes de tokens emitidos armazenados no arquivo `reposilite.db` ou outras propriedades confidenciais no arquivo `configuration.cdn`. **Recomendações** Para as versões 3.5.10 a 3.5.11, atualize para a versão 3.5.12 para resolver o problema. Como solução alternativa temporária, considere normalizar o parâmetro de caminho `<resource>` removendo todas as ocorrências de `/../` antes de usá-lo para ler o arquivo. Isso pode ser feito alterando `resource.toString()` para `resource.toPath()` no arquivo `JavadocFacade.kt`.

**Nome do software vulnerável e versões afetadas** Versões do Reposilite anteriores à 3.5.12 **Descrição** O problema reside no fato de que o conteúdo do artefato é servido pela mesma origem que a interface de usuário administrativa (Admin UI). Se o artefato contiver conteúdo HTML com JavaScript, o JavaScript será executado dentro da mesma origem. Isso permite o acesso ao armazenamento local do navegador, onde a senha do usuário está armazenada. O ataque pode ser realizado a partir do navegador do administrador, mesmo que a instância do Reposilite esteja localizada em um ambiente isolado. Esse problema pode levar ao comprometimento total da instância do Reposilite e, na pior das hipóteses, um invasor seria capaz de obter execução remota de código em todos os sistemas que utilizam artefatos do Reposilite. **Recomendações** Para versões anteriores à 3.5.12, considere as seguintes opções para corrigir essa vulnerabilidade: * Use o cabeçalho “Content-Security-Policy: sandbox;” ao servir o conteúdo do artefato para restringir a execução de JavaScript. * Use o cabeçalho “Content-Disposition: attachment” para impedir que o navegador exiba o conteúdo por completo. Além disso, reconsidere como a autenticação do site funciona para o Reposilite e considere emitir um ID de sessão único ou um token para o navegador após verificar o login/senha no servidor. Esses IDs de sessão ou tokens devem ter tempo de validade limitado. Atualize para a versão 3.5.12 para resolver este problema.

Nome do software vulnerável e versões afetadas: Versões do Reposilite anteriores à 3.5.12 Descrição: A vulnerabilidade está relacionada à expansão de arquivos Javadoc no Reposilite, onde o `file.name` extraído do arquivo pode conter caracteres de traversal de caminho, permitindo que um invasor sobrescreva qualquer arquivo local na instância do Reposilite. Isso pode levar à execução remota de código, por exemplo, colocando um novo plugin no diretório ‘$workspace$/plugins’. Alternativamente, um invasor pode sobrescrever o conteúdo de qualquer outro pacote. O invasor pode usar seu próprio pacote malicioso do Maven Central para sobrescrever qualquer outro pacote no Reposilite. Recomendações: Para versões anteriores à 3.5.12, atualize para a versão 3.5.12 ou posterior para resolver o problema. Como solução alternativa temporária, considere normalizar a variável `file.name` antes de concatená-la com `javadocUnpackPath` para evitar ataques de traversal de caminho. Por exemplo, use `val path = Paths.get(javadocUnpackPath.toString() + “/” + Paths.get(file.name).normalize().toString())` no arquivo `JavadocContainerService.kt`.

**Name of the Vulnerable Software and Affected Versions** Kafka UI versions prior to 0.7.2 **Description** The issue is related to the deserialization mechanism in the Kafka UI web interface for Apache Kafka management. It allows a remote attacker to execute arbitrary code by exploiting the vulnerability in the JMX protocol, which is based on the RMI protocol and is susceptible to deserialization attacks. This can be done by connecting the Kafka UI backend to a malicious broker or by having access to the Kafka cluster connected to Kafka UI. The vulnerability can lead to post-authentication remote code execution, which is particularly dangerous since Kafka UI does not have authentication enabled by default. **Recommendations** For versions prior to 0.7.2, upgrade to version 0.7.2 or later to address the issue. As a temporary workaround, consider disabling the dynamic.config.enabled property in settings to minimize the risk of exploitation. Restrict access to the Kafka cluster connected to Kafka UI to prevent attackers from expanding their access and executing code on Kafka UI. Avoid using the JMX ports feature until the issue is resolved. At the moment, there are no known workarounds for this vulnerability other than upgrading to a fixed version.

**Name of the Vulnerable Software and Affected Versions** Apereo CAS versions prior to 6.6.6 **Description** The issue concerns Apereo CAS, an open source single sign-on solution. It can be configured to use authentication based on client X509 certificates, which can be provided via TLS handshake or a special HTTP header, such as "ssl client cert". When checking the validity of the provided client certificate, the system fetches URLs from the "CRL Distribution Points" extension of the certificate. If the CAS server is configured to use an LDAP server for x509 authentication with a password, it can lead to a password leak when making requests to LDAP URLs from the certificate, as it uses the same password as for the initially configured LDAP server. This allows an unauthenticated user to leak the password used for the LDAP connection configured on the server. **Recommendations** For versions prior to 6.6.6, upgrade to version 6.6.6 to address the issue. As a temporary workaround, consider restricting access to the LDAP server or changing the password used for the LDAP connection to minimize the risk of exploitation. Avoid using the same password for multiple LDAP connections until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** DataHub versions prior to 0.8.45 **Description** The issue concerns authentication checks using the `AuthUtils.hasValidSessionCookie()` method, which could be bypassed by using a cookie from a logged out session. This is because session cookies are only cleared on new sign-in events and not on logout events. As a result, any logged out session cookie may be accepted as valid, leading to an authentication bypass to the system. **Recommendations** For versions prior to 0.8.45, upgrade to version 0.8.45 or later to resolve the issue. As a temporary workaround, consider disabling the use of session cookies or restricting access to sensitive areas of the system until the upgrade can be applied.

**Name of the Vulnerable Software and Affected Versions** DataHub (affected versions not specified) **Description** The DataHub frontend proxy does not properly construct URLs when forwarding data to the DataHub Metadata Store (GMS), allowing external users to reroute requests to arbitrary hosts. This enables attackers to redirect requests from the frontend proxy to other servers and return the results. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** DataHub (affected versions not specified) **Description** The DataHub frontend, when configured to authenticate via SSO, processes the `id token` in an unsafe manner. This issue arises because the pac4j library deserializes values starting with the `{#sb64}` prefix as serialized Java objects. Although a `RestrictedObjectInputStream` is in place, it still allows deserialization of a broad range of Java packages, potentially leading to Remote Code Execution (RCE) with different gadget chains. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** DataHub (affected versions not specified) **Description** The issue concerns the Metadata service (GMS) in DataHub, where the X-DataHub-Actor HTTP header is used to infer the user on whose behalf the frontend is sending a request. The header's name is retrieved in a case-insensitive manner, which can be exploited by an attacker to smuggle an X-DataHub-Actor header with different casing. This can lead to an authorization bypass, allowing any user to impersonate the system user account and perform actions on its behalf. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** DataHub (affected versions not specified) **Description** The issue concerns the AuthServiceClient in DataHub, which is responsible for managing accounts and authentication. It crafts JSON strings using format strings with user-controlled data, potentially allowing an attacker to manipulate these strings and send them to the backend. This could lead to an authentication bypass, creation of system accounts, and potentially full system compromise. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Nome do software vulnerável e versões afetadas** Versões do DataHub anteriores à 0.8.45 **Descrição** O `StatelessTokenService` do serviço de metadados do DataHub não verifica a assinatura dos tokens JWT, permitindo que um invasor se conecte a instâncias do DataHub como qualquer usuário, caso a autenticação do serviço de metadados esteja habilitada. Isso ocorre porque o `StatelessTokenService` utiliza o método `parse` do `io.jsonwebtoken.JwtParser`, que não realiza uma verificação da assinatura criptográfica do token, aceitando JWTs independentemente do algoritmo utilizado. Esse problema pode levar a uma burla na autenticação. **Recomendações** Para versões anteriores à 0.8.45, atualize para a versão 0.8.45 para resolver o problema. Como solução alternativa temporária, considere desativar a função `StatelessTokenService` até que um patch esteja disponível. Restrinja o acesso ao serviço de metadados para minimizar o risco de exploração. Evite usar tokens JWT nas instâncias do DataHub afetadas até que o problema seja resolvido.

**Nome do software vulnerável e versões afetadas** MITREid Connect versões 1.3.3 e anteriores **Descrição** A implementação do servidor OpenID Connect contém uma vulnerabilidade de falsificação de solicitação do lado do servidor (SSRF) devido ao uso inseguro do parâmetro `logo uri` na solicitação de Registro Dinâmico de Cliente. Um invasor não autenticado pode fazer uma solicitação HTTP a partir do servidor vulnerável para qualquer endereço na rede interna e obter sua resposta, o que pode levar à violação dos limites da rede, à obtenção de dados confidenciais ou ao ataque a outros hosts na rede interna. **Recomendações** Para as versões 1.3.3 e anteriores, como solução temporária, considere restringir o uso do parâmetro `logo uri` na solicitação de Registro Dinâmico de Cliente para minimizar o risco de exploração. No momento, não há informações sobre uma versão mais recente que contenha uma correção para essa vulnerabilidade.