How To Check a Website for Vulnerabilities

The internet is home to roughly 1.8 billion websites. Many of them have vulnerabilities that turn them into easy prey for cybercriminals. According to researchers’ recent findings, more than 56% of content management system (CMS) installations are out of date and hence susceptible to compromise. Another study says 19% of web applications running on websites are vulnerable.
In a global context, these stats translate to a gigantic attack surface.
Website vulnerability assessment 101
Broadly speaking, all websites in existence can be broken down into three overarching categories:

Hand-coded (manually written in HTML, created with a static site generator such as Jekyll, or designed using a web development tool such as Adobe Dreamweaver).
Created with website builders (for the most part, these are simple sites containing no databases and user interaction elements).
CMS-based (made with turnkey content management systems).

A one-of-a-kind CMS platform tailor-made for a specific site is a more exotic type. It is becoming increasingly obsolete these days due to high development costs few businesses can afford. That said, the vast majority of websites out there are based on content management systems.
For a hacker, CMS platforms hardly differ from other web-facing services in terms of exploitation. Their underlying code is publicly available, and therefore anyone can scrutinize it for bugs as well as security weaknesses. This explains why CMS-based websites rarely fall victim to targeted attacks. Instead, they tend to be hacked “in bulk.”
This form of compromise is automated and typically follows a well-trodden path. First, a malefactor pinpoints a zero-day vulnerability or a recently discovered flaw in the target CMS. Next, he creates an exploit and contrives a bot that scans all websites within a specified range for the vulnerability in question.
At first sight, it may appear that fending off these automated hacks is a matter of keeping the CMS installation up to date. However, as such websites’ functionality is extended through various plugins down the line, it’s problematic to stay abreast of this growingly complex ecosystem.
When a penetration test is under way, the white hat’s objective is to thoroughly inspect a specific website for vulnerabilities so that a potential attacker can’t exploit them. Let’s take a dive into this multi-pronged process.
Website reconnaissance
Before trying to compromise a site, a pentester (penetration tester) needs to collect information about it. A tool called WhatWeb can do the trick. It retrieves details regarding the CMS and extra components in use.
It’s best to launch WhatWeb with the “-a” key and then specify the value of 3 or 4. The only difference between the two is that in the latter scenario, the utility will additionally traverse subdirectories. Keep in mind that either option triggers a straightforward querying mechanism that spans the entirety of logs streaming toward the server.
If configured properly, the tool will return the site’s geolocation and CMS details. It will also let the pentester know whether the site uses PHP or jQuery. This information suffices to commence a trial attack. In case you simply need to determine the CMS type, there are services that provide that info in a snap.
By the way, here are the latest statistics reflecting the market share of different CMS platforms:

WordPress: 64.1%
Shopify: 5.2%
Joomla: 3.5%
Squarespace: 2.5 %
Drupal: 2.4%.

How to check a WordPress site for vulnerabilities
Because WordPress currently dominates the CMS ecosystem, let’s first go over the methods to spot weaknesses in websites running it. There is a hugely effective scanner you can use – it’s called WPScan.
It can fetch the WordPress version, brute-force the admin dashboard via a built-in dictionary, spot vulnerable open directories, detect all plugins installed, and do many more cool things. It is also included as a separate module in Kali Linux and other popular pentesting instruments. You can use its Docker Hub version if you so desire, too.
From where I stand, WPScan’s controls and keys could use some simplification. For instance, the tool comes with two help modules: a brief and a detailed one. That’s kind of redundant.
You’ll need to update the database of WPScan if you’re about to use it for the first time. When done, you can run a scan. Here are important details the scan report will include:

WordPress version;
open directories;
potential vulnerabilities; and
hyperlinks to resources describing these vulnerabilities.

