#oauth

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...

Privacy and security are an Apple selling point. But the DOJ’s new antitrust lawsuit argues that Apple selectively embraces privacy and security features in ways that hurt competition—and users.

## Summary and impact [`GoogleOAuthenticator.hosted_domain`] is used to restrict what Google accounts can be authorized to access a JupyterHub. The restriction _is intended_ to ensure Google accounts are part of one or more Google organizations/workspaces verified to control specified domain(s). The vulnerability is that the actual restriction has been to Google accounts with emails ending with the domain. Such accounts could have been created by anyone which at one time was able to read an email associated with the domain. This was described by Dylan Ayrey (@dxa4481) in this [blog post] from 15th December 2023. ## Remediation Upgrade to `oauthenticator>=16.3.0` or restrict who can login another way, such as [`allowed_users`] or [`allowed_google_groups`]. [`GoogleOAuthenticator.hosted_domain`]: https://oauthenticator.readthedocs.io/en/latest/reference/api/gen/oauthenticator.google.html#oauthenticator.google.GoogleOAuthenticator.hosted_domain [`allowed_users`]: https://oauthenticat...