As of this morning, cPanel logins are forcefully blocked from being used as FTP logins across all servers.

While we’ve stated for years that you shouldn’t ever use your cPanel login to log into FTP unencrypted because the login and password is stored and passed unencrypted to the server putting the administrative login (or the “super user”) at some risk of being compromised, due to a rash of compromised logins that we’ve seen of late, we are now forcefully preventing you from doing it.

If you are going to use FTP to transfer files, you should login to cPanel and created an FTP account for that purpose.

If you are unsure of how to do this, please visit

http://www.drak.net/support/#cpanel

and watch Movie #17, Creating an FTP Account.

SFTP can continue to be used with cPanel logins (and, in fact, can only be used with cPanel logins as SFTP actually operates over SSH and not FTP even though the name implies that it does). If you wish to use SFTP to transfer files to your account, please note you must write in to support for the SSH Port Number on your server. SFTP will not operate on the standard FTP or SSH port for security.

Please note that this change will not prevent your web site from being compromised if your computer is infected with a virus and bots obtain your logins in order to upload trojans, redirects, and so on. All this does is prevent your cPanel administrative account from being further compromised if you are infected and keeps your administrative logins from being obtained as easily as they were before.

Always store your passwords in encrypted databases, always surf the Internet with continuously running firewall and virus shields, and share your logins and passwords with as few people as possible.

Later Update:

We’ve added the SSH/SFTP port number in your cPanel under “news” for your server, right beneath the support chat button. If you are using an FTP program that supports SFTP, you only need to change 2 things, the protocol (which should go from FTP to SFTP) and the port number (which will not be the default for SSH/SFTP as we randomize them).

When you fill out an order form with DrakNet, we ask your information – your email address, your phone number, your name. All of this information is important, and is used to identify you so that when you contact us, we know who you are.

If the account is an individual account, this is relatively easy – who you are doesn’t change. Your email might change, your phone number, your address may change but who you are remains a pretty good constant that we can count on. (And if your name changed, you can usually fax us the name change and establish the name changed, though that would only need to be done if you locked yourself out of your billing.)

With companies and organizations, this can become a little more complex.

What matters on the order form

When an order form is filled out for an organization or a company there are two pieces of information that are provided to us, the company or organization name and the name of the individual placing the order. When that’s done, the person listed as the individual placing the order is then listed as the representative who is authorized to make all decisions the account. Their information is the information we look to when we confirm that someone has rights to an account.

If that person leaves the organization, that person is still the person authorized to make changes on the account, close the account, or make requests. Someone that is not listed on the account, even if they are internally appointed to manage the account by the company or organization, does not have standing with us to make any changes or have any access because we have no idea who they are. In the interest of protecting the site and account, they will not be allowed to make changes.

So, what happens when the authorized contact is a position that’s kicked around like a soccer ball?

Please note that these are only for sites that are held in accounts that have a company or organizational name. Individual accounts are individual accounts and transfer of ownership cannot be accomplished this way.

Change Contacts The Easy Way

The easiest way to change a contact on an account is for the old contact to give the billing login to the new contact so the new contact can login to the account and change the information in billing (Name, Email Address, Phone Number), as it is this information we look to when we confirm someone’s identity as a person authorized to work with us on behalf of the account.

This is simple, quick, and takes relatively little time.

Change Contacts The Hard Way

The hard way happens when the original authorized contact leaves in a huff, refuses to hand over the site, refuses to allow access to the legal owners, or simply disappears with the keys.

Changes become more complicated if a handover did not occur.

Because we have an authorized contact that cannot or will not contact us or the company or organization’s behalf, we have to have hard documentation that we are handing the site over to the legal owner or the organization or corporation. Essentially, you need to prove to us that you should have the site.

In these cases, DrakNet required a signed, faxed letter on company or organizational letterhead that states:

