The lesson here is just don’t store session data on the client and if you must, don’t take shortcuts, its tough to get right in the first place. Effectively here Zabbix stored session data in the user cookies. These were signed cookies atleast, but the signature was only checked when accessing the sessionid field from the session. SonarSource documented two ways this vulnerability could be abused.

First was to bypass authentication through the SAML Single Sign-on support in index_sso.php. Once the identity provides sent the user back after logging in, they’d have a SAML payload, from that Zabbix would verify its signature, and extra the user’s attributes into the saml_data field of the session. Later to authenticate a user, it would check if saml_data existed, and pull the username_attribute from it, logging the user in as that username. Of course, an attacker could set the saml_data[username_attribute] to whatever user they wanted to authenticate with.

To further this attack, the setup.php file, which is used during the first setup of the application, then locked off to only highly privileged users. It would use the session to track what stage of setup it was in, an attacker could craft a session cookie to make it execute stage 6 of the setup, which allowed control over a newly written configuration file.