The tool displays exclamation marks to flag things that don’t get along with proper security practices. An example is an unsecured wp-config.php file containing database access credentials.
As previously mentioned, this utility can also brute-force the username and password for the admin panel. This workflow is super-fast because it leverages multithreading. In other words, it won’t take WPScan long to retrieve weak credentials. Accessing the WP database is just as simple if the admin has specified a password that isn’t strong enough.
Whereas these details could suffice an attacker to take over the average site, there are quite a few more things to check. These include WP plugins and other potential entry points.
If the scanner doesn’t detect any plugins in the target website, it doesn’t necessarily mean that no plugins are installed. It could be an upshot of restrictions inherent to a passive scanning mode. To identify plugins more efficiently, consider applying an aggressive crawling mode.
This way, the scanner can accurately pinpoint all plugins, including vulnerable ones. Be advised that this usually takes a decent amount of time. If the site is hosted on a distant server, the speed will be lower. As a rule, it won’t take less than half an hour.
Additionally, use the CVE service to check the identifiers of documented vulnerabilities.  For instance, you may want to go over loopholes in the PHP version the CMS is using. As part of the research, look for readily available Metasploit modules for WP and give them a shot.
Checking a Joomla site for vulnerabilities
Joomla, another popular CMS, can be probed for weaknesses using a tool called JoomScan. It was created by researchers at the Open Web Application Security Project (OWASP). It resembles WPScan in many ways, except that it doesn’t have as many features under the hood. It is embedded in many pentesting (penetration testing) tools, and its user manual consists of only a few lines of text.
JoomScan supports an aggressive method of scanning website components. Its scan report includes the CMS version, the CVEs corresponding to the detected vulnerabilities, and links leading to known exploits that can be unleashed to compromise the site. Plus, it lists all of the site’s directories and a hyperlink to the configuration file if the admin has neglected to obfuscate it.
This tool can’t brute-force the Joomla admin dashboard. To execute attacks like that, you’ll need a powerful solution that operates in tandem with a series of proxy servers. That’s in part because lots of Joomla sites use the highly effective Brute Force Stop plugin. It blocks a malefactor’s IP address if the number of unsuccessful authentication attempts reaches a specified threshold.
If your site uses HTTP, which is fairly uncommon nowadays, try running the Nmap script to assess its resistance against brute-force attacks.
Checking Drupal and other CMS sites
In the case of Drupal and other less popular CMS platforms, things are more complicated. There is no effective scanner to audit these sites for security imperfections. DroopeScan is perhaps the only worthwhile automatic tool you can use, but with the caveat that it doesn’t retrieve details beyond basic site information.
You’ll have to dig into the site manually or search the web to get in-depth data you may need. Vulnerability databases like CVEdetails or proof-of-concept exploits on GitHub can point a pentester in the right direction.
An example of what you can come across is the CVE-2018-7600 vulnerability, which affects Drupal 7.x and 8.x versions and allows a hacker to cause redirects and even execute arbitrary code remotely. An exploit for this PoC can be found here. If the scanner returns nothing but the CMS version of a target site, it could be enough to exploit the vulnerability as long as the Drupal version is within the vulnerable range.
By and large, there is no fundamental difference between compromising CMS platforms such as Drupal and breaching any other Internet-facing service. Security loopholes are either there or haven’t been found just yet.
How to check a hand-coded website for vulnerabilities
Looking for security flaws in a hand-coded website is easier said than done. You can’t possibly find a scanner that will say: “This particular web application is out of date, it has a known vulnerability, and here is a link to the corresponding exploit plus a comprehensive tutorial on how to use it.”
In other words, you have a long list of potential weaknesses to check the site for. Audits like that hinge on the OWASP methodology or unique workflows.
Probing a website for unsecured entry points is a deeply creative activity. You aren’t limited to using a clear-cut framework or specific tools, especially if they are open-source. Nevertheless, security auditing is no joke. It comes as no surprise that some companies try to enforce guidelines for implementing these check-ups so that a penetration tester doesn’t miss anything in a flight of imagination.
One of the best ways to do this is to use the OWASP Web Security Testing Guide. It’s a detailed rundown of the rules for web application vulnerability detection. Its authors compiled and described the methods for testing vulnerabilities that fall under the ten most common categories (OWASP Top 10).
If you need to check the feasibility of compromising a hand-coded site, using the above-mentioned WhatWeb tool is a good starting point. Keep in mind, though, that you aren’t inspecting a CMS in this scenario – instead, you are looking for all embedded services and their versions.
Tons of framework versions are susceptible to exploitation. For instance, outdated editions of Apache Tomcat or Ruby on Rails can be breached using publicly available exploits.
Determining the programming language versions can give you important clues, too. For instance, new PHP vulnerabilities are surfacing off and on, and they can stay unpatched for weeks after discovery.
Your next move is to leverage a security scanner. Even if it doesn’t dot all the i’s and cross all the t’s, it could give you some actionable insights into the security condition of the website under scrutiny. For instance, a tool called DIRB will traverse the open directories and analyze the responses.
To look for common weaknesses, consider using one-size-fits-all scanners such as OWASP ZAP, w3af, skipfish and nikto. Keep the Mantra Security Toolkit close at hand as well. To thoroughly scan a website for web application vulnerabilities, you can use a more sophisticated tool called Burp Suite.
Protection best practices
If your website is built with a CMS, then the most effective security tactic is to refrain from installing dubious plugins, remove plugins you aren’t actively using, and keep all the software up to date. Web designers should stick with safe coding practices such as filtering special characters in database queries and extensively vetting scripts found online.
If you own a custom-built website, be sure to scrutinize its web components, get rid of redundant ones, and keep the rest up to date. Also, ascertain that the site is backed by proper tech support.
Also, you can’t go wrong with penetration testing conducted by a third-party professional. Speaking of which, many big businesses set up bug bounty programs and pay white hats for identifying weak links in their online services. On a side note, this type of activity could be a great launchpad for a bright pentesting career.
The bottom line
If you are keen on finding vulnerabilities in web services, you can refine your skills using the OWASP Top 10 guide. Also, before probing real websites for security flaws, consider trying your hand at inspecting test environments such as virtual machines riddled with known flaws.
Amsterdam-based David Balaban is the founder of the Privacy-PC.com project and is a computer security researcher with more than 17 years of experience in malware analysis.
The post How To Check a Website for Vulnerabilities appeared first on eWEEK.