Defeating Get(SystemNICAddress)?

[Angel01]

Hi everyone,

Just have a short question, i tried spoofing my mac address, but however, the Get(SystemNICAddress) still gives me the original NIC address...

Is there ever a way to defeat this function?

Thank You.

[bcooney]

What do you mean by "defeat this function?"

This is the card address, not the mac address. Add/change the card and it'll return a different value.

Sounds like you're looking at techniques to lock a solution to a workstation.

[Angel01]

What do you mean by "defeat this function?"

This is the card address, not the mac address. Add/change the card and it'll return a different value.

Sounds like you're looking at techniques to lock a solution to a workstation.

So basically there is no way at all to change this address?

Unless you change the card?

im looking to design a stronger security system for my database..

I was thinking of a few security features that deletes the entire databases's records once opened...

Oh when i mention defeat, i mean, like spoof the address or fake the address...

[bcooney]

I thought you were attempting something along those lines. Yes, changing the card is the only way to change this address. Of course, if an authorized user needs to move the solution, then what do you do? How are you handling a served solution?

Deleting records is, imho, a very risky move legally. Perhaps lock out would be better, but you'd better have a back door.

Honestly, what are you trying to avoid? I've been down this road with a client, and it's fraught with potholes.

[Angel01]

I thought you were attempting something along those lines. Yes, changing the card is the only way to change this address. Of course, if an authorized user needs to move the solution, then what do you do? How are you handling a served solution?

Deleting records is, imho, a very risky move legally. Perhaps lock out would be better, but you'd better have a back door.

Honestly, what are you trying to avoid? I've been down this road with a client, and it's fraught with potholes.

Lol... Hmm trying to avoid

1st objective : Passware...

2nd Objective : other password *recovery*

So i was thinking the only way u could use any of them is by obtaining the file and since the program removes the password all together, i was thinking either input a system where if the filepath is wrong, it deletes all records in it...

By definition of lockout you mean?....

[bcooney]

No system is completely secure. I'm not familiar with "passware." Do you mean giving the solution to other client? Simply ship the system customized (such that all reports print with a company address that only you can change). The data is the client's, not yours, and removing access to it or deleting it is strongly not advised.

[Angel01]

No system is completely secure. I'm not familiar with "passware." Do you mean giving the solution to other client? Simply ship the system customized (such that all reports print with a company address that only you can change). The data is the client's, not yours, and removing access to it or deleting it is strongly not advised.

Nope, the database will be hosted on a server where its accessible to a closed network of people.(Example office only)

Somehow just preparing for the worst in case someone obtains the file...

and passware removes whatever password in any database in less than 0.01 seconds.. @_@..

Thats the fearsome part..

I tested it on windows on my own database and i am just speechless...

If just i could understand how they do it, i might find a way to go around it..

So the only way i could figure out is, assuming the file is present in a wrong system ( other than the server) then it would self-destruct..

[victor_FM_wow!]

There is a way to achieve that, if you know the orginal NIC address:

Using Virtual Machine, LIke Hyper-V, You can change NIC address!!!

[Steven H. Blackwell]

Hmm trying to avoid

1st objective : Passware...

2nd Objective : other password *recovery*

So i was thinking the only way u could use any of them is by obtaining the file and since the program removes the password all together,

Passware and most similar programs do not remove passwords. You cannot remove the password from the file, because FIleMaker Pro does not store passwords in the file.

What you can do is use the Developer Utilities to remove [Full Access] Accounts from the file.

I'd recommend that you try to clarify your objectives here. Then we can have some discussion about a security schema that most optimally assists you to achieve those objectives.

Steven

[Josh Ormond]

Since passware requires physical access to the file, you objective should be to secure the server. It is a tangled web when you get into preventing someone from breaking into the file. Passware use brute force to replace the file's password and allow access.

There are a lot of paths to go down, when you are talking about "if someone gets a hold of the file". Encrypted drives/folders, self-destructive software, etc. They will all come back to, what happens if you accidentally trigger one of your fail-safes? You need to plan for that.

In the end, if you can prevent access to the file...normal security measure within the database structure/design are enough.

[Vaughan]

Passware use brute force to replace the file's password and allow access.

OK, everybody say it together: passwords are not stored in FMP files... passwords are not stored in FMP files... passwords are not stored in FMP files.

What IS stored in the file is the *hash* of the password. Hashing algorithms are designed to be one-way and non-reversible, so it is not possible to do a "de-hash" and work out the original password. Read that again until you understand it because it is important. This is the reason that passwords cannot be recovered from FMP files any more.(1)

