Out of the 852,301 (85%) of sites that we were able to check, we identified that 736 (0.086%) of them were exposing their database export files publicly with the same name as their domain. This may not seem like a lot, but when you consider the impact of the database contents being exposed to malicious actors, it is a considerable risk to the affected individual sites, and their users.
The sites affected included 11 worldwide government websites, a lot of porn sites, 2 small banks, 5 educational institutions and a lot of other random websites, such as personal sites, anime sites, etc.
Out of the 736 affected sites, 290 (39%) of them, were running WordPress.
Version 1.4.11, and below, of the wpForo Forum WordPress Plugin were found to be vulnerable to Reflected Cross-Site Scripting (XSS). The vulnerability was due to the Plugin using the $_SERVER['REQUEST_URI'] PHP variable to create a URL string that was later output within HTML without any output encoding.
Versions 1.3.8 to 1.3.9 of the Loginizer WordPress Plugin were found to be vulnerable to Stored Cross-Site Scripting (XSS). The vulnerability was due to the Plugin's logging functionality using the $_SERVER['REQUEST_URI'] PHP variable to create a URL string that was logged to the database without any input validation. The URL that was saved to the database was later output within HTML without any output encoding.
A few days ago the awesome folks over at Sucuri found a SQL Injection vulnerability in the popular WP Statistics WordPress Plugin, currently installed on over 300,000 websites. We wanted to check our existing toolsets would have detected the vulnerability so that we could ensure that Dewhurst Security clients were not affected by similar issues. During this process we identified the Authenticated Reflected Cross-Site Scripting (XSS) vulnerability we discuss below. This vulnerability was responsibly disclosed to the vendor who patched the issue and released a new version in the same day.
Yesterday, May 3rd 2017, a site named ExploitBox released two WordPress advisories discovered by Dawid Golunski. The titles of the two advisories are: WordPress Core <= 4.7.4 Potential Unauthorized Password Reset (0day) and WordPress Core 4.6 - Unauthenticated Remote Code Execution (RCE) PoC Exploit (default configuration, no plugins, no auth).
We constantly get asked by users how to install WPScan on Windows machines. Since none of the core developers use Windows day to day, Windows is not officially supported by WPScan. Nevertheless, it is possible to install WPScan on Windows by using Bash on Windows. In this video we'll show you how to do just that, install WPScan on Windows 10.
Yesterday, January 28th 2017, members of the WPScan Team released WPScan version 3.0. WPScan is a black box WordPress Vulnerability Scanner written in Ruby which was released in 2011 for Penetration Testers. WPScan 3.0 is not just another release. It was re-written from the ground up by a WPScan team member, Erwan.
YouTube is fast becoming the number one choice for content on family TVs thanks to 'smart' TVs and gadgets like Google's Chromecast. Recording, editing and uploading videos is also becoming much easier. Almost everyone in the western world owns a powerful smart phone with a built in camera. Generally, people also have computers powerful enough to edit videos in less and less time. And finally, relatively fast Internet speeds to upload the final video (as well as consume videos).
This cheat sheet was compiled by Dewhurst Security to record the knowledge gained when testing WordPress plugins for security issues for our clients. The security documentation provided by WordPress and found online for plugin security is sparse, outdated or unclear. This cheat sheet is intended for Penetration Testers who audit WordPress plugins or developers who wish to audit their own WordPress plugins.
On April 5th the Open Sourced Vulnerability Database (OSVDB) announced that they were shutting down.
For me, the writing was on the wall when OSVDB implemented CloudFlare's DDoS protection which makes you wait 5 seconds on a loading screen before you are able to access the site. It was not so much the waiting that alluded to the potential ending of OSVDB, it was that OSVDB's Google PageRank was taking a battering. So much that searching for terms such as 'OSVDB $somid' would not result in a osvdb.org hit on Google's front page.
You're probably all familiar of the custom protocol handlers browsers use for various things such as ```chrome://settings/``` and ```chrome://credits/```. I was using a Chrome app (extension) the other day that suggested I copy and pasted ```chrome://restart``` in to my browser address bar to restart Chrome. This got me thinking about the ```chrome``` protocol handler, what other ones are there and how they might they be able to be used for a bit of fun.
The first obvious bit of fun we could have is if someone clicked on a HTML link to ```chrome://restart``` and have their browser restart, losing all of their open tabs. This is so obvious that Chrome do not allow this to happen by default and you will see the following error in the browser console ```Not allowed to load local resource: chrome://restart/```.
Certificate Pinning is an extra layer of security that is used by applications to ensure that the certificate provided by the remote server is the one which is expected.
By including the remote server’s x509 certificate or public key within the application, it is possible to compare the locally stored certificate or key with the one provided by the remote server.
If you have been unable to intercept (Man-in-the-Middle) the application’s HTTPS traffic, after taking the necessary steps, this is probably due to the application using Certificate Pinning.
A few days ago (October, 2015) the OWASP Application Security Verification Standard (ASVS) version 3.0 was released which I had the opportunity to contribute to in a small way by helping review some of the draft documents before the official release.
I became aware of the OWASP ASVS as a growing number of my clients started asking if I used it. At the time I didn't use it but I decided to invest some time into finding out what it was. This blog post's intention is to bring some attention to the OWASP ASVS project for those unaware of it.
Today Burp Suite announced the release of a new feature they call Burp Collaborator which is enabled by default.
By default this new feature makes use of a third-party server hosted by Burp to detect vulnerabilities which are not easily detectable in the usual 'request<->response' method most vulnerability scanners use.
The legitimate concern of some people online has been that client information may now be leaked to Burp or worse leaked to the Internet if the third-party server Burp uses is ever compromised.
When you first release software online you don't put too much thought into the software license (I didn't at least). You have no idea if the project will take off. If your intention is for your peers to use it freely your first thought may be Open Source. The most popular Open Source license is the GNU GPL, so why not use that!?
I released WPScan on the 16th of June 2011 along with the GNU GPL license. After a while I built up a team, The WPScan Team, which were people who had the same goals as me, to make an awesome black box WordPress scanning tool. The WPScan Team (3 other awesome people) and I have been working on WPScan in our spare time as volunteers for almost 4 years. Countless hours, days, weeks and months of man hours have been put into WPScan and recently the WPScan Vulnerability Database by us.