KNOWN VULNERABILITIES...

[Steven H. Blackwell]

[blurb]

[big]KNOWN VULNERABILITIES OF ERSATZ AND

ARTIFICIAL SECURITY SYSTEMS

[/big]

BY:

STEVEN H. BLACKWELL

PRESIDENT & CEO

MANAGEMENT COUNSELING SERVICES

PARTNER MEMBER, FILEMAKER SOLUTIONS ALLIANCE

HTTP://WWW.FMP-POWER.COM

HTTP://WWW.FILEMAKERSECURITY.COM

For the past six months or so, the FileMaker community has again been deluged with numerous examples of ersatz and artificial security systems that purport to manage Accounts, set privileges, control access, and perform other functions found with the province of the built–in FileMaker Pro security system.

In my judgment and from my experience, such ersatz systems are fraught with vulnerabilities. They give the appearance of security, but they in fact introduce a realm of vulnerabilities into a given FileMaker Pro solution.

[color:red]◆ A Little Background.

In modern versions of FileMaker Pro, users have Accounts with passwords. Each of those Accounts is tied to a single Privilege Set. When a user is deemed by one of several different authentication processes to be a valid user, he or she is granted access to the database system with the rights defined in the specific Privilege Set attached to the Account.

[/blurb]

Generally speaking security systems are designed to protect the Confidentiality, Integrity, and Availability (CIA) of data and business process in a file as well to protect developer intellectual property. Items that impinge on CIA or that introduce methods to compromise CIA are–by their definition–security vulnerabilities. Developers and Administrators must assess on a case by case basis the likely risk level attached to a specific threat and the likely impact of any breach on the data, operations, corporate reputation, or people in an organization.

Here are some examples of known security vulnerabilities:

•Developer-created backdoors that allow an otherwise authorized user to “promote” his or her access privileges to a system;

• Developer-created backdoors that allow a user to access records or data within a given record that he or she is not supposed to be able to access;

• Developer-created backdoors that allow anyone to glean access information intended for legitimate users of a system and thereby hijack the authentication process; and,

•FileMaker based architectural or behavioral processes that can interrupt or otherwise defeat developer–created and scripted processes for controlling access (usually through User Interface manipulation).

[color:red]◆ Techniques Frequently Employed By Developers of Ersatz Systems.

Many of these ersatz systems require Administrators to set values in specific data fields to control various levels of access to data in tables. For example a 0 might be no access; 1 might be read–only access; 2 might be create and edit; and, 3 might be create, edit, and delete. Some developer-created scripted process then identifies the individual user and matches that user to these various levels and grants privileges on a table by table or file by file basis. Other variants use calculated values or global values in lieu of scripted processes.

In other instances genuine FileMaker Pro Accounts and passwords are set to open the file automatically. This is then followed by some developer–created process that captures an ersatz Account and password, compares that information with values stored in a table, and then allows the user to proceed to access the file based on the results of that comparison.

Still other systems, frequently used as part of “demo” files, purport to control access and features by setting various flag fields, tinkering with the User Interface, and similar methods. They also frequently employ flag fields that are set to allow “admin access” based on whether the field is set to 0 (false) or 1 (true). Numerous actions are permitted if “admin access” is enabled; conversely they are denied if the field is set to 0.

Some of these systems purport to allow creation of only a limited number of records or to disallow printing or to insert some “watermark” device on all printed pages, etc. If the file is in “trial mode” there are supposedly restrictions in place. If it is not in “trial mode” then normal functionality is available.

The problem with all these techniques is that they are rather easily susceptible to manipulation. Once manipulated, they provide “keys” to unlock those backdoors through which these ersatz systems are rather easily defeated. This results in unauthorized persons gaining access to files, in unauthorized levels of access by legitimate users, and in theft or manipulation of data.

[color:red]◆ Unlocking Back Doors.

Consider the case of the multiple “privilege” levels set by the 0-1-2-3 typology described above. A process similar to this one was featured in a session at the 2006 FileMaker Developer Conference. If a user’s privileges are set to be level 1 (Read Only), simply changing the level to 3 (Create, Edit, and Delete) effectively promotes the user’s privileges. If the flag field itself (the field containing the 0-1-2-3) is not protected, a user can change the value in the field. Distinguish this from a custom constructed Read Only Privilege Set in the Privilege Set definitions that an ordinary user cannot change.

Moreover, consider another situation as described above where the database is set to open automatically with a specific Account and password and then some scripted process intervenes to capture additional information that allows the user to proceed with certain “privileges” in the system. A simple Halt Script event issued against that opening scripted process can leave the file in a state the developer neither intended nor anticipated. Following that, a hacker can in many instances extract information from the table where “privilege values” are stored and then hijack the scripted process.

