Pierluigi Paganini
August 31, 2021
Technical details of a serious vulnerability in the Microsoft Exchange Server, dubbed ProxyToken (CVE-2021-33766), were publicly disclosed. The issue could be exploited by an unauthenticated attacker to access emails from a target account.
An attacker can trigger the flaw by sending a specially crafted request to web services within the Exchange Control Panel (ECP) application and access messages from a victim’s inbox.
An attacker could exploit the issue to access mailbox settings and set up an email forwarding rule in order to receive the messages sent to the victims.
As a pre-requisite for the attack, the attacker needs to have an account on the same Exchange server as the victim.
“This vulnerability allows remote attackers to disclose sensitive information on affected installations of Microsoft Exchange Server. Authentication is not required to exploit this vulnerability.” reads the advisory published Zero-Day Initiative (ZDI). “The specific flaw exists within the authentication of requests to web services within the ecp web application. By issuing a crafted request, an attacker can bypass authentication. An attacker can leverage this vulnerability to disclose information from the server.”
The vulnerability was discovered by Le Xuan Tuyen from the Information Security Center of Vietnam Posts and Telecommunications Group (VNPT-ISC) in March.
The experts noticed that Outlook Web Access and Exchange Control Panel pass authentication requests to the Exchange Back End.
When the “Delegated Authentication” feature is active in Microsoft Exchange installs, the front-end forwards the requests that need authentication to the backend. These requests include a ‘SecurityToken’ cookie that when is present in a request within ‘/ecp’, delegates the authentication process to the backend.
“Thus, for requests within /ecp, if the front end finds a non-empty cookie named SecurityToken, it delegates authentication to the back end. Code on the back end that examines and validates the SecurityToken cookie is found in the class Microsoft.Exchange.Configuration.DelegatedAuthentication.DelegatedAuthenticationModule” reads the analysis published by ZDI. “As you can see, in a default configuration of the product, a element appears, so that the module DelegatedAuthModule will not be loaded at all for the back-end ECP site.”
Anyway, the experts noticed that in a default configuration of the product, the module DelegatedAuthModule will not be loaded at all for the back-end ECP site.
“In summary, when the front end sees the SecurityToken cookie, it knows that the back end alone is responsible for authenticating this request. Meanwhile, the back end is completely unaware that it needs to authenticate some incoming requests based upon the SecurityToken cookie, since the DelegatedAuthModule is not loaded in installations that have not been configured to use the special delegated authentication feature. The net result is that requests can sail through, without being subjected to authentication on either the front or back end.” continues the analysis.
Experts noticed that in order to trigger the issue, each request to an /ecp page is required to have a ticket known as the “ECP canary”. In the absence of the canary, the request will come back with an HTTP 500. However, the researchers noticed that the 500 error response is accompanied by a valid canary that could be used to issue an unauthenticated request.
Microsoft has addressed the ProxyToken flaw in July, it has been rated with a CVSS score of 7.5 because it could be exploited by an attacker with an account on the same Exchange server as the victim.
Researchers from Bleeping Computer noticed that some experts already reported exploit attempts that occurred in the last weeks.
Below is a tweet published by security experts Rich Warren from NCC Groug:
Follow me on Twitter: @securityaffairs and Facebook
| [adrotate banner=”9″] | [adrotate banner=”12″] |
(SecurityAffairs – hacking, ProxyToken)
[adrotate banner=”5″]
[adrotate banner=”13″]
