Re: [Security-Discuss] Exploits

Hi Vince (and all),

I realize that 9.2 is not supported, and is not the latest and greatest.  I
asked the questions because in the bit of googling around, the symptoms I saw
pointed to older exploits that were fixed according to the security update
advisories, but at least at this point -appear- to be the same exploits used
to compromise the box.

That said, let's dig in!

Vincent Wrote:

> What were the factors in determining these to be the causes?  "A ptrace
> exploit" is fairly generic... considering how long 9.2 has been out 
> of support, and the large number of vulnerabilities since then, it 
> could be any one of a number of things.
> 
> I'm curious as to how you determined they got access to the box via
> openssl, however.  What do you have to substantiate that?  The 
> reason I ask is I've had a number of people assume one thing when it 
> was, in fact, something much much simpler.  Sounds to me like 
> openssl isn't the easiest thing to exploit unless you've already got 
> local access.

Because I see the following entries in the syslog and kernel logs:
/var/log/syslog:Apr  2 21:22:27 web1 kernel: request_module[net-pf-14]: waitpid(
5083,...) failed, errno 512
/var/log/syslog:Apr  2 21:22:27 web1 modprobe: modprobe: Can't locate module net
-pf-14

The initial googling revealed several messages that pointed to the Apache
mod_ssl exploit that caused this.

Interestingly, I made the change to the ssl config (yes, I am running ssl),
and also did one fix for the ptrace thing (doing a echo /no/such/file >
/proc/sys/kernel/modprobe at the end of the init scripts), and see recent
attempts:

/var/log/syslog:Apr  3 20:18:48 web1 kernel: kmod: failed to exec /no/such/file
-s -k net-pf-10, errno = 2
/var/log/syslog:Apr  3 20:27:49 web1 kernel: kmod: failed to exec /no/such/file
-s -k net-pf-10, errno = 2


> > Could someone please confirm if these 9.2 modules are indeed vulnerable (as 
> > the advisorys seem to indicate that everything was fixed, but...):
> > 
> > openssl-0.9.7b-5.1.92mdk
> > libopenssl0.9.7-devel-0.9.7b-5.1.92mdk
> > libopenssl0.9.7-0.9.7b-5.1.92mdk
> > kernel-2.4.22.32mdk-1-1mdk
> 
> 2.4.22?  Everything fixed?  You're kidding, right?  The last kernel
> for 9.2 was released over a year ago.  Not to be snide here, but if you
> insist on running a 9.2 box, the *least* you should be doing is manually
> compiling the latest kernel.org kernel and using it.

Of course I know no new things would be fixed!  I was referring to the
documented fixes.  From reading the old mandrake security update notices, I
see where both non-root ptrace exploits and mod_ssl exploits were fixed.  I
wanted to verify that these didn't resurface.

> > in to see that I couldn't restart apache.  I saw this running on port 80:
> > # lsof -i:80
> > COMMAND   PID   USER   FD   TYPE    DEVICE SIZE NODE NAME
> > ptrace24 5251 apache    4u  IPv4 137712543       TCP *:http (LISTEN)
> > hatori   5299 apache    4u  IPv4 137712543       TCP *:http (LISTEN)
> > CROND    5599 apache    4u  IPv4 137712543       TCP *:http (LISTEN)
> 
> Ok, this tells me a few things.  First, the entry vector was apache.
> Are you using apache and mod_ssl?  If you're not using mod_ssl, you can
> scrap the openssl issue as being the entry point right now.  Because
> it's run as user apache, the entry point was apache itself... now, this
> could have been a vulnerability in apache itself (there have been a 
> few) or in some web apps you're using (ie. arbitrary php code 
> execution in packages like phpbb, phppuke... err.. phpnuke, etc.). 
>  Regardless, apache (or something it's serving up) is how they got in.

Exactly.  The bad part is, I don't see anything in the standard apache logs
that would point to accesses at the same time that I see these net-pf errors.

> Now, you probably did more harm than good in restarting apache.  I don't
> believe user apache can restart it's own service (ie. apache can't issue
> "service apache restart"), so by stopping apache on your own, you let
> something that was actively waiting to grab port 80 to do so (unless,
>  of course, they got root and killed it that way... did you notice anything
> funny connecting to your website to determine whether it was apache 
> or something else actually listening on port 80?)

...and that's exactly what happened.  Parts of Apache wouldn't die; then when
I did kill it, these files kicked in on port 80.
 
> > Can't seem to find ptrace24, CROND, or hatori, but they were running.
> > Example:
> > # ps ax | grep CRON
> > 19263 ?        S      0:00 ./CROND
> 
> cat /proc/19263/cmdline and do an "ls -al /proc/19263" looking at the
> exe and cwd entries.  That should tell you where to find this file.

Great info, I'll hold on to that.

> > Any ideas on fixing the ability to run the ptrace exploit?
> 
> Upgrade?  If you don't want to run the OS, ok, fine... you're playing
> with fire but that's your call.  At the very least download the 
> latest linux kernel, compile it, and reboot.

Ok, here's a question: how much depends on a certain version of the kernel? 
In other words, am I simply able to take say a 10.2 kernel and install it? 
Does it have to be compiled from scratch?  Wouldn't other programs all need to
be compiled again?

Someone here suggested upgrading to a newer version.  I purchased CS 3.0 a
little while back with the intent of upgrading a couple of my boxes to that,
but after deploying one just recently, I found a show-stopping Apache bug that
I just can't run on a production server like this box.

Bob

____________________________________________________
Want to buy your Pack or Services from Mandriva? 
Go to http://store.mandriva.com
Join the Club : http://www.mandrivaclub.com
____________________________________________________