The article dives into the protocol being used on these services and how it works. Because this protocol was complex and had not been tackled before, there was a good chance that something was going to be uncovered.
By reversing the protocol, they discovered an endpoint that was prior to any authentication! This endpoint was used to update critical information on the server, mainly configuration files.
This API was then trivially vulnerable to directory traversal, resulting in the ability to write any file to any location on the server.
How to get a root shell? They decided to use the unauthenticated API to overwrite configuration systems (which were obviously trusted). From there, they setup the authentication to a 'third party provider' of their own server.
By controlling this authentication scheme, they could control who was authenticated. So, they issued a token for the administrative user on the platform and logged in as them.
Finally: the RCE. The admin user can write TM1 scripts. This scripting language has a ExecuteCommand primitive, which enables easier code execution.
Overall, two things stuck out to me:
- A simple lack of authentication on a single endpoint turned into a complete compromise of the server!
- The lack of defense-in-depth on this from a single bug was interesting... it appears that several vulnerabilities in this single API could lead to a remote compromise of the server. A scripting language that can execute shell commands? They sounds like it is just waiting to get pwned.