There's a nasty bug going around the Web that targets developers.
When a developer visits an infected site, the page installs a virus on their machine that silently copies the passwords stored in FileZilla, CuteFTP, and possibly other File Transfer Protocol (FTP) client software, and sends them to a central server. The server then runs a bot to access all sites for which credentials have been stolen and installs an iframe injection attack on many pages, further spreading the infection.
Infected sites occasionally break if they use the Web scripting language PHP, but frequently they continue to operate, and thus infect more users with the virus.
When a search engine such as Google detects the infection in a site, they may remove the site from their index, resulting in a financial loss to the site owner. Some browsers may flag the site as infected and show a warning that scares away users.
This attack is interesting because of the way it spreads, and the risk to developers. I would not want to be the freelance Web professional who has to explain to a few dozen clients why their sites all got hacked.
Presumably, this attack vector will eventually be used to install a payload, such as software for sending spam or executing denial-of-service attacks. After all, today's best malware is all about making money.
Big sites have security measures that would probably protect them. But what if a few million small sites are compromised and used to launch a coordinated attack? As we recently saw with Twitter's vulnerability to distributed denial-of-service attacks, there's no such thing as "not my problem" on a shared network like the Internet.
The lessons to be learned here include:
- Website owners should provision a unique FTP password for each developer so access rights can be rescinded later without disrupting the system. Hosting providers often issue a master login that provides access to both their hosting control panel (Cpanel or Plesk) and FTP. Typically, users cannot disable or change the password on this account. If the master account gets compromised, you'll need to contact support at the hosting provider, which can be slow. To avoid this risk, don't allow anyone to store the master account password in an FTP program.
- Developers should inform owners promptly if a security breach occurs so that the owners can change passwords. If a developer has access to the hosting controls, they should consider changing the passwords immediately, using a secure machine.
- Developers must take extra precautions to avoid infection of their machines, including installation of the latest OS, browser, and browser plug=in (e.g., Acrobat) patches. Developers should also use a tool like NoScript, which prohibits unknown scripts from running in a browser, to avoid infection via malicious scripts.
- Websites must be checked regularly to reveal any malware infections. Useful tools include Google Webmaster Tools, Unmask Parasites, and the Google Safe Browsing Diagnostic.
Further information about this attack is available in this blog on Unmask Parasites regarding Malicious "Income" IFrames from .CN Domains.
The bug has been wild since April 2009 -- and is still spreading.
— Jonathan Hochman, founder, Hochman Consultants