Additionally and even without those stored values, the file is now open with whatever level of privileges are associated with the automatically entered Account. Depending on how the results of these stored values are enforced, the hacker now has access to the files and is likely to be ale to perform multiple actions inside of the file and/or with its data.

A third example is the so–called “trial mode” process described above similar to one touted extensively in an article in the February-March 2005 issue of FileMaker Advisor magazine. The scripted technique to limit the number of records that can be created can be defeated simply by creating the new records in an alternate file’s User Interface rather than in the original data file’s User Interface. This would bypass the scripted process entirely. The “admin access” flag can also easily be toggled from 0 to 1 or back to 0 through the same technique of using an alternate User Interface.

[color:red]◆ Conclusions.

A review and examination of all these instances leads to several general conclusions:

1. Almost without exception the built-in FileMaker Pro security system is more secure, less tamper-prone, and more resilient than any ersatz system.

2. Developers of ersatz systems frequently appear not to understand the weaknesses of their systems and appear to be unaware of additional vulnerabilities that their systems introduce to their FileMaker Pro solutions.

3. If a developer-prescribed process to control access through one of these systems is interrupted or bypassed and if the file is left open, whatever privileges set in the Privilege Set attached to the active Account are controlling to a major degree. Presumably this level is one consistent with the highest level of developer prescribed access, not the lowest one. This presents major challenges to CIA of data and processes.

4. The practice of including “access” information in data tables is seriously flawed, if for no other reason that such information is rather easily extractable in many instances.

5. The high level of granularity of the FileMaker Pro privilege system is far better suited for managing complex combinations of privileges in a safe and secure fashion in most instances.

#######

[color:gray][smallest] The default [Read Only Access] Privilege Set should not be used because it contains additional privileges inconsistent with Read-Only access privileges.

There are specific instances where an auto-open Account and password can be very appropriate to use and where they enhance security. This is not such an instance.

[/smallest]

VulnerErsatzSyst.pdf

[Stuart Taylor]

Ok this post is scary as hell aswell as extremely useful and i assume that nobody else has posted here either because there is pretty much no argument that can be made against any points or like me (having read this about 10 times), are afraid of posting below this and getting it wrong and looking stupid in front of everyone else.

Oh well here goes ... and i think i can take the knocks.

I am currently upgrading a large system from 6 to 8.5 from scratch and its time to begin implementing security.

In my 6 version i do indeed have a database called users with usernames and passwords that set priviledges...

But i want this next version to be rock solid so its time to look at the options.

So it seems obvious that the first thing any user logging in should see it the blank username and password dialogue, the FileMaker one. (not a splash screen and not a custom dialogue or list of users)

Thing is it would seem that having a user database at all could compromise some level of security. unless each user has a uniquely named priveledge set which could identify them once logged in...

This of course does not seem practical.

I also hate the "username" attributed to the user from FileMaker itself as it is often wrong.. and multiple users can use the same machine.

Seems crazy to me that one can still open the thing in a text edit program and extract data anyway.

Oh and there are applications out there to extract the username and password. Hmmmmm

Seems to me that if you put your mind to cracking/hacking a database you would have little trouble anyway as long as you had a copy that was not on the server and there are bound to be backup copies floating around in any office as these days its bets practice to at least get your backup copies off site. Thats not to say that it could not be done ... but i know nothing about this kinda thing.

So what am i protecting myself against and what environments do i have to consider. If I follow all of the rules as i understand them.

Simplistic Environments:

1. The Single File opened from the desktop

2. The File hosted by server over TCPIP

3. The File hosted on the web via web publishing

Now i assume that the greatest risk is that of the web based solution and i also assume that this was one of the most important considerations when putting together the current security schema.

But i tend to mainly use the old fashioned client to server setup.

I do not wish to administer every client.

Here is what i think i need but i have a problem!

So i need an admin account that can be used to log in and administer the other accounts.

I think this is infact all that it should do...

This seperates my user interface from the admin interface.

So now in terms of the user base no logged in user that is logged into the solution can administer the system and the administrator can login to reset passwords and setup new accounts but has to log back in to run the solution under a different user name.

