Security tidbits for FileMaker

We talked about various things at the FileMaker conference in Rome and security is a concern for everyone. Especially as scripted attacks got frequently.

Rename Admin

Have you ever put a FileMaker Server on the internet? You may note that people knowing your address try to connect with various account names and passwords. You may want to rename the Admin user everywhere to another name. Since there is a chance someone may try the Admin account and FileMaker locks accounts for 5 minutes if you have 5 incorrect passwords for login within 5 minutes, you may run into the Admin account be blocked. Just use a different name to avoid this.

Stop using the default SSL certificate

While it is convenient for a test server to use the default Claris certificate, you need to know, that the private key for this one is included with FileMaker Server and the same for all servers. The attacked knows that and has the private key, so they can decrypt the traffic.

Better use Let’s encrypt (which should be default and automated) or make your own private certificate and use it. Or if you have lots of servers, get a wildcard SSL certificate and use it on each server with a different subdomain.

Upgrade FileMaker Server

If you read the blog post here from Alex Dubov, you realize that all versions of FileMaker Server before 20.3.2 and 19.6.4 are wide open for attackers. Someone was able to read records without authentication in older FileMaker Server versions.

Also the FileMaker Server had some trouble with the Admin Console and authentication there as you can read in the blog post from David Hamann. Please use 21.0.1 or newer to benefit from the fixes.

And prepare to update soon again as a patch for a privilege escalation vulnerability may be coming soon.

Use Encryption at Rest

If your databases are not encrypted with a file password, they are wide open. Anyone who gets access to your database files, e.g. via malware on the server, a copy of a backup or for a solution with a local file. Since an attacked can overwrite existing password hashes in an unencrypted file, they can gain access to any user. See blog post here from David Hamann.

As a plugin vendor, we ask users to hide their license keys. Since plain text is a FileMaker file can be read easily in an unencrypted file, we hereby remind you that you should use encryption at rest to prevent someone from just copying a license key for an add-on or plugin from the database file. You would not want to see your license key spread on the web or being disabled by us.

Block search machines

It is very easy to find FileMaker servers on the internet by goggling for things like “fmi/webd”. You may want to place a robots.txt file into the root folder of the web host to ask the search engines to not index your server.

A text file named robots.txt with a content like this:

User-agent: * Disallow: /

Store file in /opt/FileMaker/FileMaker Server/NginxServer/htdoc folder and /opt/FileMaker/FileMaker Server/NginxServer/htdoc/httpsRoot/ folders, so it is reachable from the outside.

Malware in Containers

Since containers can include any file, they may contain a malware, e.g. an exe file. If you download a fmp12 file somewhere, you may need to be careful. A script on opening the file may export the malware to disk and run it. We usually open unknown files with debugger open, so we can stop the start script. But that won’t work if the file is opened without full access and we can’t use the debugger. Or if the malware is run with plugin calls from a calculation to execute on opening the file.

JavaScript loads malware

If you embed something in a web viewer with JavaScript, you may need to read the whole thing and look for hidden stuff like malware. If your JavaScript reads something from a website, what would happen if the website delivers malware in the JavaScript? Please make sure your embedded JavaScript always self containing without outside references.

If you like to lean more, maybe you contact the speaker from the Rome FileMaker Week conference about this: Dimitris Kokoutsidis. And you can read his blog here: cyberfm.eu.

8 Likes

Blockquote Malware in Containers

This is excellent advice! We’ve raised our concerns about FileMaker being a transporter for viruses and malware via container fields for years.

Despite going against published best practices we run Sophos Anti-Virus on all our servers and schedule a full scan of the externally stored container files every night to try to minimise this risk. We don’t touch the files with AV during the working days as this will result in FileMaker misbehaving, hence there remains an exposure if someone were to upload an infected file and then someone downloads it and opens it the same day, which could potentially be ransomware.

There should be a way to allow AV live scanning to check externally stored data without problems, even if the FileMaker files shouldn’t be touched.

1 Like

Our Container.IdentifyData function may help you to identify what is inside a container.

Even if the extension is JPG, the content may be an executable or zip archive. Our function would help you identify it.

At least after adding a picture, you could check if FileMaker knows width and height and reject files that FileMaker can't read metadata from.