MCV Log servers left open- potential compromise of sensitive info.

[Sender]

Could my login password in any way be disclosed?

[TC1]

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.

Bingo. If they do the steps you outlined, then things are back on track.
I'll give them until Monday, business hours. Though a real company would have responded already.

[S-F]

There may be no business hours tomorrow as it's a holiday.

[TC1]

Federal holiday in the U.S., banks and post offices closed, many businesses (including the one I work at) remain open.

But the reality is that security breaches and privacy issues should not be governed by normal business hours.

[Da_JoJo]

considering one would still need a vera and a root login to that and skill to be able to trace the routes used i think in the end it isn't all that bad as it looks. thing is that mcv should make this log uploading also a safe construction so there is no risk anymore, which presumably they allready did . the ftp servers have logging and they probably know who got in there. might as well look into the fact that breaking in such system is legally protected and they can sue you as well.

[niharmehta]

The issue is not that the Vera itself is open for compromise. ( I don't think system passwords are in the logs). The issue is that the logs themselves were left open  as well as sent in the complete clear.

The system has been changed to only allow PUT requests now which helps initially. However, that is a stop gap for now. 

1) The logs are sent in the clear using FTP on the public side.  It does not use the management tunnel or any other authenticated crypto system to ensure that the system the logs are going to, is actually MCV. 

2) A real hacker would easily mask their identity. So I doubt MCV could ever find WHO for either criminal action or civil lawsuit.


A quick fix should be to use their management tunnel for transport. 

[Da_JoJo]

got a point there. it's something that needs securing and MCV should look at it.

[Colin Burke McClure]

Thank you niharmehta. This was brought to my attention this morning. Rest assured we are taking this event very seriously.

We're currently reviewing the specifics of this event and conducting a comprehensive audit.

We will respond with a detailed postmortem analysis in the next 12 hours to provide clarity on what transpired, as well as the actions have been taken to prevent this from recurring.

Thank you for your patience and support.

[niharmehta]

Colin,
Thank you for finally jumping in with an official public recognition of the problem that occurred . Good to see your team responding to this.   The audit and prevention plan is exactly what we are looking for in this.   Looking forward to your results and continuing dialog.

[Colin Burke McClure]

We wanted to get back to the group with an update, albeit more than a few hours later than we would have preferred. Our apologies. Suffice to say, we are very, very busy at present.

After reviewing the documentation surrounding this event, the root cause and resolution are clear. This was a simple human error, resulting from the misconfiguration of our servers.

As previously disclosed, there were only 2 external connections. Both brief. Further the situation was remedied immediately upon being brought to our attention. Doesn?t excuse the lapse, but on the upside, no Personally Identifiable Information was downloaded by those outside third parties.

That said, we?ve immediately implemented a 3 step check and balance process (which requires sign off of senior staff member) before deployment of any hardware that may contain PII. This will ensure that this type of oversight does not happen again.

Further, our new MMS backend is far better automated, hardened, and scalable, which further reduces/eliminate the risk of these kinds of errors in the future (as well as enabled a host of exciting new features and capabilities).

We are working triple time to get everyone updated and migrated over, but as Aaron has previously posted, this is not a trivial task. We will keep you posted.

//And yes, I did just say that...

Again, on behalf of everyone here at MiOS and Vera, please accept our apologies for this error.

@niharmehta Thanks for the kinds words and welcome. I know you guys have been starving for attention here in the forums and this is long overdue. You will be seeing a lot of of me, as well as the rest of the staff, in coming weeks and months. Our lack of attention here (however inexcusable) has not been due to lack of action. Quite the opposite actually. More to follow. Soon.

[niharmehta]

Hi Colin,
Great response. Thank you for following up. Appreciate the openness that MCV seems to have lately on the forums. Great engagement between the community and the developers generally means a great product.

Since there were only two logins to the server, that seems to indicate that it was just myself and the other user on the forum I tested with.   That is fantastic news that in this case no PII was downloaded.

One open item is the transfer of the logs via clear FTP.  This can be captured via many MITM attacks.  Does the MMS infrastructure secure this transfer or is this something that will come later?

Thanks!!