by SeerLight
Building any service necessarily includes constant work on security. Security is an ongoing process that includes continuous analysis and improvement of product security, monitoring of news about vulnerabilities, and much more. Including audits. Audits are carried out both in-house and by external experts, who can dramatically help with security, because they are not immersed in the project and have an open mind.
The article is about this very unfiltered view of external experts who helped the Mail.ru Cloud Solutions (MCS) team to test the cloud service, and about what they found. As "external forces" MCS chose Digital Security, known for its high expertise in information security circles. And in this article, we will analyze some interesting vulnerabilities found as part of an external audit - so that you bypass the same rake when you create your own cloud service.
Product Description
is a platform for building virtual infrastructure in the cloud. It includes IaaS, PaaS, a marketplace of ready-made application images for developers. Given the architecture of the MCS, it was necessary to check the security of the product in the following areas:
- protection of the infrastructure of the virtualization environment: hypervisors, routing, firewalls;
- protection of the virtual infrastructure of customers: isolation from each other, including network, private networks in SDN;
- OpenStack and its open components;
- S3 of our own design;
- IAM: multi-tenant projects with a role model;
- Vision (machine vision): API and vulnerabilities when working with images;
- web interface and classic web attacks;
- PaaS component vulnerabilities;
- API of all components.
Perhaps, from the essential for further history - everything.
What kind of work was carried out and why is it needed?
A security audit is aimed at identifying vulnerabilities and configuration errors that can lead to the leakage of personal data, the modification of sensitive information, or the disruption of the availability of services.
During the work, which lasts an average of 1-2 months, auditors repeat the actions of potential attackers and look for vulnerabilities in the client and server parts of the selected service. In the context of the audit of the MCS cloud platform, the following objectives were identified:
- Analysis of authentication in the service. Vulnerabilities in this component would help to immediately get into other people's accounts.
- The study of the role model and access control between different accounts. For an attacker, the ability to gain access to someone else's virtual machine is a desirable goal.
- Client side vulnerabilities. XSS/CSRF/CRLF/etc. Maybe there is a possibility to attack other users through malicious links?
- Server-side vulnerabilities: RCE and all kinds of injections (SQL/XXE/SSRF and so on). Server vulnerabilities are usually harder to find, but they lead to the compromise of many users at once.
- Analysis of the isolation of user segments at the network level. For an attacker, the lack of isolation greatly increases the attack surface for other users.
- Business logic analysis. Is it possible to cheat a business and create virtual machines for free?
In this project, the work was carried out according to the “Gray-box” model: the auditors interacted with the service with the privileges of ordinary users, but partially possessed the API source texts and had the opportunity to clarify the details with the developers. This is usually the most convenient, and at the same time quite realistic model of work: internal information can still be collected by an attacker, it's only a matter of time.
Found vulnerabilities
Before the auditor starts sending various payloads (the payload with which the attack is carried out) to random places, it is necessary to understand how what works, what functionality is presented. It may seem that this is a useless exercise, because in most of the studied places there will be no vulnerabilities. But only understanding the structure of the application and the logic of its work will make it possible to find the most complex attack vectors.
It is important to find places that seem suspicious or are somehow very different from others. And the first dangerous vulnerability was found in this way.
IDOR
IDOR vulnerabilities (Insecure Direct Object Reference, insecure direct references to objects) are one of the most common types of vulnerabilities in business logic, which allows one way or another to gain access to objects that are not really allowed to be accessed. IDOR vulnerabilities create the possibility of obtaining information about the user of varying degrees of criticality.
One of the IDOR options is to perform actions with system objects (users, bank accounts, goods in the basket) by manipulating access identifiers for these objects. This leads to the most unpredictable consequences. For example, to the possibility of substituting the account of the sender of funds, due to which you can steal them from other users.
In the case of MCS, auditors just discovered an IDOR vulnerability associated with non-secure identifiers. In the user's personal account, UUIDs were used to access any objects, which seemed, as security experts say, impressively non-brutal (that is, protected from a brute-force attack). But for certain entities, it was found that ordinary predictable numbers are used to obtain information about the users of the application. I think you can guess that it was possible to change the user ID by one, send the request again and thus obtain information bypassing the ACL (access control list, data access rules for processes and users).
Server Side Request Forgery (SSRF)
The good thing about OpenSource products is that they have a huge number of forums with detailed technical descriptions of the problems that arise and, if you are lucky, with a description of the solution. But this medal has a downside: well-known vulnerabilities are also detailed. For example, the OpenStack forum has great descriptions of vulnerabilities и which for some reason no one is in a hurry to fix.
A common application functionality is the ability for the user to send a link to the server that the server follows (for example, to download an image from a specified source). With insufficient filtering by security tools of the links themselves or the responses returned from the server to users, such functionality is easily used by attackers.
SSRF vulnerabilities can greatly advance the development of an attack forward. An attacker can get:
- limited access to the attacked local network, for example, only through certain network segments and according to a certain protocol;
- full access to the local network, if it is possible to downgrade from the application layer to the transport layer and, as a result, full load management at the application layer;
- read access to local files on the server (if the file:/// scheme is supported);
- and much more.
OpenStack has long known an SSRF vulnerability that is "blind" in nature: when you access the server, you do not receive a response from it, but you get different types of errors / delays, depending on the result of the request. Based on this, it is possible to perform a port scan on hosts on the internal network, with all the ensuing consequences that should not be underestimated. For example, a product may have a back office API that is only accessible from the corporate network. With documentation (don't forget about insiders), an attacker can use SSRF to access internal methods. For example, if you managed to somehow get an approximate list of useful URLs, then with the help of SSRF you can go through them and execute a request - relatively speaking, transfer money from account to account or change limits.
This is not the first time an SSRF vulnerability has been discovered in OpenStack. In the past, it was possible to download ISO images of VMs from a direct link, which also led to similar consequences. This feature has been removed from OpenStack for now. Apparently, the community considered this the simplest and most reliable solution to the problem.
And in In a publicly available report from HackerOne (h1), running a no longer blind SSRF with the ability to read instance metadata results in Root access to the entire Shopify infrastructure.
In MCS, SSRF vulnerabilities were found in two places with similar functionality, but they were almost impossible to exploit due to firewalls and other protections. One way or another, the MCS team fixed this problem anyway, without waiting for the community.
XSS instead of loading "shells"
Despite hundreds of written studies, from year to year XSS (cross-site scripting attack) is still the most web vulnerability (or ?).
File uploads are a favorite place for any security researcher. It often turns out that you can load an arbitrary script (asp / jsp / php) and execute OS commands, in the terminology of pentesters - “load a shell”. But the popularity of such vulnerabilities works in both directions: they are remembered and remedies are being developed against them, so recently the probability of “loading a shell” tends to zero.
The attacking team (represented by Digital Security) was lucky. OK, in MCS on the server side, the contents of the uploaded files were checked, only images were allowed. But SVG is also a picture. And how can SVG images be dangerous? The fact that you can embed JavaScript snippets in them!
It turned out that the downloaded files are available to all users of the MCS service, which means that other users of the cloud, namely administrators, can be attacked.
Phishing Login Form XSS Attack Example
Examples of XSS attack exploitation:
- Why try to steal a session (especially since now HTTP-Only cookies are everywhere, protected from theft using js scripts), if the loaded script can immediately access the resource API? In this case, the payload can change the server configuration via XHR requests, for example, add an attacker's SSH public key and gain SSH access to the server.
- If the CSP policy (Content Protection Policy) prohibits the injection of JavaScript, an attacker can do without it. On pure HTML, create a fake login form and steal the administrator password through such advanced phishing: the phishing page for the user is on the same URL, and it is more difficult for the user to detect it.
- Finally, an attacker can arrange - set Cookies larger than 4 KB. It is enough for the user to open the link once - and the entire site becomes unavailable until you think of cleaning the browser on purpose: in the vast majority of cases, the web server will refuse to accept such a client.
Let's look at an example of yet another XSS exposed, this time with more subtle exploitation. The MCS service allows you to combine firewall settings into groups. The group name contained the discovered XSS. Its peculiarity was that the vector did not work immediately, not when viewing the list of rules, but when deleting a group:
That is, the scenario turned out as follows: an attacker creates a firewall rule with a "load" in the name, the administrator notices it after a while, initiates the removal process. And this is where the malicious JS works.
For MCS developers to protect against XSS in uploaded SVG images (if they can't be opted out), the Digital Security team recommended:
- Host files uploaded by users on a separate domain that has nothing to do with "cookies". The script will be executed in the context of another domain and will not pose a threat to MCS.
- Send the "Content-disposition: attachment" header in the server's HTTP response. Then the files will be downloaded by the browser, and not executed.
In addition, there are now many ways for developers to mitigate the risks of XSS exploitation:
- using the "HTTP Only" flag, you can make the "Cookies" session headers inaccessible to malicious JavaScript;
- significantly complicate the exploitation of XSS for an attacker;
- modern templating engines like Angular or React automatically clean up user data before rendering to the user's browser.
Vulnerabilities in two-factor authentication
To increase the security of accounts, users are always advised to enable 2FA (two-factor authentication). Indeed, this is an effective way to prevent an attacker from accessing a service if the user's credentials have been compromised.
But does the use of the second authentication factor always guarantee the safety of the account? In the implementation of 2FA, there are such security problems:
- Rough enumeration of the OTP code (one-time codes). Despite the ease of use, errors such as the lack of protection against OTP brute occur in large companies: , .
- Weak generation algorithm, such as the ability to predict the next code.
- Logical errors, such as being able to request someone else's OTP on your phone, like this from Shopify.
In the case of MCS, 2FA is implemented based on Google Authenticator and . The protocol itself has already been tested by time, but the implementation of code verification on the application side is worth checking.
In MCS, 2FA is used in several places:
- When authenticating a user. There is brute-force protection here: the user has only a few attempts to enter a one-time password, then the input is blocked for a while. This blocks the ability to brute force the OTP.
- When generating offline backup codes for performing 2FA, as well as disabling it. Here, brute force protection was not implemented, which made it possible, if there was a password for the account and a valid session, to regenerate backup codes or disable 2FA altogether.
Given that the backup codes were located in the same range of string values as those generated by the OTP application, the chance to pick up the code in a short time was much higher.
The process of selecting OTP to disable 2FA using the tool "Burp: Intruder"
Experience the Power of Effective Results
In general, MCS as a product appeared to be safe. During the audit, the pentester team failed to gain access to client VMs and their data, and the vulnerabilities found were quickly fixed by the MCS team.
But here it is important to note that security is a continuous work. Services are not static, they are constantly evolving. And it is impossible to develop a product completely without vulnerabilities. But you can find them in time and minimize the chance of their repetition.
Now all the mentioned vulnerabilities in MCS have already been fixed. And to keep the number of new ones to a minimum and reduce their lifetime, the platform team continues to do this:
- conduct regular audits by external companies;
- support and develop participation;
- deal with security. 🙂
Source: habr.com