Cloud Computing Security Research

CLOUD COMPUTING SECURITY RESEARCH

Abstract

Cloud computing is a quicky advancing technology which is based on service provision to consumers in all markets such as security and government. It has high promises to the public and business the desire to attract large number of users in the rapidly growing environment. With high growth in cloud computing, many challenges and issues associated with this technology are bound to arise. Many are security concerns, and this is a dynamic field for research that requires proper investigation to prevent of any risks and security breaches that are looming dangers for users and providers of the service. Cloud computing has many benefits and security threats that need to be averted through security implementation. This paper majorly focuses on current case studies challenges which are being faced to inspire more research on the topic. It highlights design principles including the analysis of attacks and threats as well as how to avoid them and address of foreseen challenges.

 

Keywords: Transport Layer Security (TLS); Certification Authority (CA); Secure Sockets Layer (SSL); Infrastructure as a Service (IaaS); Software as a Service (SaaS); Platform as a Service (PaaS)

 

Introduction

This technology is a convenient, cost-efficient platform for the provision of businesses and consumer services across the internet. The services can vary from storage of data, processing as well as software services. This can be compared to early connectivity of electricity where homes opted to be connected to a greater power grid with many utilities as compared to production of their own power. In the long run, this became a cheaper option as well as time-efficient with the assurance of higher reliability. Equally, cloud computing offers scalable resources which are provisioned over the internet and this gives the assurance of many economic benefits among those who opt to have it implemented. There are many applications that thrive in the cloud computing environment. They include instant messaging, web content management and email services. With this technology, it is easier to cut down cost on additional hardware that may be required in other cases to support a device in the network without having to alter the user’s viewpoint. Users can team up with others and this way they are able to avoid any future hardware or software dependent costs that may arise in this highly dynamic trend.

The cloud technology can be classified into 3 distinct layers. The bottom layer which is mostly known as IaaS comprises of basic infrastructure parts including memory as well as storage. In the middle is the PaaS that allows for the usage of hosting habitats such as for Java and Python based applications. The layer at the top is Software as a Service. It gives users the privilege of readily available applications [1].

The key role of this layer is to cut down on capital expenditures. The amazing benefits come along with concerns more so those to do with security guaranteed by this level of technology. In this paper, I will be focusing on an overview of security and issues related to it in such environments. This ranges from real-world examples to those which are being anticipated.

Largely, this paper follows the format outlined below. In the second segment, major technologies and security used in this environment. In the third section, security-related issues are clearly outlined and discussed. The fourth section is on the conclusion as well as providing future recommendations for Cloud Computing Security.

 

Chapter 2 (Technologies Used in Cloud Computing Environment)

  1. Transport Layer Security (TLS)

It is frequently referred to as Secure Sockets Layer (SSL). It is divided into 2 parts. TLS handshake authenticates the server and desirably the user [3]. Record Layer is used to encrypt or decrypt TCP data streams with the aid of algorithms and keys. TLS has multiple alternatives for agreement of keys, encryption, and authentication. The ones that are mostly used are:

  1. The browser itself. The browser is always anonymous in this configuration. To authenticate the user, the server requests for a username/ password through a html form.
  2. During handshake of TLS, the browser receives certificate from the server. The browser is tasked with ensuring the issued certificate is from a validated Certification Authority (CA). This means that the name of domain contained in the URL requested matches those in the certificate. In the occurrence of a challenge, a security question is asked to the user.
  3. 509 certificate, which has a domain name, is used to configure a web server. The certificate ought to be from a validated CA.

This configuration worked okay when used by web applications until there was an emergence of phishing attack. This is where a user is lured to a fake web page through attacks on the DNS and spoofed emails. This prompt one to enter their username as well as passwords.

 

  1. WS- Security

It outlines the way to provide integrity, confidentiality as well as authentication for SOAP messages [5]. This outlines how existent XML Encryptions and Signature are used in the messages. Through encryption of the fragments brings about data confidentiality. XML Signature permits the fragments to be signed in a digital way thus ensuring authenticity.

This technology also clarifies tokens of security that are adopted for transfer of digital identities.

 

Chapter 3 (Security Issues)

Outlined in this section are some security issues associated with cloud computing. Real-world and potential effects of the issues are as well put into perspective.

  1. Browser Security

Here computation is performed on remote servers. It is more sensible to develop universal stand-alone mechanism for I/O rather than platform dependent software [3]. The user’s PC is used mainly for for authentication purposes as well as authorization of instructions to the cloud. Modern browsers with XMLHttpRequest and Plugins AJAX techniques are well built for I/O. The key consideration is security. Concentrating on Same Origin Policy multiple defects of the security are outlined in this document. Considering TLS used for authentication and encryption, the defects are more dominant. Web navigators cannot utilize XML Signature or Encryption. Signatures are applicable in the TLS handshake and can be encrypted through TLS. The web navigator only serves as passive data storage.

