Removal of Full Access privledges

[sphere]

Is there anyway to get back into a filemaker file if the developer tool has been used to remove full access privledge? I need to create more fields but i can't because i was an idiot and deleted the wrong file.

Edited November 29, 2006 by Guest

[Steven H. Blackwell]

Is there anyway to get back into a filemaker file if the developer tool has been used to remove full access privledge?

No there is not. Do you still have the original file that has the [Full Access] Account intact?

Steven

[sphere]

No i do not have the original file any more. Is this something that FileMaker themselves can restore or do you know of any magic way to get back into the define database area?

[Steven H. Blackwell]

No i do not have the original file any more.

Are you sure? I ask this because when the Developer Tool removes the Full Access Account, it does so on a copy of the file, leaving the original untouched.

Once removed, it is removed, and so far as I am aware, that is it. FMI does not provide passsword recovery services any longer. And even if they did, I doubt it would work in this instance.

Steven

[sphere]

Yeah the original file is definitely gone. It was lost on one of our drives when we had a system crash.

Its one of those things that happened a while ago and we just didn't "think" about it until we needed to make changes to the live server copy.

Damnit all.... i guess i better get started rebuilding it !! :

[Singlequanta]

If you send me your "locked" file I can fix it for you. I wrote an application for this very problem and can re-insert your full access admin acct for you.

[sphere]

I don't know how you did that, but thank you. You're a god send.

[K1200]

There is a question begging to be asked here from a developer's perspective (i.e., from those of us trying to distribute "protected applications")

Can you help us understand what is involved in the "re-insert your full access admin acct" operation that you've described?

We interpret that to mean that once we've checked these two options in the Developer Utilities:

Create Runtime solution application(s)

Remove admin access from files permanently

... and then built and distributed the resulting application files THAT THERE IS A WAY to restore the admin access. Although you may not want to reveal your method, can you confirm that the above is, indeed, the true situation?

If this is the case, can you recommend a way for a developer to guard against this possibility. In other words, is there something we can alter in our applications to prevent the restore ... or something we can check to detect that it has occurred? Either would be a great comfort to those of us dependent on securing the product of our efforts.

Thanks in advance for any help you might be able provide.

[Singlequanta]

Well what is involved in re-inserting access privileges is not simple business. There are no tools available on the market or forums that a person can run to "fix" secured solutions. So please do not think that using the developer feature is by any means insecure. It remains as the best way to protect your solution from reverse engineering.

However; it does not protect developers from their failure to understand basic security models.

The worst thing that you as a developer can do, is to provide any sort of back door feature, capability, access level, or methodology for promoting regular users access privileges.

Simply don't do it.

I suggest we collectively open the discussion on securing solutions against reverse engineering. There are many excellent methods to protect your intellectual property.

[pjdodd]

The worst thing that you as a developer can do, is to provide any sort of back door feature, capability, access level, or methodology for promoting regular users access privileges.

So you are saying, in effect, that developers can only provide the ability for users to create accounts that have a one priviledge set and should not allow them to change to a different priviledge set at all?

Or are you saying that only one priviledge set should exist per solution as more than one is a security risk?

Or are you saying that you should not allow users to customise their priviledges but merely be offered the choice from developer-created sets?

I suggest we collectively open the discussion on securing solutions against reverse engineering. There are many excellent methods to protect your intellectual property.

I suggest Filemaker do a lot more than provide white papers with no help for developers and sales puff about how secure it is where instead they should be providing detailed and specific advice. I seemed to have missed the chapter called "How to make your solution secure"...

I also suggest that persons who claim that Filemaker is insecure and can hack it actually prove it. As developers we need to know how hacking is done so we can understand. I'm fed up of being told this by "experts" and told to accept their word when I need a demonstration.

[Singlequanta]

I don't necessarily believe it's fair to get agro with FileMaker; they after all only manufacture a tool to get the job done.

If you build a house and forget to install locks on the door,it's not the brick companies fault. They just supplied the brick.

