Some Vulnerabilities Associated With Ersatz Log-On Systems

 

October 29^th 2015

 

My recent post [http://fmforums.com/blogs/entry/1410-new-paradigms-in-filemaker-platform-security/] on this BLOG about New Paradigms in FileMaker Platform Security has apparently occasioned a good deal of discussion in various FileMaker-related venues. Much of this reportedly has focused on the ersatz systems that I recommended be avoided. Many persons seem to have asserted that they use such systems for a variety of reasons.  And further, they proclaimed their belief that these systems were secure and immune to tampering.

Others have taken a different view, similar to my own, cautioning against the use of such systems.  Among the reasons they cited for that cautionary warning are unreliability of these systems and their susceptibility to tampering.

In this BLOG post, I am going to focus on some commonly-found characteristics of these ersatz systems and explore how an attacker might compromise them.

 

—Ersatz Systems—

Generally speaking these systems are directed towards one or both of two distinct processes: first, authentication; second, assignment of privileges in the database. The processes they employ usually start with an automated log-in to the system, usually at a self-described “low level of privileges.” What this actually means in terms of actual privileges remains to be seen on a case-by-case basis and varies among different systems.

Through the use of some process of identification of the user, a re-login occurs with an Account Name and Password unknown to the user and with a level of privileges attached to the unknown Account. That is to say, multiple users employ the same Account and Password to access the file; however, the individual user does not know either of the credentials’ items.

Furthermore, in some versions of these ersatz systems, privileges are also set by values in flag fields rather than through privilege bit elements in the Privilege Set.

 

—Compromising Ersatz Systems—

 

An attacker frequently can easily achieve a compromise of these ersatz systems, resulting in access at elevated levels of privilege. Unauthorized escalation of privileges is a common result of an attack. It is a circumstance we try to avoid wherever possible.

When a system automatically admits a user to the file without a challenge, two-thirds of the battle is already lost. The automatic initial log-on with the re-login by the unknown Account does just that.  The attacker is now in the file. As a result the attacker can now exploit any vulnerability not controlled by the developer.  And the developer likely cannot control every vulnerability. The attacker can now escalate his privileges, something (as mentioned) we try to prevent happening.

Even self-described low-level privileges associated with the automated log-on have certain capabilities. Otherwise, the ersatz system would not work. What are some of these capabilities and how might they be exploited?

First, the process that identifies the user and performs the re-login is in one of two different possible states.  It is either Paused or Not Paused depending on the scripted action that controls it.  If it is Paused, then the attacker can stop the Pause by any of several methods, most notably by external Application Program Interfaces (API’s). This means the attacker can cancel the paused state and return to a normal or unpaused state. The Allow User Abort [Off] functionality has no impact on this at all.  Pause can be stopped even if Allow User Abort is set to OFF.  Conversely, if the initial state of the process is Not Paused, the attacker can proceed to the next step.

Second, the attacker is now in the file and the file is in a normal state. The attacker can now activate the re-login process and gain privileges. Unless the re-login scripts are exceptionally well protected, the attacker can activate them by any of several different methods or a combination of methods:

         •External API’s

         •External references if the target file is not protected

•User Interface manipulation of the target file in some instances, depending on how the file is constructed.

What this means is that the re-logon process can be run without any reference whatsoever to the user’s name or other identifying information.  The attacker will now enjoy the privileges associated with the newly acquired Privilege Set. If the re-login process includes access to an Account with [Full Access] privileges, such as has been observed in a number of instances of these ersatz systems, then various serious consequences will ensue:

•Compromise of intellectual property

•Exfiltration of data

•Sabotage of data in the file surreptitiously or overtly

•Surreptitious extraction of [Full Access] Account name and password from the file. The amount of damage flowing from this can be exceptionally extensive, especially for widely-distributed commercial vertical market products.

•Surreptitious monitoring of file over time

 

—Flag Fields—

There is another set of circumstances that can happen associated with the flag fields that attempt to confer privileges.  If these are not exceptionally well-protected, the attacker can change their values, and thereby a low-level privilege coverts to a high-level privilege. Protection does not mean removing from the Layouts Menu the layouts where the flag fields might appear. Additionally, protection also does not mean keeping flag fields off of any layout whatsoever.

An attacker can manipulate the values in these flag fields by a variety of methods:

•External API’s

•External references if the target file is not protected

•UI manipulation of target file in some instances

We distinguish all of this from privileges the developer allows in the Privilege Sets in the file.  An attacker cannot manipulate such privileges in the same fashion as he could with the flag fields.

 

—Summary—

Avoid the use of ersatz log-on and privilege-granting systems. An attacker can interrupt and otherwise thwart the processes controlling the ersatz system. The attacker can manipulate data-based “privilege” flags and change their values. The attacker gains access and escalates privileges through these flawed processes. Ersatz systems detract from the real security a file needs.  Ersatz systems also impart a false sense of security about the files.  Use the tools FileMaker, Inc. gives you to protect the file.  Do not try to invent your own in almost any and every instance.

 

Steven H. Blackwell

 

ErsatzSystems.pdf