Scan a wordpress website with Wpscan – Part 1 : Basic Scan

[Nytro]

Scan a wordpress website with Wpscan – Part 1 : Basic Scan

In this tutorial we will demonstrate how to use Wpscan, a vulnerability scanner, in order to perform a basic scan to our wordpress website for known vulnerabilities. First, lets take a look at what is Wpscan.

WPScan is a black box WordPress Security Scanner written in Ruby which attempts to find known security weaknesses within WordPress installations. Its intended use it to be for security professionals or WordPress administrators to asses the security posture of their WordPress installations. The code base is Open Source and licensed under the GPLv3.

Features include:

• Username enumeration (from ?author)
  
• Weak password cracking (multithreaded)
  
• Version enumeration (from generator meta tag)
  
• Vulnerability enumeration (based on version)
  
• Plugin enumeration (todo)
  
• Plugin vulnerability enumeration (based on version) (todo)
  
• Other miscellaneous checks
  

Installation

WPScan comes pre-installed on the following Linux distributions:

• BackBox Linux
  
• BackTrack Linux (outdated WPScan installed, update needed)
  
• Pentoo
  
• SamuraiWTF
  

Note: In this tutorial I will be using Backbox 3.0 However, you can install it on Debian/Ubuntu, Fedora and Mac OSX

Prerequisites:

• Windows not supported
  
• Ruby => 1.9
  
• RubyGems
  
• Git
  

Installing on Debian/Ubuntu:

sudo apt-get install libcurl4-gnutls-dev libopenssl-ruby libxml2 libxml2-dev libxslt1-dev
git clone https://github.com/wpscanteam/wpscan.git
cd wpscan
sudo gem install bundler && bundle install --without test development

Installing on Fedora

sudo yum install libcurl-devel
git clone https://github.com/wpscanteam/wpscan.git
cd wpscan
sudo gem install bundler && bundle install --without test development

Installing on Mac OSX:

git clone [URL]https://github.com/wpscanteam/wpscan.git[/URL]
cd wpscan
sudo gem install bundler && bundle install --without test development

If you face any short of problems and for more information and about installing and known issues visit project’s page Wpscan by wpscanteam

Preparation

For demonstration purposes I have created a wordpress website, which is hosted locally, to my apache server. The name of the website is:

wp_site

and it’s url is:

http://localhost/wp_site.

You have to replace it with either a url of an existing website, i.e. http://www.your-web-site.com or with the path of your localhost.

By this point you should have Wpscan installed and your target website up’ n’ running.

Studying Time

Let’s take a look at the help page in order to get familiar with the arguments :

Some values are settable in conf/browser.conf.json :
  user-agent, proxy, threads, cache timeout and request timeout

--update   Update to the latest revision
--url   | -u <target url>  The WordPress URL/domain to scan.
--force | -f Forces WPScan to not check if the remote site is running WordPress.
--enumerate | -e [option(s)]  Enumeration.
  option :
    u        usernames from id 1 to 10
    u[10-20] usernames from id 10 to 20 (you must write [] chars)
    p        plugins
    p!       only vulnerable plugins
    t        timthumbs
    T        themes
    T!       only vulnerable themes
  Multiple values are allowed : '-e tp' will enumerate timthumbs and plugins
  If no option is supplied, the default is 'tup!'

--config-file | -c <config file> Use the specified config file
--follow-redirection  If the target url has a redirection, it will be followed 
without asking if you wanted to do so or not
--wp-content-dir <wp content dir>  WPScan try to find the content directory 
(ie wp-content) by scanning the index page, however you can specified it. 
Subdirectories are allowed
--wp-plugins-dir <wp plugins dir>  Same thing than --wp-content-dir but for 
the plugins directory. If not supplied, WPScan will use wp-content-dir/plugins. 
Subdirectories are allowed
--proxy  Supply a proxy in the format host:port or protocol://host:port 
(will override the one from conf/browser.conf.json).
         HTTP, SOCKS4 SOCKS4A and SOCKS5 are supported. If no protocol is given 
(format host:port),
 HTTP will be used
--wordlist | -w <wordlist>  Supply a wordlist for the password bruter and do the brute.
--threads  | -t <number of threads>  The number of threads to use when multi-threading 
requests. (will override the value from conf/browser.conf.json)
--username | -U <username>  Only brute force the supplied username.
--help     | -h This help screen.
--verbose  | -v Verbose output.

Hands-on time

Open a terminal and navigate to the folder, where Wpscan is installed. In my case it is in :

/opt/backbox/wpscan

Wpscan offers a variety of features, we will start by doing a simple non-intrusive scan. In terminal type:

ruby wpscan.rb --url localhost/wp_site

Output:

[+] The WordPress theme in use is catch-box v1.6.2
[!] The WordPress 'http://localhost/wp_site/readme.html' file exists
[+] WordPress version 3.5 identified from meta generator

With this scan, we gathered information about the theme that is in use, the existence of readme.html and the version of installed wordpress.

Now, we will perform a scan at website, asking WPscan to use all enumerated tools. That could be information about themes, plugins, usernames etc. In terminal type:

ruby wpscan.rb --url localhost/wp_site --enumerate

Output:

BUSTED! Among other information, such as theme, installed plugins and wordpress version, we gathered 2 interesting clues:

A known vulnerability! It is highlighted with red text, and the program provides a url of the exploit.

Usernames of the website’s users.

Wpscan Vulnerability Scanner is a powerfull tool with great features. However, the purpose of this tutorial is to demonstrate how to perform a *basic* scan. Thus, we will not show further scans.

In Part 2 we will see how we can take advantage of the information we gathered performing a scan to a target wordpress website.

Stay tuned!

Sursa: [tutorial] Scan a wordpress website with Wpscan – Part 1 : Basic Scan | antonis manaras