Closed isarmstrong closed 10 years ago
Hi,
From what I understand and the research I've done about Envato, they provide free & premium plugins & themes and you would like that when one of this item is found, wpscan ask the Envato API if it's vulnerable ? (even if I couldn't find a method to do that from the API doc)
I don't see a direct way to ask Envato's API that question either.
I haven't played with it in any detail but it seems like - maybe - you could grab the ID of the plugin in a scan then ask the API for information on that plugin ID, which would report the version for comparison. I'm on-site at my day job today so I don't have my linux box available to see how Envato plugins are enumerated or what data comes back.
OFFTOPIC question for the wpscanteam, if we are thinking of implementing this, will there be plan's to implement other commercial plugin check's also. like wpmudev.org and more.
Let's assume it's possible to query Envato API for the vulnerable items.
The WPScan base must works on a LAN (meaning no external request), so using Envato API could not be done with the current plugins/themes check. However it could be possible to add an enumeration option for Envato and/or other commercial items which would be used to query APIs
Nonetheless, the issues here are:
There are already some commercial plugins vulnerabilities in our db, but really few because they are mostly discovered during pentests/assessments.
If you have a list of commercial plugins/themes, you can add them to the plugins.txt and themes.txt files in the data directory and they will be checked (with the --enumeration p option). However, unless vulnerabilities for these items are in our db, no vulns will be found.
A solution would be that commercial plugins/themes providers had an API where you could (with an API/AUTH key) :
Then, in WPScan, we would only add an option for the API key to be passed and the different requests for each provider.
However I think I can dream on that :D
(Btw, about CodeCanyon: http://www.exploit-db.com/exploits/28377/, you may want to verify it ;p)
Hey guys, sorry to be of the topic for a few days. I had several minor emergencies with clients and one with the family dog.
Part of the problem with CodeCanyon, as I have found over the last few hours, is that there is no requirement to report a plugin version to the web. For example, the popular "Layer Slider" plugin simply tells you that it is installed, on enumeration.
With that said, Erwanlr's comment about CGM is a great example of why this is a critical feature. The fact that, in my experience, most Envato (and Woo but they are less common) plugins are not hooked into the auto-updater means the vast majority of sites running CodeCanyon plugins are sitting ducks.
Not every company cares until you rub it in their face. Ford Social (http://social.ford.com/readme.html -version 2.8.5 with superuser "admin" at the time of authoring) flat out told me in a Tweet that "I've spoken with our Ford Social rep., who has informed me his team did not find any software concerns. ^TG" - and the only thing that got them to pay attention was the result of a WPScan. GOP.com is just as bad (56 vulnerable plugins of 256). These types of businesses need things spelled out very clearly in order to act.
The popularity of private repos makes it imperative that we be able to test them. The problem then, is the technical challenge of doing so when a version number is not being reported. Any ideas on how to fingerprint that? I can put up a test site to bounce off of later today.
Private repo are IMO worse than public ones because they rely on a form of security by obscurity :/
Example with the CGM plugin, if this vulnerability is confirmed, it's a third party vulnerability, known since January 2013: http://seclists.org/fulldisclosure/2013/Jan/200. And as it's the same lab who reported both vulns, I'm pretty sure the one in CGM is real.
Premium plugins don't have an auto-updater ? Woo, that's bad
Actually, WPScan extracts the version number from the readme.txt file. There was a plan to also check in the changelog.txt but as the format is free, it's complicated (in the readme, the format is "stable tag: {version}").
I also have a private script which does a fingerprinting (md5sum of all non PHP files) of a given list of plugins from the wordpress repo and then check them on target. However doing it for a premium plugin would require to have all versions of this plugin :/
Bad time for premium themes these days :D (a lot of Arbitrary file upload vulns)
I really would like to play with one of these :'(
During our little adventure in September, I was able to determine that a lot of private repositories practice security by obscurity and do not report a version number. That means you would have to figure out another way to identify it, like actually testing the exploit against the code. That's not hard for a determined scripter to do but it's not the sort of action a plugin enumeration routine is likely to perform.
On Wed, Nov 13, 2013 at 9:28 AM, erwanlr notifications@github.com wrote:
Bad time for premium themes these days :D (a lot of Arbitrary file upload vulns)
I really would like to play with one of these :'(
— Reply to this email directly or view it on GitHubhttps://github.com/wpscanteam/wpscan/issues/286#issuecomment-28414947 .
I"m looking for a way to test the following - no longer sold - themeforest's premium themes against the Valums Uploader Arbitrary FileUpload:
LightSpeed, Eptonic, Nuance, Area53, SwitchBlade, Magnitudo, Skinizer < 1.0.4, Saico
Closing as there is no way right now to do this :/
WP-Scan is a great tool. It is a fast and simple way for me to assess a client's security without having to dig around a whole lot. It seems to me, however, that the weakest point in WP security is the Envato plugin suite.
Basically, most "developers" don't like to spend money where they don't have to, so they don't hook a client's site into the auto-update feature. Woo has a similar problem. The result is that site owners will end up with some hardly-functional swiss-cheesed security because they are running a 22 month old version of a CodeCanyon release.
Using the Envato API (http://marketplace.envato.com/api/documentation) it would be awesome if WP-Scan could look for issues. Even though they don't provide a simple XML by category with version numbers - not that I can see anyhow - it might be possible to grab individual plugin IDs from the fingerprint and check the ID against the result via API.
Granted, it's way over my head, I'm mostly a UX guy who has learned a few cheap carnival tricks and how to ask the right questions.
Thoughts?