Thanks so much for taking this on. I look forward to the video!
A newbie-level question based on one piece of wording in the bulletin:
There is a obvious vulnerability of FileMaker that allow access to the local FM-based database file:"
This only affects local files, or also files hosted on a network, and/or files hosted on FMServer ?
Thanks for your work!
From the way I read it, this is if someone gets ahold of a copy of your database. I don't think this applies to reaching a database that is hosted, but when you have direct access to the database file. Someone will correct me if I'm incorrect.
Seems obvious, but remember also to remove the FM sample file on every server installation. Or, at a minimum, block the Full Access Admin log in.
I heard about CVE-2014-8347, but didn't have a chance to look into it more deeply yet resp. confirm it. Have you?
The idea of the video is a good one. Here are two more points to the list:
- Temporary Files (e.g. ContainerCache of interactive containers, encryption of temporary files)
- Secure Container Storage
Correct, it only affects your file when someone has a copy of it. Hence why encryption at rest can protect you.
That's a good one that was mentioned at the session.
The bug is confirmed, but it only affects standalone files that are not encrypted at rest, and requires someone to know the name of the admin account.
So encrypting the file and changing the admin user to something else (even something as simple as admin123xyz or similar) will greatly improve durability.
Thanks for the notes, container storage is a big one.
(can't edit the original message)
Additional List of Topics:
-Removing FMServerSample file.
-Securing container storage.
-Securing temporary storage.
From DevCon John Thatcher's FMServer session: Don't save file as Compacted Copy on a file where EAR is enabled.
He explained the uncompacted blocks "empty" data is used by EAR to be filled with dummy data. Without any empty space it is less hard to decrypt encrypted blocks ...
// if i remembered correctly
I think that only applies to the initial encryption of your database. When your DB is not compacted, each block is about 50-75 % full, so there's space for the random data and checksums. But when it's compacted, FM tries to fill the blocks up to 100 %. That means: when you want to encrypt, you first need to "uncompact".
So, afaik, having a compacted copy only slows down the initial encryption process (once!).
Thanks both, I will be doing considerable research and collaboration with a few other developers. I will try and get in touch with John to clarify.
I would include a few moments outlining what commercially available software crackers do, and the importance of restricting access to the file and backups, and of EAR to defeat that attack vector.
Not sure if you'd want to actually demo a software cracker in a client-facing video, but it's educational for a developer to see what these tools can do. They can recover Access passwords, Acrobat, Quickbooks, recover passwords for older FM files (and reset for newer), reset passwords for local Windows Admin. It takes under a minute.
In other words it's not just the hack above that makes securing the physical filesets important. Basically if an attacker has any way to get into your network and to your files, and they're not encrypted, you're compromised.
Of course, the flip side of all that is, "I forgot my encryption password!"
We have that problem here. A lot. The person who built it initially has left the company, or the group, it hasn't been used in a couple of years, whatever the excuse.
I get calls weekly about, "Hey, can someone unlock this file for me?" If they're encrypted, the answer is, "Sorry." So good password management becomes incredibly crucial.
Some more points, that should be included in a general overview:
- SSL and Certificates
- (... and progressive downloads)
- External Auth