On Sun, 22 Aug 2010, Keith Roberts wrote:

On my Fedora 12 server, searching for 'proc/self/environ' I found the following in my apache log files:

www.php-debuggers.net 66.179.32.5 - - [21/Aug/2010:18:56:10 +0100] "GET /file.php?file []=../../../../../../../../../../../../../../../proc/self/environ%00 HTTP/1.1" 404 352

They didn't get much though, except a 404 error message.

Keith, Eero and others,

Thanks. They got a 404 error with me, obviously...but I wanted to make sure it was nothing more than that.

Gilbert

******************************************************************************* Gilbert Sebenste ******** (My opinions only!) ****** *******************************************************************************

On 08/22/2010 03:05 PM, Gilbert Sebenste wrote:

Thanks. They got a 404 error with me, obviously...but I wanted to make sure it was nothing more than that.

No, they didn't. That's why you were warned that it was a potentially successful probe.

The exploit requires that you are running php and have a script that includes a file referenced by the global variable "g" (or maybe the http request varible "g"). You should check the files that appear at the URLs indicated in your logs. If any of those files are php, then you should further check those to see if they might include files based on the "g" variable. If so, you may have been compromised.

On Sun, 22 Aug 2010, Gordon Messmer wrote:

To: CentOS mailing list centos@centos.org From: Gordon Messmer yinyang@eburg.com Subject: Re: [CentOS] Strange Apache log entry

On 08/22/2010 03:05 PM, Gilbert Sebenste wrote:

...

Thanks. They got a 404 error with me, obviously...but I wanted to make sure it was nothing more than that.

No, they didn't. That's why you were warned that it was a potentially successful probe.

The exploit requires that you are running php and have a script that includes a file referenced by the global variable "g" (or maybe the http request varible "g"). You should check the files that appear at the URLs indicated in your logs. If any of those files are php, then you should further check those to see if they might include files based on the "g" variable. If so, you may have been compromised. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

So bolting down PHP really tight should address these hacks?

Keith

----------------------------------------------------------------- Websites: http://www.php-debuggers.net http://www.karsites.net http://www.raised-from-the-dead.org.uk

