Announcing Unlimited File Size Support : upload any file of any size!

No More Size Limitations

We’re excited to announce the removal of all file size limitations within FolderGrid. You can now upload any size file to FolderGrid with no limit on the number of bytes stored.

A number of our customers want to store very large files – scientific or medical data, high resolution video content, backup files, and so forth. Unfortunately most cloud-based file servers enforce an arbitrary file size limit. We’re proud to be able to remove this restriction at our customers’ request.

Curious how we support unlimited?

Underneath the covers FolderGrid leverages the amazing infrastructure of Amazon Web Services (AWS) including use of Amazon S3 for redundant storage. The core FolderGrid service adds layers of security and usability atop AWS including an abstraction of the S3 “Object” concept. S3 does enforce a maximum object size of 5 terabytes - which ought to be more than enough for the overwhelming majority of users - but FolderGrid files maintain a one to many relationship with S3 Objects allowing us to support still larger individual files with no theoretical size restriction.

Share

Updated Apple iOS Support

Apple iOSWe’re pleased to announce that we released an update to our default web client yesterday evening that provides better support for Apple’s iOS - the operating system for iPads, iPhones, and many iPods. Users of those devices will now notice their downloads open in a new tab within the Safari web browser.

Note: iOS devices do not expose a standard file system and thus the Safari web browser on these devices will only “download” a file if you have an app installed that is capable of opening and viewing it. If you attempt to download a file that none of your installed apps can open your iOS device will simply ignore your download request and refuse to open the file.

Share

Why our zero footprint web client to our HIPAA compliant cloud file server is open-source

In short - we want you to copy it. We’ve spent considerable resources developing a zero-footprint web client that supports every major web browser including Microsoft’s infamous Internet Explorer 6. But despite that investment we give our client away freely because we want you to copy it, rebrand it, extend it, and generally make it your own.

At heart, FolderGrid is an IaaS offering and we aim to encourage outside development of mobile apps, native clients, and system utilities that leverage the highly secured file server infrastructure FolderGrid delivers. Rebranding our web client as your own to deliver a white-label solution is not only permitted - we fully support it.

Additionally, every feature of our web client is implemented through calls to our open Application Programming Interface (API) and the client source code therefore serves as a valuable reference for developers seeking to write their own FolderGrid clients. There’s no better reference documentation for a software developer than a working example. Developers! Developers! Developers!

Share

'Wall of Shame' Names Covered Entities Responsible for Exposing 21 Million Patients' Medical Records

A piece posted by ComputerWold covers the Office for Civil Rights’ listing of reported breaches of unsecured protected health information as required by section 13402(e)(4) of the HITECH Act. The listing (also known to the health care industry as “The Wall of Shame”) is posted in an accessible online format with brief summaries of the breach cases that OCR has investigated and closed, as well as the names of private practice providers who have reported breaches of unsecured protected health information to the Secretary.

“Since Sept. 2009, 477 breaches affecting 500 people or more each have been reported to the Office for Civil Rights (OCR) under the U.S. Department of Health and Human Services. In total, the health records of 20,970,222 people have been compromised, the OCR said.”
Among the largest breaches reported was TRICARE Management Activity, the Department of Defense’s health care program, which reported 4.9 million records lost when backup tapes went missing. Another five breaches involved 1 million or more records each.

Share

Securing Cloud Services

Shahid Shah recently posted a piece I wrote on Securing Cloud Services to his popular “HealthCare IT Guy” blog. In light of the highly publicized hijack of Mat Honan’s iCloud & gmail accounts, I thought I’d expand on point #5 “Don’t use reset tokens without expiration” in that piece and reframe it as “Understand the weaknesses of email-based password reset processes“. Mat’s gmail account was compromised because he had configured a “backup/alternative” email address and Google supports password reset through such backup addresses. After the attacker was able to compromise that backup email address through separate means, Google’s password reset process enabled the attacker to easily reset Mat’s gmail password and gain control of that account as well.

The lesson to be learned here is that when any account’s password reset process is tied to an email address - that account’s security is wholly dependent on the security of that email address. FolderGrid’s high security file server accounts are no exception. We rely upon domain administrators to ensure the security of the email addresses used as credentials for their FolderGrid service. Unfortunately, users tend to select weak passwords for those very email accounts due to their desire for ease of access.

If you are not hosting and securing your own email service then you should most definitely be using a provider offering two-phase authentication such as Google’s 2-Step Verification or equivalent measures. Forewarned is forearmed in the ever escalating online security arm’s race.


Share

Why we stopped trusting Egnyte – a cautionary tale for users of cloud services

Update: Please note this article was first published in July 2012. While we stand fully behind this post as true & accurate at the time of publication, we make no representation as to current applicability.

As the head of the engineering group at a leading provider of healthcare information technology, I frequently encounter the need to transfer files containing protected health information both internally amongst colleagues and externally with clients. Exchanging files containing data subject to HIPAA in a compliant manner is challenging with homegrown solutions and as Chief Security Officer I am directly responsible for meeting that challenge. So almost nine months ago we began evaluating market solutions, and liked what we saw in Egnyte.