1. who the previous contact was
2. why the previous contact cannot or will not contact us to make the change
3. who the new contact us, with their name, phone, and email
4. a specific request to drop the old contact
5. a specific request to add the new contact
6. what the role in the organization or company is of the person writing the letter, with a copy of that person’s ID on the latter itself.
7. A dated signature

and the fax must be accompanied by some official documentation showing the person sending us the request is affiliated or associated with the organization or company, and in what capacity. It could be a copy of an official bill, a dba, a contract, the incorporation papers, corporate minutes. Just something official and legal in some capacity.

We will make an attempt after getting the fax to contact the current contact and confirm the information and if we cannot confirm it, the change will be made as long as the information indisputably shows the person who signed the paper has the legal right to make the change.

The Moral of the Story is

We do the absolute best we can to keep the server secure, and the accounts secure – and part of that is knowing who’s on the server and who’s supposed to be talking to us. If the person that calls or chats or emails us isn’t an authorized person on the account, we don’t discuss things with them as a precaution against social engineering.

We assume that if you host here, we know who you are.

If you don’t host here, you don’t need to know what our random ssh port numbers are, and we don’t care if you swear up and down you are on the Board of such and such and its your account – if you hosted here, you would have known our ports were not on 22 and that firewall wouldn’t have happened. If we don’t know who you are, if you have no information with us on file so that we can substantiate who you are, we can’t tell you anything and we certainly can’t unblock you manually.

If you don’t know that, then you have had a failed changeover, and you need some help to become aware of our system, and our policies, and your site. We’re happy to help you with that – after we know for sure who you are.

It is very important for organizations to maintain their information, and for contacts to maintain current information. Have a pass through book, have more than one person as a contact, share the billing login with the Treasurer or President so problems can be dealt with easily.

If that doesn’t happen, we are going to require that you make changes “the hard way” because that’s the only way we can be absolutely sure that the account belongs to you or you have rights to it.

It is for the safety of your site, the safety of your company or organization’s web presence – and its also because we at DrakNet really don’t want to have to try and figure out who’s telling the truth in a dispute, or explain why we handed over a site to a rival faction bent on nefarious deeds to our client, or in court.

So, earlier today, DrakNet’s illustrious Brit staff member, Thomas, let me know that mod-security 2 doesn’t support overriding mod-security via .htaccess.

Of course it does, I argued – we’ve been passing out the code for it since we upgraded to Apache 2 and Mod-Security 2 and its been working since last summer. No, it doesn’t, he argued back- and I, of course, argued back that it does. So, we had to get a tie-breaker at Liquid Web, our data center, and 4 system administrators debating the issues later, it appears that in mod-security 2.5, you all no longer have the ability to turn off mod-security protection on your sites yourselves.

There was much wailing and gnashing of teeth.

While from a security perspective on a server, this is a pretty good thing, the fact is on a shared server requiring these changes to be made in server configuration files is a gigantic pain in the keister for your web hosting company. In addition, this flies in the face of the security policies we’ve had and that we advise you to use, which is protect your site 100% and only turn mod-security off when using the administrative area (which is 99% of where ya’ll tend to get caught – this means you, Wordpress widgits).

We hereby dedicate Hot N Cold by Katy Perry to ModSecurity for this change.

This does change how we handle requests regarding Mod-Security problems. Much to our chagrin.

If you are writing in for a mod-security issue, you have a few options and we’ll need a bit more information from you to resolve the issue for you. So, first, what should you send us when you have a mod-security error?

1. What time, approximately, the issue happened.
2. What you were doing at the time. What the link is, the file, and so on.
3. Your IP address.

Hopefully, this will be something simple, like you used a URL as a call and should have used a system path or some simple thing we can advise you to change. If you’re using an out of the box software installation from Fantastico, this issue’s resolution is likely not going to be simple.

If you have an out of the box installation that’s getting tripped up by mod-security, we’ll still need the above information. While its possible we’ll be able to change the rule or exempt the file universally, most often we won’t be able to do that and if that’s the case, you’ll have a few choices.

