Citrix XenServer Free 5.6 Security or "... you need to find a different hypervisor"

The further virtualization technologies develop, the more diverse “IT technology giants” are entering the market. Despite the fact that the Xen project itself has existed for a long time as an open source solution, an operating system with an integrated hypervisor like Citrix XenServer recently attracted the attention of Enterprise-level clients. Initially, the OS was focused on low / mid-end enterprises and was designed to solve the problems of minimizing the costs of a multi-server architecture. But in the development process, Citrix integrated into its hypervisor such vital things as High Availability and Likewise integration with Active Directory. Thus, at the moment there are commercial versions of Citrix XenServer positioned as a real alternative to VMWare ESX / ESXi. But, as you know, special security requirements are imposed on hypervisors. This is because when a hypervisor is captured, it’s most likely that the company will lose not only it, but all the virtual machines.




More and more, vendors are releasing their documentation on how to configure both the system and the Hardening / Security Guide class manuals. Citrix has released Common Criteria Security Target and User Security Guide documents. These documents have a number of recommendations and advice, but have too little practical information. In the CCST documentation, you can find a formal description of the protection object and a number of practical settings. In User Security, the company described a common system security methodology. Thus, a full-fledged Citrix Security Guide, which would fully cover all aspects, is unfortunately not available.
')
In 2011, Citrix was awarded the title Security Organization of the Year by ISSA. It was emphasized that the term "Secured By Design" applies to Citrix products. Perhaps some of the solutions from this company can be attributed to this category, but the study of their XenServer server products showed the presence of some specifics of their design and the peculiar interpretation of this term by a group of Citrix experts. In our article, we will explore some aspects of using Citrix Free XenServer 5.6.0 and security issues that may possibly arise from the practical use of this system. The choice of this particular version is due to a fairly high prevalence and popularity. Much of what has been said below has not undergone any changes in the versions of the 6th family.

The foundation of the entire hypervisor is XenAPI (XAPI). This is a daemon executed by the system with superuser privileges and providing an interface for managing the system itself and the virtual machines. Being a direct relative of the Red Hat Enterprise Linux operating system, the hypervisor inherited a number of standard solutions from the progenitor. This is the PAM module responsible for connecting to XAPI.

This module is configured by default to fully include the default settings from system-auth. In practice, this means that any user who has an account in the system can execute XAPI requests with pool-admin privileges except for changing the root password using the API. This feature of the system is documented and inherent in the Free and Advance versions. According to Citrix policy, when using these XenServer options, you have a system with a “single level” of the user, LSU (Local Super User). This decision by Citrix seems doubtful as part of the ideology of building Enterprise-level products in its public understanding.

This specificity creates some problems in terms of using the hypervisor as a multi-user system. In order to create distinctions, it is necessary to adjust the PAM settings of the xapi module in such a way as to limit the circle of persons allowed to control the hypervisor. There are a lot of possibilities for this, all standard PAM tools are at your disposal. A description of the features of PAM and ideas for configuring XAPI security can be found in the “The Linux-PAM System Administrators Guide” from Andrew G.Mortan and Thorsten Kukuk.

Another specific feature of XAPI is the presence of remote control over HTTP / HTTPS in the system. The daemon keeps ports 80 and 443 open on the administrative interface. In this article, we will not consider multi-interface systems; this problem is a little less acute there, given the possibility of a physical separation of the control network. But I would like to note that this layout is necessary for any production solution.



Quite often, the administrative interface is also common for data transfer and cascading of virtual machines. Thus, any control over port 80 without using SSL tunnels allows an attacker to at least use a sniffer and get system settings, and how to maximize a successful code injection or intercept a management session. As a solution, iptables is optimal. In general, it is worth limiting the traffic arriving at 80 \ 443 ports in the system. This issue is adequately addressed in a Citrix Common Criteria Evaluated Configuration Guide for Citrix XenServer 5.6, Platinum Edition.
In order to clarify the next place of concern, dive a little deeper into the motor skills of Citrix XenServer. For ease of access to virtual machines, the hypervisor uses the transfer of text / graphic guest consoles on XAPI. To do this, use a small program vncterm. The work ideology is approximately the following: When a console requests a XAPI tool, a fork of the vncterm process is created on the loopback interface and transmitted to the XAPI user.



This happens with all hosts, including the hypervisor host itself. With a few exceptions. If you connect to a hypervisor host, instead of sending it for authentication, the Citrix authoring code is executed, giving you instant access to the local console as root.



Any user who has access to XAPI on the server without being tied to Active Directory will be able to get root access to the hypervisor host.

As a secondary problem of vncterm, we note a single session for all. That is, by creating a session on the guest system as root and forgetting to log out of the guest system, you will leave the open VNC channel. The next time you request this guest, any XAPI user will receive that same open session. Compromise system is inevitable. Note that local user authentication also happens automatically on mingetty –autologin root with automatic xsconsole loading.



This is not critical, but sh code injection is theoretically possible. Therefore, you should limit the issuance of superuser privileges in the system.

Another problem is the transfer of virtual machines between servers in XenMotion mode. It occurs through the 80th port of the system in plain-text mode. Thus, the attacker has the ability to intercept data "on the fly." The solution to this problem is only one - the use of IP level encryption. But this is not the only problem with data transfer, - just by default, the iSCSI service transmits credentials in the clear. This problem is solved by activating CHAP.

Citrix XenServer uses several virtual machine storage modes: as LVM and as VHD files. in the form of LVM sections or individual files. The first mode can be regarded as conditionally safe, since only the superuser has the right to mount partitions. But the VHD storage mode as separate files is another security issue. The file is created with the standard umask from server scripts: rw-rr. Thus, the virtual machine is available to any user of the system. This problem is solved by the method of fixing the scripts, which will be described in Positive Technologies Citrix XenServer 5.6 Security Guide.

Since the system is a descendant of RHEL, it inherited their RPM package management system along with the yum add-on. Initially on the system, if you try the trivial “yum update”, you will not receive system updates. Although clearly feel that behind a beautiful screensaver dinosaur hiding Linux . The problem is that Citrix is ​​blocking connectivity to CentOS repositories at the yum configuration level. Of course, it is not a problem to turn them back on and perform a system update. But this action will lead to the early rest of the hypervisor due to the fact that Citrix changed some standard things in the system to their “religiously-faithful” ones, and now the roll-up of updates leads to the system crash. Since some packages in the system are detected by the security scanner as having vulnerabilities of the “critical” level (dhclient for example), the installation of updates becomes mandatory. To solve such problems, you need a security scanner, yum, dump, and patience.

I would like to note that from the general settings of the system “out of the box” there is an important slip in the settings of the pam_unix.so module. More specifically, it does not include the password storage mode in / etc / shadow.
Thus, given the standard permissions on the / etc / passwd file, there is potential access to the system password hashes. This also applies to the system's motor skills with NFS storages. Citrix XenServer Administration Guide recommends setting the no_root_squash option on the NFS server. Such a solution is standard for hypervisors, and such storage should be isolated from the outside world as much as possible using iptables tools or the like. In addition, of course, you should adjust the file creation modes and remap the root user to a specialized system user.

Thus, summing up as a whole, it turns out that the Citrix Free XenServer product in the initial configuration has several possible serious security problems "by design". Many of them are common problems for the RHEL family, others are unique to this system. Of course, from the point of view of Citrix, these are not problems, but architecture features of their hypervisor. The security issues and the overall security methodology for this OS will be presented in the document Positive Technologies: Citrix XenServer Security Guide, which will be released in open beta testing in the near future.