#oauth

When a data source has the Forward OAuth Identity feature enabled, sending a query to that datasource with an API token (and no other user credentials) will forward the OAuth Identity of the most recently logged-in user. This can allow API token holders to retrieve data for which they may not have intended access. ### Impact All of the following must be true: * The Grafana instance has data sources that support the Forward OAuth Identity feature. Graphite users, for example. * Some data sources are not susceptible, like Prometheus, as they do not have support for this feature. * The option being available is not sufficient enough to determine if the data source is susceptible. * The Grafana instance has a data source with the Forward OAuth Identity feature toggled on. * The Grafana instance has OAuth enabled. * The Grafana instance has usable API keys. ### Patches The following Grafana versions have been patched: * `v8.3.4` * `v7.5.13` ### Workarounds Administrators of G...

In Eclipse Dataspace Components from version 0.2.1 to 0.6.2, in the [EDC Connector component](https://github.com/eclipse-edc/Connector), an attacker might obtain OAuth2 client secrets from the vault. In Eclipse Dataspace Components from version 0.2.1 to 0.6.2, we have identified a security vulnerability in the EDC Connector component ( https://github.com/eclipse-edc/Connector ) regarding the OAuth2-protected data sink feature. When using a custom, OAuth2-protected data sink, the OAuth2-specific data address properties are resolved by the provider data plane. Problematically, the consumer-provided clientSecretKey, which indicates the OAuth2 client secret to retrieve from a secrets vault, is resolved in the context of the provider's vault, not the consumer. This secret's value is then sent to the tokenUrl, also consumer-controlled, as part of an OAuth2 client credentials grant. The returned access token is then sent as a bearer token to the data sink URL. This feature is now disabled e...

After a breach in the Dropbox Sign environment, customer information may have been stolen and API users have restricted functionality

Threat actor dropped in to Dropbox Sign production environment and accessed emails, passwords, and other PII, along with APIs, OAuth, and MFA info.

Blockchain analysis firm Elliptic, MIT, and IBM have released a new AI model—and the 200-million-transaction dataset it's trained on—that aims to spot the “shape” of bitcoin money laundering.

China's brain-computer interface technology is catching up to the US. But it envisions a very different use case: cognitive enhancement.

Prioritizing security and user experience will help you build a robust and reliable authentication system for your business.

### Summary The vulnerability impacts only users of the `IdTokenVerifier` class. The verify method in `IdTokenVerifier` does not validate the signature before verifying the claims (e.g., iss, aud, etc.). Signature verification makes sure that the token's payload comes from valid provider, not from someone else. An attacker can provide a compromised token with modified payload like email or phone number. The token will pass the validation by the library. Once verified, modified payload can be used by the application. If the application sends verified `IdToken` to other service as is like for auth - the risk is low, because the backend of the service is expected to check the signature and fail the request. Reporter: [Tamjid al Rahat](https://github.com/tamjidrahat), contributor ### Patches The issue was fixed in the 1.33.3 version of the library ### Proof of Concept To reproduce, one needs to call the verify function with an IdToken instance that contains a malformed signature to ...

### Impact Under certain circumstances an action could set [reserved claims](https://zitadel.com/docs/apis/openidoauth/claims#reserved-claims) managed by ZITADEL. For example it would be possible to set the claim `urn:zitadel:iam:user:resourceowner:name` ```json {"urn:zitadel:iam:user:resourceowner:name": "ACME"} ``` if it was not set by ZITADEL itself. To compensate for this we introduced a protection that does prevent actions from changing claims that start with `urn:zitadel:iam` ### Patches 2.x versions are fixed on >= [2.48.3](https://github.com/zitadel/zitadel/releases/tag/v2.48.3) 2.47.x versions are fixed on >= [2.47.8](https://github.com/zitadel/zitadel/releases/tag/v2.47.8) 2.46.x versions are fixed on >= [2.46.5](https://github.com/zitadel/zitadel/releases/tag/v2.46.5) 2.45.x versions are fixed on >= [2.45.5](https://github.com/zitadel/zitadel/releases/tag/v2.45.5) 2.44.x versions are fixed on >= [2.44.7](https://github.com/zitadel/zitadel/releases/tag/v2.44.7) 2.43.x ve...

This Metasploit module exploits two vulnerabilities in Sharepoint 2019 - an authentication bypass as noted in CVE-2023-29357 which was patched in June of 2023 and CVE-2023-24955 which was a remote command execution vulnerability patched in May of 2023. The authentication bypass allows attackers to impersonate the Sharepoint Admin user. This vulnerability stems from the signature validation check used to verify JSON Web Tokens (JWTs) used for OAuth authentication. If the signing algorithm of the user-provided JWT is set to none, SharePoint skips the signature validation step due to a logic flaw in the ReadTokenCore() method. After impersonating the administrator user, the attacker has access to the Sharepoint API and is able to exploit CVE-2023-24955. This authenticated remote command execution vulnerability leverages the impersonated privileged account to replace the /BusinessDataMetadataCatalog/BDCMetadata.bdcm file in the webroot directory with a payload. The payload is then compiled...