Drobo

Are you F***ING kidding me?!?! Drobo stores admin password in PLAIN TEXT in Sys. Logs

Uninstalling drobodashboard on the mac creates a log entry inside the console app. Sure, that makes sense. HOWEVER, the console log entry ALSO includes the admin password in PLAIN TEXT that gets stored with the log entry too.

This is COMPLETELY unacceptable to me. Under NO circumstances should a root/admin password be stored in system logs in an unencrypted state. ANYONE with System level access can see the password. This is absolutely pathetic. No excuse for it at ALL.

Ugh… I’m disgusted.

David

That’s about as bad as it gets. Sounds like DroboDashboard should be uninstalled using AppZapper or similar, rather than any native uninstaller.

I doubt Data Robotics will respond unless forced to.
I looked for their FaceBook page, but didn’t find anywhere that I could post. Does anyone know if they have such a page?

Hello David,

Thank you for reporting this. This was an unknown bug in our current Drobo Dashboard for Mac uninstaller script. We are actively testing a new revision that will not have this bug and, when ran, it will clean up past log entries, so they do not contain sensitive information.

This is a bug that is only in our Mac uninstaller script (titled “Drobo_Dashboard_uninstall”), so installing and running Drobo Dashboard does not cause this behavior. This entry gets placed in the log when you uninstall.

We greatly apologize for this issue and will be posted a revised Mac uninstaller very soon. I will reply to this thread when it is available.

Once again…thank you.

-ErikP
Director, Product Management

Hi Erik,

Thanks for taking care of this issue. I’m glad that Drobo has agreed with me as to the seriousness of this issue. Additionally, I’m pleasantly surprised to see a real response on these forums as to this issue.

I appreciate also how fast you’re releasing an update to solve this issue.

Thank you,

David

Hi David,

No problem. All security-releated issues have to be taken very seriously. That’s why the new uninstaller will clean up any past logs.

This new uninstaller version can be found here:
http://support.drobo.com/app/answers/detail/a_id/611/

I am a fairly recent Drobo employee, but have been a Drobo customer since day 1. I appreciated Drobo Space back in the day and it is a focus of mine to check the forums frequently. That is how I found your post and we were able to work on a fix so quickly.

-ErikP
Director, Product Management

[quote=“DrDavid, post:5, topic:2729”]I appreciate also how fast you’re releasing an update to solve this issue.
[/quote]

Possibly a better approach would have been to approach Drobo discreetly without first alerting the world to this bug. No reason to shout a security bug to the world first.

Possibly a better approach would have been to approach Drobo discreetly without first alerting the world to this bug. No reason to shout a security bug to the world first.
[/quote]

I disagree. Who knew when or if Drobo would respond to the OP.

Damned if you do and damned if you don’t… at the very least you benefited immediately from the info, vs. when Drobo chose to release a fix/response.

I disagree. Who knew when or if Drobo would respond to the OP.

Damned if you do and damned if you don’t… at the very least you benefited immediately from the info, vs. when Drobo chose to release a fix/response.
[/quote]

That’s where the whole discreet thing comes into play. I don’t believe in the “damned if you do and damned if you don’t” scenario either. How is he damned by discreetly handling a bug?

Let’s look at the four possible scenarios. The OP contacting drobo and their reaction.

Scenario 1: The OP shouts out the bug to world and Drobo tells him to take a hike. I can’t see this happening but the result would be a known bug that Drobo refuses to fix.

Scenario 2: The OP shouts the bug out to the world and Drobo fixes it. This is what happened but the bug was and is known to the world. The bug still exists and is easily exploited until all known installations obtain the new uninstall program.

Scenario 3: The OP discreetly tells Drobo and they refuse to fix the bug. The OP still has the option to “go public” if drobo doesn’t fix the bug but the bug isn’t known. While that isn’t “security” is it still better than a known bug.

Scenario 4: The OP discreetly tells Drobo about the bug and Drobo immediately fixes the code and rolls out new installers and uninstallers. The bug isn’t publicly known and new software is rolled out. Drobo can then notify their customers about the bug if they think that is best.

At any point the OP can always go public with the bug and “shame” Drobo to fix the problem or even cost them business by scaring off new customers if Drobo is slow to react or simply refuses to fix the bug.

But the way to handle a bug, especially one that exposes the password, is to contact support directly and give them a chance to do the right thing. Look over Drobo’s support history. Does anyone think they wouldn’t? Does anyone think Drobo would have reacted differently if he had contacted them directly? Did Drobo even delete the thread? Personally, I think they should have. Again, if they won’t fix the problem, the OP can always then go public.

I certainly don’t believe in security through obscurity but I do believe in giving companies the chance to fix problems and not going public immediately with bugs unless that company refuses to fix the problem.

Shrug … the product itself barely works to protect your data and they don’t even do anything about that. Look at my experience in a previous thread. No acknowledgement of problems, no timeline for fixes, and no reimbursement whatsoever. Quite frankly, a security scheme issue should probably be of less concern than the fact that the product seems to be unable to handle drive failures properly. It’s like buying insurance and finding out 6 months later when you need it that it doesn’t work.