Security Solution

The goal of this project is to deploy a security solution for a cloud-based organization.

See here for more information on the organization's structure.

This solution focuses primarily on the prevention of Distributed Denial of Service attacks and common web application exploits.

Issues & Solutions

Here we establish current vulnerabilities of the organization.

SQL Injection

SQL injection occurs when an attacker submits malicious SQL queries into a user-interactable text-field tied to an SQL table. This can be used to add, see, change, or delete items in the connected table and so is important to prevent.

On the customer service page of the organization, the user may submit their email and list an issue they've been having. We can use SQL injection to alter the values of previous tickets. See the original php code below.

$conn->query("INSERT INTO help_tickets (email, issue) VALUES ('$email', '$issue')");

Say when we process the 'issue' part of the submission, we limit it to 200 characters, and we do this to manage how much space ..... COME BACK TO

Solution

Botnet Attack

A botnet attack is a type of Distributed Denial of Service attack in which an attacker recruits a network of "zombies," or systems that the attacker has gained control of in such a way that they may coordinate those systems to generate an inordinate amount of traffic to a web server. The botnet devices will often continue to operate as normal for month until they are "awakened" and begin sending high rates of requests to a singular web server or a group of webservers owned by the target. This overwhelms the web server, either causing it to crash or taking up so much space that those who are not in the botnet (actual users) can no longer access the site. This could also be used to submit an overwhelming amount of fake help tickets or sales, drowning out our actual users and rendering our data useless. When we are overwhelmed by an amount of requests, that is called resource exhaustion.

Solution

The goal of this solution is going to be to make sure that anyone who visits our site is an actual user and to prevent unwanted traffic. We will do this by setting up a Captcha System through AWS WAF which will require all users pass through a Captcha before actually getting to our website. Thus, connections without a human entity behind them will fail to reach our site and input poor data or overwhelm it. W

1. We first set up our Web Application Firewall Access Control List as shown here
2. Navigate to the Rules tab of your Web ACL
3. Click Add rule and create your own rule
4. Name your Rule something like "CAPTCHA_ALL"
5. Change "If a request..." to (OR)
6. Add in the following configuration in order to capture all traffic:
7. In the action section, select CAPTCHA.
8. Select "Custom Immunity Time for This Rule" and lower it as much as it will go. For me, that was 60 seconds.
9. Create the Rule
10. If we try to visit the website through the load balancer's DNS name now, we will have to pass a CAPTCHA to use the website.

Spoofing Attack

Spoofing attacks are a type of Denial of Service attack in which an attacker sends web packets to a server, but instead of putting their IP address into the packet source information, they put a victim's IP address. The attacker sends a ton of web packets to the server, which when they are responded to get sent to the victim's IP, overloading their system and either causing it to crash or prevent it from receiving other requests.

Amplification Attack

An amplification attack is a type of spoofing attack that refers to a specific type of request-response relationship. Here we are looking at a small request which generates a large answer. This could be something as simple as requesting a massive file located in the server and sending thousands of responses to the victim's IP containing this huge amount of information. This will quickly overwhelm the victim and use up all of their bandwidth, known as bandwidth exhaustion.

Solution for Spoofing & Amplification

In the case of Spoofing and Amplification attacks, the malicious responses are typically coming from one or just a handful of servers. We cannot prevent the malicious requests to some other server from being made, but we can limit the responses we receive -- or at least how quickly we receive them. By limiting the amount or frequency of packets sent to our web server, we can spread out the huge amounts of data we receive into a manageable time frame.

Let us examine the behavior of our website before implementing our solution. You may have to disable the earlier CAPTCHA rule by temporarily changing it's action from 'block' to 'count'.

We will be using the "loadtest" tool to simulate a DoS attack like Spoofing and Amplification.

1. In the termminal of an ec2 instance, download npm sudo yum install npm
2. Install loadtest sudo npm install -g loadtest
3. execute the following, replacing DNS_NAME with the DNS name of your load balancer loadtest -n 9000 -c 1 --rps 200 http://DNS_NAME

This command sends 9000 requests one time at a rate of 200 requests per second and gives a report of responses to those requests as well as latency. Executing the above command should give us an output like this: Observe that there are 0 Errors, meaning that all requests were successful connections

We will make use of AWS WAF created in the previous section to introduce a rate-limiting rule.

1. Navigate to the Rules tab of your Web ACL
2. Click Add rule and create your own rule
3. Name rule something like "rate_limit_all"
4. Select "Rate-based rule"
5. Set your rate limit to 200 and your evaluation window to 2 minutes.
6. Keep all other settings at default.

Now execute the same loadtest command from before and observe the output:

A majority of requests are now blocked, so our rate-limiting tool is successful.

XSS

Cross-site scripting is a type of web application exploit in which an attacker injects malicious code into an otherwise trustworthy website, typically so that it executes on another user's machine. Any part of a web server with user-input that is not validated or normalized is at risk to these attacks. There are two types of XSS or cross-site scripting: reflected and stored. Reflected XSS executes and appears immediately after it is submitted. This could be as simple as an alert appearing on the user's screen or redirecting them to a malicious site. For the purposes of this project, we will use reflected XSS on our self rather than a different end user. Stored XSS is javascript stored in a database such that it executes when that item is retrieved from the database.

Reflected XSS

In this case, we will be using the below javascript enclosed in html <script> tags to redirect the user to this site. On the submission page, php script here displays the user's email back to them, but it does not validate that field at all, so we can enter some javascript in the email field as shown below.

<script>window.location.href = 'https://github.com/shselbst/DDoS-IPS/wiki/Security-Solution';</script>

It is difficult to show here, but when the user presses submit, they see the submitted ticket screen for a brief second before being redirected to this page.

Solution

The solution for this is incredibly simple and can be done in less than one line of code. The method htmlspechialchars takes some string as a parameter and replaces all instances of html significant characters like "<" and ">" with HTML entities, or string representations of these characters. Thus, our script above won't actually be rendered as javascript since the "<" and ">" will not be picked up by the HTML.

We replace this line in submit_ticket.php

$email = $_POST['email'];

$email = htmlspecialchars($_POST['email']);

Now instead of being redirected we see the following on the next page:

Stored XSS

Solution

Breach of Confidentiality of Financial Info

Breach at Rest

Solution

Breach in Transit

Solution