Welcome to HVAC-Talk.com, a non-DIY site and the ultimate Source for HVAC Information & Knowledge Sharing for the industry professional! Here you can join over 150,000 HVAC Professionals & enthusiasts from around the world discussing all things related to HVAC/R. You are currently viewing as a NON-REGISTERED guest which gives you limited access to view discussions

To gain full access to our forums you must register; for a free account. As a registered Guest you will be able to:

Participate in over 40 different forums and search/browse from nearly 3 million posts.

Looks quite cheap. "To a hacker such as Rios, that was virtually no security at all", “within five minutes, I’ve found what I’m looking for”.

Looks like he found how to download config.bog, which contains password hashes. I believe you have to have an access to a station with incorrect permissions. And the passwords have to be simple to brute-force hashes later.
So I might be wrong, but it doesn't look like Niagara security breach -- more like a hack of one particular demo.

Looks quite cheap. "To a hacker such as Rios, that was virtually no security at all", “within five minutes, I’ve found what I’m looking for”.

Looks like he found how to download config.bog, which contains password hashes. I believe you have to have an access to a station with incorrect permissions. And the passwords have to be simple to brute-force hashes later.
So I might be wrong, but it doesn't look like Niagara security breach -- more like a hack of one particular demo.

Agreed

To all those using the defaults on station and platform levels..... default ports... etc.... shame on you!

You can also edit the attempts of an incorrect login prior to blocking....

You can also put it behind the walls, VPN, etc, etc. to minimize a risk.

I don't have access to the pro side so not sure if this was already discussed there.

In terms of the article, I have extensive experience in Computer Security and also with Niagara and the issue brought up is not a hacking issue nor a computer security issue.

The article inappropriately adds flare to something that is more common at your bank or Facebook. Security is not a single entity and in this case the Niagara security is working fine. It was the setup of the system and the lack of configuration by the network designer that is causing problems. It is the same as all those people who buy Linksys routers and put them on their cable modem at home. If no one designed or setup the system then it will have the defaults.

Also I have many rainbow tables, which is the tables that reverse lookup hashed passwords, None on my Niagara passwords are anywhere in those tables and to brute force decode them would take about 30 months. If someone is using a poor password or not changing a password regularly then that is not a security risk of the software that is a security risk of the user.

Don't blame the car or the engine for an accident because of a poor mechanic or inept driver.

Tridium just published it's description of the matter. It is basically "if you give an access to the whole file system -- don't be surprised that any file could be downloaded". No hidden bugs or vulnerabilities.

Thats not entirely true... while it is true that most security issues are usually an installation problem there is one fault of Tridium that he found. I also know of it and won't disclose it here but its something Im sure Tridium knows about and is hopefully coming up with a solution. Its a bit more serious than simply getting access to the password hashes... but you still need some sort of access to the station to get the information. So any demo that isn't properly secured is at risk.

There is an inherent problem with systems that simply rely on password authentication for their security model. This company is not alone in their insufficient security model.

If an unwanted agent gets a user and password handed to them the idea that this should not be enough information with a secure system to compromise it in most instances. Is the root user accessible other than from the console?

This Niagara system platform is not designed with security in mind. So, it fails. Utilising a system designed with security planning is an acceptable long term solution. If you want security you need to start with that and design your system build around that premise.

The granularity is there, you can customize the security down to each object. Many don't - whose fault is that? The software developer, or the mechanical outfit who can't spell IT, let alone security? Default platform credentials, demo accounts, guest account enabled, Internet facing without any firewall in place or VPN?

If you need two-factor authentication, RSA SecurID Integration is an option starting with 3.6.

The granularity is there, you can customize the security down to each object. Many don't - whose fault is that? The software developer, or the mechanical outfit who can't spell IT, let alone security? Default platform credentials, demo accounts, guest account enabled, Internet facing without any firewall in place or VPN?

Well, to be fair, it's not always a matter of a "mechanical outfit who can't spell IT, let alone security".

We always change default credentials, it's a first action. And don't do demo guest accounts.

Past that, we set up what the customer wants. In short, its up to them. We do advise ... we don't TELL them what they should do or have.

Depending on the customer, some are very security conscious and knowledgeable.

Others, not so much. Some want convenience and ease. Essentially easy access without need for VPN, only a few accounts ... and all of them super users. <Shrug>