The fast-growing “hybrid” cloud company, which just closed a $16 million investment from Google Ventures, Kleiner Perkins Caufield & Byers and Polaris, markets “HIPAA compliance for healthcare, pharmaceutical and biomedical businesses” and offers to execute a Business Associate Agreement during account creation. With such a strong pitch for HIPAA compliance and the association with big Valley-based venture capital, one might be forgiven for trusting Egnyte to securely store and manage highly sensitive structured data without any additional due diligence.

However if you were inclined to probe further, you would find, as we did, that their posted policies seem adequate, that they appropriately disable SSLv2, and that their security whitepaper makes bold claims like “Egnyte prevents cross-site request forgery and cross-site scripting” and _“Egnyte employs a third-party security firm to perform continual penetration tests to confirm the stability and reliability of the system”. _You might even note how the whitepaper states that user passwords are protected with bcrypt – a password encryption mechanism that should appease even the most paranoid among us.

Satisfied with the findings of the most thorough evaluation we could conduct externally, I directed a company-wide rollout of Egnyte to serve as our HIPAA-compliant cloud storage and transport service. While the service met our immediate needs I desired a tighter integration with our SaaS platform, and Egnyte’s rudimentary API proved inadequate for any sophisticated integration effort.

To meet that need, my co-founders and I decided to build an alternative IaaS solution complete with a fully open API. Exporting our files and folders from Egnyte and into this new service, which we named FolderGrid, was simple enough since Egnyte exposes an FTP interface. But Egnyte makes it difficult to export your users and permissions – and our effort to migrate our users and permissions is where this story gets interesting.

My team used Google’s Chrome browser to examine the Users & Groups management pages on Egnyte’s service – hoping to find an easily parsable form of our user and group data. Here’s a screenshot of where we started (with identifiable data blurred to protect the innocent):

 

Like many modern web applications, Egnyte’s web interface uses XHR to pull data from the server. So we opened Chrome’s Developer Tools window to examine the XHR URLs used to populate this screen:

 

The first request’s named certainly seemed like it might hold the data we were looking for so we started there by examining the server’s response:

 

We stared at that response in disbelief – much like I imagine you are doing as you read this. For the uninitiated, MD5 hashes have been widely regarded as dangerously insufficient for years. So the idea that Egnyte might still be using MD5 hashes was troubling, but to see any password hashes (MD5 or otherwise) appear exposed to endusers is a critically serious security defect.

This request was initiated as we were viewing our Power Users so we jumped over to the Standard Users screen and saw more of the same:

 

I immediately logged out of my administrator account and logged back in with a normal “Power User” account with no administrative privileges. I was able to reproduce the calls and pull a full listing for every user in the account – including the administrator accounts.

So although the screen rendered by my browser only displayed basic information such as user names, email addresses, and role – the server was actually delivering far more data about every user and that data was readily readable by any Power User on the account. The obvious next move was to determine just what was included in that broader set of user data.

Upon examination there were 100 fields for every user. This screenshot only shows some of the more interesting fields we discovered:

 

On a hunch, I pulled out all the MD5Passwords from my user listing and decided to run a hash search on each to determine if any were easily crackable:

 

The very first password hash in my list scored a hit using a specialized Google search:

Although that hit alone was likely evidence enough to prove Egnyte was using unsalted MD5 hashes for password encryption, I decided to run one more test. I changed a user’s password and set it equal to my own. Then I reloaded the user screen and examined the new XHR response – our MD5Password hashes were identical.

If you’re having trouble following the technical details – the implication of all this is that any Power User on my Egnyte account could, with relative ease, deduce any other Power User’s username and password – including Power Users with administrative permissions. This of course defeats any and all permission controls on the account as well as any audit trails – since the malicious user would be indistinguishable from the authorized user once authenticated.

If you are an Egnyte account administrator you should immediately disable the option allowing Power Users to interact with Users & Groups (and of course change all of your Power Users passwords). That configuration change should protect you from this privilege escalation vulnerability. It was the first action I took – right before I began removing all data from Egnyte’s service.

As the Chief Security Officer of Pascal Metrics, I’m ultimately responsible for the safe-keeping of highly sensitive patient data from the biggest & most trusted brands in healthcare. Deciding to entrust Egnyte with some of this data was not a call I made lightly and I’m disappointed to find such a negligent oversight in the design of their web interface. Fortunately, we discovered these material weaknesses in Egnyte’s service and took corrective action before putting our clients at significant risk.

Rapidly evolving software will never be defect free and perhaps Egnyte could be forgiven for unintentionally exposing its customers to this privilege escalation vulnerability. After all, the configuration workaround I described offers some immediate protection. However, by adopting a cloud service an end-user cedes enormous amounts of control to the provider of that service – an act requiring a high degree of trust. By their nature, cloud services are not easily externally vetted and customers must rely upon the stated policies and claims of a vendor to evaluate the vendor’s offerings.

The vulnerability I have described allowed us unusual insight into the detailed workings of Egnyte’s service. They are clearly using unsalted MD5 hashes for password encryption (an indefensible design) while claiming to adhere to much higher standards (bcrypt). This blatant misrepresentation undermines any trust I might have retained for the service.

We’ve stopped trusting Egnyte, and we’ve stopped using their service. Given the potential ramifications of a data breach – especially one involving data subject to federal regulations, my advice to fellow CSOs (and all users of cloud services) is: caveat emptor.

Share