Computer Science Blog @ HdM Stuttgart

Log in
, , ,

Cloud Security – Part 2: The vulnerabilities and threats of the cloud, current scientific work on cloud security, conclusion and outlook

Andreas Fliehr

I’m glad to welcome you to the second part of two blog posts about cloud security. In the first part, we looked at the current cloud market and learned about the concepts and technologies of the cloud. Thus, we created a basis for the areas of this post in which we will now deal with the vulnerabilities and threats of the cloud, have a look at current scientific work on the topic and finally conclude with a résumé and an outlook.

Once again, I wish you to enjoy reading! 🙂

The vulnerabilities and threats of the cloud

First, we are trying to identify and discuss the vulnerabilities of cloud systems as far as possible. After that, we will look at a list of threats companies can encounter when using the cloud.

Vulnerabilities

Identifying vulnerabilities is important, because, in my opinion, this is right the way to address and eliminate issues that can lead to security problems and thereby we can create more robust systems.

The vulnerabilities of the cloud can be in my opinion:

  • the entire software stack,
  • the hardware,
  • the communication and connections between software and hardware components,
  • and the people or employees, who are involved.

The software stack is a weak point because, in the case of an infected hypervisor, all overlying components can be taken over, if no special security precautions have been taken (in the section scientific work under Iago Attacks, the background for this is explained in more detail). In addition, using service models of the public cloud means that there is an unknown system environment, which poses a potential danger. Therefore it is necessary to protect the application by means of certain mechanisms from this unknown and harmful environment. Weak points, that can be found in the software stack and thus can be exploited, in my opinion, are:

  • The programming language used: In C, for example, integer types can be exploited to generate buffer overflows causing the program to crash. When the program restarts, a malicious code, which has been written to the memory, can be executed and thereby the system can be taken over eventually.
  • Insecure settings and rights distributions in systems.
  • Insecure techniques for virtualisation: If multiple containers are based on a single kernel, there is no adequate isolation.
  • Insecure programmed apps: For example, no use of frameworks for secure programming, or no secure exception and error handling.
  • Programming errors of all kinds: Programming errors can lead to crashes, thus enableing the execution of malicious code.
  • Drivers needed for the hardware (mouse, keyboard, GPU, etc.) can be infected.

Next to software the hardware also represents a weak point. A processor, can already be delivered faulty. Thus, even the basic building blocks of systems would not be trustworthy. For this reason, Google, for example, designs its own hardware and provides it with unique verification numbers. This ensures security at the lowest level. But not every company is able to design hardware on its own, which is why a certain degree of trust in the hardware manufacturer is important. In order to increase security, trust could be strengthened by contractual regulations, or the purchased hardware could be checked for errors. A further weak point are transmissions between the hardware and software components. As long as transmissions are not encrypted, they can be read or, in the worst case, even changed. This problem could be counteracted by appropriate encryption with verification and certification.

Humans are also a weak point in systems (and maybe even the biggest). Again and again we can read in news that employees are causing system failures. One example is Amazon: an employee has mistakenly pushed down many servers by entering an additional decimal place and has thus stopped a large part of Amazons Cloud without any malicious intent. After the incident, however, the fault was not sought at the employee, but the fault source was countered by a more robust system configuration. In this way, such an event is no longer possible through an employee. In my opinion, this is the right approach for solving such issues, because by means of more robust systems, errors have lesser impact. Another example would be the incident that happened at a Dutch cloud provider. A former admin has deleted the complete customer database of the company. The data could then be recovered only with difficulty and not completely. The consequences of such an incident are considerable. In this case, a better elimination process might have been saved from damage.

If we would go deeper, we could certainly figure out many more weak points, but we will leave it with these.

There are various ways to obtain information about current vulnerabilities and exploits of systems or software to be able to counteract them early. For example, exploit databases like CVE (Common Vulnerabilities and Exposures) or Exploit Database can be searched for proof of concepts. In addition, the distributors of software or systems often have their own web pages regarding security information and current publicly vulnerabilities. It can also help to keep up with the latest happenings by tracing journals, blogs or websites about IT security, such as heise Security. Also, various conferences on IT security, such as the USENIX Securitiy Symposium, are a good place to get up-to-date information (you can find examples for current scientific work in the section “Scientific work on cloud security”). Also, there is certain software for patch management helping you to keep up-to-date with current patches. This might be useful if you included several external dependencies in your software.

Up next, we will look at the threats companies can face in the area of cloud computing.

Threats

