Re: Interesting webserver intrusion (apache 1.3.31, mod_ssl 2.8.18, php 4.3.7)

[Frank Knobbe <frank () knobbe us>]

On Mon, 2004-07-12 at 14:29, nathan c. dickerson wrote:
> Linux - 2.4.26 #2 Wed Jun 30 22:47:39 PDT 2004 i686 i686 i386 GNU/Linux
> [...]
> Since then, I have blocked the common IRC ports, and the firewall was 
> fairly tight(only allowing 4 ports in), but perhaps I could tighten it 
> down even further.

Yes, by restricting outbound connections as well.

> I'll look into a setup like this. I am not exactly sure how the jails 
> control outbound ports though.

The host systems firewall rules govern the access to the jailed system.
So even if the jail gets compromised, and an attacker gained root in the
jail, he would still not be able to alter the firewall rules of the host
system.

>  Apache needs to open the outbound to 
> communicate, and a user exploiting apache and gaining it's permission 
> could probably open up a port as well. 

Is this really the case? What connections does your server need to
establish to the outside? Keep in mind that we're not talking the web
servers response packets to the clients browser requests. Responses to
inbound connections are allowed out in statefull firewalls. What could
and should be blocked is the capability for the web server to establish
sessions to the outside. (Unless required like, for example, in credit
card processing scripts -- which can be restricted to the payment
processor hosts).

> How do the jails work? Is it like 
> a proxy? I'll definitely have to read more about the subject.

Nope. A jail is more like a virtual server. It has its own file system
and startup scripts. A jail has a dedicated IP address, which can be the
same as the host (if it's a single address). Inbound connections are
directly received in the jail. No natting or proxying required (but
optional).

> Apache/1.3.31 (Unix) PHP/4.3.7 mod_ssl/2.8.18 OpenSSL/0.9.7d
> mod_auth_mysql, mod_php4, mod_ssl, mod_setenvif, mod_so, mod_auth, 
> mod_access, mod_rewrite, mod_alias, mod_userdir, mod_actions, mod_imap, 
> mod_asis, mod_cgi, mod_dir, mod_autoindex, mod_include, mod_status, 
> mod_negotiation, mod_mime, mod_log_agent, mod_log_config, mod_env, 
> mod_vhost_alias, http_core

hmmm.... there are some I don't experience with. Perhaps someone else
could highlight high risk mods.

> Detection wasn't that special, [...]
> I noticed a spike on the cpu with some monitoring software. High cpu 
> tends to cause ftp launched via xinetd to respond slowly, which the 
> monitoring software also detects. I pretty much keep a terminal open at 
> home and at work, so I checked out what was going on.

Just another case that proofs that normal health/performance monitoring
can assist log based security monitoring. (I wonder if gkrell could be
considered an IDS ;)

> [...]so I went to 
> check these guys out on IRC to get a better idea of who they were. When 
> one of the guys on the channel messaged me, I suggested that he stop, 
> and since then, it has stopped.

I'd be nice if it were always that simple. You should have asked him for
a copy of is exploit script ;)

No clues in the httpd logs as to how they could have gained entry?
Perhaps a flaw in the ftp server? Wasn't there an increase in FTP scans
recently? Perhaps there is a 0-day for your ftp server out there. What
do your FTP server logs say? (if any survived)

Regards,
Frank

Attachment: signature.asc
Description: This is a digitally signed message part