Security Vulnerabilities in Cloud Applications

 

There are a number of cloud-based applications that we use every day, without even thinking about it; the email service, search engines, websites, even our bank application. While some might not categorize the security of their cloud application as important, we beg to differ, since we as users would like to have our personal information secured. For example, imagine an online fitness application that we can log in to in order to view our visits to the gym, our subscription details as well as our personal information like name, surname, and home address. This all sounds great, but how can it implicate the security?
Let’s assume we’re the user of such cloud-based application, but in our free time, we like to learn about IT security, which gives us enough knowledge to gain access to the personal information of other users. Let alone the fact that a malicious attacker might get access to the backend database, where the application supposedly stores passwords, which are not encrypted, but in plaintext. In such circumstances, the hacker will have access to your password and will be able to log into the cloud application in your name; not only that, he might be able to access other websites, where the authentication success will depend upon the user using the same password for other applications. Let’s take a step back and think about the initial statement that security is not important for their business; it might not be, but, because of your application security vulnerabilities, personal information (or even personal identity) of your users might be compromised, which might have terrifying consequences on your user’s lives.

Internet of Things (IoT)

Cloud-based applications normally run in the cloud, but are accessed by the users via different means. Cloud-based web applications immediately come to mind, which have been at the forefront for the last decade or so. They are also understood by most security professionals, since they have been most widely researched and analyzed in the past. This is due to the factor that personal computers are widely used by the people worldwide, but the trend is shifting to smaller devices, like smart phones, smart glasses, smart watches, smart embedded devices, etc. Basically, a lot of ordinary devices are now becoming smart devices, which have connectivity to the Internet, thus laying the foundations of the Internet of things (IoT).
While many companies are striving to make their devices (whatever they might be) smart and connect it to the Internet, there are many security-related issues that we must take into consideration before we hastily rush into buying every smart device. If we think about it, all of the smart devices, including the now old-fashioned personal computer, will sooner or later use at least one cloud-based application, when the connection to the Internet is established. When a web browser is connecting to a web page, it’s actually talking to the server that can be anywhere in the world. The same is true for mobile applications and other applications requiring Internet access regardless of where they are running, whether they are running on a personal computer, mobile device or a smart watch.
If written correctly, the cloud-based applications are programmed once and can be used by corresponding client application counterparts running on any device. We can connect to a cloud chat application via a browser extension or from a specifically written custom mobile application, but the cloud application remains the same. Therefore, it’s self-evident that, since the cloud application is the same, it must contain the same vulnerabilities, no matter how we interact with it. This brings us to the conclusion that finding and exploiting vulnerabilities in cloud-based applications can be done from any device, either from a personal computer or from a mobile phone or any other device, for that matter. The only things that change are tools and techniques available on a device from where we would like to interact with a cloud-based application. While there are many tools available for personal computers, which is only natural, since it’s been with us the longest, we can also search for the same vulnerabilities from our smart phones, but with a somewhat limited number of tools available.
It’s also worth mentioning that, leaving aside the protocols, frameworks, or the programming languages used to run the cloud-based application, the basic types of vulnerabilities remain the same, even though they might be named differently. For example, let’s take a look at session fixation vulnerability: When interacting with our bank application from a personal computer, we usually require a certificate and a password, which is given to the web browser, which authenticates us; the same is true for mobile devices, where the authentication secrets are taken by a specifically written mobile application to authenticate us to the bank application. What both approaches have in common is that if the cloud-based application contains a session fixation vulnerability, we can preset a specific session token of a user, where the client application validates it and consequently authenticates the user. It goes without saying that a session token can be anything and is dependent upon the type of application, but the principle behind it remains the same: A user has some kind of a token, which was validated by the application and can be used by attacker to access the cloud-based application in the name of the user.
We might also emphasize that there exist many vulnerabilities specific to the client that have little to do with the cloud-based applications. Those vulnerabilities are present only in certain hardware devices, operating systems, applications, application configurations, etc. Those kinds of vulnerabilities will not be described here.

Types of Vulnerabilities

Now that we’ve laid the groundwork for the basis of this article, we can describe the types of vulnerabilities present in cloud-based applications. We’ve already shown that the basic types of vulnerabilities remain the same, regardless of the internals of the cloud-based applications, which is why we can start from OWASP Top 10 [2] and provide basic descriptions of the most prevalent cloud-based application vulnerabilities.