For the threats associated with cloud usage, we will look at a list of the Cloud Security Alliance (CSA). This list is called “The Treacherous 12” and is from 2016. It represents the top 12 cloud computing threats, ranked by severity level (not by the probability of occurrence). The threats of the CSA relate to information security, not to more robust systems, but I would like to go through them with you for the sake of completeness. Below we will look at the individual points of the list with a short explanation of each in descending order:

  • Shared Technology Issues. These are security problems due to shared infrastructures, platforms or applications when using the service models (IaaS, PaaS and SaaS) of the public cloud.
  • Denial of Service (DOS). This is when an attack causes a failure of certain system components, which means that data or applications are no longer available. Examples are: WannaCry, a malicious program (ransomware) for Windows, which encrypts the data of a system, so it’s no longer able to work without a ransom payment for the decryption of data. Or: A system is attacked using a botnet, sending so many queries to a service or server that it fails. This is referred to as distributed denial of service (DDOS).
  • Abuse and Nefarious Use of Cloud Services. Security problems due to poorly secured cloud services, free trials, and fraudulent registrations with payment fraud.
  • Insufficient Due Diligence. For example, an inadequate risk assessment in development of a business model that involves the use of cloud technologies.
  • Data Loss. Data loss can occur in a variety of ways and doesn’t necessarily have to be caused by an attack. Examples are: inadvertent deletion of data, and loss of data due to unpredictable physical effects, e.g. fire or water. It is recommended to store data georedundant or at several providers.
  • Advanced Persistent Threats (APTs). Companies are an attractive target, because of their technological advance.
  • Malicious Insiders. Danger outgoing by employees, as explained by the case of the Dutch company in the previous section.
  • Account Hijacking. Hijacking of accounts, e.g. by phishing, fraud, or exploiting vulnerabilities in a software.
  • System and Application Vulnerabilities. Errors in programs or systems can lead to unauthorised access.
  • Insecure Interfaces and APIs. User interfaces, or APIs are exploited, for example, by injections, to gain unauthorised access, to modify data, or to reach a crash.
  • Weak Identity, Credential and Access Management. Security issues due to flawed multi-factor authentication, weak passwords, or not changing cryptographic keys, passwords, or certificates frequently.
  • Data Breaches. An incident in which sensitive, protected or confidential information is released, stolen, displayed or used without authorisation of the recipient. Data breaches represent the most serious threat in the field of cloud computing according to the classification of the CSA.

If you would like to have further detailed information about the threats, please refer to the CSA publication.

According to Intel, there are several tips helping to protect against Data Breaches (although these tips may be for rookies and should be clear to any computer scientist). You should:

  • keep your anti-virus software up-to-date (for this point, there are certainly different opinions among computer scientists),
  • provide additional protection through patch management or software for intrusion detection,
    backup your data (e.g. georedundant backups),
  • do not neglect the security of mobile devices, as they are used to the same extent as laptops or PCs today,
  • and train the users or employees appropriately (this point is still the main reason for the occurrence of a large part of the above-mentioned threats).

So far so good. In the next section, we will eventually look at the scientific work on cloud security.

Scientific work on cloud security

Before looking at examples of recent scientific work in the field of cloud security, I would like to briefly consider two special cases. They represent a threat and a protection of systems. Let’s briefly look at them below.

Iago Attacks

The example that represents a threat in the field of cloud computing is Iago Attacks according to a paper by Checkoway and Shacham.

First, some background information: Iago is a fictitious figure from the play Othello by William Shakespeare. He represents a demonic fool and is the antagonist in this play. Iago is a servant and would like to play his master against his knowledge and his will. Now let’s see how this is related to the attacks from the paper.

Iago Attacks exploit the fact that the kernel and the applications are peers, and the system call API is a remote procedure call (RPC) interface. The kernel is used as a mount for Iago Attacks, over which the attacks can be controlled and carried out. When there’s a system call by application, the malicious kernel returns a certain sequence of integer values as a response, which can affect the application to be against its will and perform calculations at the behest of the malicious kernel. We can conclude that in the field of public cloud computing, the application must be protected from an unknown and potentially harmful environment, in contrast to any previous way of thinking, trying to protect the environment from a bad application.

Intel Software Guard Extentions (Intel SGX)

The example concerning a protection against attacks is Intel’s Software Guard Extentions (SGX), explained in a paper by Costan and Devadas.

Intel SGX provides developers with CPU-based capabilities. Areas of an app that are protected by the CPU with SGX are called enclaves. Developers can decide which parts of an app should be enclaved. If the application is running, the data is protected by the enclave and if the app is not running it is protected by the CPU capabilities. There are CPU-based verification processes for creating enclaves, and to see if the CPU has Intel SGX capabilities. Critical data is not added to the enclaves, if the the app doesn’t verify appropriately.

