[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [cobalt-security] proftpd-1.2.2rc1-C2 vulnerability?



Michael Stauber wrote:
> 
> Hi all,
> 
> I've been tasked with looking after an RaQ4R which spontaneously rebooted a
> couple of times in the last few days.
> 
> In /var/log/messages I found the following entries which happend at or around
> the time of such a spontaneous reboot. (The RaQ's IP address has been
> X'ed out):
> 
> Jun  6 02:45:45 ns1 named[518]: "emirates.net.ae IN MX" points to a CNAME
> (mail2.emirates.net.ae)
> Jun  6 02:45:52 ns1 named-xfer[5092]: send AXFR query 0 to 152.163.159.232
> Jun  6 02:45:52 ns1 named-xfer[5092]: [[2XX.196.34.157].4015] transfer
> refused from [152.163.159.232], zone aol.com
> Jun  6 02:46:09 ns1 proftpd[3620]: 2XX.196.34.159
> (203.177.38.242[203.177.38.242]) - FTP no transfer timeout, disconnected.
> Jun  6 02:46:59 ns1 proftpd[5131]: 2XX.196.34.159
> (203.177.38.242[203.177.38.242]) - FTP session opened.
> 
> Jun  6 03:00:08 ns1 syslogd 1.3-3: restart.
> Jun  6 03:00:10 ns1 named[519]: starting (/etc/named.conf).  named 8.2.3-REL
> Tue Jan 30 16:56:25 PST 2001
> ^Iadmin@xxxxxxxxxxxxxxxxxx:/home/redhat/BUILD/bind-8.2.3/src/bin/named
> Jun  6 03:00:10 ns1 named[519]: hint zone "" (IN) loaded (serial 0)
> 
> So the last consistent action was at 02:46:59 when a user from 203.177.38.242
> opened a FTP session. This IP address points to the Philipines and most
> likely doesn't belong to a legitimate user of this box.
> 
> Then there must have something happened which caused the server to reboot,
> because the next entry is at 03:00:08, when the logging facility was
> re-initialized after a successful restart of the machine.
> 
> I'm almost sure that I've seen this in the past, with the old ProFTPD which
> was vulnerable for the globbing attack. So my question is whether
> proftpd-1.2.2rc1-C2 still has the same vulnerability?
> 
> The configuration file of proftpd-1.2.2rc1-C2 doesn't have the ...
> 
>  DenyFilter                   \*.*/
> 
> ... enty in the Global section, which was suggested as an interim fix of the
> old proftpd-vulnerability.
> 
> This brand new machine has always had all the latest patches installed, it
> has telnet disabled, SSH installed, Logwatch and Portsentry (Adv. TCP / Adv.
> UDP) running and  blocks unneeded ports with a custom IPchains firewall.
> 
> During the course of my evaluation I scanned the machine for Adore, LKM and
> other known trojans, reinstalled the diagnostic binaries like ps, netstat and
> top from the respective RPM's and installed lsof. After a couple of hours of
> playing around with all the usual toys I'm 99.9% certain that this machine
> has never been compromised.
> 
> But the question remains: What caused the reboot?
> 
> Any ideas on this from Sun/Cobalt or anyone else on this list?
> 
> --
> 
> Mit freundlichen Grüßen / Best regards
> 
> Michael Stauber
> 
>  Stauber Multimedia Design ____ Phone:  +49-6471-923812
>  Hauptstrasse 31 ______  D-56244 Goddert ______ Germany
>  SMD.NET ___ SOLARSPEED.NET ___ FORUMWORLD.COM
> _______________________________________________
> cobalt-security mailing list
> cobalt-security@xxxxxxxxxxxxxxx
> http://list.cobalt.com/mailman/listinfo/cobalt-security


Michael,

A number of things can cause a reboot that are not related to an
intrusion. If you have a user running a perl/cgi script on the server
that calls to a function or something that doesn't exist on the server,
it can bring the server down. I have also seen instances where the
server was running overloaded and was brought down to its knees by an
overloaded system. Mostly likely its an errant CGI script or too many
complex CGI's running on your system for it to handle. You can try
checking your CPU load during busy and not so busy times by type "top"
at the command line. Watch what is happening and your cpu load, how much
mem is being utilized during this time. If you are running out of
memory, you may need to upgrade.

Another thing that would cause this problem is something I saw today.
The admin at one site never checked his mail or didn't delete it off the
server. The admin mail file swelled to 348mb file!!!! Youch! Everytime
mail was sent to the acct or the admin checked it, it consumed 348mb
memory to do its thing. If you are running a loaded server when that
happens, it can cause all sorts of nastyiness.


-- 
Bill Irwin