But i can not ... i think (tell me if i'm wrong) just make the edit access privs and accts open i can only use the scripts available to me for which the administrator must know to choose the menu item Edit Accs & Privs or i need a user database that is only accessable by the administrator ...or ofcoures they could just have the whole thing stored in there brains hmmmmmmm.

but of course if i do this i will have to store the user names in a database that can be viewed in textedit or notepad. grrrrrrrrrr

I also need to log the users activities and display that info to other users.

So is it just the password i am trying to protect surely its both to be really safe... should i not have a username that does not match the actual name or the user (an email address for example)

It would also be great to test the number of attempts the user has attempted to login to lock a terminal down... and ofcourse this would mean scripting and therefore auto login of a low level account.

How am i gonna let my user/administrator administer this fella?

Am i just barking up the wrong path with the whole security surrounding the username aswell as the password or am i missing something?

I really want to get some good advice on this, i know its a bit of a ramble.

OK TIME TO SHOOT ME DOWN

best

Stuart

Edited November 7, 2006 by Guest

[Steven H. Blackwell]

are afraid of posting below this and getting it wrong and looking stupid in front of everyone else.

This is a complex subject. And we all start at the same place in learning about it. So don't anyone be reticient to post questions or comments.

I am out of time to answer these questions today, but I will provide some answers as soon as I have time.

One thing to look about using is External Server Authentication where the Accounts are managed externally by FileMaker Server and/or the Directory Server.

Also, Account Name is better than User Name for just some of the reasons noted.

Steven

[Stuart Taylor]

That would be great ... I have said username throughout when actually in many cases i meant AccountName maybe i should clean that up now

Everywhere i change username to accountname i will write +Accountname so your post makes sense to others.

I often work with small companies who use Mac Servers and even Macs running standard osx i know this is a problem but has often to do with budget constraints... Is this an issue... i have not yet used Server 7+ but think you are talking about Microsoft Active Directory which i tend not to have in my environments.

best

Stuart

Edited November 7, 2006 by Guest

[Stuart Taylor]

Ok i think i have made a little conceptual leap... correct me if i am wrong.

I am in fact still able to let my administrator customise my privilige sets via extended priviliges.

I could on a simple level have the following: privilige sets:

Leve1 1

Level 2

Level 3

extended privilige sets:

Create Records

Delete Records

my administrator could tick

Level 1

Create Records - Yes

Delete Records - Yes

Level 2

Create Records - Yes

Delete Records - No

Level 3

Create Records - No

Delete Records - No

My script can test for these with a patterncount test

I could also customise read/write levels ect with calculations in the same way and these can only be edited by my administrator... neat

But still the overall user management illudes me if i need avoid creating a database with account names open for people to view in a text editor. Maybe i do not need to avoid this.

hmmmm

Edited November 8, 2006 by Guest

[Stuart Taylor]

An after thought but if each FileMaker Account generated a unique ID we could draw on (a third element that was not part of the login process) this would allow us to create a user database with just the account ids and all of the other data could be unrelated to the actual login info we have to use.

hmmmm

[Steven H. Blackwell]

Leve1 1

Level 2

Level 3

extended privilige sets:

Create Records

Delete Records

my administrator could tick

Level 1

Create Records - Yes

Delete Records - Yes

Level 2

Create Records - Yes

Delete Records - No

Level 3

Create Records - No

Delete Records - No

Not a good idea at all. It takes usually about 90 seconds to crack one of these and to "promote" a user's access.

Macintosh has Open Directory. Windows has Active Directory.

You can have the Directory Service manage the Accounts. Or the Accounts can be managed locally on the server rather than from within FileMaker Pro itself.

Check out the External Server Authentication Tech Brief on the FMI Web Site at:

http://www.filemaker.com/support/upgrade/techbriefs.html

Steven

[Stuart Taylor]

OK so i have to get all of my filemaker server clients running OSX server to begin with.

Question: I find it difficult to understand why Extended Priviliges would be included in the Accounts & Priviliges Controller if it is so darn insecure... but i know you know what your talking about, just seems FM should be more responsible with locating it within the Accounts Admin window - i did not think to question that it was a security risk.

Now next question I have all of my privilidge sets being authenticated via Open Directory (or Active Directory)

This takes away my responsibitity in terms of Account management ... great...

I have my groups set up:

FM_intern

FM_employee

FM_management

FM_finance

FM_administrator

but i now find myself with an interesting set of questions:

1. There would seem no possible way to allow anybody to set access priviliges other than the ones hard coded in the privilige set.

eg: A user administrator could not securely change setting that could be calculated by the privilige set as i cannot safely store them. Right or Wrong

2. One question that leaps out at me is if i provide a white paper regarding setup.

What is to stop an employee stealing a copy setting up the same user groups on another server and accessing the data with whatever passwords they want?

3. I have clients that take copies on laptops so they can work on flights ... how do i get around that one?

[Steven H. Blackwell]

Question: I find it difficult to understand why Extended Priviliges would be included in the Accounts & Priviliges Controller if it is so darn insecure...

It's possible I did not understand what you were describing, but whatever it was it did not resemble custom Extended Privileges. You sounded as if you were describing what I referenced as ersatz systems. Such systemas, as the article describes, are pretty much profoundly insecure.

Use Privilege Sets to define the privileges of a set of users. You attach as many Accounts to a given Privilege Set as needed. Privilege Sets are based on roles. Their privileges rarely change once they are created. Users on the other hand may be moved from Privilege Set to Privilege Set at frequent intervals. This is done externally by moving their Accoutns from one group to another.

HTH

Steven