According to the Intel, SGX can be used to protect against a compromised BIOS, corrupted hypervisors and firmware as well as against modification and disclosure of data. It is designed for C and C ++ applications only. SGX can protect applications from corrupted hypervisors, but not the hypervisor itself from a takeover. Intel SGX is available for processors from the 6th generation (also known as Skylake), but this only applies to CPUs with an S specification, that must be declared specifically. You can check this list, that provides information about which hardware supports SGX.

Criticism of Intel SGX

There is also criticism of Intel’s SGX: 98% of the cloud runs on Intel processors, which is almost a monopoly in the field of cloud computing today. MIT researchers criticise that Intel could expand another monopoly position with SGX: manufacturers must purchase a license and attestation key from Intel for the use of SGX. Thus, Intel can decide about the use of SGX and thereby over the winner and loser of the market. For example, Intel could have a very strong influence on the market through targeted pricing.

A paper by Schwarz et. al (2017), for example, deals with how to hide cache attacks using SGX. We can see that a technology that is supposed to be conductive for protection of systems can be exploited in order to conceal malicious processes.

Another drawback, which is associated with SGX, is that the there is a growing number of extensions for Intel’s CPUs, thus (among others) the complexity increases drastically. The documentation of SGX alone contains 120 pages and an increasing number of such extensions are brought into the CPU, which leads to an incredible complexity. Reading the description of a single modern Intel CPU would take a month with 40 hours of reading per week.

After getting to know these two special cases, we will now take a look at the papers that are currently dealing with cloud security.

Overview of recent papers on cloud security

The following is a selection of recent papers about cloud security. It is briefly described what the respective paper deals with. The selection of these papers is based on the assortment of Adrian Colyer, author of the blog The Morning Paper. Colyer chooses a paper of his interest daily and describes what it is about. In my opinion, this offers a pretty good pre-selection.

These papers are:

  • Deconstructing Xen, Shi et al., NDSS ’17. For this paper all publicly known vulnerabilities of the most widely used hypervisor Xen were investigated and an implementation named Nexen was developed, which counteracts most of the vulnerabilities.
  • SGXIO: Generic Trusted I/O Path for Intel SGX, Weiser & Werner, CODASPY ’17. SGXIO provides support for generic and trusted I/O paths to protect the input and output of users between enclaves and I/O devices.
  • Panoply: Low-TCB Linux applications with SGX enclaves, Shinde et al., NDSS ’17. This paper looks at what happens when an application is split into several small services, each running in its own enclave communicating with each other.
  • Shielding applications from an untrusted cloud with Haven, Baumann et al., OSDI ’14. This paper introduces the concept of shielded execution. Shielded execution is the opposite of sandboxing (a sandbox protects the system environment from a bad application): It protects the confidentiality and integrity of the code and data of an application against an untrustworthy host. That is also referred to as reverse-sandboxing.
  • SCONE: Secure Linux Containers with Intel SGX, Arnautov et al., OSDI ’16. By using SCONE (Secure CONtainer Environment) applications should not only be packaged and deployed with ease, but also most securely.
  • SGXBounds: memory safety for shielded execution, Kuvaiskii et al., EuroSys ’17. The authors of the paper show that memory safety attacks are still possible when using SGX, and offer a possible solution.
  • A study of security vulnerabilities on Docker Hub, Shu et al., CODASPY ’17. Docker Hub offers a huge selection of different images. The authors developed a framework for automated scanning of images on Docker Hub for vulnerabilities. The results are partially frightening.

As we can see, many of these papers deal with Intel’s SGX. This shows the market influence that Intel has already exerted and confirms the previously mentioned criticism of the MIT researchers.

All of these papers are certainly very interesting and worth looking at, but going into detail would go beyond boundaries. However, I would like to introduce you to one of these papers, since we have already dealt with the structure of the according technology in the first post: Deconstructing Xen.

Deconstructing Xen

Hypervisors are important for virtualisation, but vulnerable to attacks (especially Xen due to its monolithic design in pure C). Hypervisors are missing a security monitor for supervision and separation strategies to isolate processes. The authors analysed all public vulnerabilities of the Xen hypervisor. 144 vulnerabilities were located in the core of the hypervisor, not in Dom0 (domain 0 – Dom0 is the first domain launched by Xen on booting; it has special privileges, such as launching new domains or accessing the hardware directly, therefore is responsible for device drivers and hardware).

For the study, Xen was divided into Security Monitor, Shared Service Domain and isolated per VM Xen slices as the following figure shows:

