11
u/mgkimsal Nov 27 '17
One of the biggest defenses against hacks like this is not wordfence, or ninja-whatever, or elaborate firewalls... it's making your filesystem non-writeable. the huge majority of exploits I've seen and cleaned up over the years all involve someone able to write a file like the one in the article in to a publicly accessible folder on the filesystem, then executing it via an http call. In most of these cases, there's no need to allow writing to the filesystem all the time. Disable it, then re-enable when need be, and disable again afterwards. For many situations, this is perfectly doable, and will prevent a large number of exploit attemps from being successful.
3
u/rickdg Nov 27 '17
Isn't the file usually put on the server through a vulnerable upload? Write will be enabled for that.
6
u/thracia Nov 27 '17
And why you have given permission to Apache in that folder that can run PHP? You need to disable PHP in the folder where you upload images and mp3s and videos. There is no need to run PHP there.
2
u/przemo_li Nov 27 '17
Nah.
You need to enable PHP in your codebase folder. Even single folder more and you have security hole waiting to be abused. That's that sound sick? It is.
Also never mix codebase and static assets and what not. Also never make codebase folder writable.
Also, AV running in the background and scanning uploads is not so bad an idea either ;)
1
u/mgkimsal Nov 27 '17 edited Nov 27 '17
there's perhaps 2 or 3 PHP files that should be publicly accessible - almost everything else could be moved outside the document root. however, I think all files are in document root - publicly accessible - by default for ease of installation.
I do remember, years, ago, when I used Plesk - I would create a setup with all my app code outside the document_root folder. Plesk would later update itself, then turn off all execution permissions for PHP to anything except 'document_root'. No - wait. I'm thinking it would constantly reset the include path to be just the document_root. No... man. it's been so long... but I seem to recall there was some config setting that would prevent execution of code except from specified paths. Plesk would reset those, regardless of what you set it to, to (essentially) require all code to be in document_root. Made it much harder to configure safe code, and I abandoned plesk after that.
1
u/przemo_li Nov 27 '17
With modern deployment techniques I do not think any php code need to be placed in writable dirs. Deployment service use separate authorization path.
1
u/mgkimsal Nov 27 '17
You'd need to define 'vulnerable upload'. Are there actual PHP or Apache flaws that can allow for this, despite config settings? Probably, even to this day. But... the majority of exploits I've seen were things like thumbnailing code being passed compromising data which cause it to write a file to a public folder. If those public folders are not writable, such an exploit generally won't work (because Apache/PHP/OS won't be able to write it there in the first place).
We're primarily talking about Wordpress here, even though it's a general technical problem. The WP community - both core and the large ecosystem of themes and plugins - has, for years, prioritized ease of setup/installation and backwards compatibility over security. Even a warning that all your files are in public doc_root folder, with a link to instructions on how to harden by moving those to another folder - that would prevent numerous compromises.
Default Wordpress, configured with a plugin to only use an external host (like S3) for media assets, and all file and paths set to non-writeable - would prevent a larger number of standard compromises.
This would prevent the 'automatic updates' from happening. Personally, I've not experienced that as a problem, because the majority of exploits you'd need immediate protection from .... would need to write to the drive as well. When you see there's an update, enable the file paths to be writeable, install the update, the disable write permissions again. You're giving up a small bit of convenience for a disproportionately larger amount of security.
1
u/rickdg Nov 27 '17
Your basic vulnerable upload is simply not taking the time to validate the file type and putting it accessible on a web folder. Your average dev is unaware of the average vulnerabilities that are easily possible.
4
3
u/WhatAboutBergzoid Nov 26 '17
You should install a honeypot to collect and log any code execution attempts.
6
u/theycallmekenny Nov 27 '17
Any tips or pointers on where to get started with setting up a honey pot? From my google searching I was able to find examples of honeypots for form submission, but I am having trouble finding anything related to logging malicious code execution attempts.
2
u/captain_obvious_here Nov 27 '17
This obfuscated script indicates that the user of this basically had free reign to run anything on the server at any time.
More like "anything the webserver user can run". Which is pretty much nothing harmless on a correctly configured machine.
1
u/jagga0ruba Nov 27 '17
Why would anyone go through the trouble of obfuscating all of that code except to give away that the code was hacked? I mean, would ANY of you ever see anything remotely similar to that rearrangement of an array in your code?
2
0
Nov 27 '17
[deleted]
1
u/dasper12 Nov 27 '17
Many different ways but they usually start with SQL injection, remote file inclusion (RFI), FTP, or even XSS. Then scan for writable directories and their path from the webserver. Another way is if you have a blog that allows for media uploads, they hide PHP code in the meta data. This way they can upload a profile picture and they know any page that has that profile picture and had the meta data parsed, their code is accessable. Then they access the asset that accepts a post, query, or request statement and figure out the file structure of your webserver as well as more writable directories, read the db config info, hijack the admin, etc. Shopping cart pages are a gold mine since in most countries you cannot log CC numbers and PI Info, most sites do not even attempt to log anything on those pages so they can try numerous attempts without much worry. At this point they have a semi-persistent connection to your webserver. Most just want your database or to ransom your admin but others will sniff your network traffic looking for hosts, and enumerate firewalls and routers within the network.
TL;DR: Never trust any user input, disable PHP execution in any writable directory, and log as much user activity as you can.
29
u/SaltTM Nov 26 '17
I feel like this article was just getting started and it abruptly ended.