The goal now is to propose a secure solution with the aid of TLS while encouraging users to accustom cryptography for augmentation in browser hub.

  1. Legacy Same Origin Policy

Including scripting languages in Web pages necessitated definition of access for the scripts. The open option is to permit read/ write operation on content than have similar origin while not permitting those from a different origin. Legacy same policy does this. There are multiple cases where where challenges with SOP come up such as in the WWW. Dan Kaminski in 2008 proved that Domain Name System (DNS) caches can be simply intoxicated with bogus data. Domain names can be unreliable since DNS relies on caching. To achieve reliability, such an attack can only be fixed through UDP source port randomization. Other challenges with DNS are in home routers and such an attack makes content to be unreliable until they are secured by other means. TLS has been used for data protection during transport together with authentication of servers’ domain name. Such issues became probable with the onset of phishing attacks on banking online.

 

  1. Browser-based Cloud Authentication Attacks

Federal Identity Management Protocols within the browser can expound on the knowledge of the security crisis within the browser. This is because the navigator on its own cannot generate cryptographically valid XML tokens for authentication against the Cloud. For this, a trusted third party is inevitable.

Microsoft’s Passport, which has been broken by Slemko, is the prototype for these protocols. If there is no possibility of direct login at a server due to missing required credentials, redirect can be sent to the server, where the user keys in credentials such as username and passwords. Another HTTP redirect sends this to the requesting server. In case an attacker gains access to these tokens, all services of the user are at risk. Currently majority of protocols used in authentication are insecure. This is because the browser cannot issue XML based security tokens on its own. FIM systems keep security tokens where they can receive protection via SOP.

  1. Secure Browser-based Authentication

With the integration of SOP and TLS properly, FIM protocols are secured [7]. With the aid of TLS In order to protect (SAML) tokens, we can use the following methods.

  1. Strong Locked Same Origin Policy

This is based on making the client strong so that he can make dependable security choices. It is implemented using server’s public key and not DNS which is insecure.

  1. TLS Federation

SAML token sent inside an X.509 client certificate replaces other identification information such as names. The validity period of the certificate is same to that of SAML token.

  1. Holder-of-Key Assertion Profile

TLS with client authentication is put into use without the client certificate transporting information about authorization.

  1. Session binding of TLS

By binding, the token to a certain TLS session the server may presuppose that data he sends in response to the SAML token will still be protected by the same TLS channel.

  1. Future Enhancements on Browser

Despite the success in using TLS, it remains confined in its abilities a center for authentication. It is impossible to add a Signature or Encryption through packing an applicable JavaScript library at the time of runtime since the keys require higher protection. To make this possible, two enhancements are key.

  1. XML Encryption: No information on XML is important. Only a stream of byte is to be encrypted or decrypted. A naming scheme crucial for retrieval of cryptographical keys “behind” API should therefore be stipulated.
  2. XML Signature: This is relevant since the data structure of XML Signature is reviewed in the API. Here a fix for XML wrapping attacks also plays a part.
  3. XML Signature

This Element Wrapping is a properly identified attack on protocols, which uses XML Signature for protection of authentication and integrity. This as well is the case for Cloud Computing. Figure 1 and 2 illustrate the idea of this intrusion.

Figure 1: SOAP message whose SOAP body is signed.

Figure 2: SOAP message after attack

In figure 1, a SOAP message is dispatched by a legitimate user. It is about a call for “me.jpg” file. The sender signed this, and it is confined in the SOAP header. Through eavesdropping the message, the attacker can launch an attack. A new body is created after the initial one is transferred ed to a new developed wrapping element. The now established body carries the operation, which the attacker intends to launch in the initial authorization; in this case it is the requisition for “cv.doc”. The service request is executed since the message that is a result of this still has a valid signature of the legitimate client.

Many countermeasures against these measures have been put in place since the discovery of these attacks. Inline approach is one of the methods. Its creation was such as to enhance protection of some features of SOAP message format thus preventing wrapping attacks. Later, this approach was rendered obsolete as the attacks could still happen. Because WS-Security was rarely being used in business applications, attacks were more theoretical. This was only so until a real-life wrapping invasion became publicized in 2008 when Amazon’s EC2 services became vulnerable to these. The attacker performed an EC2 operation was performed using a variation of the attack. A signed SOAP request by the genuine subscriber was intercepted. SOAP validation allows for this kind of operation to interfere. Infestation of a group of virtual machines for them to send spam mails manifests that the attacker can launch an attack on a legitimate client’s account and change it.

  1. Flooding Attacks