Still others tell us to just leave it as they (the customer) hasn't a plan in place yet, and they'll implement security later ... and they just never get around to it. Or, if they do, implement only minimal methods.

Quite commonly, they'll start with the best intentions. Setting up some scheme of Users, Permissions, and Categories that seems to fit their wants and needs. But then find that they need to continuously change or massage the specifics. Which takes time, effort, and someone with the correct credentials who is able to do this.

But the fact is, its an in-house maintenance/repair department doing this, typically. And also typically ... they're always short of time and manpower as they have other duties to attend to ... like the real work they're hired to do.

So, in the end, what I often see is that virtually everyone ends up with unrestricted access and privileges under his/her log-in; or the user name and password of one or more of the super users becomes common knowledge.

I see it all the time.

Just a couple weeks back I was on one of a particular customer's sites. Said customer, a large organization with many sites, had changed user names and passwords, permissions, etc after we'd initially set up their site. Doing due diligence to the idea of implementing at least basic security. I was there on a warranty/service call. And wanted to view things from the front end, and perhaps make a few changes (didn't know yet if it'd be necessary). Tried at first to log in using a user name and password we'd originally had set up for our own use during system setup. No go.

Head of maintenance wasn't around or available, I guess he's one of those types who actually turns off his cell phone when he's out fishing. I asked his stand-in if he'd log in on his account. He told me I didn't want to do that since his account was restricted. But, without pause, went on to say, "Just log in with Jake's name and password ..."

Jake is the head of maintenance who'd gone fishing.

And pointed to the sheet of paper on the wall next to the PC, which had the info neatly printed on it.

He left commenting, "Or just ask any of the maintenance staff, we all have it memorized."

Certainly some controls contractors do less than they should, at a minimum, to implement at least some sort of security.

OTOH, unless one is dealing with some small Ma & Pa business, where Ma and Pa haven't a clue and rely upon the contractor to handle it, the responsibility for security is really in the customer's lap. It's the customer's system ... and their network.

We advise em ... we don't TELL em what they have to do. Then it's up to them to either lay out what they want so we can implement it, or to do it themselves (we provide training and manuals) ... and KEEP it up to date.

Do the Iridium folks have weak security methods and vulnerabilities built into their system?

I'm not qualified to answer that. I know more than a little about the subject, but am hardly an expert.

I do know that a LOT of end users out there don't even implement the basics. And if they'd do just that much ... it'd be a VAST improvement.

But getting em to do that is another subject. Heck the average home user or small business pretty much ignores all the basics right now as concerns their internet connections, presence, and usage ... even tho they've been warned time and time again by endless news articles, etc that they should be a bit more security conscious.

What's that old saying? "Yah can lead a horse to water but yah can't MAKE him drink it."

Greetings to you Digo. Perhaps you could answer the question of whether the root user is accessible other than from the console? As a second can you provide the RSA key documentation? Whilst you do this I will state this is still not enough protection in the context of a secure system, but simply a start. It is an improvement this 3.6 version started this functionality. When was this version released? Apparently the article was generated before this release.

The social element that Osiyo is describing is a primary reason why simple password protections in your system should not be all that is utilised and also why passwords should not be the reason in most instances your secure system is compromised. I need to make the important statement again: More layers are affected.

AtticusFinch,
Although you seem to have a security background you forget the number 1 rules of security. "There is no patch for the user" If a system must be used it CANNOT be secure. PERIOD.

In a typical security environment your "Threat Assessment" would determine the layers of security that are needed for a system. If the systems is just your HVAC for an office building, username & password is more than sufficient because the threat is low even if compromised. If it is running the access control system to a research facility then additional security may be needed based on the threat assessment. In today's security world much of that comes from outside sources such as additional IT network security, system monitoring, etc. I have worked on some very secure sites and have yet to see 1 product that has all the security necessary, it is often a layered approach from multiple vendors.

Niagara AX 3.6 has been available since July 2011 and it does have RSA support but I don't the documents handy.

Support for SSL has been implemented for a very long time and works very well, but most sites don't use it because it has an additional cost. With a proper setup of SSL and a password policy, the system can be as secure as any common banking application used today. If the security is good enough for an online bank it should be sufficient to protect the temperature of an office building. Things can always be more secure in some way or another but you need to manage the level & cost of security against what you are protecting.