issues with security

Brad Bartram bradbartram at ccsisp.com
Mon Feb 2 14:07:05 EST 2004


Blackhole.c by itself is a backdoor program although it can, and is, embedded 
into various exploits.  Most of the examples of the ssl handshake 
vulnerability use blackhole.c renamed as bugtraq.c as that is the method used 
in the vuln-dev example code.

Not to say this isn't an apache-ssl exploit, but some circumstantial evidence 
makes me think it's something else.

 - The apache-ssl exploit this code used was from a couple of years ago 
(apache version <1.3.27 with a much older version of openssl) often known as 
the slapper worm.  Redhat 9 did not ship with that particular vulnerable 
code.

 - Most script kiddies aren't intelligent or crafty enough to change c code 
that much to open a different filehandle other than the one already 
hardcoded.

Given that there isn't really enough information to do more than offer up 
pipe-smoke induced hypothesis, I'd be very interested to hear what it is, but 
I would say much like a cancelled tv series - we may never know what 
happened.

brad

On Monday 02 February 2004 01:32 pm, Justin Bennett wrote:
>  From a simple google search blackhole.c looks like it's used to exploit
> apache's ssl handshake vulnerability. Have you updated your apache rpms.
>
>
> Justin Bennett
> Network Administrator
> RHCE (Redhat Certified Linux Engineer)
> Dynabrade, Inc.
> 8989 Sheridan Dr.
> Clarence, NY 14031
>
> Robert Meyer wrote:
> >Hmmm... sounds like either someone has gotten hold of your root password
> > (you never mentioned if you changed it) or has managed to create a root
> > perms account in your password file that got copied over or there is
> > something in your PHP code that is exploitable.  Cruise your PHP code and
> > make sure that it's not invoking any SetUID programs.  Also, make sure
> > that you're not running apache as user 'root'.  If the only thing that
> > the firewall is allowing through is port 80, then the next thing to do is
> > to run apache in a chroot jail so that it can't get at the O/S in any
> > way.
> >
> >Also, turn off ANY AND ALL services on the server that are not being used.
> >This includes 'telnet', 'ftp', 'ssh' (if you're not using it), Email, SMB,
> > etc.
> >
> >I still would have a look at your firewall's rules to make sure that it's
> > not letting anything but port 80 through.
> >
> >Turn on RedHat's internal firewall.  There are options when you do the
> > install to automatically firewall the machine and you can determine what
> > ports are allowed by the kernel.
> >
> >Did I mention your firewall's rules? :-)
> >
> >Cheers!
> >
> >Bob
> >
> >--- cliff at cliffmeyers.com wrote:
> >>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
> >
> >__________________________________
> >Do you Yahoo!?
> >Yahoo! SiteBuilder - Free web site building tool. Try it!
> >http://webhosting.yahoo.com/ps/sb/




More information about the nflug mailing list