Full Report
The author noticed a file called WSRequestXSSproxy_ajaxprocessor.jsp that hadn't changed much sense 2008. It's unused but a leftover artifact of the product. The whole purpose of this was SSRF as a service. In 2020, they noticed this internally and tried to fix it but failed. The patch just made it so that you had to be authenticated to access the endpoint. Because of some issues around Java applets, a special case was added to not have authentication on .jar files. The check did a string comparison check with endsWith on the path of the URL. By adding ;.jar to the end of the URL, it would bypass the check. This works because of matrix parameters. By adding this string to the end of the URL, you can then get the SSRF unauthenticated once again. The SSRF is heavily based around SOAP and XML. The vanilla code allows for control over the URI, username, password and payload within XML. Using a CRLF vulnerability in the SOAPACTION header, we can add arbitrary headers to the request. This gives us more freedom to exploit how we want. This is a limitation though: we can only read XML and JSON responses. What if we wanted to read something else? The Range header is used to specify which bytes to send in the response. By choosing which bytes to send in the SSRF response and combining the newline injection, we can return a byte at a time. Luckily for us, this will return an error with our character in the middle of it. This turns a mostly blind SSRF into a full-read SSRF. The newline injection can be used to exploit HTTP pipelining to get Request Smuggling. Notably, this can desync requests and responses. If you're lucky, other users will get your response or you'll get another users response. Overall, a good chain of vulnerabilities to increase the impact. I didn't know about the matrix parameters so that's a new tool to add to the bag of tricks.
Analysis Summary