Portal Home > Knowledgebase > Articles Database > Unauthorized Symlink


Unauthorized Symlink




Posted by albatroz, 06-25-2015, 04:51 PM
Thanks to CXS I have just discovered some symlimks not created by me that were inside a website we recently moved to our server as you can see in the attached picture. Are they safe to delete?

Posted by HelpOps, 06-25-2015, 05:37 PM
Yes, you should be able to delete them, as there should be no links inside of those accounts that symlink to root. It appears they may have been used for unauthorized backdoor shells. More then likely the application the user is hosting is running insecure code and may have backdoor scripts inside them. I would recommend checking with your customer on the backstory on what happened.

Posted by iserversupport, 06-26-2015, 02:25 PM
Use this command you can list all the Symlink's inside the folder, make sure to run it inside "public_html" find . -type l -print -ls

Posted by Srv24x7, 06-27-2015, 12:27 PM
Hi, The account that you have just moved to your server is a compromised account. I would suggest you get your server audited immediately, as the links you showed are the root symlinks and probably those will exploit your server if they are not properly removed. Unlink then before you remove them. Please make sure you have audited this account properly, as the hacker may follow this website to exploit it again and you may risk your server with this too. This should not be taken lightly as it could lead your server to be compromised too.

Posted by sabrina84, 06-27-2015, 06:10 PM
Hi albatroz, you did not mentioned your environment detail, you just migrated server, host changes or hardware obsolete migrated to new hardware?. First rule of migration is that new server is properly patched with latest updates and scanning software, so when you start transferring your website from one server to another, you come to know the difference, because in old server might be some garbage is there and that require cleaning, because mostly developers does alot of testing during coding and codes are always there with alot of loop holes and it can damage the website/server as well. Last edited by Postbox; 07-04-2015 at 10:10 PM.

Posted by brianoz, 06-27-2015, 08:15 PM
Seriously bad advice; there is virtually no risk to your server and the poster's comments make very little sense technically. I'd check though that the symlinks don't work, if they did, you have your server misconfigured and need to setup some form of symlink protection or install CloudLinux. This is a standard technique for attempting to find other accounts on a server and if they all point to root (/) it's possible the attack didn't get to go further as they often then try to enumerate all the accounts on the server, using the symlinks to download wp-config.php files (and similar for other CMSes).

Posted by Srv24x7, 06-28-2015, 12:29 PM
The fact that you dont agree clearly states that you have not came across any such situation. I have checked most of the hack attempts that the hacker makes while I do security of the server. Once you have root symlink in place, there are 95% chances of user configurations being exploit with this. I think you should try this first and make comments. Although you may not be able to get access to most system files, but passwd is exploited very easily with this and once this is exploited, you get all the information of the user through it because this file is readable by user, although not writable. Try uploading simple PHP shell. Whenever you see a root symlink, you go to be careful and this is know by almost all the security specialist too. If you consult any security specialist and tell him you saw root symlink, first advise you will get is audit your server on priority to check if it has not spread.

Posted by Johnny Cache, 06-28-2015, 01:58 PM
Seriously not a good idea to suggest that a working symlink to [/] "didn't go farther than" [/]. That's because once you're there, you're there. There's no "farther" left to go. That's the end of the road. Trip's over. Done walikin'. A couple of years ago, when this was of major concern, there were many, many ways of making this work. I believe securi.net titled their blog "From Account Compromise To Full Root Access". Snacks for thought. Assumption should never be a part of analyzing a system compromise of any level.

Posted by brianoz, 06-28-2015, 07:55 PM
An eminently reasonable point; I didn't intend to imply that the root link definitely hadn't gone further. It would depend on whether they had Apache symlink protection enabled and/or CloudLinux installed. If they did, it would have gone no further. As you say, when this was an issue there were ways of making it work, but there were equally strong ways of preventing it from working that most of us had running (eg: enforcing file permissions was one of them, on top of Apache symlink protection). All about multiple layers ... Actually, the security specialist would know that it's not a problem if the server is properly protected. What the security specialist would say is to check that you have the server properly protected, then no further auditing would be needed. Again, if you have the correct(*) symlink protection in Apache, and/or CloudLinux, symlinks cannot be exploited. In CloudLinux, perhaps you could explore your CageFS area, but that's it, and it's mostly locked down anyway. Re your comment about a PHP shell, an uploaded PHP shell is very limited on a system protected by CloudLinux. Granted, it's always the first step towards root level compromise but on a properly patched kernel, that's also harder than you'd think. (*) there is an Apache symlink owner check that cannot be disabled via .htaccess Last edited by brianoz; 06-28-2015 at 08:03 PM.