1. You can request us to exempt your site from the specific rule that’s catching you up.
2. You can request that we exempt a directory from the specific rule that’s catching you up.
3. We can turn off mod-security per directory.
4. We can turn off mod-security for your entire site.

Every time you lower security, you raise your chance of being compromised. The “easy” solution is to just turn it off – and its easy right up until the time you lose your site due to a hack. So, you’ll have some decisions to make if you need this done.

While ideally, we can turn things off and on for you like before, it’s just not practical. We may do it once for you but if this is something that will come up repeatedly, we’ll need to find a permanent solution.

The past week or so we’ve seen a rash of compromised accounts, more so than we’ve seen at any time in the past. It’s certainly not epidemic, but its more than we really want to see. We wanted to go over best practices (yes, again), and give you an overview of how we tend to handle compromises.

Best Practices

Upgrade. Please upgrade. Please, please, please, please, please upgrade.

No, really. We so, so, so want you to upgrade.

Those software versioning numbers? They actually, honestly mean something – so much so that there is a Wikipedia article written just to explain it it you.  Much of the time, compromises are not found until software has been widely released, and all software on your site is public, open to anyone that feels like trying to get a digital molotov cocktail in there through a window left cracked open.

There seems to be a common misconception that you will know when your site is hacked – that a hacked site will sport a “Ha ha, got you!” page telling you that you’ve been compromised, your stuff will stop functioning. While that does happen, it’s not the most common hack out there in the wild.  Frankly, the hackers that do that are practically doing you a favor, because they’re telling you so you can take steps to fix it. Many hackers feel that this is a noble calling for them, though if you get owned you may find yourself feeling differently.

The hackers you want to guard against are the ones you don’t see – these guys don’t announce it as its not a skills “thing”. They don’t want you to know what they’re doing, and they don’t want us to know, either. They want your site to stay up and running for as long as possible, so they can send spam through your site, or have people fill out a phishing form, or they can poke around trying to get everyone else’s information on the server. Stealth is key to carrying out these kinds of hacks, and many times you can be totally compromised with nefarious baddies using your site as a playground and you won’t know.

So, how do you keep them from targeting you in the first place?

Well, you can’t. You’re on the Net. That’s the reality – you’re a target. If there is a hole in your site, they will look for it. Everything you decide to do with your site should have that in mind.

So, how to you keep from cracking that window?

1. Be Selective with the Scripts you install – half the time, you let them in yourself. Just like someone handing you a bag at the airport isn’t a good idea to take, there are scripts floating around out there saying they do one thing, and doing another. If it’s a Wordpress Theme or plugin and not on the Wordpress site where the listing is free, stop and wonder why its not. Is the software active? Is it being updated? Does the site look like software developers that take things seriously, or does it have that spammy feel? Was the last release in 2006?
2. Keep your software updated! – If your software is actively maintained by decent developers, the developers will address security issues. Google the software name and “vulnerability” – chances are you’ll find something. You can use that info to see how quickly an update was released and an issue addressed so that you know as far as you can tell whether something is well maintained – but an update being released is meaningless to you if you don’t upgrade your software. This is a serious issue here at DrakNet, and can be a terminable offense.
3. If you disable security, realize you’re asking for it – Mod-security and our PHP settings are instrumental in our ability to protect you against your own worst instincts to use bad code, not update your scripts, and transform a site’s original code into something you want when you aren’t a developer and aren’t wholly sure what the heck you are doing. Yes, we let you override – we expect that when you override you know the potential consequences, and that you accept them and are prepared for them, which brings us to…
4. Backup Your Stuff – A backup is the only fool proof method to be completely secure against recovery from compromises, far enough back that the site is secure. If your site is compromised and allowed to run with it, they potentially will be useless, but most of the time they save your site and save you hours of work. You can utilize the Backup feature in cPanel to take complete website backups of your account settings, files, emails, databases, etc. Keep them. We maintain only a weekly, and a monthly. If you’re compromised a month or two ago, you’re looking at a site nuke.

