Hacker News Reader

Comment by Vanderson | Hacker News Reader

I built into my CMS an automated scanner that checks hashes on system files and sends alerts if there are any changes detected. (also for any files that shouldn't be there)

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.)

View on HN

I can't say there's 0 problems with WP core, but often the problems aren't in core system files, but in all the various plugins/themes. Also, those files (and core files) can get auto-updated - all hashes for those would need to be scanned for, and you'd have to trust every single theme/plugin vendors, and you'd have to trust all the plugins/libs those others use. And have to get them all to participate in the first place, no?

That is a good point. A hash standard for plugins could be implemented by WP then. And a way to verify the hashes shouldn't really be hard, and it would go a long way to making WP more secure by default.

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.

the other aspect is that many compromises in WP come from writeable file systems.

/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).

>the other aspect is that many compromises in WP come from writeable file systems.

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?

what you're missing is that this is precisely why wp is popular - click buttons and have new files installed automatically, just move any file anywhere and have it execute.

I guess I am looking at it from a systems building perspective. If you can control the rules for what files are allowed to run (ie limit them to something like "plugin.php" or a directory like /something/something/plugin) then add access rules to the server (again, by default shouldn't be hard) to limit running files to those rules.

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?

In most cases, yes. Most shared hosting providers will execute all PHP files as a default, although it's quite doable to block access using rewrite rules or custom access controls.

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.

Back when I did a lot of WP sites, the WordFence plugin pretty much did exactly this...

Looks like it's still available and recently updated: https://wordpress.org/plugins/wordfence/

At a glance this looks neat. But don't you think it's odd that WP doesn't have built in security of a similar nature?

no, because it takes time/effort to keep all that up to date. if wp.com provided it for a fee for wp.com-hosted sites, i'd understand that.

Agreed. Unfortunately, ultimately, WP is about marketshare. Period. End of story.

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.

I would imagine enough bad press has caused some of the security enhancements of the past. Maybe more are coming?

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.

You could also use a generic File integrity monitor for something like this (e.g. tripwire https://github.com/Tripwire/tripwire-open-source )

This looks quite extensive. Does it rely on a clean install to start with? (this seems to be the single point of failure for most FIM systems I've seen so far)

This is a GUI and runner around an open source webscanner for each CMS.

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.

Couldn't you just set it to automatically quarantine any suspect files?

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?

Yep, you can quarantine, overwrite, or disallow writes altogether in _some_ directories, but any of those will prevent auto update or component updates managed by the CMS... Which is a nice feature to patch known vulnerabilities. A happy medium might be to quarantine and send an alert for manual approval, or having the hash change trigger deeper inspection -> quarantine & alert based on some risk assessment.

These scanners will only send alert, no ability to remediate built in.

I guess an alert is better than nothing. But you still have to deal with the cleanup. It seems the only real way (which I figured out) is to have a separate management system from the CMS.

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.

I use aide for that purpose. Works great, and is pretty fast. http://aide.sourceforge.net

Of course it's not going to tell you if your CMS is unpatched, misconfigured, etc. Just that nothing's changed.

That is interesting. I guess you have to assume your current set of files are all valid for this to work?

Yes...you have to do the first run when things are known good.

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.

This is a great idea. Thanks for sharing.

I got the idea from a security company trying to sell me WP security suite that will scan all your files, and automatically replace them if they are bad. Since I wasn't running WP, I couldn't use it. But I liked the idea and I built my own scanner into my CMS (Archetype).

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.

i second this (but also as a learner not a guru) i admin a server where nothing is writable by the user the webserver runs as except manually modified items/folders where the cms is expecting to upload images or pdfs etc. The hand-changed folders are non-executable by php . I'm sure there is a smarter solution but since implementing this we haven't had a successful malware/deface incident .

Yep, this is my experience as well. I have accounts get compromised because of a weak password. (maybe 2fa will help) But also, accounts can be locked down to IP address (harder to manage but helps more)

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.

Reply on news.ycombinator.com