• Server-side injection: A hacker can inject his own logic into the application’s backend to get access to sensitive information. A cloud-based application can store a lot of information about users, where an attacker might be able to access not only his own information, but the information of other users as well.
• Client-side injection: In a server-side injection, an attacker injects additional instructions to be executed on the server; in client-side injection he injects the instructions to the server, but they are replayed back to the client to be executed by the client application. This is usually because of an XSS vulnerability in a web application, where a hacker sends a link to the user, who clicks on the link, after which the additional code is executed in the user’s web browser.
• Session management: If a cloud-based application provides authenticated access to users, the user can log in to the application via his credentials. It’s up to the application to provide a secure communication channel (HTTPS) from the client’s application to the cloud-based application. If applicable and where the utmost security is desired, a service can also provide certificate-pinning.
• Exposure of sensitive data: Many cloud-based applications allow you to save data in the cloud, ranging from less to more sensitive information. If storing high-priority sensitive information in the cloud, we have to ensure the data in the cloud is properly encrypted, which can only be secure if the encryption and decryption happens on the client side, prior to sending anything to the cloud.
• Logical mistakes: Many applications that allow authenticated access actually provide limited access to data stored in the cloud. But the application shouldn’t rely only on a user’s session to give access to the data; it should have proper access controls in place to check whether the data being accessed actually belongs to that user. This can often be exploited by authenticating to the application and changing the ID of the arbitrary element to access the element of other users, where the element can be a document, an email, personal information, etc.

• Vulnerable libraries: Many applications use third-party libraries and framework to set the grounds on which they build their own application. While there’s nothing wrong with that approach, we have to make sure the libraries are updated and their functionalities are not exposed to the Internet: only the application functionality should be accessible.

Conclusion

In this article, we’ve explained the concept of a cloud-based application and how client applications communicate with them to do something useful. There are many different devices, such as personal computers, smart phones, smart watches, and any Internet-capable device that communicates with the cloud-based applications via different means. While the means of interaction can differ greatly, the vulnerabilities in cloud-based applications remain the same, but their discovery largely depends upon the client-side technology used.
When testing a cloud-based application for security vulnerabilities that can only be interacted with through a smart phone, whether an Android or an iOS, the vulnerabilities in that cloud-based application are similar. You as a penetration tester or a security consultant have to keep in mind that the security vulnerabilities in such an application are not different, they are not harder, or even impossible to find, but they are the same as if the application provided a web-based interface to interact with its functionalities.
We have to keep that in mind in order to test for security vulnerabilities of non-typical cloud-based applications. For example, a cloud-based application providing input fields to invoke certain functionality, like sending an email to another user, has to have some kind of verification to prove the user is a human, like a captcha. Otherwise, a hacker could write a small program to invoke this functionality over and over and send millions of emails per day. In case a mail service like MailGun is used to send and receive emails through a simple API, the owner of the cloud-based application will have to pay for all of the emails send by the hacker. Now, this could be a critical vulnerability, but can be easily prevented with an implementation of a captcha mechanism to prove to the application that you are indeed a human; this is practically self-evident when looking at a web application and almost any security professional will identify and report it to their customer.
The problem arises with a mobile application, which could implement the same input fields without the captcha mechanism, because it isn’t customary for a user on a mobile device to fill out any captcha forms. Remember that captchas were also not used back in the early days of world-wide web, but have now become an essential part of many web applications to enhance security. To make matters worse, many developers don’t even realize that a hacker can intercept any network traffic and replay it, even outside of the application, but if a mobile application signs every request sent to the cloud-based application, a hacker can also inject himself into the mobile application at runtime and send the requests from inside the mobile application, which would sign every request for him. Therefore, a cloud-based application should verify how many requests have been sent from the same client, regardless of the type of application being used, and after a number of consecutive requests, ask the client application, a mobile application in this case, to display a captcha to the user to fill out.
We have to keep in mind that a hacker can control any client-based application, regardless of whether they are running in his web browser in the form of web application or in a mobile application. The vulnerabilities in cloud-based applications are the same and can be exploited form any client application, only the tools and techniques can greatly differ.

1. References

[1] The top cloud computing threats and vulnerabilities in an enterprise environment: http://www.cloudcomputing-news.net/news/2014/nov/21/top-cloud-computing-threats-and-vulnerabilities-enterprise-environment/
[2] Top 10 2013-Top 10: https://www.owasp.org/index.php/Top_10_2013-Top_10

SHARE

Dhirendra Biswal

Hi. I'm Dhirendra The Admin of this Blog I'm A Certified Ethical Hacker also a Web Developer With Programming Skills in various Programming Languages.

• 
• 
•