Posted by SneakySysadmin, 06-29-2015, 05:47 PM
Seriously? No. A symlink to the root directory of the server isn't going to compromise it. It might disclose information you don't want disclosed, or if on a shared server might disclose other customers data - but exploit the server it won't... and a properly configured Apache isn't going to follow those symlinks anyway - so there's that. Apache should be configured to only follow symlinks if the owner matches. This kind of nervous-nelly hyperbole is uncalled for from someone with "Server Management, Server Security" in their sig. Does the site need to be investigated? Absolutely. Is it an OMG THE WORLD IS ENDING issue? Absolutely not.

Posted by tuhostmx, 06-29-2015, 10:35 PM
1000000% AGREE

Posted by Srv24x7, 06-30-2015, 02:28 AM
So you are suggesting Its not a security risk because the hacker can navigate through the entire file system ? Asking to disclose information that you don't want is a security breach in itself. So as i suggested this should not be taken lightly. Seriously ? YES I will suggest you get your facts clear about this -- Read this if you have some time https://blog.sucuri.net/2013/05/from...ot-part-i.html

Posted by SneakySysadmin, 06-30-2015, 01:48 PM
If you want to embrace your Straw Man please don't do it in public this way. No one, least of all myself, said it wasn't a security risk. I said it wasn't going to compromise the server - which is what you claimed. Also, please allow me to point out the obvious that you seem to have completely overlooked? If they can CREATE a symlink? They can already do everything that seems to be terrifying you? If they can create their own bloody files they ALREADY have sufficient privileges to navigate the file system and, if they find a vulnerability elsewhere, can leverage that access to a root compromise. The SYMLINK does not do that, especially a symlink on a migrated site - because it means the intruder that presumably compromised the original site has, for at least the time being, been left behind. That blog post appears to have been written by someone with as little real experience as you appear to have. Privilege escalation is nothing new. If a site is compromised, as this one may in fact be, then the intruder may be able to compromise the server from that. This Is Not News. ... and the fact that they use an "old trick" to symlink to '/' ? If the symlink is what scares you then you're underthinking this as much as the blog author is. The symlink is not the threat, and is certainly no threat to a properly configured web server... It's the fact that the intruder can create their own damn files that should be scaring the hell out of you.

Posted by brianoz, 06-30-2015, 10:38 PM
Interestingly, to change the topic just a little, has anyone noticed that the volume/type of attacks seems to be steadily climbing? We did a review of some of our servers a little over a year ago before introducing the current set of protections we have and found around 30% of sites had some form of compromised file on them, and that's with some mod_security protection! I wonder what percentage it would be on those hosts that offer virtually no protection? We've regularly had people move sites to us and not get hacked again. I wouldn't be surprised to see figures like 50%+ on unprotected hosts.

Posted by Srv24x7, 07-02-2015, 12:09 PM
This is what your statement was "A symlink to the root directory of the server isn't going to compromise it. It mightdisclose information you don't want disclosed, or if on a shared server might disclose other customers data" I think you should test things before you comment anything. Thing I mentioned is purely what I have tested. Give it a try yourself. Probably get an appointment fix with a professional hacker (white hat hacker) and get your doubts cleared on this... I have tested this on a live production server. I think you should just do the same and see the level of penetration that a root symlink can cause.

Posted by brianoz, 07-04-2015, 11:43 AM
Some of us here are white hats. Happy to offer some limited help to anyone struggling with this. Seriously, how many times do people who know this better than you have to tell you - yes, we've tested it, yes we've all seen it many times, and no it doesn't "penetrate" or compromise the server. I suspect your problem here is that you don't know the difference between full compromise (concerning) and information disclosure (not concerning in this specific case). "Compromise" as used in this thread means that they have root level access to the server and can change files etc, and move between accounts. "Information disclosure" means they can look around a little, usually only in the account they've attacked. Now, to a related point: if you can use that link to browse your server, your server isn't secure because you haven't set it up properly to be protected from symlinks. Check the links in my signature for how to fix this, or get CloudLinux installed. As an example, these symlinks do nothing on our servers as we have those common and well understood fixes installed, and they make the symlinks unusable. I suspect, from what you say, that they do work on your server, which is why you're so confused, and if I was you I'd fix things so they don't work, and make sure that you understand well how to provide this very important and key concept as a service to your customers, if you are planning to continue offering admin services. All of us have been corrected at least once in this forum over the years - for me, I'm sure it's been many times. Annoying though it is to be wrong publicly, it's part of life and we've all been there at least once. WHT has some of the top experts on the planet reading it and until you get 10 or 20 years under your belt it's pretty hard to match the skills of some of the amazing folks here. Again, if you're offering public advice, please be particular you are right or myself and others will need to continue to correct you, as wrong information in this forum can be really dangerous.

Posted by Dilstar, 07-04-2015, 12:24 PM
i dont want to use cloud linux, just dont want to. so what will be the best way to do, i have read that, mod ruid + jail can resolve that issue, but how about the permsisions



Was this answer helpful?

Add to Favourites Add to Favourites    Print this Article Print this Article

Also Read
DDoS Protection (Views: 701)
ezzi.net down? (Views: 624)
Advertisment option (Views: 621)

Language: