Website hacking is one of the most common types of attacks. If you are interested in how sites get hacked and what you need to pay attention to protect your resource, this article is for you. Here I will go through the beginnings of web application penetration testing and show examples of how to check a site for vulnerabilities.
As of July 2020, there are 1.74 billion websites on the internet, and many of them are vulnerable. A decade ago, a study by the Web Application Security Consortium showed that at least 13% of sites can be hacked automatically. And in a recent study by Positive Technologies, 19% of tested web applications are vulnerable. A really huge field for attackers to act!
How to check a website for vulnerabilities
By structure, the sites are divided into three main classes:
- self-written (handmade in HTML, produced by a static generator like Jekyll, or assembled in a design program like Adobe Dreamweaver);
- made in online builders (mainly business card sites with no databases or transmitted fields)
- working on CMS (content management system, content management systems) already done.
There are also homemade CMSs built for a specific site, but now this has become a rarity – only the largest resources can afford to support your system, and the costs associated with this are not easy to justify.
Most modern websites are built on pre-built engines. For example, our site is no exception: it runs on the popular WordPress system (at least for now, in 2020).
From an attacker’s point of view, site engines are no different from other services and services. Its source code is usually publicly available and can be scanned by any researcher for errors, including security holes. Therefore, CMS sites are rarely the victims of targeted attacks. Most often they break down en masse.
Such hacking is automated and is usually done according to the following scheme: the attacker finds a vulnerability (by himself or simply Google something new). Then make an exploit or take a ready made one and write a specialized bot. This bot searches for the specified hole on all sites in a row in the specified range and tries to exploit it.
It would seem that to protect against automated attacks you just need to keep the software up to date, but in reality the CMS is packed with various plugins and it becomes difficult to keep track of all of them.
Pentesting has a slightly different task: checking a specific site for vulnerabilities. We will talk about this.
Collection of site information
Before attempting to attack a target, you must gather information about it. The WhatWeb tool works well for this. This utility provides detailed information about the victim’s CMS and the web tools it uses.
I advise you to start WhatWeb with the -а switch, followed by the value 3 or 4. The only difference between them is that in the second case WhatWeb will also scan subdirectories. Note that both options establish an aggressive polling method, with all subsequent logs, or rather “flowing” to the server.
Here is an example of responses running and collected:
Here we can see that this is a UK company website made in WordPress, using PHP v. 7.1.33 and jQuery 1.9.0, 2.2.3. It was not a bad start!
If you don’t have a VPN, or just don’t want to bother installing it, check out the online version of WhatWeb.
By the way, when working with foreign sites, it provides great speed.
If you only need to define the name of the CMS, there are separate services for this, even Russian-speaking ones.
Here are the latest statistics on the popularity of various CMSs on the Internet:
- WordPress – 58.12%;
- Joomla – 17.12%;
- OpenCart – 4.65%;
- Drupal – 3.75%;
- Wix – 3.74%;
- MODX Revolution – 2.81%;
- MODX Evolution – 2.76%;
- Nethouse – 2.23%;
- others – 4.78%.
Checking the WordPress site for vulnerabilities
Since WordPress is the most popular CMS right now, let’s jump right into it. A very powerful scanner that can do magic has been released: WPScan. At the time of writing this article, the current version was 3.7.8. This scanner can determine the version of the scanned object, brute force the admin panel (it even has its own built-in dictionary), look at vulnerable open directories, determine installed plugins, and much more. Also, it comes pre-installed on Kali Linux and other distributions for pentesters. There is even a Docker container version.
In my opinion, the control and keys of WPScan could be simplified. Even the program has two help – short (-h) and detailed (-hh).
Before using WPScan for the first time, you need to update its database.
After that, we started scanning. On its own, keyless WPScan will provide general information about the site, only superficially scanning the target.
wpscan --url http://example.com
After the line Interesting Finding (s): the very points that you should pay attention to begin:
- WP version;
- open directories;
- suspicions of vulnerabilities;
- links to resources where you can read about these vulnerabilities.
At the end of the output, a red exclamation mark marks lines that violate security rules. In our case, this is the wp-config.php configuration file sticking out with the login and password to the database.
We continue to investigate and, using the same software, we try to reset the admin panel username and password:
wpscan --url http://[IP-address] --passwords pass.txt --usernames user.txt
Brute force is very fast due to multithreading. If the admin used standard accounts and set simple passwords, then the result will not took too long to come.
Checking sites for vulnerabilities. Found credentials
As you can see, we got the credentials for the admin panel and the database without much difficulty. This would be more than enough for the average cracker, but we haven’t checked everything yet. The following are the WP plugins and other popular entry points.
The crawler showed us that the selected site does not have any plugins installed, however this may be a false conclusion based on the limitations of the passive crawling method. For more reliable plugin detection, you should set an aggressive search method:
wpscan --url http://[IP-address] --enumerate ap --plugins-detection aggressive
Note that the ap key will show all found plugins, while vp will show only the vulnerable ones. This procedure is time consuming. The speed will depend on the distance from the site, but even in the best case it will take at least 30 minutes.
As you can see, the aggressive method produced results: version 3.1.1 of the Akismet anti-spam plugin was detected.
Akismet Plugin v3.1.1
Exactly the same actions should look for other vulnerable plugins for WP. Read more in the manual under — list.
See also Known vulnerability identifiers: CVE. For example, for the PHP version the CMS is running on. Then find prebuilt Metasploit modules for WP and test them in action. I highly recommend reading the detailed article on how to protect WordPress.
Checking a Joomla site for vulnerabilities
Joomla is also quite a popular CMS, for which there is a scanner: JoomScan. It was written by the guys at the Open Web Application Security Project (OWASP). It’s still relevant, although it hasn’t been updated for a long time. The latest version 0.0.7 was released in September 2018.
In essence, it is the exact same security scanner as WPScan, only a little simpler. JoomScan is also pre-installed on most security professional distributions, and its entire manual fits on a few lines.
It also supports an aggressive scanning method for installed components. The command to start scanning in aggressive mode looks like this:
joomscan --url http://220.127.116.11/ --enumerate-components
Below is an example of an analysis of an old and leaky version of a Joomla site found on the Internet.
Checking for vulnerabilities on the Joomla site. JoomScan
As you can see from the screenshot, the program displays the CMS, CVE version of the found vulnerabilities and links to exploits that can be used to hack the site. The output also contains all the directories found on the site and a link to the configuration file, if you forgot to hide it.
JoomScan doesn’t know how to brute force the admin panel. Today, to perform such brute force, you need a serious tool that works with a chain of proxy servers. If only because Joomla sites often use the brute force stop plugin. When the number of failed login attempts reaches the specified number, it blocks the attacker’s IP address.
If your Joomla site runs on HTTP (which is already rare), try using the Nmap script.