or,

If you build a glass house, and leave a rock on your doorstep....

As for "proving it" I think that is irrelevant. One should always build their solution with the full intent that someone WILL hackit. That way you mitigate your risk.

I was once asked to "hack" a commercially available FM solution by the vendor. And -- no word of a lie -- I gave the company the unlocked code to their solution in under 30 minutes. Their solution retailed for over 15,000 usd and they paid me a consulting fee of $2K USD to 'break into it'

When i presented the company with the hacked code they wanted to know "how i did it" I showed them the agreement we signed that clearly stated the project was to hack in and reveal the schema, plus create a join to a table. The agreement did not specify that I was to reveal "How" So I did not tell them. I did say though that their security issues were far from trivial.

After a small negotiation, they agreed to pay me an additional $5K to reveal the methodology.

So, once the "cheque cleared" I sent them this:

---- quote ----

Gary,

Further to our security audit the methodology employed to obtain your source was as follows:

1) using IP Scan my associated XXXXXXXXXX scanned your companies IP address range which is publicly visible.

2) we identified your FTP server as being ftp.xxxxxx.com

3) We then prepared to initiate a brute force password attack but found this was not necessary as your FTP server had anonymous login enabled

4) At the root level of your FTP server we observed the following directory structure:

drwxr-xr-x 30 root root 4.0K Nov 11 10:50 ..

-rw-r--r-- 1 root root 93M Sep 24 10:46 afma.tgz

drwxr-xr-x 4 root root 4.0K Nov 10 09:38 archive

-rw-r--r-- 1 root root 0 Nov 9 10:28 .autofsck

drwxr-xr-x 2 root root 4.0K Nov 25 04:28 bin

drwxr-xr-x 2 root root 4.0K Sep 18 00:09 boot

drwxr-xr-x 2 root root 4.0K Nov 11 10:43 DB

drwxr-xr-x 9 root root 5.6K Nov 20 08:24 dev

drwxr-xr-x 80 root root 12K Nov 21 21:17 etc

drwxrwxr-x 8 root users 4.0K Sep 25 07:55 files

drwxr-xr-x 2 root root 4.0K Nov 6 15:41 FILES

-rw-r--r-- 1 root root 27K Sep 17 14:42 .fonts.cache-1

drwxr-xr-x 6 root root 4.0K Nov 11 10:26 home

drwxr-xr-x 2 root root 4.0K Aug 13 2004 initrd

drwxr-xr-x 11 root root 4.0K Nov 25 04:21 lib

drwx------ 2 root root 16K Sep 18 00:09 lost+found

drwxr-xr-x 5 root root 4.0K Nov 20 08:25 media

drwxr-xr-x 2 root root 4.0K Dec 8 2004 misc

drwxr-xr-x 3 root root 4.0K Nov 21 21:20 mnt

drwxr-xr-x 4 root root 4.0K Sep 18 15:45 opt

dr-xr-xr-x 384 root root 0 Nov 9 21:27 proc

drwxr-x--- 17 root root 4.0K Nov 19 16:55 root

drwxr-xr-x 2 root root 12K Nov 25 04:28 sbin

drwxr-xr-x 2 root root 4.0K Sep 17 14:09 selinux

drwxr-xr-x 2 root root 4.0K Aug 13 2004 srv

drwxr-xr-x 9 root root 0 Nov 9 21:27 sys

drwxr-xr-x 3 root root 4.0K Sep 17 14:27 tftpboot

drwxrwxrwt 9 root root 4.0K Nov 25 08:02 tmp

drwxr-xr-x 2 usyd root 4.0K Nov 11 11:16 USBK

drwxr-xr-x 15 root root 4.0K Nov 8 07:30 usr

drwxr-xr-x 22 root root 4.0K Sep 17 14:27 var

drwxr-xr-x 5 root root 4.0K Sep 17 17:44 ZEUS

