MCS Cloud Platform Security Audit

SkyShip Dusk by SeerLight

The construction of any service necessarily includes constant work on security. Security is a continuous 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 on their own and by external experts who can dramatically help with security, as they are not immersed in the project and have a clear view.

The article is about this very unpopular view of external experts who helped the Cloud Solutions (MCS) team test the cloud service, and about what they found. As the "external forces" MCS chose Digital Security, known for its high expertise in the security community. And in this article we will analyze some interesting vulnerabilities that were found as part of an external audit - so that you get the same rake when you make your cloud service.

Product Description Cloud Solutions (MCS) is a platform for building virtual infrastructure in the cloud. It includes IaaSs, PaaSs, a marketplace of ready-made application images for developers. Considering the architecture of MCS, it was necessary to check the safety of the product in the following areas:

Perhaps, everything that is essential for the subsequent history is everything.

What kind of work was carried out and why are they needed?

A security audit is aimed at identifying vulnerabilities and configuration errors that can lead to leakage of personal data, modification of sensitive information, or to disrupt the availability of services.

During the work, which lasts 1-2 months on average, the 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:

  1. Analysis of authentication in the service. Vulnerabilities in this component would help immediately get into other people's accounts.
  2. The study of the role model and access control between different accounts. For an attacker, the ability to access someone else's virtual machine is a welcome target.
  3. Client side vulnerabilities. XSS / CSRF / CRLF / etc. Maybe it’s possible to attack other users through malicious links?
  4. Vulnerabilities in the server side: RCE and all kinds of injections (SQL / XXE / SSRF and so on). Server vulnerabilities are usually more difficult to find, but they lead to the compromise of many users at once.
  5. Network segment isolation analysis of user segments. For an attacker, the lack of isolation significantly increases the attack surface on other users.
  6. Business logic analysis. Is it possible to fool a business and create virtual machines for free?

In this project, the work was carried out according to the Gray-box model: auditors interacted with the service with the privileges of ordinary users, but partially possessed the source code of the API and had the opportunity to clarify details with the developers. Usually this is the most convenient and at the same time quite realistic model of work: internal information can still be collected by an attacker, this is only a matter of time.

Vulnerabilities Found

Before the auditor begins to send various payloads (payload, which is used to attack) to random places, you need to understand how it works, what functionality is presented. It may seem that this is a futile exercise, because in most of the studied places there will be no vulnerabilities. But only an understanding of the structure of the application and the logic of its operation will make it possible to find the most complex attack vectors.

It is important to find places that seem suspicious or something very different from others. And the first dangerous vulnerability was found in this way.


IDOR vulnerabilities (Insecure Direct Object Reference, insecure direct links to objects) are one of the most common vulnerabilities in business logic that allows one way or another to gain access to objects to which access is actually not allowed. IDOR vulnerabilities create the possibility of obtaining user information 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, the possibility of substitution of the sender’s account, due to which you can steal them from other users.

In the case of MCS, auditors just discovered the IDOR vulnerability associated with non-system identifiers. In the user's personal account, to access any objects, UUIDs were used, which seemed, as security men say, impressively non-gross (that is, protected from brute force attack). But for certain entities, it was found that ordinary predictable numbers are used to obtain information about application users. I think you realize that it was possible to change the user ID by one, send the request again and thus get information bypassing the ACL (access control list, data access rules for processes and users).

Server Side Request Forgery (SSRF)

OpenSource products are good because they have a huge number of forums with a detailed technical description of the problems that arise and, if you're lucky, with a description of the solution. But this coin has a flip side: well-known vulnerabilities are also detailed. For example, the OpenStack forum has wonderful descriptions of the vulnerabilities [XSS] and [SSRF] , which for some reason no one is in a hurry to fix.

Frequent application functionality is the ability for the user to send a link to the server that the server clicks on (for example, to download an image from a specified source). With insufficient security filtering of the links or responses returned from the server to users, such functionality is easily used by attackers.

SSRF vulnerabilities can greatly advance attack development. An attacker can get:

OpenStack has long been known for its “blind” SSRF vulnerability: when accessing the server you don’t get a response from it, but you get different types of errors / delays, depending on the result of the request. Based on this, you can scan ports on hosts on the internal network, with all the ensuing consequences, which should not be underestimated. For example, a product may have an API for back office, available only from the corporate network. Possessing documentation (do not forget about insiders), an attacker can use internal methods using SSRF. For example, if you managed to somehow get an approximate list of useful URLs, then using 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 case of detecting SSRF vulnerabilities in OpenStack. In the past, it was possible to download VM ISO images via a direct link, which also led to similar consequences. This feature is currently removed from OpenStack. Apparently, the community considered this the easiest and most reliable solution to the problem.

And in this publicly available report from the HackerOne (h1) service, the exploitation of a non-blind SSRF with the ability to read instance metadata leads to Root access to the entire Shopify infrastructure.

In MCS, in two places with similar functionality, SSRF vulnerabilities were detected, 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 studies written, from year to year XSS (cross-site scripting attack) is still the most common web vulnerability (or attack ?).

Downloading files is a favorite place for any security researcher. Often it turns out that you can load an arbitrary script (asp / jsp / php) and execute OS commands, in the terminology of pentesters - “load shell”. But the popularity of such vulnerabilities works in both directions: they are remembered and developed tools against them, so recently the probability of “loading the shell” has been tending to zero.

The attacking team (represented by Digital Security) was lucky. OK, in MCS, on the server side, the contents of the downloaded files were checked, only images were allowed. But SVG is also a picture. And what can be dangerous SVG pictures? The fact that you can embed JavaScript fragments in them!

It turned out that the downloaded files are available to all users of the MCS service, which means that you can attack other users of the cloud, namely, administrators.

An example of using a phishing login form using an XSS attack

Examples of exploiting an XSS attack:

Consider an example of yet another XSS identified, this time with trickier operation. MCS service allows you to combine firewall settings into groups. XSS was discovered in the group name. Its peculiarity was that the vector did not work immediately, not when viewing the list of rules, but when the group was deleted:

That is, the scenario was as follows: an attacker creates a firewall rule with a “load” in the name, the administrator notices it after a while, initiates the deletion process. And here the malicious JS also fulfills.

For the MCS developers, to protect against XSS in downloadable SVG images (if they cannot be abandoned), the Digital Security team recommended:

In addition, there are now many ways available for developers to mitigate the risks of operating XSS:

Two-factor authentication vulnerabilities

To increase account security, users are always advised to enable 2FA (two-factor authentication). Indeed, this is an effective way to prevent an attacker from gaining access to the service if the user credentials have been compromised.

But does the use of the second authentication factor always guarantee the safety of the account? There are several security issues with the 2FA implementation:

In the case of MCS, 2FA is based on Google Authenticator and Duo . The protocol itself has already been tested by time, but the implementation of code verification on the application side is worth checking.

The MCS 2FA is used in several places:

Considering that the backup codes were located in the same range of line 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 Burp: Intruder tool


Overall, MCS as a product turned out to be safe. During the audit, the Pentester team was not able to access the 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 continuous work. Services are not static, they are constantly evolving. And to develop a product completely without vulnerabilities is impossible. But you can find them in time and minimize the chance of their repetition.

Now all the mentioned vulnerabilities in MCS are already fixed. And in order to minimize the number of new ones and shorten their lifetime, the platform team continues to do this:


All Articles