OK, you’re hacked. Now what?

If we find it, you’ll be suspended, instantly. We will not call you to discuss the situation, we will not conference to debate what to do, we will not send you an email asking if its ok to take you off line. We will lock down the script and/or the entire site if there is any suspicion that the hack went farther, immediately. We cannot continue to allow sites that are:

1. spamming
2. phishing
3. hacking
4. serving viruses
5. serving malicious software
6. out of the direct control of the authorized admin

to continue to blissfully function on a server we control. If you put our machine at risk in any way, shape, or form from malicious activity, we will shut you down. Yes, even if its “not your fault” because, folks, just because you didn’t choose to do it doesn’t mean that the real world consequences of what’s going on are simply suspended due to your non-active role in the malicious activity. The rest of the clients who share the box with you are still at risk, and your site simply will not be allowed to put their services at risk.

Once your script is locked or your site is suspended, we’ll send you an email, letting you know about it. From there, you have a few choices:

1. We can completely delete your install, install you fresh, and you can start over. Before anyone screams that this is grossly unfair, I’d like to remind you that this is what we do if a server is compromised, and its no fun for us, either. If our server is hacked, the only foolproof way we have to secure it is to rebuild it from the ground up, and so that’s what we do. So, we’re not giving you an option without being aware of (a) what an unmitigated pain in the keister it is or (b) without being willing to do this ourselves on a much grander scale.
2. If you know enough to secure it, and we are reasonably sure it is related to a script only (and you’re reasonably sure you can track it down and remove all of the offending code and fix all underlying security vulnerabilities before putting your site back online), we can unlock most of the domain while keeping the site offline for everyone but you based on your IP so that you can upgrade and patch what needs to be upgraded and patched or reinstall things so they are secure. You can also hire an admin company to do the same type of thing.
3. You can pay us to secure the site, and rebuild what we can, with no guarantees regarding what we will be able to salvage, for $75 an hour.

Shared hosting is managed around your site. We control the building and the utilities – however, if you set the office we rented you on fire after pouring gasoline on the floor and lighting a candle, the cleanup is not included as part of your hosting fees, especially when your security practices go outside of the recommended security practices.

Taking your site offline is not meant as punishment – it is done not only to protect our other clients, but also in order to keep from putting your site’s visitors and your customers at risk.

If you find that you’re hacked first, finding and removing a specific block of bad code that a hacker has inserted can clean your site for a time, but keeping your site from being infected in the future will require fixing the security vulnerabilities that allowed the hacker to insert the code in the first place.

We have upgraded all servers to cPanel 11.24, or “cPanel Accelerated“, which should be a souped up yet slimmer version of cPanel. Likely, you personally won’t see much of a difference though you resellers will see some added branding options.

The good news is Accelerated has implemented many security fixes that are default on current out of the box software installations that cPanel gathers into one package, as well as addressed cPanel’s woefully late but finally here response to PCI Certification, something many of you merchants are clamoring to get before the deadline passes and you start to be fined.

(We know how you feel, we put it off as long as we could, too.)

The good news is that all servers should now pass a PCI Compliance scan, with some caveats. You’ll need to let us know your PCI Compliance company’s IP range so that we can exempt them from the firewall on the Apache port only. PCI Scans throw so many holes and exploits at the server that we inevitably wind up firewalling them, which is good for the security of your site – but not so good when they want to fully see how your web site responds to those attacks and where the holes are.

Please try and let us know when they’re coming beforehand so we can make sure that they can do and see what they need to do for you to pass. You’ll only need to do this the first time, as we’ll keep the range in there. If you want a company that we work with, we can guarantee that you’ll pass Security Metrics scan, as we did on the same servers and we already have their IPs.

The bad news? Well, it’s not bad, really, and this won’t affect the vast majority of you, but we have turned off the ability to include executables in SSI. The exec command executes a given shell command or CGI script, and as you can imagine, this is an incredibly exploitable aspect of your web site and we watch people hammer the server all day trying to shove them in there. We swat most of them away with mod-security.

