Question Possible security issue?

[Dree]

1 of my shared hosting servers running Plesk 12.5 was hacked from 1 vhost.
Scripts were uploaded into a compromised CMS, which created symlinks to config-files of all other vhosts on the server.

These symlinks were created using CGI/Perl. All files of other users were readable.
All this was made possible because of a simple .htaccess which enabled CGI and FollowSymLinks.

Right now I think I tackled the issue by configuring nginx to allow symlinks only to files of the same users.
But straight out of the box Plesk seems to be vulnerable to this.

Any thoughts on this?

 

[Dree]

No-one seems to be interested and Odin made it pretty much impossible to create a support ticket.
I don't want to put this hack in the open, so please contact me?

 

[IgorG]

@AndreyZ will reply you soon.

 

[AndreyZ]

Hello,
Sorry for the delay.

This is known issue. It was addressed in Plesk 12.0: the option Restrict the ability to follow symbolic links was introduced.
But this option is switched off by default, because it breaks some applications. (At that moment some widely used applications, e.g. Drupal, became broken.) Now we are considering the possibility of switching it on by default.

Anyway, I advice to use kernel-based symlink attack protection. E.g. Grsecurity. Or if you use CloudLinux, you can use SecureLinks in mod_hostinglimits.

Extra references:
- https://docs.plesk.com/en-US/12.5/a...ns-and-subscriptions/web-server-apache.72120/
- https://docs.plesk.com/en-US/12.5/c...e-utilities/service_plan-hosting-plans.38365/
- https://forums.grsecurity.net/viewtopic.php?f=3&t=3175

 

[Bitpalast]

A question on this case, please: Isn't it also possible with Perl enabled in a subscription to access any other file on the host computer beyond the cage of user's subscription? As far as we had tested that, users who have execution rights for Perl can easily read and write system files and influence system services, because Perl is not limited to the chroot shell. So isn't the security gap in the first place enabling Perl in subscriptions? Asking seriously for your opinion.

 

[AndreyZ]

Perl scripts served by apaches's `mod_perl` are executed with apache's rights, so yes, this is insecure in shared hosting environment: it is possible to read/write files accessible to apache system user.
Perl support should be switched off in shared hosting environment.

However CGI applications are executed on behalf of subscription's system user, so CGI applications written in Perl are limited enough.
CGI support is OK in shared hosting environment.

 

[Dree]

If I may be completely honest:
I don't think it's best practice to release a product that's vulnerable to attacks out of the box.
Close all holes and let customers open them if they want to take the risk.

I also added this to the nginx-config, perhaps it's worth considering adding it to the default config:

disable_symlinks if_not_owner;

Since we run nginx and apache, it's still possible to hack-around this by requesting the apache port :7080 instead of nginx, but I'm firewalling that now for remote IP's.

 

[AndreyZ]

it's worth considering adding it to the default config

Yes, this is already done in Plesk 17.0. I hope this will be backported to Plesk 12.5 soon. Thank you.

"disable_symlinks if_not_owner" is in effect (and is required for security) only when Serve static files directly by nginx is switched on.
Otherwise Apache serves static files using `mod_aclr`, and "disable_symlinks if_not_owner" has no effect.

And all this (Serve static files directly by nginx, "disable_symlinks if_not_owner", and firewalling :7080) do not prevent serving malicious symlinks by Apache: nginx rejects serving static file (because it is a malicious symlink), but redirects the request to Apache (as fallback).

So Restrict the ability to follow symbolic links and kernel-based symlink attack protection are still required.

 

[Dree]

Another addition to this topic.
Don't use Cloudlinux to block the creation of Symlinks that are insecure. It will break Plesk, you won't be able to add subscriptions anymore because it uses a symlink.
I'm still in talks with Cloudlinux for a good solution.

 

[AndreyZ]

Actually, SecureLinks (specifically, Symlink Owner Match Protection - that is what we need) works out of the box in CloudLinux 6.

Unfortunately, Symlink Owner Match Protection does not work in CloudLinux 7 now. ID of this bug is CLKRN-57. Bug ID will be into kernel release note (follow https://www.cloudlinux.com/blog) when the issue will be fixed by CloudLinux team.

You can check Symlink Owner Match Protection configuration like this:

[centos@ip-172-31-16-7 ~]$ sudo sysctl -a | grep -E '(fs.enforce_symlinksifowner|fs.symlinkown_gid)'
fs.enforce_symlinksifowner = 1
fs.symlinkown_gid = 48

Theoretically, this should not break Plesk, because only apache process (gid 48) should be affected.
Practically, this does not break Plesk and protects from the symlink attack. I have checked this on fresh AWS EC2 instance, using the following resources:

• CentOS 6 image: https://aws.amazon.com/marketplace/pp/B00NQAYLWO
• CloudLinux installation doc: http://docs.cloudlinux.com/index.html?converting_existing_servers.html
  
• Plesk installation doc: http://page.plesk.com/plesk-free-download-wp