Hack the web! Checking web sites for vulnerabilities and exploiting them

Hacking web sites is one of the most common attack types. This article is dedicated to such attacks and protection against them. I will address the pentesting basics for web applications and explain how to deal with popular web engines using real-life examples.

As of January 2020, there were 1.74 billion web sites on the Internet, and a large share of them are vulnerable. Ten years ago, the Web Application Security Consortium has demonstrated that at least 13% of the sites can be hacked automatically. Positive Technologies recently published a study entitled Web Application Vulnerabilities: Statistics for 2018; according to it, 19% of the tested web applications were vulnerable. What a great opportunity for malefactors!

Hacking web sites: General principles

By their structure, web sites are divided into three large classes:

• custom-made (sites created manually in HTML, generated by a static generator (e.g. Jekyll), or assembled using a web development tool (e.g. Adobe Dreamweaver));
• created using online tools (mostly advertising sites not containing databases or transferable fields); and
• based on premade Content Management Systems (CMS).

Sometimes, you may encounter a custom-made CMS created for a specific web site; but such phenomena are extremely rare nowadays. Only a major web resource can afford the maintenance of its own system.

The majority of modern sites use premade engines. HackMag is not an exception: it uses the popular WordPress system.

From the attacker’s perspective, site engines are not different from other services. In most cases, their source codes are publicly available; and everybody can check such a code for errors and vulnerabilities. Therefore, CMS-based sites rarely become victims of individually targeted attacks: normally, they are hacked en masse.

Such massive attacks are automated and follow a simple scheme: the hacker discovers (or Googles) a vulnerability, creates an exploit (or takes a premade one), and writes a specialized bot. The bot searches for a specific vulnerability on all web sites within the preset range and tries to exploit it.

In theory, to protect your site from automated attacks, all you have to do is update the software on a regular basis. However, in reality, CMSs are often supplemented by various add-ons, and it becomes increasingly difficult to patch all the possible holes.

Pentesting has a different purpose: check a specific web site for vulnerabilities; this is exactly what this article is about.

Information collection

Prior to an attack, you have to collect as much information about the target as possible. For this purpose, I recommend WhatWeb: the utility provides detailed information about the CMS used by the target site and its web tools.

Launch WhatWeb with the -а key and specify the value after it: 3 or 4. In the latter case, WhatWeb will scan subfolders as well. The both variants enable the aggressive scanning mode, including the retrieval of all incoming logs received by the server.

Below is an example of the program launch and output:

As you can see, this site belongs to a British company; it is based on WordPress CMS and uses PHP v. 7.1.33 and jQuery 1.9.0, 2.2.3. Not bad!

If you don’t have a VPN or don’t want to spend time on the utility installation, use the online version of WhatWeb.

With some sites, it works even faster.

If you need just the CMS name, use specialized services, for instance, WhatCMS.org.

Below is the recent statistics showing the popularity of various CMSs:

• 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%; and
• others – 4.78%.

WordPress

WordPress is currently the most popular CMS, so let’s start with it. A special and extremely powerful scanner, WPScan, has been developed specifically for WordPress. At the time of the writing, the latest version was 3.7.8. The scan can identify the version of the scanned object, brute-force the admin account (it even has a built-in dictionary), analyze vulnerable open directories, detect the installed plugins, etc. Furthermore, it is included in Kali Linux and other pentesting distributions. A docker container version is available as well.

In my humble opinion, the developers of WPScan could simplify the controls and keys. The program even has two help functions: a short one (-h) and a detailed one (--hh).

Prior to using WPScan for the first time, update its database.

wpscan --update

Now you can run a scan. Without keys, WPScan will perform just a superficial scan and provide basic information about the site.

wpscan --url http://example.com

Information worth your attention begins after the string Interesting Finding(s):; it includes:

• WP version;
• open directories;
• potential vulnerabilities; and
• links to resources describing these vulnerabilities.

In the end of the output, you will see strings marked by red exclamation signs and describing the identified violations of basic security rules. In this particular case, it is the undisguised wp-config.php file containing the login and password to the database.

Let’s continue the research and try to brute-force the login and password to the admin account using the same tool:

wpscan --url http://[IP-address] --passwords pass.txt --usernames user.txt

The brute force attack is performed very quickly thanks to multithreading. If the admin uses standard accounts and simple passwords, you won’t have to wait for long.

As you can see, it is pretty easy to get logon credentials to the admin account and database. For an ordinary hacker, this would suffice – but we are pentesters and should check a few more things, including WP plugins and other popular ‘entry points’.

The scanner claims that no plugins are installed on the tested web site; however, this may be not true due to limitations of the passive scanning mode. To detect plugins, use aggressive search:

wpscan --url http://[IP-address] --enumerate ap --plugins-detection aggressive

The ap key will display all the found plugins, while the vp key, only vulnerable ones. This procedure can take a while: half an hour and more. The scan speed depends among other things on the site remoteness.

The aggressive method has detected the Akismet v. 3.1.1 antispam plugin.

Other vulnerable WP add-ons can be detected in a similar way; see the --enumerate section in the manual for more detail.

Don’t forget to check the CVE database for identifiers of known vulnerabilities, including the PHP version used by the CMS. Then look for premade Metasploit WP modules and try them.

Joomla

Joomla is another popular CMS, and there is also a special scanner for it: JoomScan. The program was developed by the Open Web Application Security Project (OWASP) and still remains actual despite the absence of recent updates. The last version (0.0.7) was released in September 2018.

JoomScan resembles WPScan, even though it is much simpler. The utility is included in most pentesting distributions, and its manual consists of just a few lines.

The program also supports the aggressive scanning for installed components. The command launching the scanner in the aggressive mode is as follows:

joomscan --url http://84.42.34.2/ --enumerate-components

Below are the scan results for an old and vulnerable version of a Joomla-based web site found on the Internet.

As can be seen, the program provides the CMS version, CVE identifiers of the detected vulnerabilities, and links to exploits that can be used to hack the site. The output also includes all directories found on the site and a link to the config file (if it’s not concealed).

JoomScan cannot brute-force the admin account. To perform this type of attack, a powerful tool able to work with a chain of proxy servers is required. In addition, Joomla-based sites often use the brute force stop plugin. After a certain number of failed attempts, it blocks the attacker’s IP address.

If you stumble upon a Joomla-based site using HTTP (such things are pretty rare nowadays), you may try brute-forcing it with this Nmap script.

Drupal and other CMS

The situation with Drupal (as well as with other not-so-popular CMSs) is more complicated. The existing scanners are unable to detect vulnerabilities in such web sites. The only available tool is DroopeScan, but it only collects the basic information about the target.

DroopeScan is installed using pip (accordingly, Python must be installed on your PC).

pip install droopescan

Time to launch the scan. DroopeScan supports not only Drupal; so, you have to specify the target CMS:

droopescan scan drupal -u http://url

The rest of information has to be retrieved manually and Googled on the Internet. Vulnerability databases, including CVEdetails, and ready-to-use exploits with PoCs available on GitHub and Darknet will help you in that.

Take, for instance, the CVE-2018-7600 vulnerability affecting Drupal7.х and 8.х. It allows to upload and remotely execute a shell. An exploit to this PoC is available here.

The scanner provided to me the CMS version, and this was sufficient to exploit the vulnerability. Overall, the hacking of Drupal and other CMSs is not much different from the identification of vulnerabilities in any other online service. Security breaches are always present, but some of them may be not discovered yet.

A combat exploit is also available online; it allows to open a Meterpreter session and use the vulnerability to the fullest.

Hacking custom-made sites

Testing custom-made sites is much more difficult. There are no scanners able to tell you: here is an obsolete version of the web application; here is a known vulnerability; and here is a link to the exploit and its description. All you have is a very long list of potential vulnerabilities to be explored. You may pentest such sites using either the OWASP methodology or your own algorithm.

On the one hand, pentesting is a creative process. It does not have a rigid framework or a mandatory list of tools, especially if these tools are open-source programs. On the other hand, security audit is an important procedure, and some organizations try to structurize it to make sure that the pentester hasn’t missed anything.

Take, for instance, OWASP Testing Guide v4. This document describes in detail the vulnerability identification procedures for web applications. The authors have identified and outlined in simple terms techniques used to detect the ten main vulnerability classes (OWASP 10).

If you are about to test a custom-made web site for vulnerabilities, start with the above-mentioned WhatWeb. The only difference is that you are checking not a specific CMS, but all the detected services and their versions.

Many sites use vulnerable framework versions. For instance, obsolete versions of Ruby on Rails and Apache Tomcat are pretty common, and exploits to them are available on the Internet.

It is important to check the programming language version. New vulnerabilities are identified in scripting languages on a regular basis (take, for instance, PHP); and weeks may pass between their detection and respective security updates on the target web site.

The next step involves security scanners. They may not deliver a final verdict, but at least provide some food for thought. For instance, the dirb utility explores the open directories and returns the response codes.

To check a site for typical vulnerabilities, use universal scanners: nikto, OWASP ZAP, w3af, and skipfish. Mantra security toolkit can be helpful in some situations, too.

Burp Suite tests web applications for vulnerabilities in a more sophisticated way. As an example, let’s examine the identification and exploitation of SQL injections.

Burp Suite is included in Kali Linux. Launch it, found the Repeater (a tool that manually reissues requests and analyzes the application’s response), and run it. In GET or POST requests, search for an id=12-like value transmitted to the server and pass it to the Repeater.

Add a single quote to check whether special characters are filtered out in the transmitted value or not. A syntax error sql message appears. This error indicates that the web site is vulnerable to SQL injections. Use sqlmap to automate the attack.

sqlmap -u http://url/page.php?id=1 --dbs

The -u key sets the target’s URL, while --dbs instructs to check all database management systems.

The SQL injection utility will determine the suitable payload and retrieve all required data from the site’s databases as per your commands. If the program finds password hashes, it will suggest you to extract passwords from them. This utility is extremely useful for exploitation of blind SQL injections.

Protection

If you own an CMS-based web site, the best security strategy is as follows: (1) don’t install suspicious add-ons; (2) reduce the number of plugins to the minimum; and (3) update the software on a regular basis. Web designers and programmers should adhere to the basic coding rules: filter out special characters in requests sent to databases and thoroughly check all scripts found on the Internet.

If your web site is custom-made, check all web components used in it, remove the optional ones, and promptly update the remaining ones. The best way is to organize the site maintenance prior to its launch.

The universal solution is to retain third-party experts to carry out security audits on a regular basis. By the way, big companies often pay rewards for the identification of bugs in their online services. The bug bounty is a good starting point for an aspiring pentester.

What’s next?

If you are interested in pentesting web services, I suggest you to practice in OWASP 10. In addition, you can polish your pentesting skills on special playgrounds and vulnerable virtual machines available online.