On 1/13/14 at around 8:00AM PST , while poking around the my Vera, I found the static credentials used by Vera to archive logs to PUBLIC FTP servers.

I tested these credentials manually, I was surprised to see that I was able to traverse the system and download ALL LOG FILES FROM ANY VERA THAT HAD "ARCHIVE TO SERVER" enabled. The directory was organized by the Vera ID number. I found my own Vera directory and downloaded many of my logs. I could easily see the directories of thousands of other Vera. However, I did not download any other users logs.

I verified my findings first with a senior member of the board as well. Using their contacts within MCV, the log server was secured within a few hours. I also opened a case, and left a VM and PM with MCV on that day to understand the scope of the issue, and how users will be notified. I have heard nothing useful back at all. Four days later, the only thing they told me was that the settings on the server were open for just a short time while the servers were migrated and a setting was missed. However, no details were provided on time frame or impact to users. I have repeatedly asked for notification to these forums to alert others of this mistake with no response.

Checking my log files, I have found security system PIN and other information that would pretty easily identify the location of my Vera. If you are integrating your Vera with any security devices I would change these codes immediately and no longer archive to MCV servers.

I delayed making this public until the servers were secured or offline and was hoping that MCV would do the right thing and let people know of this error and provide recommendations to reduce risk .

At this point, it seems the servers are indeed restricted from downloads or directory browsing.

However, it does bring up another question. Right now, the logs use simple FTP over an unencrypted path to MCV servers. It does not use any sort of encryption nor does it use the SSH-VPN tunnel that MCV uses for remote access. The log information with associated potentially security codes are sent in the clear. This needs to be changed ASAP or everyone should consider no longer archiving to MCV servers if they are worried about security . Using the tunnel would be an easy first step in securing this data while being transported.

From what I've seen in my short time in these forums and using the product, there's a lot of things they need to learn, and not just about security. If it wasn't for the generous developers and senior members like yourself spending your personal time in these forums, this product would be dead, IMO.

WTF? So because I use the gcal plugin I need to change my Google login information? And change all of the PIN codes on my lock? And whatever else I've entrusted to Vera? Probably my Vera Alerts ID's too. So since Monday people could have been reading my calendar (I keep a lot of personal data on there) and receiving my Vera Alerts? And knowing where I live? And who knows what else.

This really sucks.

Logged

My forum account was apparently hacked by a leprechaun. And he's drunk all of the time. If a post of mine seems a little off kilter, it's probably because he made it.

Well, it has been locked down since monday afternoon some time. I do not know when the server migrations occurred when the error was introduced. MCV did not share that information. So it may have been open for hours or days. MCV should let us know how long this was open and which users files were downloaded as per their logs. Maybe (hopefully) nobody had their logs downloaded. Who knows. Obviously the clear FTP is another issue, but other than the NSA or other government entities , it is unlikely a backbone router has been compromised in the middle.

As for the backup of the configurations to the backup storage servers, the transport does seem to be secured via SSL as it is using HTTPS from some cursory connection traces I did. However, who knows how secure the storage is once it is backed up.

What is interesting is that the log data is hosted in a data center located in Northern California, and the backup files in another data center in Southern California. I would assume that they would potentially be under the data breach disclosure laws in California .

Personally I am disappointed. I really like the MCV platform and had no ill will towards MCV. I just want them to do the right thing .

I would assume that they would potentially be under the data breach disclosure laws in California .

I have just had a brief discussion with an attorney and while he mainly works in international law he seemed to think that if Vera users have no agreement with MCV in regards to data security they can do whatever they like so long as there are no proven damages. And in this case it, so far, appears that there have been no damages. So unless someone can prove that their house got broken into or something like that due to this oversight MCV could plain deny the whole thing to everyone if they so desire. I'm of a like mind with you in not wanting to vilify MCV. Frankly I want them to succeed as a company and product. But I do think that they should fess up to their customers on this one. If they want to leave us in the dark regarding software and hardware updates that's one thing. Their products are still working as advertised.... for the most part. But if they want to neglect our personal information we trust them with we should be informed so we can make other arrangements.

