issues with security

[John Seth]

I see this thread is getting old, but I can't help but put my two cents
in...

basically, I've never had an issue with PHP and I've always run the
latest apache. Upgrading to a non-stable release of PHP most likely
won't help. IMHO.  Secondly, one of my sites got hacked some time ago,
including an exploit. How? A file uploader I had left laying around and
forgotten about due to lack of use.  It was a cgi script.  I replaced
with with a homemade PHP script that does many checks, including making
sure something was posted, of a particular type (in this case, it's an
image uploader, so: jpg, gif & png), and from a particular referring
page, ie: not from an outside source "POST"'ing to my site.

As mentioned below, make sure there are no text boxes or ways for users
to enter information on the system via a webpage.  A perfect example
would be having a form for someone to run a system command... as an
example:

Command to Run:
[ gcc blackhole.c     ]

That combined with a file uploader may allow anyone to upload a fil,
compile and/or execute files of any type. It's not a PHP issue, it's a
coding issue.  Never trust what a user types, even if their a coworker
;)  That's my two cents.

 - Tony



Brad Bartram said:
> A couple of quick questions -
>
> Have you checked your firewall for signs of intrusion?  Especially if it
> is
> running with default passwords.
>
> blackhole.c takes two arguments - the name it should run under that it
> will
> display when viewed in ps and the port it should bind itself to listen
> to.
> What port was it listening on?  If it was other than 80 or 443, it may
> give a
> clue as to what happened - either your firewall was compromised to let
> the
> new listening port through or it was an automated attack like Justin
> suggested.
>
> In php, when dealing with file uploads or sessions, you have to be
> careful.
> (I know you asked mark, who is probably the best person to answer this,
> but
> I'm feeling verbose today ;-)).  Most of the php vulnerabilities in the
> last
> couple years have revolved around file uploads.  Whenever you let
> someone
> access your server to write data to the disk, there is a danger.
>
> Sessions are the exploit du jour as they allow for many neat tricks like
> cross
> site scripting and script exploitation through the use of session
> hijacking.
>
> Essentially what it all comes down to, is in any application where you
> must
> accept user input of any kind - never ever trust the user to provide
> good
> data.  Always check the input for invalid shell characters or data that
> could
> be passed in to execute other types of functions.
>
> Contrary to what I've seen many people say, PHP is a secure language as
> exploits in the core of the language are few and far between.  The
> problems
> with php tend to arise with bad technique - and with the ease with which
> php
> allows code to be written, bad technique is easy to use.
>
> brad
>
> On Monday 02 February 2004 01:57 pm, cliff at cliffmeyers.com wrote:
>> real quick, here's what I re-installed with after the hack:
>>
>> - Apache 1.3.29
>> - mod_ssl 2.8.16-1.3.29
>> - mm 1.1.3
>> - OpenSSL 0.9.7c
>> - PHP 4.3.4 (didn't use 4.3.5RC1 since it's not "stable", but I'm
>> going to
>> use it in my re-install tonight)
>> - and a bunch of other latest versions of source code, including zlib,
>> libpng, libjpeg, freetype, mysql and pgsql
>>
>> The box is firewalled by a Sonicwall hardware firewall.  The only
>> ports
>> open to the WAN are 80 and 443.  The only other services running on
>> the box
>> are sendmail (bound to localhost, used by PHP) and FTP which we IP
>> restrict.  Right now there are only 4 known IPs allowed to connect via
>> FTP
>> and they're all static IPs that our clients use.
>>
>> Now, the stupid choice I made was probably to use a backup of the
>> webroot
>> that was made after the system was compromised.  I suppose it's
>> possible
>> they left something in the web root that was allowing them to hack
>> their
>> way in.  So tonight, I will be re-installing again and making the
>> following
>> changes:
>>
>> (1)  Using PHP 4.3.5RC1
>> (2)  Using a backup about 3 weeks old, before the system was
>> compromised
>>
>> Someone suggested that I run "chkrootkit" from chkrootkit.org but that
>> didn't flag anything as being bad.  I changed the root password and
>> root
>> passwords on all other machines as soon as this happened.  As far as I
>> can
>> tell, the other 2 web servers I'm running (Apache with ColdFusion)
>> haven't
>> been touched.  This leads me to believe it was a PHP exploit.
>>
>> Mark, what kind of "bad code" in PHP might open this server up for
>> attack?
>> I don't have any CGIs or PHP code doing any kind of suexec type stuff,
>> although a bunch of scripts do allow file uploads (although most of
>> them
>> are behind HTTP-auth or PHP session-based authentication anyways).
>>
>> Thanks again everyone for your help and comments!  Any other ideas
>> would be
>> *greatly* appreciated.
>>
>>
>> -Cliff
>>
>> On Mon, 2 Feb 2004 13:20:17 -0500, "Mark Musone" wrote:
>> > There is an exploit for apache handling chunks, and also for
>> mod_ssl.
>> >
>> > Depending on whats running under php, there could be some bad
>> > programming, however it's most likely it's an apache thing. What
>> else
>> > are you allowing through your firewall?
>> >
>> > Although doing security audits and security monitoring for our
>> clients
>> > is a core part of our NOC group, we generally don’t do it as an
>> outside
>> > professional service, however if you are interested, feel free to
>> email
>> > me and I can see if we can set something up.
>> >
>> >
>> >
>> > -----Original Message-----
>> > From: owner-nflug at nflug.org [mailto:owner-nflug at nflug.org] On Behalf
>> Of
>> > cliff at cliffmeyers.com
>> > Sent: Monday, February 02, 2004 12:46 PM
>> > To: nflug at nflug.org
>> > Cc: Darin.Perusich at cognigencorp.com
>> > Subject: issues with security
>> >
>> > Hi Everyone,
>> >
>> >
>> > Apparently my first message didn't go through, so here I go again:
>> >
>> >
>> > I've been away from the list for a little while, but been having a
>> major
>> > problem
>> > here at the office so I figured I'd post to see if you guys had any
>> > ideas...
>> >
>> > On the 22nd we had an issue with one of our systems that I thought
>> had
>> > to do with
>> > some kind of hard drive error.  The system is a Red Hat Linux box,
>> > running
>> > primarily Apache and PHP to serve web sites.  I typically compile
>> these
>> > things
>> > from source so I can have a little more control over
>> configurability.
>> >
>> > Anyways, as it turned out, I noticed late last week that there were
>> > processes
>> > running that shouldn't be there.  After I killed the processes I
>> noticed
>> > files in
>> > the /tmp directory, where PHP stores most of the session files
>> (unless I
>> > tell it
>> > to store them somewhere else).  There was a 'blackhole.c' file and
>> some
>> > other
>> > things which had been compiled to run on my system.
>> >
>> > I talked to my other programmer and we were going to come in
>> Saturday to
>> > do a
>> > full re-install, but the hacker struck against Thursday night around
>> 11
>> > PM and
>> > defaced all of our sites.  I came into the office and spent the next
>> 8
>> > hours
>> > formatting, installing Red Hat 9, download all the newest source
>> code
>> > for Apache
>> > and PHP, and getting everything set up.
>> >
>> > Well, I get into work today, and guess what?  Another bad process
>> and
>> > more files
>> > in the /tmp folder.  I killed them all again, and am going to do
>> > *another*
>> > reinstall tonight.  I was e-mailing a colleague asking for his input
>> so
>> > I'll post
>> > a few of the ideas I had for how the hacker got back in.  Here they
>> are:
>> >
>> > (1)  I used the latest stable version of PHP, 4.3.4, when in fact
>> there
>> > is a new
>> > version, 4.3.5RC1.  I wanted to avoid a release candidate version
>> but
>> > that would
>> > be my first guess.
>> >
>> > (2)  Some other vulnerability I don't know about.  I installed the
>> > latest version
>> > of every other package so that's probably unlikely. Every other
>> service
>> > is
>> > firewalled, so...
>> >
>> > (3)  I used the web backup from the morning of the 30th so as to not
>> > loose any
>> > changes - perhaps there was something in there that it allowing the
>> > hacker to
>> > gain access again.
>> >
>> > (4)  A problem with some of our PHP code.  Again, not sure how
>> that's
>> > possible or
>> > what the issue might be.
>> >
>> > Does anyone have any other ideas?  Can anyone direct me (or offer)
>> > security
>> > consulting services to help take a look?  Is there any other
>> information
>> > I can
>> > provide?  This is the first time I've really dealt with this and my
>> > blood
>> > pressure is through the roof... thanks very much guys.
>> >
>> >
>> > -Cliff Meyers
>
>
>