5) We systematically scanned through each directory until we discovered your development teams directory in USBK/xxxxxxxxx/xxxx/xxxxxx/FileMaker/Source/

6) We ftp'd the entire content of the directory which provided us with not only the entire source code to your solution, but all development documentation, project plans etc.

On a side note, we also downloaded the contents of your salesstaff directory and are now in posession of all of your customers details as well as your database of leads

---------------------

There was more to the email.

Now Gary was some pissed off with us after paying us $7K to reveal how we cracked his solution. After he calmed down he hired us to come to their office and install a proper security regime.

Hackers who are going to go to any length to get your data begin with creating a portfolio of their mark; They would gather information such as vital statistics:

Phillip J Dodd,

DOB 12 - 05 - 1974 East London

BA Media July 1996

and so on and so forth...

The point of all of this is:

If there is someone out there who is TRULY motivated to get your source code -- they will. Even if it means physically breaking into your office and stealing your computers. (And I have seen that happen)

So ask yourself this: What are you trying to protect and who are you trying to protect it from?

Returning to the topic of Filemakers native inbuilt security; it is very secure. Unless you have a low level mathematical background (And I notice you only received B's in your A and AS levels) to reinsert [full access] privileges to an FM solution.

This by the way, is certainly not meant as a personal attack in any way at all.

I re-iterate; filemaker is only a tool, and is only as secure as you make it and the environment in which you deploy it.

Edited November 24, 2006 by Guest

[Stuart Taylor]

Sphere sent the file to Singlequanta.

Singlequanta reinserted the Admin Privileges.

You think Singlequanta has created a second profile to fake this.

Why would they bother.

It would hardly be clever to post the hack on the forum. That leaves everybody open to the vulnerability.

Far better to post the exploit to FileMaker themselves to see if they can close the hole.

Is there ever a way of stopping people from hacking files...

Seems to me that its not ... you just have to make it as difficult as possible but there will always be a Singlequanta out there who will crack it. You just have to hope as in this case they use there knowledge for good.

What files can't be hacked or cracked... its just a file containing data at the end of the day.

I mean look how long it took for WEP to become a victim and i'm sure WPA is being worked on (if it hasn't been done already).

[Stuart Taylor]

Removed Post

Edited November 24, 2006 by Guest

[Singlequanta]

So true.

And think about the Norwegians that cracked the DVD cypher....

Thanks to them anyone can now freely copy DVDs.

Again -- if someone is truly motivate they will find a way. Sometimes it is by accident, other times its by deliberate and criminal behavior.

[Steven H. Blackwell]

I suggest Filemaker do a lot more than provide white papers with no help for developers and sales puff about how secure it is where instead they should be providing detailed and specific advice. I seemed to have missed the chapter called "How to make your solution secure"...

I also suggest that persons who claim that Filemaker is insecure and can hack it actually prove it. As developers we need to know how hacking is done so we can understand. I'm fed up of being told this by "experts" and told to accept their word when I need a demonstration.

This screed is overdrawn in my view.

The White Papers are designed to reach a broad audience with both conceptual and technical information. That was also the intent of my book.

I have demonstrated at a number of Developer Conferences and User Group meetings in both the US and Canada how any number of vulnerabilities can be exploited to gain access at unexpected levels. This usually involves taking advantage of some ersatz "security" feature that someone programmed into the files. A frequent target is the system that assigns "levels" of security that can easily be changed.

Frequently all that needs to be done is to create an external UI file and define a Cartesian join to an open data file. This exposes all those data elements in the ersatz "security" scheme.

See, for example, http://tinyurl.com/rbo5c.

Steven

[pjdodd]

If there is someone out there who is TRULY motivated to get your source code -- they will.

Leads to two conclusions:

1) Filemaker is not secure.

2) Do not listen to security experts because in the end it's a waste of time.

But wait, you said

... Filemakers native inbuilt security; it is very secure

So it is secure then!

But...