After years of running with no sites ever being exploited on these servers, though, we have seen a recent rash of exploits from poorly coded CGI scripts, and we’re not going to allow it anymore by default. If you see:

[Mon Nov 10 19:11:03 2008] [error] [client XX.XX.XX.XX] unable to include potential exec “/script/here.cgi” in parsed file “/another/file.html”

You are trying to include an executable, and that’s no longer allowed just out of the box on everybody. You also need to turn on cgi scripts if you use them just to be safe.

In geekspeak IncludesNOEXEC is now the default, or more specifically, mod_include allows execution of CGIs and external commands using Server Side Includes and they are now disabled by default by the Options -IncludesNoExec directive.

Before you begin hyperventilating and wonder where you’ll get the time to recode your site, we do allow overrides, so you can take our security and turn it on its ear by creating an .htaccess file with the options you wish to have and blow your site wide open if that’s what you feel like doing.

If you wish to use a .htaccess file to permit the execution of CGI programs in a particular directory, you will need to create an .htaccess file that adds the executable option to that directory.

Options +ExecCGI

AddHandler cgi-script .cgi .pl

If you wish to use a .htaccess file to permit the execution of and including of CGI programs in a particular directory, you will need to create an .htaccess file that adds “Includes” to the Options (overriding the IncludesNoExec that exists by default).

Options +Includes +ExecCGI

AddHandler cgi-script .cgi .pl

Our current settings are:

-ExecCGI -FollowSymLinks Includes IncludesNOEXEC -Indexes -MultiViews SymLinksIfOwnerMatch

any of which you may override.

Just please remember that if you are deliberately turning off our security, if you are not keeping your scripts updated, if you disable the things meant to protect you and you wind up getting hacked, we’re going to suspend you outright should you get exploited. We can’t afford to do security consulting for $5 or $10 a month and the most we’ll do is install an older backup and tell you to fix your stuff. You’ll need to convince us that if we turn you back on, you’ll be able to secure your scripts and if you can’t, we will terminate the account, so please realize your responsibility in trying your hardest to keep your site secured is considered sacrosanct here.

We take our job to secure your sites very seriously – we expect you to do the same for our servers and out of respect for your neighbors.

You didn’t really think we were going to tell you that, did you?

Actually, some of you likely will have clicked on this thinking that’s exactly what we were going to do.

Security is one of the most challenging aspects of running a shared hosting company. After all, the existence of hosting that’s “shared” seemed like it shouldn’t exist at all – most networks are closed to everyone and open only to those that need them. By definition, a shared hosting network and server has to be open to everybody that’s needs access no matter where in the world they are, but closed to everyone that would harm the network no matter where in the world they are.

Because of the inherent oxymoron-ness of shared hosting, security on the servers is quite extensive and has to be fine-tuned nearly every day. We employ mod-security, a software firewall, blacklisting services, scanners, and a host of other things to catch problems as they come up. Despite our choice to not automate any set ups are installs, our security is automated and will kick in immediately when there are certain defined problems.

We get at least 2-5 people firewalling themselves per day. In response to being told they firewalled themselves, we get these frequent responses back.

1. Can you whitelist my IP?
2. Can you explain exactly what I did so I won’t do it again?
3. I don’t know what a port scan is so I could not have done it.
4. But I was using the right login!

None of these are the correct responses, and they won’t get you anywhere. Here’s why.

Can you whitelist my IP?

OK, so, a firewall is designed to spot things that people do against the servers. The means people outside our network, and believe it or not, those who we gave access to that maybe we shouldn’t have. What you are asking us to do is to tell our servers to ignore anything that you do wrong so that if you do something wrong, your access won’t be blocked and you can keep doing the wrong thing until you get it right (or so you can keep banging on the server until you email support).

When you see it explained like that, can you understand why, maybe, that’s not a good idea?

