Symlink attack, how to block.

[Paul Muloin]

Using plesk 12 installed fresh from the official plesk ubuntu 14.04 iso. latest uppdates

last week we had a mass defacement of websites via a symlink attack thru a compromised vhost.

Looks like they gained access to their user and then wrote data to all folders it could find in that group (which was everyone).

here is the kicker, all http docs folders belong to group psaserv. This default plesk behavior is what got us into trouble, allowing a comprimised user in that group to symlink everywhere. Also, by default apache follow symlinks was on. unsure if turning symlinks off is wise in the plesk environment if you want things to work properly.

Most other panels, from what ive read, don't clump all vhost users into the same group and wont have this issue.

Im guessing if we went around and changed group ownership to be unique per vhost, then plesk will fail to do things like backup and stuff.

Is there a way to prevent this kind of attack without breaking plesk?

 

[Paul Muloin]

Looks like a lot of this will simply go away with the inclusion of Mod_ruid2 in the next release of plesk. The other thing we can look at is migrate to cloudlinux+plesk.

so far no issues with symlinks off in apache.

 

[IgorG]

here is the kicker, all http docs folders belong to group psaserv.

That's true, but it's ok.

This default plesk behavior is what got us into trouble, allowing a comprimised user in that group to symlink everywhere.

This is incorrect. Currently in Plesk:

1. Any unix user can symlink anywhere, and it's ok.
2. `psaserv` by default does not have write permissions in vhost's httpdocs.
3. Subscription's (vhost's) system user isn't a member of `psaserv`.

Also, by default apache follow symlinks was on. unsure if turning symlinks off is wise in the plesk environment if you want things to work properly.

Apache's `FollowSymlink` is enabled by default because unfortunately some web applications, e.g. Drupal, cannot work with disabled `FollowSymlink` (but they should, this is a bug of the web application, it should use `SymLinksIfOwnerMatch` instead).
Plesk itself works fine with disabled `FollowSymlink`. If not - report bug to Odin - http://www.odin.com/support/plesk/bugreport/

Most other panels, from what ive read, don't clump all vhost users into the same group and wont have this issue.

This statement looks confusing. Currently in Plesk:

1. vhost's user is NOT a member of `psaserv`.
2. vhost's user is a member of `psacln`.
3. `psacln` does NOT have ANY access to vhost's directory.

So, in case of Plesk this is ok.

Is there a way to prevent this kind of attack without breaking plesk?

I don't know exactly which attack was used against you. There are two different problems mentioned above. Both of them are relevant.

1. Symlink attack related to apache's `FollowSymlink`.
In short, it is possible to fix, but not too easy. Plesk does everything it can by providing “Restrict the ability to follow symbolic links” option.
2.1. Problem of scripts executed with apache rights by mod_perl/mod_python.
In short, the best solution is not to allow mod_perl/mod_python at all. Use FastCGI. It is fundamentally impossible to fix fully.
2.2. Problem of scripts executed with apache rights by mod_php.
In short, the best solution is not to allow mod_php at all. Use PHP-FPM or FastCGI.
However mod_ruid2 could help. But need to use it with cautious (see below)!

Would you like me to describe smth. in details?
Do you allow use of mod_php/mod_perl/mod_python?

Looks like a lot of this will simply go away with the inclusion of Mod_ruid2 in the next release of plesk.

Unfortunately, mod_ruid2 is not a panacea. Even worse, it could weaken security very much!
https://github.com/mind04/mod-ruid2/issues/7
http://web.archive.org/web/20140807103455/http://lists.err.no/pipermail/mpm-itk/2013-September/000680.html