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

From: Frank Knobbe (frank_at_knobbe.us)
Date: 07/14/04

  • Next message: Robin: "Re: Strange log in Apache after webdav-like exploit" 
    To: "nathan c. dickerson" <nathan@pro.net>
Date: Tue, 13 Jul 2004 22:13:02 -0500

    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

  • Next message: Robin: "Re: Strange log in Apache after webdav-like exploit"