Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
Uhh Hit em with a little Ghetto Gospel So am i less holy Because i Puff a blunt and Drink a Beer with my homies? Theres no Need for you to fear me if you Take your Time and Hear me Maybe you can learn to cheer me. It aint about Black and white cause we Human !!! Lord can you Hear me speaaak!! http://rapgenius.com/2pac-ghetto-gospel-lyrics Am 09.08.2013 um 16:33 schrieb Kingcope isowarez.isowarez.isowa...@googlemail.com: 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.isowa...@googlemail.com: 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.isowa...@googlemail.com: 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:
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
Uhh Hit em with a little Ghetto Gospel So am i less holy Because i Puff a blunt and Drink a Beer with my homies? Theres no Need for you to fear me if you Take your Time and Hear me Maybe you can learn to cheer me. It aint about Black and white cause we Human !!! Lord can you Hear me speaaak!! http://rapgenius.com/2pac-ghetto-gospel-lyrics Am 09.08.2013 um 16:33 schrieb Kingcope isowarez.isowarez.isowa...@googlemail.com: 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.isowa...@googlemail.com: 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.isowa...@googlemail.com: 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:
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
One thing u gotta remember most of the Admins who handle webservers in a network are also developers since most of the organizations will always need to cut on expenses, and as we know, most of the developers will just look into finishing work and making it work. So if something doesn't run due to httpd.conf, you will find these guys loosening server security, therefore opening holes to the infrastructure. Just my two cents ./Chucks On 8/10/13, Kingcope isowarez.isowarez.isowa...@googlemail.com wrote: Uhh Hit em with a little Ghetto Gospel So am i less holy Because i Puff a blunt and Drink a Beer with my homies? Theres no Need for you to fear me if you Take your Time and Hear me Maybe you can learn to cheer me. It aint about Black and white cause we Human !!! Lord can you Hear me speaaak!! http://rapgenius.com/2pac-ghetto-gospel-lyrics Am 09.08.2013 um 16:33 schrieb Kingcope isowarez.isowarez.isowa...@googlemail.com: 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.isowa...@googlemail.com: 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.isowa...@googlemail.com: 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
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
On Sat, Aug 10, 2013 at 6:10 AM, Gichuki John Chuksjonia chuksjo...@gmail.com wrote: One thing u gotta remember most of the Admins who handle webservers in a network are also developers since most of the organizations will always need to cut on expenses, and as we know, most of the developers will just look into finishing work and making it work. So if something doesn't run due to httpd.conf, you will find these guys loosening server security, therefore opening holes to the infrastructure. Cognitive Bias and Dissonance are well known problems in security engineering. NB's comments are a testament to the disconnect between the creators of the system and the users of the system. (No offense to NB). See, for example, Peter Gutmann's Engineering Security (www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf) or Ross Anderson's Security Engineering (http://www.cl.cam.ac.uk/~rja14/book.html). Jeff ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Using XXE vulnerabilities for attacks on other sites
Hello participants of Mailing List. I'll tell you about using XXE vulnerabilities for attacks on other sites (about it I already wrote last year). Those who haven't read my 2012's article Using XML External Entities (XXE) for attacks on other sites (http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/2012-August/008481.html) can do it now to remind this topic for themselves. In that article I've told about using XML External Entities (XXE) vulnerabilities (WASC-43) for conducting CSRF and DoS attacks on other sites. And in new article I continued this topic. In June I wrote new article Using XXE vulnerabilities for attacks on other sites, which I translated recently (http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/2013-August/008887.html). I described many new software and web applications, which are vulnerable to XXE, such as libraptor, Advanced XML Reader, PHP 5.3 and 5.4, WordPress 3.5 and 3.5.1 and Sybase EAServer. And mentioned about my tool for automation of such attacks - DAVOSET. Which can be used for conducting attacks on other sites via Abuse of Functionality vulnerabilities and I was planning to add support of attacks via XXE. Last month I released DAVOSET v.1.1.2 - DDoS attacks via other sites execution tool. In this version I added support of XML requests for XXE vulnerabilities. So now you can use XML External Entities (XXE) holes at web sites for conducting automated DoS and DDoS attacks on other sites. Best wishes regards, MustLive Administrator of Websecurity web site http://websecurity.com.ua ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
