They are out there… or should that be ‘they are in and around your network?’

Yes, at any moment in time, they may infest your network, putting your data at risk; ticking time-bombs waiting to explode, configurations ripe for exploit.

And don’t forget those decisions made in the heat of the moment that, had rational thought prevailed, would never have been permitted.

These are some of the threats that surface during a security audit and they are bad. It doesn’t take an elite hacker with a deep knowledge of Assembly or the ability to read and understand raw PCAPs to make the most of these weaknesses.

Sometimes it does not even take an intentionally malicious act to get a company to find out just how bad some of these things are.

All it takes is a little bit of short-sightedness, bad luck and poor timing to cook up disaster.

We’ve put together a list our top 24 threats and weaknesses that could impact your network: how many would you find in a security audit?

1. Default Passwords

There is a really good reason why you should be concerned about using default passwords. A Bing search returns over 64,000 results for a search on “default password list”.

It barely takes a second to find the default password for any program or piece of firmware, and most attack programs have those lists ready to go. Always change default passwords to something complex and unique in your environment. And never use the same password… see #11.

2. Administrators running as administrator

When you are logged on with administrative rights, or root rights, or sysadmin rights, or whatever the superuser account is called, then everything you do executes under those privileges.

That’s why you should have a standard user account for regular work, and use your admin account only when you need to. Unfortunately, not every admin exercises the same caution… and that’s when the trouble starts. Best practices refresher anyone?

3. Shared accounts

It is important that everyone has a unique account and password as that way they are accountable for their activity on the network (and traceable). If everyone uses the same account, or even just knows the password to a privileged account, you may as well disable logging to save the disk space because you will never figure out who did what.

4. Service accounts with known passwords

It’s not the first time someone needs to log onto a server and their account doesn’t have the necessary rights, so they just log on with the backup software’s service account or the BESADMIN account or some other account that is not theirs, but has the privileges they need and a known password. See 3 above. No accountability.

5. No, stopped, or out of data antivirus software

“Uhm, yeah, well, I stopped the antivirus service because it was using up too much CPU and I needed that server to run faster” – That’s the phrase that usually follows the detection of hundreds of different pieces of malware infecting thousands files on a machine.

If antivirus software is slowing a server down, then there is something wrong with how the antivirus software is set up or the server needs looking into as well.

Consult the documentation for the antivirus software and the other applications running on a system, and configure the antivirus software with the required exceptions to ensure that the server is not impacted, but it is protected.

Of course, if it was a user’s workstation that is now infected because they turned off antivirus, take it away and issue them an etch-a-sketch (picture). You should also be using a centrally-managed AV to avoid users turning AV on and off when they feel like it.

6. Missing operating system patches

In many cases of exploited systems, the number one root cause is often missing patches. Patches are created and rolled out for a reason… there’s a bug that needs to be patched.

If you don’t patch the bug, you are a sitting duck just waiting to be exploited. It’s simple: patch early, patch often. Checking for updates each day keeps the bad guys away.

7. Missing third-party application patches

And don’t just assume that operating system patches cover all your bases. Microsoft releases patches on a regular cadence, but patches for third-party applications come out all the time.

Workstations need updates for their PDF readers, Flash players, and all the other applications users like to run, but that doesn’t mean servers don’t have this issue.

How many third-party applications do you have that depend on Java? Check out our category Patch Central for a monthly summary of third-party patches… worth bookmarking for regular reference.

8. Unlicensed software

If you don’t think unlicensed software is a threat to your network, then you either have all your systems completely locked down with a standard image and site licenses for everything, or, you’ve never had to deal with a licensing audit.

If your users can download and install software on their machines; if you have a software share on a network server that admins (or others) can get to, and if you save your EA keys in an Excel spreadsheet that is passed around from admin to admin, then odds are good you have unlicensed software on your network.

9. Default configurations

Default configurations are not recommended configurations or best practice setups and they most definitely are not secure configurations.

Whether you are looking at the security logging on a system or the default credentials to access a system, change the defaults. The former are set far too low to give you useable data on any production system and the latter are well known and documented.

Review your domain policy for audit logging and set a policy that provides you with enough data to go back and reconstruct events. Scan your systems for default configurations and credentials and go change them now.

10. Example code

Example code is great for lab and test systems but should be removed from production systems before they go into production. Example code is usually written to show how something works.

It is not written to illustrate secure coding practices. Many an exploit has taken advantage of example code to get into a system.

11. OOB SuperMicro BMC controllers

If you have an out-of-band management card that uses a SuperMicro BMC controller, and you haven’t already patched it, then you have a system that can be queried by anyone with network access to obtain the admin credentials with which to log onto the controller.

That means they can bounce a system, mount and boot from a virtual ISO, and own your system simply by having network connectivity to it. And if you use the same creds to get into the remote access controller as you do for other things, they now have those creds too.

By the way, if you have servers with iLOs or DRACs then you have SuperMicro BMC controllers. The good news is a patch is available. The bad news is you have to find the update, and then go apply it to every server by hand.

12. Cleartext protocols

Anyone on your network with a protocol analyser could potentially grab cleartext credentials off the wire, but with properly configured switches that is less of an issue.

Anyone in Starbucks with a protocol analyser could potentially grab cleartext credentials out of the air if one of your users stops in with their laptop for a latte. That is a serious issue.

Eliminate all cleartext support now, both for your users and your admins. Telnet is done. SSH is where things are at. All email protocols these days have SSL or TLS versions. FTP should be used for anonymous download only. Anything else should use SFTP.

By Christina Goggi, Web Content Specialist, GFI Software