I can't imagine this would be hard to add to Wordpress or any other system?
Edit: The advantage of this system is that I don't have to know about any threats specifically (ie, no data management on threats) to keep them out, so there is no cat/mouse games.
(maybe this is how this scanner works also? I can't tell from the github docs.)
Then if a plugin maker doesn't add the hashes to their downloads (or wherever they would need to be hosted) they wouldn't get a green lock next their listing?
Also, this could at least be automated away even if no one participates. I see it like this. You install the plugin, a hash table is built on the files that are installed. Maybe this is the moment of insecurity, but even SSH has a moment like this when storing keys.
This way you could at least detect "changes" to the plugins, but maybe not verify the initial install is good. But it's 50% there.
And this technique could be added to WP core and no forcing anyone to do anything. :P
But of course, if the server can create the hashes, then the server can manipulate them. But it would be more work for the hacker at least.
I keep all hashes out of the way of the web server so even if hacked, the web server can't be used to hide their activity.
FIM approach is very effective if you have the time to review many alerts from plugins, or maintain hash list as brought up in thread.
Or in a more dramatic manner, overwrite certain files with the originals. Seems like overkill when you could just disable server permissions on writing to such files.
But either way, it seems you shouldn't be "required" to monitor anything in a fine grained manner. I feel this is the benefit to having code do work for you. And this seems like a simple problem to solve in a number of manners.
A scanner like the one presented doesn't seem to actually help you fix anything, just alert you to threats. Unless I misunderstand how it works?
Of course it's not going to tell you if your CMS is unpatched, misconfigured, etc. Just that nothing's changed.
But, I found an once of prevention is worth more than a monthly fee for a scanning service. No system files should be writeable by the web server, 98% of the problems solved right there. The other 1% is don't allow any user uploaded files to be executable. The last 1% is don't allow any unknown files to be created in any executable space.
Maybe there's a permanent 1% in there that is unsolvable? (social engineering among other unknown threats/bugs, etc...)
I am not a security expert, so I have had to learn both the hard way and from a lot of studying.
Scanning a joomla! website triggers exceptions.
Scanning a WP site, well, I don't know, I'm still waiting for the test to complete. Using WPScan on regularly base, I'm surprised it takes so long, but may be it was a full deep scan ?
If I CTRL+C the docker command line, results is shown on my terminal but never on the GUI.
I think a progress bar or something visual should be a good thing to add.
It was handy when I had a wordpress site hacked, very easy to find the hacked files. Doesn't help much with the database though.
These scanners will only send alert, no ability to remediate built in.
Having the CMS manage it's own files seems like an oversight committee watching itself. :P
This seems like an opportunity for WP to do what Microsoft did, make their own security system to pair up with WP.
But does WP allow php executable on user upload directories by default? I know this is more of a server setting, but it would make sense to test for this in WP admin and alert the user.
/wp-content/foobar.php wouldn't have a hash because it's not a plugin file, but a file that was a file that written to the filesystem by some other exploited plugin. You'd need to be on the lookout for any files that shouldn't be there, but when you're dealing with media folders where anyone can write anything, you're left guessing as to what 'might' be wrong (although executable PHP in an /images folder is probably suspect from the start).
Yes, which is why I am stunned WP is setup by default this way, it's baffling to me. But I guess it makes it easier to manage?
>You'd need to be on the lookout for any files that shouldn't be there...
Yes, and this is what I did with my system, it's really not hard. Maybe like 10 extra lines of code to list all the current files, compare to a known list of hashes, if it's not listed, then it's a bad file.
All files in any user uploadable areas automatically are not executable. Every web server has a way to do this I am sure. (I don't know all of them)
This seems like such a simple problem to solve with a few basic changes to WP. What am I missing?
Looks like it's still available and recently updated: https://wordpress.org/plugins/wordfence/
Matt & Co love to brag about marketshare. But the WP Elite are the Washington DC of OSS. That is, completely disconnected from the day to day lives of the underlying community.
Sad. But true.
My experience is that some businesses that use WP rely on other companies to maintain security, and maybe individuals or small businesses don't consider it to much.
Then you have a lot smaller surface area of potential problems. I am not suggesting it has to be required by WP, but at least "available". This wouldn't cause any sort of popularity concerns or ease of use either.
Any plugin that wants to be more secure just follows some rules outlined by WP parent-corp and add the .htaccess (or whatever) rules and presto, more secure.
I don't run WP anymore than for testing stuff, can you really put a file anywhere by default and it's executable?
Problem is that the majority of WordPress users lack the know-how to do it on their own, as well as the will to pay for someone else to do it for them.
Web hosts aren't interested because supporting it would be a nightmare due to the millions of possible plugin/theme combinations.