On 14/07/2008, at 9:44 PM, Steve Holdoway wrote:

On Mon, 14 Jul 2008 19:16:13 +1200 Glen Eustace wrote:

...

OK, vector identified.

The password for the site was cracked, then the site was downloaded, modified and then uploaded again. This happened concurrently from two sources.

My pet hate is all these designers who just must have ftp access. Don't they realise that the ftp password is transferred in clear text over the internet? sftp is no big deal to set up either end.

Secure FTP doesn't save people who have poorly chosen passwords, which I imagine is what happened in this case, and is in my opinion a much more likely to be exploited problem than unencrypted FTP. -- Nathan Ward

Nathan Ward wrote:

On 14/07/2008, at 9:44 PM, Steve Holdoway wrote:

...

On Mon, 14 Jul 2008 19:16:13 +1200 Glen Eustace wrote:

...

OK, vector identified.

The password for the site was cracked, then the site was downloaded, modified and then uploaded again. This happened concurrently from two sources. My pet hate is all these designers who just must have ftp access. Don't they realise that the ftp password is transferred in clear text over the internet? sftp is no big deal to set up either end.

Secure FTP doesn't save people who have poorly chosen passwords, which I imagine is what happened in this case, and is in my opinion a much more likely to be exploited problem than unencrypted FTP.

-- Nathan Ward

</lurk> I agree, slack passwords are a crackers delight :) <lurk>

On Tue, 15 Jul 2008 08:02:34 +1200 Criggie wrote:

Tom the Lurker wrote:

...

Nathan Ward wrote:

...

On 14/07/2008, at 9:44 PM, Steve Holdoway wrote:

...

My pet hate is all these designers who just must have ftp access. Don't they realise that the ftp password is transferred in clear text over the internet? sftp is no big deal to set up either end.

Secure FTP doesn't save people who have poorly chosen passwords, which I imagine is what happened in this case, and is in my opinion a much more likely to be exploited problem than unencrypted FTP.

...

I agree, slack passwords are a crackers delight :)

And if you're not watching/analyzing your logs, its very easy to miss someone trying passwords.

I had a case where a customer's site had a backup DSL link, which wasn't really used. We got a cacti threshhold alert that said "DSL link using four times as much as last week!!!" (400 bytes/sec) Turned out that someone was trying all manner of usernames/passwords against an AS/400 running an FTP server. And it had been going on for hours. The usernames/passwords were anything from simple admin/root/ftpuser/jim/bob/mary through to obfusicated things like r00t/5up3ru53r/passw0rd/3TC...

Who's going to notice an extra 400 bytes/sec on a busy link, other than by monitoring logs for denied requests?

-- Criggie

http://criggie.dyndns.org/

I don't, but I run logcheck to *tell* me ( and fcheck to tell me of any file changes, and... )! tbh my production servers have a backdoor single account ssh access to the internet, which is protected by denyhosts, and all other access is from a staging server via vpn, still using secure ( but separate ) protocols. I don't care too much about the shortcomings of denyhosts, as a) it's protecting the emergency backup service, and b) I've got enough static ip addresses whitelisted to get in from - imo it's perfect for this job. OK, you *could* break in through a distributed attack on the ssh port, but the real risk to my servers is now human, from those with the relevant knowledge of the network configuration. But to me the chances of someone looking for a starting point 9000 miles from the server, breaking in, then going through a few other hoops before hacking across the vpn to the production server is remote enough to put a long way down my list. And, of course, I'm lucky enough not to have to support 1903 vintage IBM boat anchors (: Steve

The plot thickens, as they say. There is no evidence of multiple attempts to get in via ftp. The userid was not something that would be easily guessed, can't comment on the password as I don't know what it was. The user and password would appear to have been obtained and used. From communications with the account holder, it would appear, though unconfirmed at this stage, that someone who had legitimate access to the site, *MAY* have done something they would prefer not to admit to. I am guessing a case of social engineering or similar. So in this case, the protocol used may be irrelevant. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Glen and Rosanne Eustace GodZone Internet Services, a division of AGRE Enterprises Ltd. P.O. Box 8020, Palmerston North, New Zealand 4446. Ph: +64 6 357 8168, Fax +64 6 357 8165, Mob: +64 21 424 015 http://www.godzone.net.nz "A Ministry specialising in providing low-cost Internet Services to NZ Christian Churches, Ministries and Organisations."

From communications with the account holder, it would appear, though unconfirmed at this stage, that someone who had legitimate access to the site, *MAY* have done something they would prefer not to admit to.

Whilst still unable to say 100%, the timing etc and what I have found ( which admittedly isn't much ) about the malware concerned, it would seem that the unfortunate individual had a run in with VirusRemover 2008. He is now $155.00 worse off and a few of us have had a cleanup to complete. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Glen and Rosanne Eustace GodZone Internet Services, a division of AGRE Enterprises Ltd. P.O. Box 8020, Palmerston North, New Zealand 4446. Ph: +64 6 357 8168, Fax +64 6 357 8165, Mob: +64 21 424 015 http://www.godzone.net.nz "A Ministry specialising in providing low-cost Internet Services to NZ Christian Churches, Ministries and Organisations."