Two core issues here, first is an auth-bypass due to incorrect parsing, and the second is a pretty straight forward command inject in an authenticated feature. There is also a bit of a bonus issue in how they gained access to the source code.

First, the authentication bypass. The application has two layers, the back-end application itself which does no authentication in the code, and the front-end reverse proxy server that does the actual authentication checking before forwarding the request to the back-end. There were a couple endpoint that could be accessed without authentication, so the front-end server would take the requested path and see if it had a prefix matching one of these allow-listed paths. The problem is that it wouldn’t resolve any directory traversals before this check. So a path like /api/v1/allowed/endpoint/../disallowed/endpoint would be able to pass the prefix matching. However the back-end request would end up going to the /api/v1/disallowed/endpoint handler. Giving an attacker unauthenticated access to any endpoint. It is worth noting that for your own testing of this sort of issue you will need to issue teh request manually with something like burp repeater as your browser will resolve that directory traversal before making the request.

The command inject is fairly trivial the License key status check endpoint would take a value from the URL and use it in a command line to start a perl script. Allowing for trivial command injection.

The bonus issue is just a bit fun but because researchers were unable to get a copy of the VM for Pulse Connect Security and the software was behind a sales process they had to find another way to access to code. They targeted a cloud deployment, in order to get access to the filesystem they shutdown the VM, and editted the book arguments to change the init or first process run on startup to /bin/sh. However /bin/sh was blocked by the kernel, //bin/sh however was not blocked.