1 2 3 Previous Next 0 Replies Latest reply on Jan 26, 2016 11:41 AM by disabled_JackRodgers

    Linking to another's file...

      In the really old days before the Internet and security problems, we'd link to one of our solution files and not think anything about that since that was the way it works.

       

      Now we put many, many tables inside one file and think that since we have accounts and passwords, etc. that the file is secure. And with the little checkbox in 14, I thought they would now be. I assumed that the checkbox shown would mean that you would have to have the same account name and password to link to my file when this box is checked. Sadly, you do not.

       

      Allow Access.png

      All this checkbox does is require that the unwanted linker with any old full access account click a button to accomplish what they used to do without this checkbox.

       

      Authorize Linking.png

       

      Note; hacker is a brand new file with just the admin account as created by FileMaker. When I create a new TO and point to the file, this dialog opens. So, by creating a new TO in a new file, I now have full access to all of the tables in the file and all of the scripts.

       

      Disclaimer: this test is being run locally and the file is not protected with the encrypt when not open capability of Advanced. It does however have accounts and passwords and was tested both open and closed. I don't have a server to check this on a remotely hosted file but will next week. So, for the time being the limits are that these are local files on my drive.

       

      Having checked the box and feeling safe and secure, I closed the file and opened a brand new file which I named Hacker just for the heck of it.

       

      I left it in a pristine state so that the Admin account was active and then I opened the design environment and created a new To and pointed it at my file. Bingo, Do you want to open this with Full Access. Yes, and there was the TO to my supposedly safe file and I could create TOs to every file and even import scripts using a plain, new file.

       

      I used this technique to bypass the protection of the 2 Factor demo file and once I had created the TOs I simply replaced all of the Persitent IDs with my own and now I could walk right in. Took five minutes to think it through. Granted it wasn't a secure file but a demo file.

       

      It might be interesting to test this on one of the encrypted 'safe' files created with Avanced since the encryption may not be of the entire file but just a new password. IF the file isn't really encrypted, then it might be possible to do this on a copy.

       

      Of course this is old stuff and everyone will tell you to protect your backups for just this reason. No one needs an account name and password to access the data and import scripts just a full access account in any file. A quite serious flaw isn't it... Every old FileMaker file is potentially open to every user in the world if they can get next to it.

       

      Of course, remotely logging into the file on a server will require an account name and password. So what happens if you create a new file and that account name and password and give it full access privileges rather than read/write. Can you now do what I did since you have access? You are fully vetted with your credentials but now you are outside the box. Is this so?

       

      This isn't just a FileMaker problem, its applicable to almost all databases and guess what, those big data files aren't as secure as FileMaker data is as they may be little more than a text file with no protection. dBase files can be read by a text editor or one of hundreds of small apps that read xbase files.

       

      Years ago I could use Word and open the FileMaker file and with a little effort begin grabbing bits of data. It was easier with an xBase file since the data all lined up in fixed lengths. Then FileMaker did something to the data and the visual text disappeared so that method didn't work. But what I've described above was even better and easier.

       

      14 closes a few holes but there are thousands of files out there that use the old technology and are wide open...

        • 1. Re: Linking to another's file...
          wimdecorte

          JackRodgers wrote:

           

          All this checkbox does is require that the unwanted linker with any old full access account click a button to accomplish what they used to do without this checkbox.

           

          That's simply not true... if "fmpFirewall" is set up with File Access Protection" then someone else can not link to that file with the full access pw in the "hacker" file.  Unless they already happen to know what the full access credentials are in "fmpFirewall".

           

          Of course you need to change the [Full Access] account in fmpFirewall to something else than the default "admin/no password".  If you don't do that then it is not a failure of the feature (as you seem to indicate) but a failure of the developer.  That's like leaving the keys in your car and the doors unlocked.  If you are testing this particular scenario (where admin/blank still is a full access set of credentials in fmpFirewall) then all you are demonstrating is that people need to pay attention to security.  But it sounds like you are saying that the features are broken.

           

          Just try to be a little more specific in explaining what you are testing and describing.   You seem so determined to sow fear and uncertainty that I feel like I have to jump on every single thing you post.  Because your posts are just so lacking in accuracy.

          • 2. Re: Linking to another's file...
            electon

            wimdecorte wrote:

             

            Just try to be a little more specific in explaining what you are testing and describing.   You seem so determined to sow fear and uncertainty that I feel like I have to jump on every single thing you post.  Because your posts are just so lacking in accuracy.

             

            Soldier On, Don Quixote.

             

            Isn't it the case that linking two files where ( in this case ) Full Access accounts match, because FileMaker will pass the credentials to the second file, you will not be presented with a login when clicking Yes?

            Only if they don't match you will be asked for correct credentials.

             

            This behavior is not new and has been there for eons.

            Require Full Access to reference this file has been there at least since version 12.

            It makes no difference if the file is local or hosted. Both adhere to same FileMaker security rules.

            Copying / duplicating the file does not remove any of the references.

             

             

            What's your agenda here Jack?

            You seem to want to become a FileMaker security evangelist on this forum.

            So far ( in other posts as well ) you're not providing much insight, I'm sorry.

            • 3. Re: Linking to another's file...
              wimdecorte

               

              Isn't it the case that linking two files where ( in this case ) Full Access accounts match, because FileMaker will pass the credentials to the second file, you will not be presented with a login when clicking Yes?

              Only if they don't match you will be asked for correct credentials.

               

               

              That is correct.  But with a twist.

              If you enable "file access protection" then you can't link to a file with a non-full access account even if your lower level credentials match an account in the target file.

               

              Picture this scenario:

              Target File:

              - has  very strong full access credentials, nothing I can guess and definitely not the default Admin/nothing

              - has an account for me: wim/wim

               

              My "hacker" file:

              I create my own file and create an account: wim/wim

               

              If file access protection is NOT turned on in the Target file then I can link to the target file from my file (because I am authorized to the target file with those credentials).  And I can see all the tables and records that I am allowed to see based on my privilege set in the target file

              ==> this is where a lot of the ersatz scripted "security" systems fail because they simply don't implement the native FM security and rely on their own scripted processes.  ALL of which are bypassed this way.

              If the native FM security WAS fully deployed I would not be able to see anything that I am not supposed to see.  It's as simple as that.

               

              If file access protection IS turned on then I can NOT link to the target file even though I have an account in that file.  My wim/wim account is a Full Access account so I can not link to the file and see data that way.  That whole problem goes away with one simple checkbox.

               

              That does not mean that with this checkbox turned on, that bypassing normal FM security is ok and that "scripted security" is safe.  Not by a long shot.

              • 4. Re: Linking to another's file...
                wimdecorte

                JackRodgers wrote:

                 

                It might be interesting to test this on one of the encrypted 'safe' files created with Avanced since the encryption may not be of the entire file but just a new password. IF the file isn't really encrypted, then it might be possible to do this on a copy.

                 

                 

                I'm afraid this shows you don't understand how encryption is implemented in FM.  There's Encryption-at-Rest and Encryption-in-Transit... which one are thinking about and how do you think it works?

                • 5. Re: Linking to another's file...

                  Odd that you would respond without testing what I said because I tried, maybe didn't succeed, to show that:

                   

                  • fmpFirewall was full protected with passwords, etc.
                  • The blank Admin account was deleted
                  • I created a local file and did nothing to it other than go to the Dabase... dialog and create a TO that was pointed at the fmpFirewall file.
                  • Both files were local files and not on a server much like a pilfered copy of a backup might be.

                   

                  The checkbox in question did noting to prevent access to the file by someone using a full access account, anyone it seems, and that account does not have to be in the file being accessed.

                   

                  What I said was correct...

                  • 6. Re: Linking to another's file...

                    EAR is the file I am interested in testing. From my reading on it only the second password is encrypted and not the entire file. I wouldn't concern myself with data in transit just data in a file I can get a copy of. There's millions of them out there and they aren't data safe.

                    • 7. Re: Linking to another's file...
                      wimdecorte

                      JackRodgers wrote:

                       

                      Odd that you would respond without testing

                       

                       

                      That's a big assumption on your part.  I did test, with a brand new set of files... did not get the results that you have.

                      • 8. Re: Linking to another's file...
                        wimdecorte

                        JackRodgers wrote:

                         

                        EAR is the file I am interested in testing. From my reading on it only the second password is encrypted and not the entire file.

                         

                        Care to point us at what you are reading?

                         

                        EAR encrypts the whole file.  Passwords have been protected for a long time now.  Not even the commercial pw crackers can reveal your pw.  They can brute force overwrite them, but not reveal them.  And not when EAR is enabled.

                        • 9. Re: Linking to another's file...
                          Steve Wright

                          I tested what you describe and found that not to be the case, as expected.

                           

                          File 1: Protected with a unique full access account.

                          File 2: Hack File, protected with its own unique full access account, unrelated to that of File 1.

                           

                          When attempting to link / view TO's via File 2, I am required to authenticate using the credentials of File 1 else, nothing.

                          Of course, if I know the credentials of File 1, then of course I can link it, because I already have full access.

                           

                          So I'm confused, am I reading the original post incorrectly?

                          • 10. Re: Linking to another's file...

                            Maybe some day someone will actually test what I say and not offer theories. I stated what I did quite clearly.

                             

                            I checked the box as shown and closed the file which had full password and account name protection and the Admin account was deleted.

                             

                            I created a new file and did nothing to the accounts and went into the Database dialog and created a TO that was linked to the fmpFirewall file.

                             

                            Then I wrote about it as above saying that the checkbox did not protect the file by requiring the knowledge of the active accounts. Admin was enough.

                             

                            Now everybody tells me I am wrong, that it doesn't work, yet not one person actually tests this.

                             

                            Its easy. Make sure there is no Admin account in your file and that it is protected.

                            Close the file and it sould be on your local drive.

                            Create a new file and enter the database dialog and create a TO pointed at your secure 14 file...

                             

                            Do that. Don't chat about it. Don't tell me that I am theoretically wrong because I started with the same misconception everyone is holding on to and discovered it was false.

                            • 11. Re: Linking to another's file...

                              Try creating the second file and not creating any accounts just let the Admin account be...

                               

                              I think that is the problem child from what I read somewhere. Even if we delete the Admin account or worse just change its name, there may be an Admin account with no password that makes the connection.

                              • 12. Re: Linking to another's file...

                                Did you use just the Admin account with no password or overwrite it or create new accounts?

                                • 13. Re: Linking to another's file...
                                  wimdecorte

                                  Steve Wright wrote:

                                   

                                  So I'm confused, am I reading the original post incorrectly?

                                   

                                  I don't think so, I know your test results to be correct.  And to be doubly sure I retested them today before I posted.

                                   

                                  Jack's long standing modus operandi has been to post vague descriptions with even more opaque references just to scare people.  Maybe he has good success getting business that way, all the more power to him.

                                  All I want to achieve is to be a counter-point and provide some perspective.  I don't expect people to believe me at my word but at the very least I want to make sure that a developer that is new to the platform, does not get the impression that there are sorts of things wrong with the FM security based on what Jack is posting.

                                  • 14. Re: Linking to another's file...
                                    wimdecorte

                                    I think two people now replied that they tested...

                                    1 2 3 Previous Next