A great feature of Cloud Computing comprises of sourcing primary operational roles to a Cloud system service provider [2]. Among the primary roles is the maintenance of server hardware whereby rather than running an individual data center users can rent the hardware on demand (IaaS). This in the long run has financial benefits. This environment facilitates a changing adaptation of hardware requirements based on the workload. If the demand by users rises, they are given more avenues of access to virtual machines for the services. This has a serious effect in terms of security. By giving more computational power in the presence of an attacker, chances of flooding attacks are increased. The attacker can send many folly requests to a certain service to the service implementation which needs to have them processed in order to determine validity. Workload increases in case of an attack and this mostly would result in a Denial of Service to the hardware.

The effect of such an invasion is expected to be intensified exceedingly as a result of the effects discussed below.

  1. Direct Denial of Service

More computational power is provided if the cloud computing OS notes higher call of duty on overwhelmed service. This makes it hard for hardware boundaries to process. This way the OS tries to prevent invasion through increasing computational ability while giving him more freedom to alter service provision. By attacking a given target service, the attacker causes total loss of requested service.

  1. Indirect Denial of Service

A cloud service supported by the attacked hardware may indirectly suffer because of workload created by flooding. If it happens that a service is running together with the flooded service on a shared server, its availability is also influenced. Denial services on targeted services can result in the same effect on services that are deployed on the shared server. Relying on how sophisticated the environment is, the resultant effect can get worse if the OS notes that there is limited availability and thus it struggles to redeem affected services to have the transferred. Obviously, this leads to increased workload on the standby servers. It goes without saying that the flooding attack is as well transferred. Multiple jump overs may end up transferring to many servers in this environment.

  1. Accounting

The major intention behind cloud computing is to charge customers according to the workload they have caused, their usage. Flooding attack can raise the bill for usage direly. The user who is responsible for the flooded service gets in trouble for having to pay the bills caused by the attacker.

 

  1. Integrity of Cloud

The great duty of any Cloud Computing OS is to ensure virtual machines are well organized and coordinated. When a service is requested for by a user, it determines and finally offers the requested service for implementation. This task relies on data embedded on the implementation modules of the service. This may be inclusive of description documents of the associated service. Majority of the descriptions are needed before service request by a specific user. This regulates how relevant a service is to accomplish an explicit purpose.

  1. Metadata Spoofing Attack

Its goal is to reengineer metadata descriptions of services on the web in a malicious manner. For example, an attacker may do modification of WSDL of a given service resulting in requesting an operation such as setAdminRights instead of an operation to delete a given user. In the event that a client gets handed this tweaked WSDL document, all operation calls related to deleting a user will lead to SOAP messages which look like the other and at the server side they will be enacted as invocations for the operation of setAdminRights. Finally, the attacker gets the ability to duplicate multiple client logins, which may seem to have been annulled by semantics of the application. The reality is, they are still valid. On top of this, they are given administrator level access rights.

This kind of attack can be hard for the attacker to implement in Static Web Service invocations since extraction of service invocation code from WSDL happens only once. This is during the generation of the client’s code. It can only be successful if the process is interfered with. Also, the chance of the invasion being identified more so in the existence of sound testing techniques is assumed to be high. Such restrictions tend to be lowly considered in Cloud Computing environment.  The system has WSDL repository functionality where majority of the users more zestfully request for a WSDL file. This way, the chances that an attack will be successful are increased.

  1. Malware Injection Attack

The goal of this attack is to introduce a vicious service implementation into the cloud environment [2]. This malware can do full changes and blockings as well as eavesdropping. The attacker adds to the system the malicious service implementation module (SaaS or PaaS). This can also be a virtual machine instance (IaaS). Through tricks, the cloud service is duped to treat this foreign service as new valid requests for a given service. With this success the valid user gets redirected to the implementation of the malicious service.

A countermeasure to this can be performance of service integrity checks before using a service for upcoming inquiries. A hash value can be stored on the image file of the original request instant. To navigate this, the attacker needs to have a hash value comparison so as to be able to inject into the system a malicious program.

 

Conclusion

In this paper, I have outlined part of concerns related to Cloud computing. I took the initiative to investigate ongoing challenges with regards to XML Signature and the Web Services security structures. I also delved into the strengths of navigator security in the context of Cloud Computing as well as integrity of cloud service.

It is clear that there are many threats  to the security of this technology, and they need thorough scrutiny of the potential effects and their application in real computing scenarios. From my observation, to continue improving on cloud computing security, there is a need to strengthen its security capabilities [1]. This is for both web service frameworks and web browsers. Part of our contribution in this ongoing work is to strengthen foundations of this environment that have been put in place by the underlying tools, specifications, and protocols.