Figure 1: Structure of Nexen
(Source: Deconstructing Xen, Shi et al.)

(Para-VM is a virtualisation technology that provides a software interface similar but not identical to the actual hardware.) A nested kernel architecture was interleaved into the Xen address space (that’s also where the name Nexen comes from, it stands for “nested Xen”). Thereby, VM-based hypervisor compromises are tied to individual Xen VM instances. This already prevents 107 of the 144 known vulnerabilities. It also enhances the code integrity of Xen because it protects against all code injection compromises. It has an average overhead of 1.2% (which is very low in contrast to the prevented vulnerabilities).

If you would like to deal more deeply with scientific work of the field of cloud security, you can use the papers listed above as an entry point or read their summaries of Adrian Colyer on The Morning Paper, which I can highly recommend.

This should be almost all information on the topic of cloud security I wanted to provide and I already thank you right now, if you made it this far. In the next and the last section, we will briefly recapitulate, draw a conclusion, and take a look at the possible prospects of cloud security.

Summary, Conclusion and Outlook

Let’s first summarise what we’ve looked at in the two blog posts:
In the first post, we first looked at how much the cloud is contributing to digital transformation and why security in the cloud is important. After that, we looked at the concepts and technologies of the cloud and have already drawn conclusions about the security of the different techniques for server virtualisation. Thus we learned about specialisation and isolation in the cloud computing area. In this post, we looked at the various vulnerabilities and threats of the cloud, and finally looked at some scientific approaches that deal with the topic of cloud security. The two posts are intended to serve as a basis on which further development can be carried out in order to be able to deal with more specific topics from the cloud computing area in future and to go even further into the depth of the topic.

I would like to draw a conclusion by answering the following question: “Which type of the cloud is safer, the public or the private cloud and why?”

In the public and private cloud, same technologies can be used for server virtualisation. As a result, both types generally have the same technical weaknesses.There are, however, some points which can adversely affect security in the public cloud. These are:

  • The system environment is shared by several users, multiple users though lead to a larger attack area.
  • Resource management is handed to the cloud provider. A threat can be posed, for example, by the employees of the provider.
  • The provider could use unsafe techniques for server virtualisation.
  • There is an unknown and potentially insecure system environment. This differs according to the service model:
    • SaaS: You have to rely on the safety precautions of the supplier. There is no technical influence on the application or the system (except maybe the app settings).
    • PaaS: You should protect the application against an unknown system environment (and, of course, also against external influences).
    • IaaS: The operating system can be influenced by a malicious hypervisor. Similar to PaaS, the application should be protected against threats.

We see the public cloud has a variety of additional attack points in contrast to the private cloud. The cloud providers, however, are professionals and should be able to protect their systems against attackers or a failure respectively. In my opinion, you should weigh whether it is worth outsourcing business processes to the public cloud or not with these issues in mind.

Finally, let’s look at a few points, which I believe the field of cloud security will continue to deal with in future.

The developments of the above-mentioned papers help to protect an outsourced application from an unknown system environment. A problem, however, is that these developments are relatively new and some are not yet publicly available. Examples are SCONE and SGXBounds (which is based on SCONE). Furthermore, according to my findings, there is still no established way to particularly protect applications, according to the type of server virtualisation. This illustrates the relevance of the topic today. Due to the abundance of work, however, we can conclude that much is currently being done to make the systems in the field of cloud computing more secure.

Machine learning in the context of cloud security is, in my opinion, a topical issue. Malware detection software to spot anomalies in system environments are highly in demand. Together with machine learning, techniques can be considered to identify malicious processes, for example, by detecting outliers. But also processes that disguise themselves as ordinary processes must be recognised. There will certainly still be a lot going on in this area in the future.

In addition, the buzzword “zero trust” is also leading the way, according to a trend prediction from Forrester. Zero trust means “never trust, always verify”, on technical as well as on user or employee level. Examples for its importance at user level, are repeatedly confirmed by media reports. But it is questionable how corresponding processes would affect the motivation of the employees.

We can see there is a lot going on in the field of cloud security and the topic is far from exhausted. I hope you could get a basic insight into the topic with these two posts and possibly an interest to go even deeper.

Did you notice areas that I did not cover or do you possibly have different views in certain points? Let me know and write your opinion in the comments! I am looking forward to your feedback!

Thank you for your interest! 🙂

Sources (Web)

Sources that were not stated in the text. All sources were last accessed on September 3, 2017.

Posted

in

, , ,

by

Andreas Fliehr

Tags:

, , , ,

Comments

Leave a Reply