issues with security
johnseth at phoenixwing.com
Mon Feb 2 16:52:09 EST 2004
I see this thread is getting old, but I can't help but put my two cents
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
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.
Brad Bartram said:
> A couple of quick questions -
> Have you checked your firewall for signs of intrusion? Especially if it
> running with default passwords.
> blackhole.c takes two arguments - the name it should run under that it
> display when viewed in ps and the port it should bind itself to listen
> 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
> new listening port through or it was an automated attack like Justin
> In php, when dealing with file uploads or sessions, you have to be
> (I know you asked mark, who is probably the best person to answer this,
> I'm feeling verbose today ;-)). Most of the php vulnerabilities in the
> couple years have revolved around file uploads. Whenever you let
> 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
> site scripting and script exploitation through the use of session
> Essentially what it all comes down to, is in any application where you
> accept user input of any kind - never ever trust the user to provide
> data. Always check the input for invalid shell characters or data that
> 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
> with php tend to arise with bad technique - and with the ease with which
> allows code to be written, bad technique is easy to use.
> 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
>> 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
>> and they're all static IPs that our clients use.
>> Now, the stupid choice I made was probably to use a backup of the
>> that was made after the system was compromised. I suppose it's
>> they left something in the web root that was allowing them to hack
>> way in. So tonight, I will be re-installing again and making the
>> (1) Using PHP 4.3.5RC1
>> (2) Using a backup about 3 weeks old, before the system was
>> Someone suggested that I run "chkrootkit" from chkrootkit.org but that
>> didn't flag anything as being bad. I changed the root password and
>> passwords on all other machines as soon as this happened. As far as I
>> tell, the other 2 web servers I'm running (Apache with ColdFusion)
>> 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
>> 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
>> 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.
>> On Mon, 2 Feb 2004 13:20:17 -0500, "Mark Musone" wrote:
>> > There is an exploit for apache handling chunks, and also for
>> > Depending on whats running under php, there could be some bad
>> > programming, however it's most likely it's an apache thing. What
>> > are you allowing through your firewall?
>> > Although doing security audits and security monitoring for our
>> > is a core part of our NOC group, we generally dont do it as an
>> > professional service, however if you are interested, feel free to
>> > 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
>> > 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
>> > 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
>> > 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
>> > things
>> > from source so I can have a little more control over
>> > 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
>> > 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
>> > 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
>> > PM and
>> > defaced all of our sites. I came into the office and spent the next
>> > hours
>> > formatting, installing Red Hat 9, download all the newest source
>> > for Apache
>> > and PHP, and getting everything set up.
>> > Well, I get into work today, and guess what? Another bad process
>> > 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
>> > I'll post
>> > a few of the ideas I had for how the hacker got back in. Here they
>> > (1) I used the latest stable version of PHP, 4.3.4, when in fact
>> > is a new
>> > version, 4.3.5RC1. I wanted to avoid a release candidate version
>> > 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
>> > 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
>> > 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
>> > 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
More information about the nflug