Tom Fitch asked:
I'm extremely curious to hear if anyone has ever experienced or even heard of an actual incident of someone circumventing FileMaker security (other than password cracking utilities). What was the damage and what was the exploit? How could it have been prevented?
The short answer to this question is Yes.
I am not going to provide in this venue explicit instructions about how to attack a FileMaker Pro file or a FileMaker Server machine. Neither am I going to describe specifically how any of the following exploits were mounted. But I can and will give some specific examples of attacks.
A key phrase from Tom’s question is “…circumventing FileMaker security….” When developers employ the built-in FileMaker Platform security schema and properly configure it, it is difficult to compromise a file. It is not impossible, however, to do so; but, it is difficult. The ease of mounting an attack increases, and likelihood of success of an attack becomes greater, when all the parts of the security schema are not employed or not employed properly.
The problems begin to multiply when a developer makes careless mistakes about security. Likewise, problems proliferate when a developer does not realize that he or she has left a vulnerability exposed. And problems really compound when a developer employs ersatz, so-called “extended” Identity and Access Management and Privilege Control schemes.
An example of the latter type of problem is the institution of so-called “registration codes” that purport to convert demo versions of files into fully working versions once the developer receives some fee paid by an end user. Some of these structures are quite elaborate, involving hashes of various strings based on such items as IP address, Persistent ID values returned by the calculation function of the same name, System NIC Addresses, and Start and End Dates for the “demo” period of the file. The problem is that the end results of these schemes can often be manipulated by FileMaker Pro itself or by any of several external API’s. Any number of solutions found on well-known FileMaker community websites are subject to this type attack. Once downloaded, these solutions can be used without payment to the developer.
In another instance, a development company in an English-speaking country had a substantial world-wide install base for a FileMaker-based commercial solution. But the company’s developers were not careful about controlling the User Interface of the system they sold to end users. At one end-user customer, a person was able to manipulate that interface to gain knowledge of a [Full Access] Account apparently present in all copies of the commercial product throughout the customer base. This placed the underlying business model of the development company at great risk.
A commercial time-billing solution offered for sale on another well-known FileMaker community website required payment of a fee to convert the demo version to a working version. There were separate fees for single-user and for multi-user versions. The developer left information exposed on a “developer-only” layout. While there were no data fields to be compromised, the developer appeared to believe that removing the layout from the list of layouts and naming it with a — would prevent access. Several different API’s were able to access the UI-based data. As a result unauthorized users were able to discern [Full Access] credentials and use the file at will by the simple expedient of disabling all the demo to multi-user control processes.
Several years ago, a failure to employ correct Account and Password settings in a hosted file on a FileMaker Server machine combined with a lack of proper attention to settings in the Admin Console resulted in the extraction of a file from the server. Moreover, data were extracted from other files although export privileges were blocked for all subordinate Accounts. The developer of these files had relied on the UI instead of the security schema. Hence, the files and data were vulnerable.
In yet another incident, a consulting company in another largely English-speaking country contracted a couple of years ago with well-known outside developers to assist an in-house “subject matter expert” to develop a commercial solution the consulting company intended to sell in its particular industry. One of the outside developers constructed a very elaborate scheme to “manage” Accounts, Passwords, and Privileges only partially using the FileMaker security schema. However, the outside developers carelessly left all the ersatz data elements exposed at the “Manage Database…” schema level. They also relied on an OnOpen script to trigger, implement, and enforce their system. Consequently, the entire system was easily by-passed, the files opened, and the ersatz values detected and extracted. Despite working for a year on development of the system and spending no doubt a large sum of money, the consulting firm faced the prospect of their solution’s being compromised. It could be used without registration or payment by anyone who obtained a demo copy.
Finally, there was an incident some time back wherein the customer list and customer history of a well-known FileMaker development and training firm was left completely exposed to the world. This came about as a result of auto-entered credentials, even though those credentials did not provide [Full Access] Privileges to the development company’s files. Competitors were able to access the information and use it as desired.
All these incidents could have been prevented by full and proper application of the features in the FileMaker Pro security schema. In a couple of weeks, I will be releasing a White Paper describing six common exploits run against FileMaker Platform systems. These exploits target one or more of seven identified vulnerabilities. I will also explain how developers can close those vulnerabilities.