Re: [Security-Discuss] Exploits

* Bob Puff@NLE <bob-6dd4Sf22++lWk0Htik3J/[email protected]> [2006-04-03 16:24:29 -0400]:

> Looks like one of my (fully-patched) 9.2 boxes just got rooted by two 
> things that I thought had been fixed a long time ago.
> 
> It appears that they got in via the openssl-too-open exploit, and then used 
> a ptrace exploit to get root.

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.

> 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.

There are probably 100 CVE names since that time related to the Linux
kernel... not all of them for 2.4, of course, but I'll bet you there are
at least 30 or more problems with the kernel you're runnign.

> I was alerted to this attack by seeing net-pf-14 errors in my logs.  Logged 

Which logs?

> 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.

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?)

> 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.

> I changed the SSL config to: SSLCipherSuite 
> ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:!SSLv2:+EXP:+eNULL
> ...hoping that fixes the way they got in.

Doubtful, unless you have concrete proof that they used openssl somehow
to get in.

> 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.

-- 
"lynx -source http://linsec.ca/vdanen.asc | gpg --import"
{FEE30AD4 : 7F6C A60C 06C2 4811 FA1C  A2BC 2EBC 5E32 FEE3 0AD4}
Wasting time like it was free...

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFEMbM0LrxeMv7jCtQRAhupAJ0cz5CtTnU37mFD/w8NwbNLLby23ACgqgKx
t8yJLJIrnf7ubSn9NZdD6hQ=
=az8t
-----END PGP SIGNATURE-----