#oauth

This Metasploit module exploits an authenticated administrator-level vulnerability in Atlassian Confluence, tracked as CVE-2024-21683. The vulnerability exists due to the Rhino script engine parser evaluating tainted data from uploaded text files. This facilitates arbitrary code execution. This exploit will authenticate, validate user privileges, extract the underlying host OS information, then trigger remote code execution. All versions of Confluence prior to 7.17 are affected, as are many versions up to 8.9.0.

### Impact The Pomerium user info page (at `/.pomerium`) unintentionally included serialized OAuth2 access and ID tokens from the logged-in user's session. These tokens are not intended to be exposed to end users. This issue may be more severe in the presence of an XSS vulnerability in an upstream application proxied through Pomerium. If an attacker could insert a malicious script onto a web page proxied through Pomerium, that script could access these tokens by making a request to the `/.pomerium` endpoint. Upstream applications that authenticate only the ID token may be vulnerable to user impersonation using a token obtained in this manner. Note that an OAuth2 access token or ID token by itself is not sufficient to hijack a user's Pomerium session. Upstream applications should not be vulnerable to user impersonation via these tokens provided: - the application verifies the [Pomerium JWT](https://www.pomerium.com/docs/capabilities/getting-users-identity) for each request, - the co...

103 models of Toshiba Multi-Function Printers (MFP) are vulnerable to 40 different vulnerabilities including remote code execution, local privilege escalation, xml injection, and more.

The Microsoft Security Response Center (MSRC) has always been at the forefront of addressing cyber threats, privacy issues, and abuse arising from Microsoft Online Services. Building on our commitment, we have introduced several key updates to the Report Abuse Portal and API, which will significantly improve the way we handle and respond to abuse reports.

GitLab has released security updates to address 14 security flaws, including one critical vulnerability that could be exploited to run continuous integration and continuous deployment (CI/CD) pipelines as any user. The weaknesses, which affect GitLab Community Edition (CE) and Enterprise Edition (EE), have been addressed in versions 17.1.1, 17.0.3, and 16.11.5. The most severe of the

The modern kill chain is eluding enterprises because they aren’t protecting the infrastructure of modern business: SaaS.  SaaS continues to dominate software adoption, and it accounts for the greatest share of public cloud spending. But enterprises and SMBs alike haven’t revised their security programs or adopted security tooling built for SaaS.  Security teams keep jamming on-prem

Bitbucket Branch Source Plugin 886.v44cf5e4ecec5 and earlier prints the Bitbucket OAuth access token as part of the Bitbucket URL in the build log in some cases. Bitbucket Branch Source Plugin 887.va_d359b_3d2d8d does not include the Bitbucket OAuth access token as part of the Bitbucket URL in the build log.

**In order to be exploited you must have both OAuth2 and Password auth methods enabled.** A possible attack scenario could be: - a malicious actor register with the targeted user's email (it is unverified) - at some later point in time the targeted user stumble on your app and decides to sign-up with OAuth2 (_this step could be also initiated by the attacker by sending an invite email to the targeted user_) - on successful OAuth2 auth we search for an existing PocketBase user matching with the OAuth2 user's email and associate them - because we haven't changed the password of the existing PocketBase user during the linking, the malicious actor has access to the targeted user account and will be able to login with the initially created email/password To prevent this for happening we now reset the password for this specific case if the previously created user wasn't verified (an exception to this is if the linking is explicit/manual, aka. when you send `Authorization:TOKEN` with the OA...

### Impact A MFA bypass in the Firefly III OAuth flow may allow malicious users to bypass the MFA-check. This allows malicious users to use password spraying to gain access to your Firefly III data using passwords stolen from other sources. As OAuth applications are easily enumerable using an incrementing id, an attacker could try sign an OAuth application up to a users profile quite easily if they have created one. The attacker would also need to know the victims username and password. ### Patches Problem has been patched in Firefly III v6.1.17 and up. ### Workarounds - Use a unique password for your Firefly III instance, - Store your password securely, i.e. in a password manager or in your head. ### References - https://owasp.org/www-community/attacks/Password_Spraying_Attack - https://www.menlosecurity.com/what-is/highly-evasive-adaptive-threats-heat/mfa-bypass

### Summary By combining two vulnerabilities (an `Open Redirect` and `session token sent as URL query parameter`) in Strapi framework is its possible of an unauthenticated attacker to bypass authentication mechanisms and retrieve the 3rd party tokens. The attack requires user interaction (one click). ### Impact Unauthenticated attackers can leverage two vulnerabilities to obtain an 3rd party token and the bypass authentication of Strapi apps. ### Technical details #### Vulnerability 1: Open Redirect ##### Description Open redirection vulnerabilities arise when an application incorporates user-controllable data into the target of a redirection in an unsafe way. An attacker can construct a URL within the application that causes a redirection to an arbitrary external domain. In the specific context of Strapi, this vulnerability allows the SSO token to be stolen, allowing an attacker to authenticate himself within the application. ##### Remediation If possible, applications shoul...