When using the ssrfFilter library in conjunction with the Request library in JavaScript there is a bug that can result in the SSRF filter being disabled. The way the anti-SSRF library, ssrfFilter works is that is creates its own object that cna be used in=place of Node’s default request agent for http/http requests. As the agent it can apply SSRF filtering at a relatively low level making it harder to bypass, but it depends on being able to control the agent the higher-level library (in this case the Request library) is using. When there is a cross-protocol redirect like from http to https, the Request library will delete the existing agent (and later replacing it with the default one). This needs to happen because the default agent can only work for one protocol. However this also means that if someone sets the antiSSRF library’s agent to be used, simply by redirecting across protocols the filtering can be disabled.

The authors also looked at a couple other libraries, finding that node-fetch was not vulnerable as it didn’t support cross-protocol redirects, and axios configuration take sin separate http and https agents, though notably an application can forget to set one of the agents and have a similar bypass.

A few vulnerabilities in Azure Web Services via Kudu Git repo manager used for git deployments. Kudu exports a source control management (SCM) portal that can be accessed if you’re authenticated into the instance through Azure Active Directory (AAD), which allows you to manage your web app. The first vuln is the fact that all cookies (including the session cookie) have the same-site attribute set to ‘None’, allowing cross-origin attacks.

The second and more serious vuln was the origin header check was able to be subverted via passing an ._. as a subdomain. Typically it would only accept requests with a validated origin of https://<my-webapp>.scm.azurewebsites.net. But by passing a ._. after the domain (https://<my-webapp>.scm.azurewebsites.net._.<attacker-site>./), you could set up a wildcard DNS on an attacker site and get your attacker site passed as a valid origin. They did have to find an endpoint that was vulnerable though to be abused in a CSRF context, and for RCE the main one of interest was the api/zipdeploy endpoint for uploading and deploying code via a zip file.

Another issue is the fact that while api/zipdeploy expects an x-webform-urlencoded;charset UTF-8 request, it also accepts text/plaintext requests, which doesn’t require preflights. Exploiting these issues will allow an attacker to leverage a victim to upload a web-shell and obtain RCE.

Three vulns in Apollo Configuration Management System (two of which were recognized as CVEs). The first vuln (which isn’t acknowledged by the vendor) is a Spring Expression Language (SpEL) issue where various settings are merged with spring framework properties, allowing SpEL injection for RCE. It wasn’t acknowledged as an issue since you need admin-level access, but it does escalate from admin access to code execution.

The second vuln was an auth bypass in the service registry (“Eureka”), which is used for registering the config, admin, and other services. Since the config and admin service are obviously sensitive, they have token-based authentication. The problem is, eurka runs on the same instance as the config and admin services with no auth checks. If you have access to it, you can leak the token by sending a service registration request to eureka and ask it to create a new instance of the admin app. Then, whenever a request is made from the app to the admin service, it’ll send the token in the request to the instance URL specified in the attacker XML config.

The last bug is a CSRF issue due to a lack of CSRF protection in the AuthConfiguration class. In most cases, this isn’t an issue, since most methods that mutate data expect json-encoded data protected by Cross-Origin Resource Sharing (CORS). However, a few methods (such as PermissionController::addManageAppMasterRoleToUser()) just use path variables. This specific method can be CSRF’d to grant roles to an attacker’s account. This will only work on firefox, safari, and other browsers that don’t set the SameSite=Lax.

Solid post document some of the practical aspects of pulling off this attack, but the root issue was a change in Android’s parcel API, without going into details about parcels you can think about this as similar to just opening a file. You usually need to provide a mode, like w for write, or r for read access. By default on POSIX systems using mode w will also truncate the file. So If you open a file with 100 bytes with mode w and then write 10 bytes, with truncation by default, it’ll truncate the file to be 10 bytes long since that is all that was written. Without truncation you’d just be replacing the first 10 bytes with the new content, leaving the remaining 90 bytes unchanged.

The API change (Android 10 and later)) in parcels was that now w did not truncate by default, instead you’d need to pass in a mode of wt to truncate. The default markup and cropping software on Pixel devices did not account for this change (it was an undocumented change). So, files cropped using the default application if they were smaller than the original would have trailing information containing part of the original, unedited image.

The post here goes into actually recovering the corrupted original/source image if that aspect is of interest to you check it out.