This just comes down to overly verbose error message. The Coindesk website has an API endpoint that normally serves a list of published articles. That endpoint works as a simple proxy to the arcpublishing API. When the arcpublishing API returned with a status code other than 200 (Success) it would print basically all the information a developer might want, stack trace, configuration information, request info. This includes all the headers used in the request, including the Authorization header which contained the token used to authenticate with arcpublishing. Using that token manually gave basically full access to the arcpublishing API.

There are two bugs here, one that allows an attacker to reset the password of any account, another to bypass 2FA.

Password Reset

This comes down to an unexpected array being passed in to the /api/recover_password endpoint. Normally it is expecting a JSON body containing a string named email. By passing an array to this, the first email will be used to find the account to reset the password for, but the email will be sent to both emails in the array. Meaning the attacker will get a copy of the password reset link.

2FA Bypass

This is atleast a partial bypass of 2FA, its unclear what the restrictions are. The login response even before providing the 2FA code contained the keys necessary to authenticate with the API. As the API doesn’t enfore the 2FA requirement an attacker can bypass the need for 2FA.

This sort of 2FA bypass is something I’ve seen a number of times, more often when dealing with a secondary authentication mechanism, like logging in on an admin panel needing an extra password. You can bypass it by simply using the API so its a good thing to keep an eye out for.

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.

A few vulnerabilities here, inconsisently enforced permissions, server side request forgery with an extension blocklist, and password reset link poisoning.

Inconsistent Permissions

Within Concrete CMS they use a fairly flexible User Group permission setup, where groups can inherit privileged from their parent group. While the primary editor performed a permission check when moving a group to prevent an Editor in this case from moving the Editors group to be under the Administrators group. That same check was not done within the “Move Multiple Group” interface however. Allowing an editor to escalate their privileges.

Server-Side Request Forgery

This was pretty straightforward as it was by design; a feature to allow editors to download a file from a remote server and save it locally. It did block file extensions like .php. To get around that, they used a common trick of putting a /test.html after the .php (.../info.php/test.html). Under many setups this will get routed to the PHP file. They also used DNS rebinding to make a request to the instance metadata server.

Password Reset Link Poisoning

This is an attack that pops up from time to time. When making a request to the forgot password endpoint it’ll generate the URL for the password reset email. To do this it uses the Host header to determine what domain it should use in the link. So an attacker could change that header, but still direct their request to the server’s IP. The link it send to the victim will use the poisoned host. It does rely on them clicking the link to expose the token from their URL but its a fun attack to be aware of regardless.