Logged

My forum account was apparently hacked by a leprechaun. And he's drunk all of the time. If a post of mine seems a little off kilter, it's probably because he made it.

Security issues are found all the time in the software world. Most of the time when companies at least take the effort to communicate with their end users to the risk, impact, and mediation plan. Customers can implement the fix and move on. No long term harm done as long as the company takes the view that responsible disclosure is right for both their customers and themselves.

No point even considering a lawsuit or legal liability. Regardless if it is possible or not. It is in nobody's best interest to even really consider it. An adversarial relationship with MCV is in nobody's best interest.

Hopefully they can implement a truly secure logging mechanism before the next release. For now, just stop archiving. Change your pin codes, device/plugin passwords, and hope that MCV decides to comment here.

I'm in no way trying to bring the law down on MCV. That wasn't my point. I was just trying to clarify if they were legally obligated to inform us. I tried to make that clear at the end of my last post but maybe I didn't succeed.

Though I am pissed!

Sorry.

Logged

My forum account was apparently hacked by a leprechaun. And he's drunk all of the time. If a post of mine seems a little off kilter, it's probably because he made it.

Security issues are found all the time in the software world. Most of the time when companies at least take the effort to communicate with their end users to the risk, impact, and mediation plan. Customers can implement the fix and move on. No long term harm done as long as the company takes the view that responsible disclosure is right for both their customers and themselves.

No point even considering a lawsuit or legal liability. Regardless if it is possible or not. It is in nobody's best interest to even really consider it. An adversarial relationship with MCV is in nobody's best interest.

I work in the software and website world, and in security. I agree with your first paragraph.

I respectfully disagree with your second paragraph. Governmental laws and punishments, and civil lawsuits, are not always about extracting punishment or damages, but to effect change. To make sure it doesn't happen again and to send a message that these types of actions are unacceptable. We have laws to help create the type of world we all want to live in.

As you began to allude to, when companies communicate with their customers and get in front of the issue (ie, the Target breach for example), things work out better for everyone. Fears are quelled and any possible damages that might have occurred are minimized. All MCV has to do is communicate with their users. They don't do that, and when they do, it seems reluctantly.

I'm in no way trying to bring the law down on MCV. That wasn't my point. I was just trying to clarify if they were legally obligated to inform us. I tried to make that clear at the end of my last post but maybe I didn't succeed.

Though I am pissed!

Sorry.

@S-F. What you say makes sense. In fact, any company really need to consider their potential liability any time they decide to store end user sensitive information. Not just from civil liability but also potential brand issues. I know you were not threatening a lawsuit, I just wanted others to reconsider that train of thought .

I respectfully disagree with your second paragraph. Governmental laws and punishments, and civil lawsuits, are not always about extracting punishment or damages, but to effect change. To make sure it doesn't happen again and to send a message that these types of actions are unacceptable. We have laws to help create the type of world we all want to live in.

As you began to allude to, when companies communicate with their customers and get in front of the issue (ie, the Target breach for example), things work out better for everyone. Fears are quelled and any possible damages that might have occurred are minimized. All MCV has to do is communicate with their users. They don't do that, and when they do, it seems reluctantly.

In a bigger picture. Completely agree.. Especially when the damages are large, and the "little guy" has minimal leverage.

In this case, MCV is a small company, their ability to even defend themselves is probably minimal. More than likely they would just end the Vera line and we are done with our cool little, cheap, no recurring cost, extendible, flexible, zwave controllers. Nobody is interested in that.

They do need to do a LOT of work to rebuild trust. Threatening with lawyers is not the first step in this process.

Now this is public, lets give them a chance to do whats right. Although I could not get them to do it privately, I assume that if this has made enough users angry, that they will respond..

What would make me happy is:Disclosure of the issue and affected time. Private notification of any users that had their information downloaded. (if any)Steps and timeframe to secure logging archiving and transport.Documentation on how private information is collected, transported, and protected. (logs, backups, etc).How they plan to keep this from happening again.

I have heard security is a big focus of the upcoming release. So hopefully they have changed their internal processes and will jump on these issues.