suPHP bypass Hack

A

astra

Verified User
Joined
Mar 4, 2009
Messages
94
Dear DA Users,

We are using for years suPHP on our sharehosting servers with success till today.

Also we use http://help.directadmin.com/item.php?id=247 for installation.

Code: 
Safe Mode OFF
Open BaseDir ON

disable_functions:exec,system,passthru,shell_exec,escapeshellarg,escapeshellcmd,proc_close,proc_open,dl,popen,show_source	exec,system,passthru,shell_exec,escapeshellarg,escapeshellcmd,proc_close,proc_open,dl,popen,show_source

/tmp noexec
chgrp apache /usr/bin/perl /usr/bin/wget /usr/local/bin/wget /usr/local/bin/curl /usr/bin/curl /usr/bin/python

chmod 705 /usr/bin/perl /usr/bin/wget /usr/local/bin/wget /usr/local/bin/curl /usr/bin/curl /usr/bin/python


There scan on old joomla installations like 1.5.x 1.6.x 1.7.x and slipstream an upload file into the folder images/stories/* and replace all the index.* files in the server.

Yes i know users need always update there joomla to the last stable version.

But my biggest concern now is how there bypass suphp? it works for years great, bud it seems the hackers found a way to bypass this security.

Back into the days with CLI modes there did always the same trick, so thats why we switch to suPHP CGI/FastCGI modes.

There use tooling named webr00t cgi shell and make a symbolic link link to /root

Is there someone with the same problem?
 
You mention Joomla and replaced files in images/stories/* - I have seen that happen on some of my customers, and it has always been because of outdated insecure version of JCE in Joomla. I would be 99% sure that this is the problem for you, because you say it happens in images/stories/* - you should make sure your customers upgrade JCE to the newest version. Read more here http://www.joomlacontenteditor.net/news/item/jce-and-your-sites-security

Next thing is that you are talking about hackers making a symbolic link to /root - that is possible because you are not using harden-symlinks-patch, please do step number 2 here: http://help.directadmin.com/item.php?id=421
 
Hi Ditto,

Thanks for your reply.

We have:
secure_htaccess=no
harden-symlinks-patch=yes

There use .htaccess with:

Code: 
Options FollowSymLinks MultiViews Indexes ExecCGI

AddType application/x-httpd-cgi .cin

AddHandler cgi-script .cin
AddHandler cgi-script .cin

****
OR:
****

Options FollowSymLinks MultiViews Indexes ExecCGI

AddType application/x-httpd-cgi .root

AddHandler cgi-script .root
AddHandler cgi-script .root

I gonna look for a good solution to scan on joomla version on a server.
 
Last edited:
There is a version.php file in the joomla folder that has that information.
 
Oke we analyses the logs and found the same way from different hackers:

.htaccess hacker1

Code: 
Options FollowSymLinks MultiViews Indexes ExecCGI

AddType application/x-httpd-cgi .cin

AddHandler cgi-script .cin
AddHandler cgi-script .cin

and suexec_log

Code: 
[2013-01-22 08:33:59]: uid: (613/customer1) gid: (614/customer1) cmd: izo.cin
[2013-01-22 08:34:02]: uid: (613/customer1) gid: (614/customer1) cmd: izo.cin
[2013-01-22 08:34:23]: uid: (613/customer1) gid: (614/customer1) cmd: izo.cin


.htaccess hacker2

Code: 
Options FollowSymLinks MultiViews Indexes ExecCGI

AddType application/x-httpd-cgi .root

AddHandler cgi-script .root
AddHandler cgi-script .root

and suexec_log

Code: 
[2013-01-22 15:17:31]: uid: (915/customer2) gid: (916/customer2) cmd: web.root
[2013-01-22 15:17:34]: uid: (915/customer2) gid: (916/customer2) cmd: web.root
[2013-01-22 15:17:36]: uid: (915/customer2) gid: (916/customer2) cmd: web.root

It seems that the http://help.directadmin.com/item.php?id=421 patch not working well because there use FollowSymLinks to access the system.

Both customers are on a separate server.

Is there some that can tell how to test if http://help.directadmin.com/item.php?id=421 works on my system?

Thx.
 
suphp only protects php files not cgi scripts. You should use php-fpm or ruid then.
 
Hello,

Fistly, to prevent panic, I'm seeing no "suPhp bypass", in case anyone was wondering.

From what I'm seeing:

1) Insecure php script allows files to be uploaded. Don't use old/insecure scripts.

2) They likely uploaded new php files then ran them to add .htaccess, since suPhp has write access to disk at that User, as designed.

3) Then they're using cgi-bin to run things as the User.. not too far off from suPhp anyway.. so nothing too surprising there.
For 1.42.2 we have changed the cgi-bin part in the templates, to better shut off cgi-bin access if they're not allowed.

4) the symlinks patch only applies to files read by apache.. it doesn't apply to php or cgi-bin scripts.
To test it, create a link where the owner of the link doesn't match the owner of the file it points to. Remember to use "chown -h" to change ownership of a link (in case you create it as root).
Then view that link through apache, which should be rejected, if it's pointing to a file with a different owner.
The option they've added to .htacess is FollowSymlinks, which (if the patch is enabled) is internally converted to "SymLinksIfOwnerMatch".. so the link's ownership must match the ownership of the file it points to, else it will throw an internal server error.
This is to prevent the "apache" user from wandering into other account folders, since apache can see all User's directories. Php in CLI has open_basedir to prevent wandering. The secure_access_group takes care of the rest (cgi, suPhp, cron, ssh).

5) Using php-fpm or ruid wouldn't change much in this case.. the main issue is just the insecure php script.. the rest is not too alarming. The link to /root likely was not usable at any point, since root shouldn't be able to be gained. Sure, they created it to try, but it's not likely it was able to see in.


The general rule is to only allow a User/Domain/Script what it needs, and nothing more.

suPhp is great if your php scripts need write access to disk... prevents the need for 777 directories, or chowning to apcahe.
If your php scripts don't need it, then use CLI.. as it would save you if you've got an insecure php script (runs as "apache", has no write access).

Hope this helps!

John
 
Is this symlink flaw different to:
Apache 2.2.17 October 18 said:
  • core: check symlink ownership if both FollowSymlinks and SymlinksIfOwnerMatch are set [Nick Kew]
  • core: fix origin checking in SymlinksIfOwnerMatch PR 36783 [Robert L Mathews ]
Click to expand...
 
I'm not sure that apache symlink path we use is related to the changes to apache bugfixes.

To enable cgi for one user, enable it in that User's settings as normal.
Disable it for anyone who doesn't need it.

John
 
You must log in or register to reply here.
Back
Top