Triv00ett said after your post: "We would need to disable local php.ini also, which is allowed currently."
However, he deletes own post. So we may ignore that
- Status
However, he deletes own post. So we may ignore that
Infopro
Well-Known Member
Just wanted to let people know that I've now seen for the first time another way hackers are exploiting the symlink vulnerably. They created a tar archive of the symlinks folder. So instead of using Apache to follow them, they're using tar. I'm not sure how they're doing this but I've got a decoded copy of the script used and I'm inspecting it further.
I've come to agree with cPanel's original stance that fixing Apache isn't the way forward, we're switching to CloudLinux with CageFS as soon as possible for all our servers.
I've come to agree with cPanel's original stance that fixing Apache isn't the way forward, we're switching to CloudLinux with CageFS as soon as possible for all our servers.
I've seen the exploit done that way (tar file) plenty of times as well. Sadly, it's nothing new. I have many copies of different symlink auto-hack scripts, but the vast majority of the time they still rely on Apache to follow the links. If they run the tar command using a webshell, it's likely running with the webservers permissions rather than how it would act being run from a prompt. In testing I could only use bash as a normal cPanel account to steal config files when users had accidently set their public_html to 755 instead of the default 750. Otherwise, I had to use apache to follow the links. Cloudlinux with securelinks and cageFS is certianly a great way to go to be sure. Still, I've still yet to have anyone mass-deface a server that had stevens patch in place.
@Brianoz:
I'm looking at your scripts and although I assume that setting any php-file to 600 should be fine, I want to take a little less chances on a server with a larger number of domains on it, so I was considering the possibility to only chmod the files in the /home directories that are symlinked to in 99% of the hack attempts that we see (wp-config.php, config.php and configuration.php).
Feasible or not?
I'm looking at your scripts and although I assume that setting any php-file to 600 should be fine, I want to take a little less chances on a server with a larger number of domains on it, so I was considering the possibility to only chmod the files in the /home directories that are symlinked to in 99% of the hack attempts that we see (wp-config.php, config.php and configuration.php).
Feasible or not?
If you're having problems with hackers using CGI shell / sym links still add this to your pre_main_2.conf
<Directory /home*/*/public_html>
Order Allow,Deny
Allow from all
Options -FollowSymLinks
AllowOverride None
</Directory>
<Directory /home*/*/public_html>
Order Allow,Deny
Allow from all
Options -FollowSymLinks
AllowOverride None
</Directory>
That will then break other .htaccess directives needed for application to work correctly. I find that Rack911's Apache patch has been the most effective so far to prevent cross account symlinks.
Are you sure? Well, without it clients are free to exploit CGI Shells and sym links on our server. The cpanel race condition patch did nothing. And for some reason Rack911's patch doesn't block CGI Shell access in browsers.
Last edited:
Nobody has any thoughts about my "patch", can anyone confirm what Jeff Shotnik said? I'm not 100% sure what he meant by it.
I believe what he meant was that by setting "AllowOverride None" you are essentially disabling all .htaccess functions, including things like redirects.
Are you sure? We've recompiled Apache with Race Condition Patch and now when we try to follow a symlink to another user PHP file we get this error in Apache error_log:
root [/home/attackbase/public_html]# grep victim.txt /usr/local/apache/logs/error_log
[Fri Apr 05 10:55:51 2013] [error] [client x.x.x.x] Caught race condition abuser. attacker: 508, victim: 501 open file owner: 501, open file: /home/attackbase/public_html/victim.txt
Last edited:
cpanel race condition patch is useless if you want to use dso on the server or you have any files owned by nobody. I think there should be something between stevens911 patch and cpanel patch.
To be fair, if you're using DSO as your PHP handler then you've got plenty more to worry about than this patch when it comes to your server security!
It's not spam - it's intended to be constructive criticism. If you're trying to add security to your server in the form of this patch then I can't understand why you would use DSO at all as this opens up enough other issues. Personally, I would say that if you have a requirement for DSO, move it to a separate server where you can run this without risk to other sites. I fail to see though how you can easily secure a server with symlink protection where various sites are running files owned by the same user as this is open to much more than just an apache issue then.
I agree SuPHP is "better" security wise on servers with multiple sites, and obviously the symlink issue is a non-issue if you only host one site. Still, SuPHP is less efficient resource-wise than DSO, and adding the current cPanel patch makes it even less efficient. Also when you enable the patch, it doesn't mention that it will break serving of 'nobody' owned files.
While it is true that if you hack one site on a DSO server you would have access to all "nobody" owned files and dirs on the server across multiple sites, the configuration.php files are normally going to be owned by the username and not nobody. DSO vs SuPHP is going to make no difference in that case whatsoever. As a matter of fact, often hacked website cleanup is EASIER on a DSO server, because you know what directories are web writable. On a SuPHP server, if one site gets hacked, the hacker has write access to every single file on that site. Of course, without the symlink "hack" they can't get to other sites. You have to weigh your options; do you want the infection contained to just one site (SuPHP), or potentially everyones web-writable directores (DSO... but these directories are usually just images and wordpress uploads, etc.). I personally choose the SuPHP route, but the point is it's not a black and white issue and SuPHP is NOT a one-size-fits-all solution for PHP handling.
It would be very nice if both the rack911 style patch AND the patch currently added were both options in EasyApache. This would probably take cPanel devs 10 minutes of actual work. tops, and should have been done months ago. Sorry if that sounds rude, but it's true.
While it is true that if you hack one site on a DSO server you would have access to all "nobody" owned files and dirs on the server across multiple sites, the configuration.php files are normally going to be owned by the username and not nobody. DSO vs SuPHP is going to make no difference in that case whatsoever. As a matter of fact, often hacked website cleanup is EASIER on a DSO server, because you know what directories are web writable. On a SuPHP server, if one site gets hacked, the hacker has write access to every single file on that site. Of course, without the symlink "hack" they can't get to other sites. You have to weigh your options; do you want the infection contained to just one site (SuPHP), or potentially everyones web-writable directores (DSO... but these directories are usually just images and wordpress uploads, etc.). I personally choose the SuPHP route, but the point is it's not a black and white issue and SuPHP is NOT a one-size-fits-all solution for PHP handling.
It would be very nice if both the rack911 style patch AND the patch currently added were both options in EasyApache. This would probably take cPanel devs 10 minutes of actual work. tops, and should have been done months ago. Sorry if that sounds rude, but it's true.
Last edited:
- Status
| Thread starter | Similar threads | Forum | Replies | Date |
|---|---|---|---|---|
| K | Security Policy Handling Failed | Security | 4 | |
|
Solutions for handling ddos attacks? | Security | 3 | |
| P | Security Handling [improving the error message is CPANEL-5713] | Security | 2 | |
| H | Not find any solutions after my port 2086/2087 Blocked :'( | Security | 1 | |
| O | What anti-virus solutions? | Security | 93 |