Sounds like a Vicky Pollard (Little Britain) set-up of "yeah but no but yeah but no but yeah but no but yeah but there's who other security issue that you don't know about". It seems as though I can never get a straight answer let alone some clear and simple practical advice. Ultimately the "tech talk" does not concern me because I am primarily interested in finding out things to do to improve security. I want less talk and more action, more advice, specific advice. That's why I asked for a demo of how you hacked them so i could see what, if any, lessons could be learnt.

Your hacking example is feeble because you got in via anonymous login and found the developer files handy as you please - only an imbecile (and/or PC user) would leave anonymous login enabled and those files exposed. Do you have an example using a standalone solution file? I am not degrading your hacking skills but pointing out that in your example they were not used, not really.

So ask yourself this: What are you trying to protect and who are you trying to protect it from?

Good questions. But what if the solution is standalone, so the answers become "My Database" and "everyone who hasn't paid"? (Again) I find that security issues focus on solutions over the internet/web/ftp and (again) the issue of IP related security takes dominance over the actual safety (or not) of the actual filemaker file(s). Perhaps you could use your experience to shed some light on the vulnerability of standalones and the holes that you have found in hacking them.

And finally...

That data about me is false. I know because I entered it.

Your own hacking example shows neither the power of mathematics nor the power of cunning. You succeeded because of human idiocy and oversight and employed the same lazy approach to "finding me out". We all know the point you were trying to prove but your mistake has revealed two weapons at the developers disposal; mis-information and mis-direction. With the database you were lucky, with me you were not (across the internet I have gradauated from as early as 1994 to as late as 2002, but my certificate only has one year!). Isn't it dangerous to accept the data as real/valid?? When constructing a database isn't psychology as important as relying on smug mathematical encryption?

That is an area of security I would like to open up, with an aim to providing practical help. Just as you (I think it was you) advised not to call accounts or sets Admin and User etc i think this area should be explored more, based on the assumption that the hacker has got your file in their paws and is looking for the hole (i.e. the field, table, username that is the bleeding obvious).

pjdodd

[Inky Phil]

PJDodd

I find your haughty attitude a little offensive.

I am grateful to singlequanta for sharing his expertise with us and you referring to his work as 'feeble' is not only disgraceful but demonstrates that you have missed the point entirely.

If you want 'less talk and more action, more advice, specific advice.' I suggest that you pay for it.

That way you just might value it - although I doubt it.

Phil

[pjdodd]

If you want 'less talk and more action, more advice, specific advice.' I suggest that you pay for it.

That's a good point.

These forums are for free advice, not for "experts" to peddle commercial services. I suggest these forums apply more rigour to distinguish between free advice and other non-such genuine help.

you referring to his work as 'feeble'

"Hacking" using anonymous login is not hacking.

"Hacking" using the developers files is not hacking.

"One does not applaud the tenor for clearing his throat." (Dangerous Laisions)

[Inky Phil]

You win that one PJ .

I too am now coming round to believe that the forums could be a little more rigorous in their selection of contributors.

I believe however that my criteria might be somewhat different to yours.

P.

[Genx]

Re: The FTP part... yeh meh.

Re: The FileMaker portion -- It's unheard of... Seriously -- If no backdoor's are left, no ways of "promoting users" to other privelege sets -- then how do you do it?

[pjdodd]

I just found software called XXXXX for sale (name not mentioned for obvious reason). $50 dollars. Shareware.

Has anyone else seen this??

It successfully lists all the user names and passwords of Filemaker files. It works on standard Filemaker files and those bound to runtimes. I've tested it. Can this be right? Is there a defence against this?

(Note to moderators: this is not an advertisement for the product.)

[Genx]

Meh, you'll get 10 of those pop up.

It's a well documented security "hole".

The defence is to remove the [Full Access] Account

[Ocean West]

This thread is closed, why don't we all go out and take a nice walk for some fresh air.. If there is any more pertinent information regarding the thread's subject matter than that is a different issue.