Somewhat traditional CE.TE request smuggling attack on a few of Apple’s domains. The main trick with this one was to place a \n in the Transfer-Encoding header name. So the full header being Transfer-Encoding\n : chunked This allowed the TE header to be smuggled through any checks on the frontend and still be parsed by the backend server.

Server-Side Request Forgery with both server-side and client-sided impacts.

There was an API endpoint that would email a PDF to a user with a screenshot of a given location (intended to just be an endpoint on the particular application) but an @ could be used to break out and provide a custom domain and path for the request.

This allowed for the obvious server-side impact, reaching internal endpoints including a redash login page with the credentials auto-filled in visible plain text (including the password).

The client-side impact comes because the requests the server made to get a screenshot were authenticated as the current user. It would do this by adding a couple headers, one with the user’s API key and the other with their email that would authenticate the request as that user. So an attacker could leak a victims API key and email by tricking an victim into navigating to the vulnerable endpoint with a CSRF attack.

Slight race-condition in the Pritunl VPN client leading to a semi-controlled file-write as SYSTEM which could be leveraged into code execution as SYSTEM.

The normal flow for the application was that a user would import an OpenVPN configuration file that would be written into the a folder under the users %APPDATA% folder. Then when the VPN client was told to connect, it would sanitize the configuration, ensuring no sensitive directives were used. It would write this santiized configuration into its %PROGRAMDATA% directory and then provide it to the openvpn client.

The problem being that any user could write to the %PROGRAMDATA% folder and race the OpenVPN execution, trying to overwrite the sanitized version before OpenVPN gets it. Form this point, OpenVPN is executed with –security-script 1 so direct code execution wasn’t possible.

Instead the log directive could be abused to write a log file to any location as SYSTEM, and partial control of the logged content could be used. Where there are several avenues for escalation, Rhino Security Labs created an ipconfig.bat in the application’s Program Files directory as it would attempt to run the ipconfig command without using an absolute path, meaning the bat would get executed.

Cool little trick against the NodeBB oauth flow resulting in a CSRF that would associate an attackers third-party account with a victim NodeBB account.

If you’re not familiar with Oauth flows, the basic idea is that you login to a third party auth provider (like Google for example). Google does their thing, and then assuming all is okay, redirects you back to the original application (NodeBB) with a code in the URL. NodeBB can then go ahead and exchange that code for information about your Google account and associate it with your NodeBB account.

The problem is in that association process, NodeBB assumed anyone coming to the url with a code that worked on Google must want that account associated with the account they are currently logged in as. So an attacker could get this code legitimately for their own Google account, and then trick or coerce a victim user using CSRF into visiting the url with the attackers code. Allowing the attacker’s account to be associated with the victim’s NodeBB account.

Ideally the state parameter should have been used, which would provide a unique value in the redirect to the auth provider, that it would return back with the code. Preventing CSRF by requiring a unique value that the attacker wouldn’t know, and providing a mechanism to verify the code is being assoicated with the correct account.