There are two vulnerabilities in this blog post: authorization bypass and arbitrary file write. They will be discussed in this order.
The first vulnerability is really just poor logic. The authentication handling in IBM WebSphere has MANY different ways and is very complex. The program uses SOAP (XML stuff) in order to do the authorization dance.
When using token based authorization, there was a check to see if the user DOES NOT have a proper authorization token, by checking for NULL. But, in reality, this passes a value back called Unauthenticated instead of NULL. Now, the user can use the rest of the program, with limited users access.
From this minimal authorization bypass, it was possible to trigger a Deserialization Vulnerability that had already existed. But, the "patch" (notice the bunny ears) was to ensure that the user was authenticated. Because of this authorization bypass, this vuln was back on the table!
After this, the author had to find a
custom Deserialization Gadget (as most of the default Java ones have been fixed now), which has in a different blog post entirely
The second vulnerability was a classic directory traversal in the file upload functionality. Of course, this allowed for an easy RCE :)