24 things threatening your network right now

GFI Software Limited

By Christina Goggi, Web Content Specialist, GFI Software
Wednesday, 13 August, 2014


24 things threatening your network right now

All it takes is a little bit of short-sightedness, bad luck and poor timing to cook up disaster. So how many network threats and weaknesses would you find in a security audit?

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 by employees 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.

Here is a list of 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-date 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 of 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. 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. You should also be using a centrally managed AV to avoid users turning AV on and off when they feel like it.

Antivirus software logos

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?

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 licences 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 set-ups and they most definitely are not secure configurations. Whether you are looking at the security logging of 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.

Binary code numbers

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.

13. Credentials stored in cleartext files

This happens far too often in batch files and scripts, and it needs to stop. Anyone with access to a file storing creds now has those creds and, at that point, we’re back in the same situation as #3 and #4. Store creds as encrypted strings or, better still, configure your scripts when possible so that they don’t need to store creds at all and instead execute in the context of a service account which can securely store creds.

14. Runaway log files

Disk space is cheap, but it is not infinite, and a process that generates huge log files that are never reviewed or cleared can chew up all of your free disk space. When it does, the server comes to a screeching halt. This can become the cause of both accidental and intentional denial-of-service attacks. Either you shoot yourself in the foot or an attacker slams endless bad login attempts against your server. End result: the logs fill up and the system crashes.

Ensure that logs are reviewed regularly, cleared out when they are no longer needed and that you monitor systems for disk space.

15. Weak (or no) wireless encryption

If you are using WEP or WPA on your wireless network, or if you aren’t using any encryption at all, then all your network data can be read by any attacker within range. And since ‘range’ can include the parking lot across the street, the hotel next door or the office on another floor, that includes a lot of space you cannot see, let alone secure.

WPA2 Enterprise is really the only valid encryption algorithm you should be using at work, and you should make sure you are using WPA2 at home with strong, complex keys. That way, your neighbour’s kid won’t try cracking your wireless network to impress her friends.

16. Windows XP

Yes, I know it was the best operating system you ever used. I, too, have fond memories of XP going back to the early 2000s. Let it go. XP is end-of-life, and that means there are no more security patches. No more updates. No more support.

If you still have XP on your network, then you are just making it easy for the bad guys. Remember that there were patches for XP almost every month up until the last month it was supported. Do you really think that there are no more vulnerabilities out there?

Windows XP screenshot

17. Legacy firewall rules

For all the review and oversight that goes into opening something on a firewall, it never fails to amaze me the number of legacy firewall rules there are on systems. The servers that they applied to are dead and gone. The services long since transferred to some other platform. And yet, there is still a NAT on the firewall, and a rule permitting inbound traffic.

Some day in the future, when a new system is put into the DMZ but before it has been hardened and reviewed, there’s going to be internet traffic hitting it. I hope it can handle that. Take some time now to review your firewall rules and make sure that all the openings are still valid. Add to your server deprovisioning process and send a notification to the firewall team so that they can remove all the rules that are no longer needed.

18. Legacy group memberships

Just as firewall rules are sometimes no longer needed, not every user needs to be in every group to which they were ever added. Roles change, titles do too, and some users no longer need access to everything they used to need. Review group memberships at least annually to ensure that least privilege is still in effect.

19. Legacy ACLs

And while you are reviewing group memberships, you should also review your ACLs to ensure that they are still current and correct. If users have access to data that they should not, they are going to find it. That’s the 83rd corollary to Murphy’s Law. If that data is sensitive or embarrassing, the impact to the company could be significant. Review ACLs with data owners annually to ensure that they are correct.

20. Access to personal email accounts

When users have access to personal email from work, they can send data out which you have no visibility into, and they can bring data in, potentially including malware. All of that bypasses your filtering systems and DLP systems, and the news frequently reports on data that has been compromised because someone emailed a file to their personal account so that they could work on it from home. Access to personal email from work machines may just be too dangerous to permit.

21. Self-signed/internally generated certificates

How many times a day do your internal applications ask your users to see, and click through, this warning? If you are using self-signed certificates, or internally generated certs where your users’ systems don’t trust the root CA, then you are training your users to ignore warnings. You are doing most of the hard work for those using phishing attacks against you.

Never use self-signed certs for anything users will interact with, and ensure your internal CA is trusted by all your internal clients, so users never have to think that this is a message that can be ignored.

22. Users who will download anything

There are employees who will download any screensaver or freeware application, or anything they are sent with a ‘this is the coolest/cutest/most helpful life-changing application that you have ever seen’ note attached. Yes, those. Every network has at least one individual. And no matter how many times they have to get their system reimaged, they are just one pop-up ad away from downloading and installing something else.

23. Users who will click on anything

Similar to #22, these users are the ones who will click on anything. Any link in an email, any ad on a webpage, anything at all, and they always click ‘Yes’ when prompted. They aren’t going out of their way to download and install something - they are just really click happy. They are the employees with six toolbars and three search providers in their browser, all their default file associations are messed up and, yes, they do provide their username and password in response to that helpdesk survey they saw on Facebook. And they aren’t even ‘friends’ with the company helpdesk! You are going to have to go the extra step to help these employees kick those habits.

24. Users who believe anything

These are users who really believe a foreign prince or president wants them to help him smuggle millions out of his country. Who really believe that the guy with the funny accent who doesn’t know their name actually is from helpdesk and needs their credentials to back up their files before a virus deletes everything. Who have no clue why Bill Gates wants them to forward an email 20 times, but they are happy to do so in exchange for that free trip to Disney World. These are a danger to the network and need a reality check and a lot of education before they really cause some damage to the company.

A lot of these 24 items are familiar to admins but the fast-paced environment we all work in takes its toll on our cautious approach to everything. A regular security audit will help identify most of these danger points.

But each one of the threats above must be addressed sooner rather than later. Don’t underestimate the importance of educating (and re-educating) employees. They are the last and most important lines of defence on your network because they are the weakest link. Understanding that, and working with that, is a great start.

Images courtesy SFSD Technology Help Desk, Thomas Guest, Jim Sher and Yuri Samoilov under CC

Related Articles

Is the Australian tech skills gap a myth?

As Australia navigates this shift towards a skills-based economy, addressing the learning gap...

How 'pre-mortem' analysis can support successful IT deployments

As IT projects become more complex, the adoption of pre-mortem analysis should be a standard...

The key to navigating the data privacy dilemma

Feeding personal and sensitive consumer data into AI models presents a privacy challenge.


  • All content Copyright © 2024 Westwick-Farrow Pty Ltd