The firewall is there to protect the server as a whole, and you are not the only client on it. In addition, many clients that we have are not savvy enough to recognize when their computer has been unwittingly drafted into being a member of a botnet. Even if you are sure you didn’t do that portscan yourself, it doesn’t mean that your computer or another computer on your network didn’t.

Can you explain exactly what I did so I won’t do it again?

We can, in general, tell you how to do it right – what we can’t do is explain step by step what you did wrong. This is especially true for orders that are flagged and refused for install – and in that case, we won’t even take the time to explain to you fully how to do it right as we feel the order form is fairly self-explanatory.

While the slice of the server you have is “yours”, the machine is our responsibility to secure. One of the ways we do that is making sure that exactly what we do for security remains a tightly held secret.

We’ll tell you that we use mod-security, but you won’t get a copy of our rules. We’ll let you know the server firewalled you for performing a certain action too many times, but we won’t tell you exactly how many times it was that set it off. We’ll tell you that you were temporarily firewalled but we won’t tell you how long the ban will last before it expires. All that information can be used to piece together a picture of our practices that no one should have a picture of but us.

I don’t know what a port scan is so I could not have done it.

See the response to whitelisting – many clients that we have are not savvy enough to recognize when their computer has been unwittingly drafted into being a member of a botnet. Even if you are sure you didn’t do that portscan yourself, it doesn’t mean that your computer or another computer on your network didn’t.

If we are picking up scans that you know you didn’t or couldn’t have physically done, you need to look to other explanations. It could be as simple as your computer being infected, it could be as complex as your wife suspects you are talking to a mistress through email and is trying to hack into your mail account to get evidence. There are a lot of explanations for firewalling from the simple (I forgot my password and refuse to email support so I’ll just hack away until I get it) to the complex (someone wants to hack your account and they live under your roof).

But I was using the right login!

This one’s just thrown in here because we are like the omnipotent and unknowable deity within the metal confines of these boxes. We know what you typed in. We probably even know what you did last summer since we likely have it archived somewhere.

If we tell you we see that you typed in “groggy” to log in and your login is really “eueytgdfy”, just believe us. It saves time.

This morning when you go into your cPanel, you’ll see a new button under Software/Services called Old Script Finder. Old Script Finder searches your web site for old, out of date scripts by searching for signatures on some of the most popular, and most security issue-laden if not updated, scripts being used today.

After installing, we ran a report on all five servers. There’s only eight sites on the new server and half of the scripts (3 of 6) were out of date. Half of them. Before you take a deep breathe in shock at that news (considering the server hasn’t even been up a week), let’s get to all of you other folks on the older four servers… I’m sorry to say wasn’t a single one that didn’t have 80% of the scripts out of date – ranging from just a few steps behind to woefully, woefully so far behind that the message was “script obsolete”. Even we were a bit surprised at the statistics.

Currently, we have only the most basic options on this script enabled – every Saturday, it will search all the servers and it will take stock of who’s scripts are out of date. That report will appear in your cPanel. It will tell you what script is out of date, where that script is located, what version you have and what the current released version of the script is. There is also a button for you to run the script on your own to take a look in your own directory if you install something – please use it sparingly as this is a fairly resource intensive endeavor.

The catch is you need to look at it, and you need to take action.

Hopefully, this handy tool will help you get a handle on updates and give you information you didn’t have before. It should also help folks that have installed scripts and forgotten about them – I took a look at some of the things that were found and I get the feeling that a few of you are going to be shocked at what’s hanging out in your web site.

If the statistics don’t get significantly better, we’ll take the next step and have the server email you regarding your out of date scripts. If that doesn’t get a response, at some point, we may start locking them down after repeatedly warnings are ignored.

For a list of scripts that are looked at, click the more information button below.

(more…)

Logging into cPanel. That’s pretty much it.

