Solutions for handling symlink attacks

Status
Not open for further replies.

WillDashwood

Member
Oct 12, 2004
13
1
153
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.
 

quizknows

Well-Known Member
Oct 20, 2009
1,008
87
78
cPanel Access Level
DataCenter Provider
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.
 

vlim

Member
Jul 24, 2012
10
0
1
cPanel Access Level
DataCenter Provider
@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?
 

carl5

Registered
Feb 25, 2013
3
0
1
cPanel Access Level
Root Administrator
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>
 

Jeff Shotnik

Well-Known Member
Oct 10, 2012
61
0
6
Denver, Colorado, United States
cPanel Access Level
DataCenter Provider
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>
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.
 

carl5

Registered
Feb 25, 2013
3
0
1
cPanel Access Level
Root Administrator
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:

Spetsnaz

Well-Known Member
Jun 25, 2011
78
0
56
cPanel Access Level
Website Owner
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.
Where is Rack911's patch tut?
 

LDHosting

Well-Known Member
Jan 19, 2008
93
2
58
cPanel Access Level
Root Administrator
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.
 

AndyB78

Well-Known Member
Oct 7, 2003
80
2
158
Romania
cPanel Access Level
Root Administrator
The cpanel race condition patch did nothing.
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:

nospa

Well-Known Member
Apr 23, 2012
110
0
66
cPanel Access Level
Reseller Owner
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.
 

PenguinInternet

Well-Known Member
PartnerNOC
Jun 20, 2007
192
24
68
Cardiff, UK
cPanel Access Level
DataCenter Provider
Twitter
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.
 

quizknows

Well-Known Member
Oct 20, 2009
1,008
87
78
cPanel Access Level
DataCenter Provider
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.
 
Last edited:
Status
Not open for further replies.