This starts off in a pretty straight-forward way with an arbitrary file upload vulnerability, but also includes a bit of discussion about exploiting it in a more hardened environment which had some interesting insight.

On the vulnerability-side, the handlers for multipart PUTs and POSTs had optional authentication. The default configuration was to set CONTENT_APIS_ALLOW_ANONYMOUS=WRITE which would allow an anonymous user to use these endpoints. In addition there was no sanitization of the provided filename, so while the final write location is prepended with the temporary directory, one could escape out and write a malicious JSP.

Unfortunately for the authors, but good on the bank there were some additional layers of defence at play, two in particular:

First was discovering where to upload a file to that would matter and be writable.The authors here used a fun little trick of writting through /proc/self/cwd to get the working directory of the execution agent. So ending up inside of the tomcat hierarchy, avoiding the need to guess where it was located. Their intent was to write to ROOT/html but this was hardened by the bank and could not be written to.

To get around this, they took another route that I cannot recall ever seeing before. Its not a universla technique as it is going to depend on how your particular server deals with caching and etags but they retrieved the etag for a javascript file. And then wrote to the local path for that cached version of the JavaScript file to get a stored XSS. For tomcat this ended up being in the form of FIRST-CHAR/SECOND-CHAR/FULL-ETAG/fileAsset/FILE-NAME but if you want to try this technique out you’ll need to determine what it is for your target’s server.