When you sign up or install an account, we issue you a cPanel login – this login is essentially the “root” of your account with full administrative powers to do very nearly anything that it gosh darn well pleases, and since it has shell access to the server, it’s a pretty powerful little login. It’s one of the reasons that we force you to login to the servers using SSL, and we’re so adamant about keeping your site from obvious risks we also firewall your ability to get into cPanel from any other way other than in an encrypted manner.

Much to our chagrin, it can also work for FTP or logging into mail – and though you can use it that way, you shouldn’t, because those logins are not encrypted and you are sending a plain text password through the internet and through multiple networks in such a way that anyone can pluck it out of the air. This is extremely unsafe, and we highly recommend that you not do it at all.

All cPanel email accounts should be created in your cPanel – sending those passwords through the air in plain text isn’t really any better, either, but at least you are limiting the access that they can get to that email account only. (We will have an article regarding encrypting your logins, but that’s beyond the overview scope of this article).

All FTP accounts should be created in your cPanel – sending those passwords through the air in plain text isn’t really any better, either, but at least you are limiting the access that they can get to that FTP account only. The only exception to this would be if you use SFTP, which is actually run over shell and not over “FTP” – in that case, you are required to use your cPanel login as that login is the only true Unix login and hence the only way that you can have SFTP access.

You cannot simply login to SFTP on port 22, either – we hide all shell ports and we do not publish those ports anywhere. You’ll need to email the support department and request the port for your server as they are all different. This allows us to know exactly who has shell access, and to monitor its security with a little extra glance every now and then.

We do recommend SFTP for everyone on a Junior account or above (as Intros don’t have shell). It is a more secure way to get files back and forth between the server, and if you are on an ISP that throttles FTP upload speeds you can sometimes dramatically speed up your FTP sessions when uploading to your site by using SFTP as it’s not a (currently) commonly throttled port when ISPs are throttling ports common to file sharing to limit their end users ability to share files.

It addition, by creating your FTP and Email accounts yourself, you put the ability to reset passwords when you forget in your own hands, and you don’t have to wait for support to do it for you, which is a handy little thing to be able to do.

Trend Micro is reporting that a massive attack has been launched against web sites using old or poorly configured PHPBB installations.

This compromise is almost similar to the mass compromises that they and others have reported on earlier this year — visiting a compromised site leads to a series of redirections, which eventually causes the downloading of malware.

In this particular case, TROJ_ZLOB.CCW is on the tail-end. “In true ZLOB fashion, this variant poses as a video codec installer”, and appears as the graphic at left.

For more information, check out the Trend Micro Blog.

If you have PHPBB installed on your web site, take action now to make sure that it’s up to date and patched, and not being compromised. We seem to have a particular issue at times with folks trying out the software, and not using it – leaving it hanging out in an ignored subdirectory mis-configured, un-patched, and totally vulnerable because it’s still public and malicious folks can still find it. Unpatched and unused bulletin board systems often become a playground for hackers as they post spam after spam in your forgotten board, taking up resources on the server as well as putting your account and anyone who stumbles onto the unused software at risk.

Never leave unmaintained software hanging out in a public directory – if you are going to periodically play with new software but can’t give it adequate attention frequently or immediately, put it in a password protected directory so that it’s not available to the general public just in case you forget about it.

If anything in your directories are public, always make sure that they are patched, current, and maintained – and if you can’t use the most current version of a software for compatibility issues, make sure that the version you are using is not compromised. A simple Google search for the software name, version, and security advisory is usually enough to turn something up if there is one.

We will be doing an audit of the servers to find PHPBB versions subject to this risk, and will take them offline if we find them, so if you’re using it, get there before us and patch it.

This past week has brought up some very interesting illustrations of just how careful you have to be when downloading or purchasing software off of the Internet. Everyone knowns not to download “too good to be true” free programs to their computer, and almost everyone now runs virus and malware scanners for their desktop to protect their computer from a wrong decision. Can the same scheme that infects your computer infect your site?

You bet.