All email addresses are challenge-response protected with TMDA [http://tmda.net] -----------------------------------------------------------------

On Wed, 25 Aug 2010, Gordon Messmer wrote:

To: CentOS mailing list centos@centos.org From: Gordon Messmer yinyang@eburg.com Subject: Re: [CentOS] Strange Apache log entry

On 08/24/2010 04:25 AM, Keith Roberts wrote:

...

So bolting down PHP really tight should address these hacks?

No. This vulnerability would be in a PHP application. I don't believe you could configure PHP in such a way that this would no longer be a problem.

Hi Gordon.

register_globals is supposed to be off by default - so that should stop any global variables being injected.

; You should do your best to write your scripts so that they do not require ; register_globals to be on; Using form variables as globals can easily lead ; to possible security problems, if the code is not very well thought of. ; http://www.php.net/manual/en/ini.core.php#ini.register-globals register_globals = Off

; open_basedir, if set, limits all file operations to the defined directory ; and below. This directive makes most sense if used in a per-directory ; or per-virtualhost web server configuration file. This directive is ; *NOT* affected by whether Safe Mode is turned On or Off. ; http://www.php.net/manual/en/ini.sect.safe-mode.php#ini.open-basedir ;open_basedir =""

; display_errors ; ; This directive controls whether or not and where PHP will output errors, ; notices and warnings too. Error output is very useful during development, but ; it could be very dangerous in production environments. Depending on the code ; which is triggering the error, sensitive information could potentially leak ; out of your application such as database usernames and passwords or worse. ; It's recommended that errors be logged on production servers rather than ; having the errors sent to STDOUT. ; Possible Values: ; Off = Do not display any errors ; stderr = Display errors to STDERR (affects only CGI/CLI binaries!) ; On or stdout = Display errors to STDOUT ; Default Value: On ; Development Value: On ; Production Value: Off ; http://www.php.net/manual/en/errorfunc.configuration.php#ini.display-errors

; Print out errors (as a part of the output). For production web sites, ; you're strongly encouraged to turn this feature off, and use error logging ; instead (see below). display_errors = OFF

I'm sure there are other things that can be configured to nake this attack much more difficult.

Kind Regards,

Keith

----------------------------------------------------------------- Websites: http://www.php-debuggers.net http://www.karsites.net http://www.raised-from-the-dead.org.uk

All email addresses are challenge-response protected with TMDA [http://tmda.net] -----------------------------------------------------------------

On 8/24/10, Keith Roberts keith@karsites.net wrote:

So bolting down PHP really tight should address these hacks?

As others have mentioned, this is trying to take advantage of a poorly written PHP script that doesn't sanitize/check the input before using. However, you could possibly lock down PHP further to reduce the possibility of such apps working by using the disabled_function setting to disable the riskier functions which allow shell/command/file operations. Of course depending on how aggressive you are, it could lead to scripts breaking.

On 08/27/2010 09:08 PM, Emmanuel Noobadmin wrote:

However, you could possibly lock down PHP further to reduce the possibility of such apps working by using the disabled_function setting to disable the riskier functions which allow shell/command/file operations. Of course depending on how aggressive you are, it could lead to scripts breaking.

You'd have to disable file include() and require(), which would break everything.

On 08/28/2010 05:30 AM, Stephen Harris wrote:

In general it's not just PHP; it could be perl, script.. anything eg this extremely bad and broken CGI program:

That's true, but /proc/environ isn't in a format that's valid for most languages. If a PHP script can be made to include /proc/environ, code can be injected by the caller. For instance, their Agent string could include PHP code which would end up executed. Other languages may not be as prone to that specific issue.

On 08/29/2010 05:51 AM, Stephen Harris wrote:

There's nothing special about /proc/$$/environ. All the variables in there are already available to the process. eg

Yes, and the shell could even be made to do as you wanted if you could convince a script to "source /proc/$$/environ". You don't see many web services written in POSIX sh, though.

Badly written CGI programs are badly written CGI programs no matter what language they're written in. The exact nature of the exploit may be different, but they all fall into a similar class - the programmer ****ed up.

Yes, that's true, but the original message in this thread saw an attempt to load /proc/self/environ through a php script. You're getting pretty far off topic, now.

On Sun, 29 Aug 2010, Nataraj wrote:

I think running apache in a chroot environment might be one of the most effective protections. I used to do that in the past, but I found it too much work to maintain. Now there are things like mod_chroot and perhaps other tools, but I have no experience with them and don't know if they make it easier.

Nataraj

Getting really OT now.

Why cannot each Linux distro provide a chroot package that works "out of the box" for that particular distro?

So when there are updates, the whole package could be updated?

Keith

Emmanuel Noobadmin wrote:

On 8/24/10, Keith Roberts keith@karsites.net wrote:

...

So bolting down PHP really tight should address these hacks?

As others have mentioned, this is trying to take advantage of a poorly written PHP script that doesn't sanitize/check the input before using. However, you could possibly lock down PHP further to reduce the possibility of such apps working by using the disabled_function setting to disable the riskier functions which allow shell/command/file operations. Of course depending on how aggressive you are, it could lead to scripts breaking.

The best way to attack this problem is to take a close look at the known issues and make sure your code doesn't expose any of them. Start by reading the OWASP[1] web site. Their annual Top Ten[2] list of vulnerabilities is a good place to start. They also have sample code snippets in a variety of languages to sanitize and validate input. We utilize both their recommendations and code in a number of our sites. It gives us a good start toward PCI compliance.

Another excellent resource is the "SANS-CWE Top 25 Most Dangerous Programming Errors"[3]. This applies to all applications that have network access, not just web pages. The press release[4] explains what the list contains.

Bob McConnell N2SPP

[1] http://www.owasp.org/index.php/Main_Page [2] http://www.owasp.org/index.php/OWASP_Top_Ten_Project [3] http://www.sans.org/top25-software-errors/ [4] http://www.sans.org/top25-software-errors/press-release.php