Show Notes

89 - SharePoint RCE & an Apache Path Traversal

Bit of a saga starting with a patch to Apache httpd earlier this year that introduced an old vulnerability back into the Apache when encountering

Apache not properly handling URL encoded values allowing an encoding like .%2e/ to be decoded as ../ but not be detected as a directory traversal during earlier processing. The patch for this added a check for .%2e (the particular case required the first . not be encoded) but later use of the path do more decoding so by double encoding the second . traversal was enabled again.

Only the phone number parameter was being validated. So an attacker could maliciously modify the country code. That may not sound too damaging but the SMS provider supported having multiple phone numbers separated by a ,. So by sending a country_isd as the attackers number and a , the validated phone number will be appended and the OTP will be sent to both locations.

Had a JWT, and noticed functionality to invite a user to a group and then change their privileges, these privileges were reflected in the JWT scopes. Though modification of this edit user request additional scopes that were not displayed could be added, such as the company:operations and company:support scopes. Which then generated a JWT able to access an internal employee only API. The same vulnerability also existed in assigning scopes to your own API keys.

SharePoint Workflows are essentially a series of tasks to streamline a business process. With the clear potential for abuse there exist an authorizedTypes list that will both allow and block classes. One of the classes blocked is the WorkflowCompiler which as the name implies is the class used to compile a workflow. If a workflow could invoke the compiler it would be possible to modify the restrictions the compiler enforced and compile and run an otherwise blocked workflow.

So, its not, at least as far as this exploit goes possible to use teh WorkflowCompiler with default configuration, however much of the compiler’s implementation resides in the WorkflowCompilerInternal class which is not blocked.