#auth

### Impact A flaw discovered in Rancher versions from 2.5.0 up to and including 2.5.9 allows an authenticated user to impersonate any user on a cluster through the Steve API proxy, without requiring knowledge of the impersonated user's credentials. This is due to the Steve API proxy not dropping the impersonation header before sending the request to the Kubernetes API. A malicious user with authenticated access to Rancher could use this to impersonate another user with administrator access in Rancher, receiving, then, administrator level access in the cluster. ### Patches Patched versions include releases 2.5.10, 2.6.0 and later versions. ### Workarounds Limit access in Rancher to trusted users. There is not a direct mitigation besides upgrading to the patched Rancher versions. ### For more information If you have any questions or comments about this advisory: * Reach out to [SUSE Rancher Security team](https://github.com/rancher/rancher/security/policy) for security related inquir...

### Impact This vulnerability only affects customers using group based authentication in Rancher versions up to and including 2.4.17, 2.5.11 and 2.6.2. When removing a Project Role associated to a group from a project, the bindings that grant access to cluster scoped resources for those subjects do not get deleted. This happens due to an incomplete authorization logic check. A user who is a member of an affected group with authenticated access to Rancher could use this to access resources they should no longer have access to. The exposure level will depend on the original permission level granted to the affected project role. ### Patches Patched versions include releases 2.4.18, 2.5.12, 2.6.3 and later versions. ### Workarounds Limit access in Rancher to trusted users. There is not a direct mitigation besides upgrading to the patched Rancher versions. ### References Cluster and project roles documentation for Rancher [2.6](https://rancher.com/docs/rancher/v2.6/en/admin-settings/rba...

Gitea 0.9.99 through 1.12.x before 1.12.6 does not prevent a git protocol path that specifies a TCP port number and also contains newlines (with URL encoding) in ParseRemoteAddr in modules/auth/repo_form.go.

Unlike the SolarWinds and CodeCov incidents, all that it took for an adversary to nearly pull off a massive supply chain attack was some slick social engineering and a string of pressure emails.

The city is stymied in efforts to pinpoint the issue since its IT systems were shut down in the wake of the cyberattack.

### Impact Due to default case-insensitive collation in MySQL or MariaDB databases, third-party authentication user IDs are not case-sensitive and could cause different IDs to match. ### Patches This issue has been addressed by https://github.com/python-social-auth/social-app-django/pull/566 and fix released in 5.4.1. ### Workarounds An immediate workaround would be to change collation of the affected field: ```mysql ALTER TABLE `social_auth_association` MODIFY `uid` varchar(255) COLLATE `utf8_bin`; ``` ### References This issue was discovered by folks at https://opencraft.com/.

### SpEL Injection in `GET /api/v1/policies/validation/condition/<expr>` (`GHSL-2023-236`) ***Please note, only authenticated users have access to PUT / POST APIS for /api/v1/policies. Non authenticated users will not be able to access these APIs to exploit the vulnerability. A user must exist in OpenMetadata and have authenticated themselves to exploit this vulnerability.*** The [`‎CompiledRule::validateExpression`](https://github.com/open-metadata/OpenMetadata/blob/main/openmetadata-service/src/main/java/org/openmetadata/service/security/policyevaluator/CompiledRule.java#L51) method evaluates an SpEL expression using an [`StandardEvaluationContext`](https://github.com/open-metadata/OpenMetadata/blob/main/openmetadata-service/src/main/java/org/openmetadata/service/security/policyevaluator/CompiledRule.java#L57), allowing the expression to reach and interact with Java classes such as `java.lang.Runtime`, leading to Remote Code Execution. The `/api/v1/policies/validation/condition/<ex...

### SpEL Injection in `PUT /api/v1/events/subscriptions` (`GHSL-2023-251`) ***Please note, only authenticated users have access to PUT / POST APIS for /api/v1/policies. Non authenticated users will not be able to access these APIs to exploit the vulnerability. A user must exist in OpenMetadata and have authenticated themselves to exploit this vulnerability.*** Similarly to the GHSL-2023-250 issue, `AlertUtil::validateExpression` is also called from [`EventSubscriptionRepository.prepare()`](https://github.com/open-metadata/OpenMetadata/blob/b6b337e09a05101506a5faba4b45d370cc3c9fc8/openmetadata-service/src/main/java/org/openmetadata/service/jdbi3/EventSubscriptionRepository.java#L69-L83), which can lead to Remote Code Execution. ```java @Override public void prepare(EventSubscription entity, boolean update) { validateFilterRules(entity); } private void validateFilterRules(EventSubscription entity) { // Resolve JSON blobs into Rule object and perform schema based valid...

Lazarus, Kimsuky, and Andariel all got in on the action, stealing "important" data from firms responsible for defending their southern neighbors (from them).

ArcaneDoor is a campaign that is the latest example of state-sponsored actors targeting perimeter network devices from multiple vendors. Coveted by these actors, perimeter network devices are the perfect intrusion point for espionage-focused campaigns.