[WEB SECURITY] AT&T exposes /etc/passwd , bad php

Rainsford, David rainsford at acer.edu.au
Mon Jul 27 20:50:44 EDT 2009


Some of the files are available at http://pastebin.com/f3708fa52

I get the feeling the server was just a ³toy² server for them and probably
was not hardened as much as you would expect www.att.com to be for example.
The /etc/passwd file shows a huge number of users and as they have UserDir
turned on any one of those users could have written some bad PHP code.  It
would be unrealistic to expect all code on this server to be properly
analysed for security holes, however I imagine the sysadmins are now reading
up on how to put Apache in a jail, which is at least one step they could
have taken to minimize this problem.  Add modsecurity to the mix and you¹re
half the way there!  It is definitely a lesson that security is important
regardless of whether the application is important, and that anything that
you put on the web should be treated as a potentially serious hole,
especially if that server has access to other machines on their network.

I don¹t think PHP is the culprit here, you can write insecure code in any
language.


On 28/7/09 10:03 AM, "Matt Parsons" <mparsons1980 at gmail.com> wrote:

> I wonder if AT&T did a security review of this application.  If you had one of
> the leading vendor tools you could have done a source code analysis of the
> code in php and prevent this from happening.   In the future, companies like
> AT&T should consider reviewing their PHP code from both a white box and black
> box.  At a minimum, I would consider making sure there was proper permissions
> on that file.   Personally, I would have written the application in a language
> that is a bit more secure like .NET or Java.
>  
> Matt
>  
>  
> Matt Parsons, CISSP
> 315-559-3588 Blackberry
> 817-238-3325 Home office
> mparsons1980 at gmail.com
> www.parsonsisconsulting.com
>  
> 
>  
> 
> From: Kevin Stewart [mailto:kevin.g.stewart at gmail.com]
> Sent: Monday, July 27, 2009 6:21 PM
> To: Michael Condon
> Cc: Shane Forsythe; websecurity at webappsec.org
> Subject: Re: [WEB SECURITY] AT&T exposes /etc/passwd , bad php
>  
> By the way, the AT&T url breaks semantics by allowing a write condition in a
> GET request. Not that leaving an open ended "page=" in a form post would have
> been any better...
> 
> Kevin S.
> 
> On Mon, Jul 27, 2009 at 7:19 PM, Kevin Stewart <kevin.g.stewart at gmail.com>
> wrote:
> It is semantically correct to use a GET (and querystring) when the request
> will not write or change data.
> 
> (see: http://www.w3.org/2001/tag/doc/whenToUseGet.html).
> 
> At a minimum though, you cannot bookmark POST requests and their responses are
> usually not cached - two very important performance and usability
> considerations.
> 
> Kevin S.
> 
> 
> 
> On Mon, Jul 27, 2009 at 4:11 PM, Michael Condon
> <admin at singulartechnologysolutions.com> wrote:
> Can anyone convince me (or anyone else) why I should ever use a QUERY_STRING
> in a URL?
> 
> 
> -----Original Message-----
> From: Shane Forsythe [mailto:shane.forsythe at fau.edu]
> Sent: Monday, July 27, 2009 1:09 PM
> To: websecurity at webappsec.org
> Subject: [WEB SECURITY] AT&T exposes /etc/passwd , bad php
> 
> In an amazing example of how not to do file operations with php.  AT&T
> has the following URL
> 
> http://www.research.att.com/areas/visualization/papers_videos/subpage.php?pa
> ge=
> 
> You can add ANY file to the end and will happily retrieve for you,
> though I'd suggest not actually testing it out
> (some examples that were vurnable)
> ../../../../proc/cpuinfo
> /etc/passwd
> 
> It appears they have taken page offload and our now aware of it, but if
> you follow the comments here, it was active for a good portion and
> thoroughly combed over
> http://www.reddit.com/r/programming/comments/94z5w/att_exposes_etcpasswd_bad
> _php/ 
> <http://www.reddit.com/r/programming/comments/94z5w/att_exposes_etcpasswd_bad%
> 0A_php/> 
> 
> 
> This seems to be an escalating of AT&T event regarding 4chan
> 
> 
> 
> 
> 
> 
> ----------------------------------------------------------------------------
> Join us on IRC: irc.freenode.net <http://irc.freenode.net> #webappsec
> 
> Have a question? Search The Web Security Mailing List Archives:
> http://www.webappsec.org/lists/websecurity/archive/
> 
> Subscribe via RSS:
> http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
> 
> Join WASC on LinkedIn
> http://www.linkedin.com/e/gis/83336/4B20E4374DBA
> 
> 
> 
> ----------------------------------------------------------------------------
> Join us on IRC: irc.freenode.net <http://irc.freenode.net> #webappsec
> 
> Have a question? Search The Web Security Mailing List Archives:
> http://www.webappsec.org/lists/websecurity/archive/
> 
> Subscribe via RSS:
> http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
> 
> Join WASC on LinkedIn
> http://www.linkedin.com/e/gis/83336/4B20E4374DBA
> 
> 


-------------------------------------------------
Please consider the environment before you print
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20090728/80db0c74/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.jpg
Type: image/jpeg
Size: 2509 bytes
Desc: not available
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20090728/80db0c74/attachment.jpg>


More information about the websecurity mailing list