Non-theoretical security incidents

[Fitch]

I've been following this discussion, it's very interesting. Rather than hijack the discussion, I've started this topic.

 

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?

[ggt667]

What do you need to be done?

[Steven H. Blackwell]

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.

 

 

Steven

[Fitch]

@Gjermund I'm simply looking for information so that I can better understand the magnitude of potential risks and how to best mitigate them.
 
@Steven Thanks for taking the time to write up those examples. It partially answers my questions. I do understand the reluctance to publicly reveal attack methods. But these days isn't it generally agreed that security through obscurity is considered harmful? Is there no way we can disseminate this information to responsible FileMaker developers without inviting mass attacks?
 
It's tough to get people to follow best practices if they don't have a good understanding of the consequences. Getting people to vaccinate their children for example. Or, I can tell my kid to not leave a rake lying on the ground with the tines pointing up. But she won't remember unless I illustrate what can really happen.
 
Well now I'm just rambling. Looking forward with great interest to your White Paper, and continuing this discussion.

[Wim Decorte]

 

It's tough to get people to follow best practices if they don't have a good understanding of the consequences. 

 

I would think that the consequences can be easily understood: partial or total loss of data and/or intellectual property, reputational damage (yours and the client's), possible legal ramifications...

 

Best Practices are a summary of a body of experience.  They are not dogmas so they should be challenged at all times, but following them is largely a choice, and should be a reflex when in doubt (IMHO).

Unless you ware willing to wait for experience to kick in.  As someone wiser said: "Experience is a bad teacher, it gives you the test first, then the lesson".

Knowing what the price is from making a mistake in the security realm, I would not be comfortable ignoring those best practices. 

 

As to your plea for more openness: that should be directed at FMI.  They should control that information and set the direction.

[Fitch]

Thanks, Wim. I'm pretty sure we're all aware of consequences of that type. I'm not questioning that those are Bad Things. Poor choice of words on my part. What I'm going for is something more like "mechanisms." HOW does it work?

 

For instance: my wife is very smart. Yet she has a hard time remembering which buttons to push to control our A/V system. I think this is because she doesn't have an understanding of how the various components are connected. Because she feels it's not worth knowing, she has to rely on rote knowledge and will have a difficult time troubleshooting should the need arise.

 

That is the kind of knowledge I want. I don't want to push buttons by rote, even if they are the correct buttons.

[Josh Ormond]

I think what Tom is saying, and he can correct me if I'm wrong...we hear a lot of "this bad thing happens if you don't follow good security practices". Which is helpful!! We get alerted to a potential problem. But often no one explains what the actual best practices are...and what the bad practices are.  Though I suspect Stephen has been working on revealing that in a responsible way ( ie, the conference in Chicago, his upcoming White Paper, etc ).

 

While we will go off and try to see what is the problem and correct it, there are many things that we have never encountered, via FM or anything else, and we don't know how a particular 'feature' allows an access point to the data...so may never find the problem. Looking at Stephen's examples, all of them make sense to me, I can see what likely happened to allow the vulnerability. And I'll be double-checking my files to look for goofy things I did as a new FM developer back in 2006 or so.

 

Plus I am sure that while I likely understand a large portion of the problem being discussed, practical examples of proper security is often a VERY good teacher.

 

One example that I always appreciate, was the warning to never store security and/or confidential info in Global Variables. I figured out on my own why that was BAD, BAD, BAD. And have steered clear of that pitfall. But until someone pointed out the specific best practice, mainly because I hadn't used variables all that much yet back ~2007, the only thing I had read about it was '...advanced users could access important data stored temporarily...'.  ( now I read that and know exactly what it means )  

 

At any rate, I look forward to the discussion and info that comes from it. All of you provide such a valuable service to the community, and I have learned everything I know about FM from you guys and others on other forums. I can only bow and say "Thank you."

[Ocean West]

when developing i wonder how many consultants add X number of hours to the invoice or to the project scope for data security model and ongoing maintenance I have a real fear that this being overlooked and goes on quite a bit especially with all the good gruntled employees everybody is content in a fog of false-security – but as Steven will corroborate it only takes ONE to compromise the whole system, and they don't even have to have malice or ill intent, even the guy who's name is on the door and singing the check can leave the system wide open.

 

There is no "black box" approach to FileMaker security auditing, because any such tools would be a back door to compromise the very system your trying to secure. Aside from hiring an expert in the field to Audit your system the only method is to ensure that we as developers must have a well defined guideline and take the time from pushing pixels to sit down with the client and discuss security standards AND IMPLEMENT THEM all the while contrast them against the tome of examples of things NOT to attempt.

 

As an consultant in this vocation there is almost a duty that in order ensure your longevity that you must maintain a the highest level and even insist that the client cannot waive such constraints on the system as it not only protects you but protects them and the FileMaker Platform - yes I am sure there is plenty legal jargon to financially protect you from such recourse but that would mean much has transpired when it is effectuated - loss of a client - legal fees - and some probably heated words. 

[Steven H. Blackwell]

 

It's tough to get people to follow best practices if they don't have a good understanding of the consequences. 

 

It's difficult to achieve this even when people do have such an understanding. They simply--apparently--appear to believe that the vulnerabilities do not apply to them or to their systems.

 

 

 

But these days isn't it generally agreed that security through obscurity is considered harmful? Is there no way we can disseminate this information to responsible FileMaker developers without inviting mass attacks?

 

I would be interested to hear any recommendations you have, Tom, or that anyone else has for dissemination of such information.  However, not describing methodologies for specific attacks does not constitute "security through obscurity" by any means in my view.

 

Stay tuned for more developments.

 

Steven

[Steven H. Blackwell]

The above referenced White Paper is now available:

 

 

http://fmforums.com/forum/blog/13/entry-830-an-exploit-based-approach-to-providing-filemaker-platform-security/

 

 

Steven