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 Mail.ru 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

Mail.ru 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:

• virtualization environment infrastructure protection: hypervisors, routing, firewalls;
  
  
• protection of virtual infrastructure of customers: isolation from each other, including network, private networks in SDN;
  
  
• OpenStack and its open components;
  
  
• S3 own development;
  
  
• IAM: multi-tenant projects with a role model;
  
  
• Vision (machine vision): APIs and vulnerabilities when working with images;
  
  
• web interface and classic web attacks;
  
  
• vulnerabilities of PaaS components;
  
  
• API of all components.
  
  

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

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:

• limited access to the attacked local network, for example, only on certain network segments and on a certain protocol;
  
  
• full access to the local network, if downgrade is possible from the application level to the transport level and, as a result, full load management at the application level;
  
  
• access to reading local files on the server (if the file: /// scheme is supported);
  
  
• and much more.
  
  

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:

• Why try to steal a session (especially since now there are everywhere HTTP-Only cookies that are protected from theft with js-scripts) if the downloaded script can immediately access the resource API? In this case, the payload can change the server configuration through XHR requests, for example, add the attacker's public SSH key and gain SSH access to the server.
  
  
• If the CSP policy (content protection policy) prohibits the implementation of JavaScript, an attacker could do without it. In pure HTML, make up the fake login form of the site and steal the administrator password through such advanced phishing: the phishing page for the user is at the same URL, and it is more difficult for the user to detect it.
  
  
• Finally, an attacker can arrange a client DoS - set cookies larger than 4 KB. It is enough for the user to open the link once and the whole site becomes inaccessible until you guess specially to clean the browser: in the vast majority of cases the web server will refuse to accept such a client.
  
  

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:

• Host files uploaded by users on a separate domain that has nothing to do with “cookie”. The script will be executed in the context of another domain and will not pose a threat to MCS.
  
  
• In the HTTP response of the server, give the header “Content-disposition: attachment”. Then the files will be downloaded by the browser and not executed.
  
  

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

• using the “HTTP Only” flag, you can make the session headers of cookies inaccessible to malicious JavaScript;
  
  
• a correctly implemented CSP policy will significantly complicate the operation of XSS for an attacker;
  
  
• modern template engines, such as Angular or React, automatically clear user data before displaying it in the user's browser.
  
  

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:

• Rough search of OTP-code (one-time codes). Despite the simplicity of operation, such errors as the lack of protection against the OTP brute are also encountered by large companies: the Slack case, the Facebook case .
  
  
• Weak generation algorithm, for example, the ability to predict the following code.
  
  
• Logical errors, for example, the ability to request someone else's OTP on your phone, as it was with Shopify.
  
  

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:

• At user authentication. Here there is protection against brute force: 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 perform OTP busting.
  
  
• When generating offline backup codes to run 2FA, as well as turning it off. Here, protection against brute force was not implemented, which made it possible to regenerate backup codes or disable 2FA completely if there was a password for the account and an active session.
  
  

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

Result

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:

• conduct regular audits by external companies;
  
  
• to support and develop participation in the Bug Bounty-program Mail.ru Group ;
  
  
• to do security. :)