Cybersecurity Project

Introduction

In this project, there was a list of cybersecurity focus areas to choose from. Examples are insecure protocol and application attacks. The focus area that I selected was was password attacks, and one CVE that I chose to base my solutions on was CVE-2020-10102.

Details of the CVE-2020-10102 can be found here.

There were 2 main issues that I identified from this CVE:

(1) Incorrect configurations

Attacker can easily create a list of valid emails because invalid emails entered will render a “no such email” message.

(2) Brute force with no additional authentications

Without multi-factor authentication, the attacker can simply gain access to an account with just a valid email and password combination.

My team mates implemented other solutions for this project. The overall security architecture is shown below, with the boxed section highlighting my responsibilities for this project.

Summary of my solutions

The project also required integration with my other teammates, so I incorporated Azure SMB File Share Authentication into my project.

Summary of my solutions:

Web application with multi-factor authentication
Azure SMB File Share Authentication
Suspicious Access Incident Response
Suspicious Access Playbook
Azure Virtual Machine Resiliency

Solution #1: Web Application With Multi-Factor Authentication

The web application is developed using Python, Javascript, and HTML. It uses the SQLite database to store credentials for simple email and password authentications.

To use the application, the user has to register for an account before being able to log in.

REGISTRATION

Email and password check

When a user registers, the application will check that it is a valid email that includes the “@” symbol.

For passwords, it will use a password policy which checks that the following criteria are met:

At least 7 characters long
Contain at least a small alphabet
Contain at least a big alphabet
Contain at least a digit
Contain at least a special character

Saving of TypingDNA typing pattern

After the user email and password has been checked, the application will proceed to register the user and save the typing patterns. As a best practice stated in the TypingDNA API documentation, the application will save at least 2 typing patterns. However, from past testing, the application would usually save 4 typing patterns during every registration.

Username and password

The first level of authentication is the username and password.

When a user enters the email and password, the system will check that the credentials match, before proceeding to further authenticate the user.

If the user enters the correct email and password combination, the application will proceed to check if the correct user is logging in through TypingDNA’s API, which will be discussed below.

If the user enters a wrong email and password combination, or an invalid email, the application will return the error “Not Authenticated”. This message does not let the user know if the email exists or not, which makes it difficult for the attacker to come up with a list of credentials to brute force the application.

TypingDNA API (Innovative Component)

The second level of authentication involves the use of TypingDNA’s API. This API uses the typing patterns saved for the user during registration to check if the correct person is logging in.

The idea behind this API is that users have different typing patterns. Hence, if user A is trying to log in as user B, and even if user A has the correct credentials for user B, the authentication will fail. This is because user A will have a different typing pattern from user B.

To implement the TypingDNA API, I first included the typing recorder Javascript file in the front-end of the application to collect typing patterns from the end users. Then, the collected typing patterns are submitted to the API for enrolment or analysis, along with a User ID. Patterns submitted will be intelligently handled as enrolment or verification attempts depending on the context of the request, whether previous enrolments exist, and if there are sufficient typing patterns saved. The TypingDNA authentication API will then return a verification or enrolment JSON response, which includes an accuracy score.

A best practice followed is the idea of saving at least 2 typing patterns upon registration, as mentioned in the TypingDNA API documentation.

Regardless of whether the user’s typing pattern has been authenticated, the user will be asked to authenticate using OTP authentication. I have implemented OTP to be compulsory because I do not wish to solely rely on the typing patterns.

One-Time Passcode (OTP) Authentication

To implement OTP authentication, I used the python module PyOTP.

This module offers 2 ways to generate OTPs:

HMAC-Based One-Time Password Algorithm (HOTP)
Time-Based One-Time Password Algorithm (TOTP)

I used TOTP to generate my OTPs. After that, the OTP is sent to the user through email using MailTrap, which is a mail testing tool.

Based on the NIST Special Publication 800-63B (5.1.4.1 Single-Factor OTP Authenticators), OTPs should only be valid for 2 minutes, which is the expiry time that I have set for my OTPs.

To successfully authenticate with the OTP, the user has to submit the correct OTP within 2 minutes since the generation of the code.

reCaptcha

An additional feature in the web application is reCAPTCHA. This is included in the login and sign up pages.

Based on OWASP, one way to prevent automated attacks is implementing CAPTCHA, which helps to distinguish between humans and computers. Hence, CAPTCHAs are effective in stopping any kind of automated abuse, including brute-force attacks, which is part of the CVE that I have chosen.

Solution #2: Azure SMB File Share Authentication

To implement it, I first created users in the Azure Active Directory, then assigned these users to groups. Next, I created the Azure Active Directory Domain Services and a Windows 10 Azure Virtual Machine. The virtual machine will be joined to the domain.

Before testing the authentication, I assigned roles to the groups created in the Azure Active Directory at the start.

The table below shows the 2 main roles I used and their respective permissions.

To connect to the file share created in the Azure File Storage Account, I had to run the following command in Windows Powershell for each user.

Solution #3: Suspicious Access Incident Response

To monitor and get alerted when there are suspected risky users, I used the Azure Active Identity Protection feature. The users in the Azure Active Directory (default directory) were used in this incident response.

First, I set configured the user risk policy to be applied on all users.

By enforcing the policy, users with a risk level of low and above will be blocked from future access.

The incident response flow followed by the Azure Active Directory Identity Protection feature is based on the playbook for suspicious access, which is shown as solution #4.

Solution #4: Suspicious Access Playbook

The playbook describes the actions that should be taken in the event a suspicious login event has been detected. To simulate an incident, a test case has been included below (in the test cases section).

The main flow of the playbook is that tier 1 analysts will first analyse traffic and be alerted of any login activities from anonymous IP addresses. Once the user account has been alerted to be a risky one, it will automatically be blocked from future login attempts.

Tier 2 analysts will then continue to investigate the event using the logs captured. If the user account has been confirmed to not be compromised, the account will be unblocked. If the user account has been confirmed to be compromised, the account will remain blocked.

If there are any suspected changes made to the system, the company’s senior manager should make the decision to restore backups.

For post-incident actions, the company may want to review their access control policies to ensure that they are up to date. They should also analyse the actions taken during the incident and think of ways to improve.

Click the icon below to view the playbook.

Solution #5: Azure Virtual Machine Resiliency

If an attacker manages to successfully gain access to the target host and make configuration changes to the computer, it can affect other hosts in the same network. Hence, backups are crucial in restoring old configurations that the target has originally set.

To implement Azure virtual machine resiliency, I used the Azure virtual machine backup feature.

The screenshot below shows the policy set for the backup activity.

Description of policy

The virtual machine should be backed up every day at 11.30PM.

Every time a backup is successful, there will be alert saying so. A test case below shows the confirmation message that the virtual machine was backed up successfully.

Summary of Test Cases

After implementing the solutions, it is important to test that they work. The following tables summarise the test cases

Security Review

Security Testing

Integration Testing

Key Takeaways from this Project

My past projects have all been focused on creating a new solution. However, this project module required me to use a currently available solution and integrate it with my team's security architecture.

Easily, many would go straight to implementing a web application firewall, however, because I wanted my solution to be innovative, I went looking for more unique APIs that are not popular yet.

One way to make things innovative was through machine learning, which was exactly what TypingDNA used. Their API was straightforward, but because I had not done it before, integrating it with my own work was the tricky portion.

Through guidance from Google and YouTube, I managed to produce a working login page with 3 authentication requirements - username and password, TypingDNA, OTP (and reCaptcha!).

I hope to incorporate more machine learning into my security solutions in future!

CSPJ Key Takeaway