The File crackers use a brute-force method that simply overwrites the part of the FMP file that contains the unknown-password hash with the hash of a password that is known. It's like "picking the lock" of an uber-secure door by demolishing the whole wall and replacing it with another wall with a door that you have the key for.

To push the analogy a bit further, the only way to demolish the wall is to get access to the building; hence restricting access to the building is an important part of securing the door. Once you've got access to the building you can break into anything, given enough time. Similarly with FMP files, once somebody has physical access to the file, all that's needed is time.

BTW this is not a situation that is specific to FMP. From Wikipedia: ...commercial products are available that claim the ability to test up to 2,800,000,000 passwords per second on a standard desktop computer using a high-end graphics processor.^[3] Such a device can crack a 10 letter single-case password in one day.

--

(1) Passwords ARE stored in FMP 6 .fmp5 and earlier files. Hence it is possible to recover passwords from .fp5 files. Replacing passwords with hashes was a major part of the security upgrade that came with the FMP 7 file format.

[comment]

passwords are not stored in FMP files... passwords are not stored in FMP files... passwords are not stored in FMP files.

Well, you could say that passwords are stored in FMP files in a hashed form - so that overwriting the part that has the accounts and the hashed passwords does "replace the passwords". That's merely semantics.

Once you've got access to the building you can break into anything, given enough time.

What really worries me is the ridiculously short time that overwriting the file part takes. I am not overly bothered by a brute-force attack* based on trying a multitude of passwords; just try and see how long it takes to try a combination of account name and password - even when automated, say by AppleScript.

---

(*) Re nitpicking: overwriting the "passwords" is NOT a brute-force method.

[Vaughan]

What really worries me is the ridiculously short time that overwriting the file part takes.

I'd guess that some engineers in FMI still have ringing in their ears from the slap they got for missing that attack vector. The fact that it hasn't been fixed suggests that it's a fundamental part of the file structure strategy.

Regarding my term "brute force" agreed it's a poor choice in this context. I mean something along the lines of "brutal" as in "unsophisticated"... like thieves that steal bank ATMs by driving stolen cars through the glass walls the machines are mounted in, then driving off with the whole unit in a van.

[comment]

The fact that it hasn't been fixed suggests that it's a fundamental part of the file structure strategy.

I wish I could agree - but FMI's record of fixing things suggests an alternative explanation may be more plausible...

[Vaughan]

I was suggesting that the fix might have to wait until the next version that requires a file conversion (similar to fp5 -> fp7).

[comment]

That's a bet I wouldn't mind losing.

[Josh Ormond]

Regarding my term "brute force" agreed it's a poor choice in this context. I mean something along the lines of "brutal" as in "unsophisticated"... like thieves that steal bank ATMs by driving stolen cars through the glass walls the machines are mounted in, then driving off with the whole unit in a van.

lol

I guess as poor choice of words as I originally used. Appreciate the discussion, and clarification guys.

[bcooney]

Time to read Digital Fortress.

[Jason DeLooze]

Since FMP knows how to change an Account's password, the task of creating a tool that replaces (changes) a password to a known value is simple; just watch how FMP does it. There is no need to reverse engineer algorithms, checksums, or file structure. Maybe the Reset Account Password functioanlity is a good place to start; after all, the Account Names are stored in the file (obscured), and there is functionality that retrieves and decodes them for display. So a tool could be (quite easily) built that recovers the Account Names and changes the Passwords without damage to the file.

A couple more items to know: the Auto-Open Account Name and Password are stored (obscured) within the file. Also, the current User's sign-in Account Name and Password are held in memory. Both of these items are used to open other (linked) FMP files, which may use a different hash key (timestamp+salt, perhaps) for hashing passwords in the linked files. Thus, the plain-text versions of these Account Names and Passwords must be available for opening the linked files.

And what about FMS Injection Vulnerabilities? Has any injection testing been done on FMS? When was the last time there was a security update for FMS ... never? Maybe we should just accept that "it is good enough for Mom & Pop" and get on with our lives.

[DarkMantis]

Lol, this did make me laugh but spoofing a MAC address is easy. It wouldn't be a flaw in FileMaker but its a flaw in the Data layer between the Operating System and the Hardware itself.

In Windows you can spoof the MAC address manually or you can even download pre-made software which will perform this for you.

*Nix is the same, you can spoof MAC addresses just as easily, but it takes a bit more knowledge about the operating system (if you are used to Windows).