Corporate data is often a trade secret. Leaking them can lead to a blow to reputation, financial losses, or even bankruptcy. Therefore, the security requirements for a B2B product must be very high. Creating a new product - Corporate Mail Mail.ru - we paid special attention to the issue of its security.
Corporate Mail Mail.ru is an on-premises version of the familiar B2C mail Mail.ru. Compared to it, it contains a number of modifications to work in a new environment - the customer circuit.
To make our customers confident in safety, we decided to undergo an audit in a third-party company and fix all the deficiencies we found before offering the product to the market. To do this, they turned to one of the most reputable companies in the field of information security - Digital Security.
The audit results are under the cut.
Remote code execution in uWSGI
There are different frameworks for building Python web applications. Typically, the Python Web Server Gateway Interface (WSGI) is used to communicate between the web application and the web server. In addition, using WSGI allows you to implement middleware components.
To standardize communication between a Python web application and a web server such as Apache or Nginx, PEP 0333 was developed, followed by PEP 3333, which describes the WSGI interface. We will not dwell on how WSGI works, but will tell you about a popular server that supports the WSGI interface - uWSGI.
The uWSGI server can work both in the normal web server mode and in the "WSGI mode", exchanging data with another web server, for example Nginx. At the same time, Nginx uses the binary protocol of the same nameuwsgi , which is interesting for cybercriminals due to its rich functionality. When analyzing the "internals" of the solution, a uWSGI server was found, which all internal components of the product had access to.
The problem was that in the uwsgi protocol, you can use so-called magic variables that allow you to dynamically configure the uWSGI server. Among these variables there is
UWSGI_FILEone that allows you to load a new dynamic application if you specify the path to the file in the variable. As it turned out, uWSGI-server can handle different circuits in this way, for example section, fd, call, or most interesting - exec. Thus, you can pass the variable as a valueexec://<cmmand>to execute an arbitrary bash command. To analyze this problem, an exploit was written, available on github .
An example of a query that executes a command.
This vulnerability could only be exploited if the attacker:
- Is already on the internal network of the product, for example, one of the components has been compromised. This could allow him to hijack a new component, gain access to new data, and continue the attack.
- Has SSRF with the ability to send arbitrary data over TCP (for example using
gopher://). In this scenario, an attacker can gain access to the inside of the product.
It is worth noting that implementations of CGI interfaces for other programming languages or frameworks can also be vulnerable, for example, an exploit from the same repository for FastCGI. This is not to say that this is a vulnerability in the usual sense, but rather a feature of CGI servers, so you need to limit access to such servers as much as possible.
Bypassing CSRF protection
With the introduction of various security mechanisms in browsers, client-side attacks on the modern web are gradually disappearing. This also applies to CSRF: browsers have already implemented support for the SameSite cookie, although if configured incorrectly, there may still be loopholes. In addition, many popular frameworks allow developers to easily configure CSRF protection, but a few bugs or non-critical vulnerabilities can turn into a CSRF attack potential. Such errors were found in the calendar application included with our product.
The application has an API that allows you to perform actions on the user's events and calendars, for example: edit, view or delete them. To refer to the object, the UID parameter is passed in the URL path, which is responsible for the ID of the calendar or event. It looks like this:
example.com/api/calendar/{UID}/action?
example.com/api/event/{UID}/action?
By default, the UID is randomly generated and cannot be influenced by the user. But in the application, two places were found in which the user can change the UID.
The first is to import files in ICS format (a special format for calendars and events), they have a special UID field that the user controls when importing. In this case, after importing events, their UIDs will remain the same as were transferred in the file. Also, this parameter has no filtering. Thus, the user could create an event with an arbitrary UID.
The second is the ability to change the UID-calendar when editing it. This could be done by intercepting the request to edit the calendar and simply changing the UID field. There was no filtering here either.
Another important feature: this API implements CSRF protection; for this, a special parameter is passed in the GET parameters, which plays the role of both a key for the API and a CSRF token. It is added via JavaScript to all API requests. It is bad practice to pass CSRF tokens in GET parameters, in this case, tokens may leak through the referer, application logs or browser history.
Putting it all together. An attacker can control object UIDs in an application and share access to both events and calendars with other users. In this case, users will see the same UID, and when they start working with such an object, requests will be executed with a UID that is controlled by the attacker. Using this, an attacker can make an object with a UID like:
../../../AnyPathTo?anyparam=value&
Now, when the user performs an action on the object, a request will be generated:
example.com/api/event/../../../AnyPathTo?anyparam=value&/action
Then a token will also be added to it, playing the role of a CSRF token:
example.com/api/event/../../../AnyPathTo?anyparam=value&/action&token=abcdef
And finally, making the request, the browser normalizes the sequence "
../", as a result, the request will be sent to
example.com/AnyPathTo?anyparam=value&/action&token=abcdef
Now an attacker can force a user to send a request to the application along an arbitrary path with arbitrary parameters and with the correct CSRF token. It remains to understand what request methods we can execute.
It turned out to be simple: when editing, PUT is sent, when deleting, DELETE, when viewing, GET (POST is used to create, and we cannot force the victim to use it). By using DELETE, an attacker can force the user's browser to execute a request to delete an object from the user. A separate bonus for an attacker is that when a user edits an object, a PUT request is sent with the request body. When editing a calendar, the request body will contain JSON, which contains all the parameters of the current calendar. That is, the attacker who created the “malicious” calendar controls these parameters. If an attacker succeeds in redirecting an edit request from the “malicious” calendar to the user's private calendar, then all the properties of the “malicious” calendar will be applied to the properties of the victim's user's calendar.This can overwrite the access to the calendar because it is one of the calendar properties specified in JSON.
MITM attack capability
Penetration of an intruder into the company's internal network is a dangerous situation that is fraught with serious consequences. Therefore, during the audit of the product, one of our tasks was to find flaws in the system architecture that could help an attacker move up the domain or improve external attacks.
One of the main features of the product is integration with Active Directory. It is implemented for authentication via LDAP and collecting messages from the Exchange server, in this example we will focus on ActiveSync. For an attacker, this is a very interesting target because user accounts and passwords are passed between the product and Active Directory during the connection. By gaining access to the connections, an attacker will be able to hijack accounts and will be one step closer to compromising the domain.
In internal solutions and on the servers of companies, there is often a problem with the incorrect use of TLS or its absence at all, while it is not difficult to implement TLS for a service. This is usually a consequence of the fact that the company's internal network is considered more secure, and company administrators do not spend time creating the correct PKI infrastructure and issuing certificates for all servers.
The most common attack inside corporate networks is MITM. This type of attack most often allows access inside a company's Active Directory. At the same time, it is not always possible for an attacker to attack the server-to-server interaction within the company's network; most often, during penetration tests, he or his model falls into a user network segment in which there is no Exchange server or domain controller. In addition, in our case, the product does not use broadcast name resolution protocols such as NBNS, LLMNR, mDNS, so spoofing of these protocols will not allow MITM to be implemented. Thus, for a successful MITM between the solution and other servers, it is necessary for the attacker to have access to the network where one of these components is installed. It is sometimes possible to achieve this goal - there are vulnerable routers or servers,which ultimately allow you to access a particular network.
In our case, during the analysis, it turned out that integration with Active Directory is vulnerable to MITM attacks.
When the user enters a username and password, the system sends two LDAP requests to the domain controller. The first request returns a list of mail addresses, and if the user's login is present in this list, then the second request is sent, which is Simple LDAP Authentication. Data is transmitted in clear text without using SSL / TLS, or rather, LDAPS (LDAP over SSL) is not used. This allows an attacker, even in the event of a passive MITM attack, to obtain user accounts that are currently authorized in the product.
The second problem: when connecting to an Exchange server using the ActiveSync protocol to collect incoming messages, the system did not authenticate the server's TLS certificate. In this case, an attacker could implement an active MITM attack, upon receiving a connection, he could give a self-signed certificate, establish a connection and proxy the data to the Exchange server; then MITM will be invisible, and an attacker can obtain user credentials, which are transmitted in the ActiveSync protocol.
By exploiting these vulnerabilities, an attacker could theoretically obtain user accounts and then use them in an attack on an Active Directory domain. Separately, it should be noted that the correct use of TLS is a necessary task for a company that implements a solution.
Result
We are constantly faced with hacker attacks and have gained solid experience in how to fight them off. We believe that the products that we put in the customer's perimeter should be as safe as possible, including based on the results of independent checks. Corporate Mail Mail.ru is just such a product.
We were faced with a time-consuming task: to transfer a large code base with many microservices to the customer's infrastructure so that mail would work on its own most of the time, without failures and administrator interventions.
We asked the auditors to pay the most attention to the changed authorization (Corporate Mail uses the customer's AD) and the main mail API - the source code of these components was analyzed in detail. As a result, the shortcomings found were mainly related to the changed network topology and modifications specific to the on-premises solution.
For the rest of the components (calendar, Mail.ru for business administration interface), a gray-box model was used: auditors interacted with the service with the privileges of ordinary users, but could connect to the container with the running application, partially possessed the API source code and could clarify the details with the developers.
The audit was very useful for us. We found a number of shortcomings in some of the components, which we promptly corrected to bring a safe product to market. At the same time, we were convinced of the high level of protection of most of the other components. We plan to conduct such audits on a regular basis - we want our product to always be in the top of the safest domestic solutions, not only in our opinion, but also in the opinion of independent auditors.
The security of Corporate Mail is the combination of the security of the product itself and the client's infrastructure. That is, the responsibility for the safety of corporate data lies with us, the developer, and the client himself. In addition, we have formulated recommendations for best practices to protect infrastructure from flaws and always advise customers during the installation of our product.