Just this week, it was discovered that a massive number of Wordpress Blogs were hacked by an organized scheme, including installations at ZDNet, utilizing an xml-rpc vulnerability. Some of the hacks also came in through users downloading Wordpress themes that were infected (likely deliberately, but maybe not). Remember the old Lost Boys vampire thing where you have to invite him in for the vamp to be able attack you in your own home? Yep, same thing.

Frankly, we here at DrakNet are not immune to this – this past week, I was toying around with the idea of installing a directory of Soholaunch hosts. I had looked at this software and when I tried to order, it checked me out at a different site – which should have been my first clue. $90 later I had software that I hadn’t checked out, and the awakening came only after I purchased it.

When I unpacked it, there were immediate indications that something was amiss – the files provided were all dated May of 2005. “Good” PHP practices in May of 2005 compared to April of 2008 have changed significantly, and what everyone thought it was a-ok to do back then in the intervening years has been shown in some cases to be insecure and downright dangerous, so I began to do the due diligences that I should have done before I plunked down my money.

What I discovered was that multiple XSS And SQL Injection Vulnerabilities were found in the software in May of 2006 – a year after all the files provided me were created. Checking their web site, I found that the company advertised that their last update to the files was in December of 2006, implying that the software had been updated after these vulnerabilities were found – and yet as I searched through the installation I had downloaded, there wasn’t a single file provided that was dated after 08-18-2005, two days before it’s first official release date, and a year before it’s landing on multiple security advisory lists.

Had I done a search for the company, I would have seen that their company name and the word “nightmare” comes up multiple times on their first search page and I would have gotten some indication that, perhaps, this software wasn’t exactly my best choice. Had I simply done a search for their company name and the word vulnerability, I would have seen that there were 9,390 entries. I was in a hurry, and I didn’t – it was my own fault, and I admit it. I do know better, but I was in a hurry, and skipped that part.

As a consequence, I’m now arguing for my $90 back. I first went to the company who, of course, doesn’t do refunds and offered to work out what the issue was. When I outlined and detailed what I perceived as a suspicion that the company fraudulently advertised an update that didn’t take place to make it seem that they had patched insecure software that they hadn’t, suddenly, they were silent.

I then went to their payment processor for a refund, and thusfar the company has refused to speak to them, either. I will likely wind up having to drive to my bank, fill out paperwork, print out all of this evidence, and file a chargeback. Lesson learned… again.

So, how do you not fall into a trap like this?

Remember that old software is usually insecure – there’s even a term for it. Abandonware. Abandonware is old software, no longer maintained by the company or creator, and is no longer updated or patched when security issues are found within it. Microsoft FrontPage is actually now abandonware – as of late 2006, it is no longer supported, updated, or patched. There are thousands of scripts like this floating around on the Internet.

Google the script and the company with the word vulnerability and security. See if problems have been found with the programs, and whether the software developers are actually paying attention to the security community – good software companies (or good open source software developers) will jump when a vulnerability is found in their software, and will report back to the alert lists that it’s been patched after they release that patch to protect their users. If they don’t, that should be a red flag.

Google the script and the company to see what people are saying about them – everyone that does business on the Internet is going to aggravate someone, and finding something negative isn’t always a reason to run. You should, though, find more good opinions than bad opinions about the software and the company, and if you don’t find any opinions the software may not be widely used enough to have had it’s vulnerabilities discovered. This is the Internet – people talk. If they aren’t talking about you… well…

Don’t download Wordpress Themes, scripts, and so on from spammy looking sites. Get it from spammy sites, get a spammy product. Realize that anything that you put on your site is potentially open door to the developer and/or anyone else if there’s a hole – make sure that developer is trustworthy insofar as you can both not to take advantage, and to stand behind what they created with a sense of responsibility towards the people that use their software.

Remember that your web site is a veritable playground of mischief, and be as selective as you can in what you decide to snag and put on there – any program has the ability to put a back door into your site and subvert your site for its own ends. Do as much as you can to make sure that it doesn’t happen – and don’t get lazy like we did – because it’s the one time when you decide to just hurry up and do it that you may get burned.