An Observation Regarding Microsoft Access Security That Might Interest You (1 Viewer)

[nIGHTmAYOR]

While brawsing this forum i came across an advice by someone regarding switching between 2 system.mdw files in order to import objects across two different database with each relying on different system.mdw file.

Now what was interesting was that the advisor came to adress the subject as a security issue that made me wonder .. years back i tried this approach and i stepped into piles of *exclaimation marks* , yet back then db/mdw passwords recovery programs were still not fully unleashed so i decided to re-open the hive and go through it one more time.

Going through the process of manually creating a system.mdw there were 2 major set backs!

1 - if by a chance you managed to create a database by right clicking >> New >> Microsoft Office Access Database x and then trying to secure it you have managed yourself some *bump* you could have lived and not noticed..the default db owner is set to Admin with blank password , so no matter how many users you add and how you set ownership to whichever users , simple login useing long forgoten Admin account with blank password can restore you ownership to whichever objects other users own. trying to change ownership of database is rendered disabled not even if you logged through Admin account and tried to dismiss ownership to another. now like that isnt enough if you changed system.mdw with another freshly created system.mdw with default Admin user and blank password .. yes , you gain full control and ownership to the application.

2 - if you were cautious enough you would first run access >> log in to access useing an account of choice >> file >> new , what now ? yes your database owner is set to logged in user , which is good .. is it ? nope , just create a freshly new system.mdw , recreate an account with same name as owner with blank password , use it to log in , notice anything ? yes , you're the "owner" man

However

If you managed to setup your security using security wizard microsoft handles all the above addressed issues through an undocumented mean..
the wizard manages to set ownership and everything to selected user , Yet , use the Admin account as a peculier identifier to that such system.mdw would be the only valied security database to have access to such created database. how ? simply it generates a random password for Admin account and check it against one stored on database and if both are correct owner username/users are allowed to authenticate.

Now a funny notice if you accidently reset Admin password you will lose access to your database despite owner password exists and is not compromised and despite that Admin account might not have a single ownership to database objects and dspite microsoft doesnt warn you about it .

All that was before system.mdw security was compromised and various recovery tools flooded the internet that could decode any set password .

Now feddling with password recovery tools , acquiring Admin password , creating a fresh security.mdw and setting Admin's password acquired and recreating the owner user with blank password too can grant you accessibility to application.

Conclusion:
Never rely on ms access system.mdw security , apart from it i have never seen any security module that you can just beat by plain logic not even an investment in reverse engineering.
If you rely on system.mdw in securing your application then i would suggest declairing your application as an open source and save yourself the mockery

regards

 

[Banana]

I agree that system.mdw shouldn't be used if you want to secure a database. Everybody should create their own .mdw file. That said, the instance of using two .mdw applies to case where you want to secure the database's objects but not require a password login for the users to use it. (e.g. you want to prevent the user from being able to edit the tables or forms for example).

In this case, you develop with a custom .mdw that you keep to yourself, and make the custom account the owner of the database and the objects within. You would then give the Users group the permission to run forms and other certain objects while denying them the permissions to design forms, open table directly and so forth. This is actually more secure than one .mdw approach, because the end user doesn't have the .mdw with that developer account; they're just stuck with a vanilla system.mdw.

Secondly, I want to address this:

2 - if you were cautious enough you would first run access >> log in to access useing an account of choice >> file >> new , what now ? yes your database owner is set to logged in user , which is good .. is it ? nope , just create a freshly new system.mdw , recreate an account with same name as owner with blank password , use it to log in , notice anything ? yes , you're the "owner" man

IINM, that can be only done if we left PID blank. The security works by creating a hash of the account name and PID to create SID. So if in one .mdw I create a account with name 'Bob' and PID 'Bob', but in another .mdw I create a account with name 'Bob' and PID '123', the two accounts are *not* same. This is why PID is quite important and it would be foolish to use blank PID or PID same as the name or something trivial because that is just a dictionary attack away. Preferably, the PID should be a random hash so nobody can reproduce the accounts in their own .mdw without that PID.

I hope that helped some. I love to see everybody get their elbows rolled up and dig in and decipher the riddle.

 

[gemma-the-husky]

access must treat system.mdw specially

because i use a number of mdw files, i tend to keep them in my top level c folder, including a copy of the system.mdw

so if i join the c:\mygroup.mdw, everything is fine

i then join the c:\system.mdw group, and it is fine

but if i then goto rejoin the c:\mygroup.mdw, it tells me my current workgroup is actually

c:\programfiles\microsoft etc - ie the buried away system.mdw - and NOT the one I actually joined

which begs the question - can access use more than 1 system.mdw file?
its not an issue for me, just an observation really

 

[Banana]

access must treat system.mdw specially

I think it's more accurate to say Access treats 'Admin' User and 'Users' group exactly same, regardless of which .mdw you have. The security process always involve taking away the permissions and ownership from 'Admin' user and 'Users' group. It's also usually recommended to have a custom 'Admins' group, though you still need to keep the original 'Admins' group because that's the only group that has GRANT/REVOKE privileges, *even* if they didn't have the permissions to the objects themselves.

which begs the question - can access use more than 1 system.mdw file?
its not an issue for me, just an observation really

I'm pretty sure it can only use one .mdw. I've not seen that odd behavior you described, though I should note that is because I don't join a workgroup from Access UI. Rather, I join using the shortcut, making it good only for this session and thus simplify the management and never having to tell my users to click few dialogs; just use the shortcut instead or it won't work.

That said, it's important to remember that 'Admin' user and 'Users' group will always be same for *all* .mdw. Any permission given to them means that a vanilla system.mdw will have that permission even if that wasn't what you intended. This is also true for any user or groups that has same name *and* PID between the two .mdw.

 

[datAdrenaline]

The name of the .mdw really has nothing to do with it ... its all about the Workgroup ID of the .MDW used when creating the new MDB and the Personal ID (PID) of the user used to create the MDB.... Bannana elaborated nicely.

The scenarios laid out by Nightmayor are all symptoms of ULS that has been improperly set up.... and will indeed lead one to the conclusion that he has made.

If you would like, I would be willing to post a db that you can not break into with the methods described.

....

With all that said, there are indeed 3rd party tools that have the ability to extract the required information from an MDB and thus allow you access to the MDB to do as you please. Ultimately ULS should not be used to protect highly confidential information, but it does do pretty get at what it was intended to do ... WorkGROUP based security (or rather limitations).

As a point of note, the new file format for A2007 (accdb) does NOT support User Level Security.

 

[datAdrenaline]

>> can access use more than 1 system.mdw file? <<

The Access User Interface to a JET database can NOT use more than one .MDW, however, in code you can gain access to different datasources utilizing more than one .MDW.... Although I can't say that I have done that in recent memory.

 

[Banana]

Ultimately ULS should not be used to protect highly confidential information, but it does do pretty get at what it was intended to do ... WorkGROUP based security (or rather limitations).

While I agree with the assessment, I think it's fair to point out that theoretically, ULS (in combination to MDE among other things) should be sufficiently secure to prevent tampering of front-end clients to a RDBMS backend with proper security, else the trouble of using RDBMS and its all fancy security tools is a waste of time.

 

[datAdrenaline]

One "expansion" to Bannana's reply to Nightmayor ...

>> that can be only done if we left PID blank. <<

... Or if the PID is identical ... For example, if you create a "clone" of the user that is the owner.

Also, note that the Workgroup ID's have to match too. So ....

>> This is also true for any user or groups that has same name *and* PID between the two .mdw with the same Workgroup ID <<

{italics added by me to Banana's quote}

 

[Banana]

Thanks for pointing out the workgroup ID- I had forgotten about that, and it explains why one should not try to secure the database with the vanilla system.mdw rather using our own .mdw; it just put the exploiters one step closer because of WID being same.

 

[datAdrenaline]

Hello Banana ...

>> ULS (in combination to MDE among other things) should be sufficiently secure to prevent tampering of front-end clients to a RDBMS backend with proper security, else the trouble of using RDBMS and its all fancy security tools is a waste of time. <<

Both ULS and MDE's can be "broken". ULS's can be broken with 3rd party tools, and MDE's can be reverse engineered via the "p-codes" that are a result of the compiled code... So, if your MDB/E application stores a user name and pwd to a RDBMS (I assume you are talking SQL Server, Oracle, MySQL ...) then your DATA is at risk for attack.

I figure "security" is a series of barriers. In my environment, corporate and departmental applications (ie: NOT public applications), I generally implement enough security to keep curious folks from getting into trouble, and "power users" are generally left struggling, but I fully realize that tools exist that can break my front end.... and I DO store UID and PWD info in my app ... but that UID and PWD does not have schema changing rights in the SQL Server back end.

 

[Banana]

Well, that's only made me even more paranoid.

My application use WAN due to remote locations, but that was actually the easy part- encrypting the channel between the end user's computer and the server. The trouble is that I have to trust the end user's computer being relatively free of nasties.

I do not store the UID and PWD on my application, supplying it just in time, with the idea being that even if they found out my algorithm, they're still no closer to getting the key to the server.

The only thing I can't protect against (besides the beforementioned trusting my end user's computer being clean) is bait'n'switch- they put in a code that stores the PWD and phones mothership. This is what I'm hoping ULS/MDE would at least protect against. :\

 

[nIGHTmAYOR]

oh for me its plain easy how to secure my app

i rely on backend security (constructed views with specific user rights) and customely designed userlevel security (vba / custom password encryption algorythms) along with mde compilation while stripping out hash that could be rebuelt into code (third party app) finaly dissabling the shift and shortkut keys (microsoft support scripts) and construct my custom menues (stripping out shortcuts to properties and exports).

while one would think of this as too much this is actually what you do on programs you create with any decent developing platform.

as for an mdw i wouldnt realy care what rights it holds , it has no relevance to my apps at that point.

and remember :
its not because access made it easy you're allowed to get lazy

 

[nIGHTmAYOR]

Banana ,,, you mentioned erlier a dictionary attack , deary password recoverers just decrypt mdws as smooth as opening a text file , some even retrieves PID.

datAdrinalin , 99% of access users learn mdw setbacks the hardway , i bet even you had to learn all about wid and all the other blas blas after first tackle with the issue by someone who had some knowledge of computing who tried or managed to exploit it.

 

[Banana]

Banana ,,, you mentioned erlier a dictionary attack , deary password recoverers just decrypt mdws as smooth as opening a text file , some even retrieves PID.

Ooo, I didn't know there was one that could retrieve PID. I have seen tools that gives you the username and password, and hence my earlier suggestion that if you are concerned against this particular vector of attack, then you would want to split the .mdw; distribute the custom .mdw that only has end users' accounts while keeping the .mdw with the developer account to yourself. This still applies even if they got the PID for the end users' account because they still don't have the PID for the developer account from the .mdw which they don't even have.

datAdrinalin , 99% of access users learn mdw setbacks the hardway , i bet even you had to learn all about wid and all the other blas blas after first tackle with the issue by someone who had some knowledge of computing who tried or managed to exploit it.

*raises hand*

 

[datAdrenaline]

Hello Nightmayor,

>> i bet even you had to learn all about wid and all the other blas blas after first tackle with the issue by someone who had some knowledge of computing who tried or managed to exploit it. <<

Well ... my first attempt at using the .MDW's was with A97 ... and you are correct I did not do it correctly!, I created everything with the Admin user and the default workgroup file, which made my db owned by all (as you have experienced). The way I figured out I was wrong was through a forum (UtterAccess) and I replied to thread inquiring about ULS ... I responded with what I thought to be accurate info, I was asked to post my technique and a sample db, and before I posted, I went through things with a fine tooth comb ... I then discovered my errors, and posted my realization that I was in error... Then proceded to fix my implementation of ULS, and now have a pretty good handle on ULS and techniques to prevent intrusion (but admittedly not as practiced as I was when implementing ULS on a regular basis!). The primary vehicle to my education on ULS was through the info found in this MS article:

http://support.microsoft.com/default.aspx?scid=KB;en-us;q165009

AND through experimentation and such (the best way to learn IMO!) ...

....

If you are interested I can link you to a few of my favorite threads over on UA concerning security and such (achieve ULS security with out entering a pwd; linked tables with storing a pwd in the linked tabledef, but NOT being prompted for a pwd...) Also, one of them being how to handle security with the removal of ULS for the ACCDB format... Just let me know, and I will gladly provide a link.

 

[nIGHTmAYOR]

If you are interested I can link you to a few of my favorite threads over on UA concerning security and such (achieve ULS security with out entering a pwd; linked tables with storing a pwd in the linked tabledef, but NOT being prompted for a pwd...) Also, one of them being how to handle security with the removal of ULS for the ACCDB format... Just let me know, and I will gladly provide a link.

feel free to , there is nothing wrong with extra knowledge (to me and viewers ).
yet hear this funny story :
when i designed my first project i wrote my own security and that was merily because i was good with vb and never knew about mdw approach , Untill one day a guru like person i met on irc introduced me to it and then advised me to rely on it as it was the most powerfull security module he came across ever..now if only i took the blue pill :\

 

[Banana]

nIGHTmAYOR, if you can, I'd love to see that module and learn a thing or two from it, myself.

One common problem I've seen with most of custom security modules is that they invariably have to leave the key lying somewhere on the file, which make it a simple game of hide'n'seek for the exploiters, and even compiling into MDE will not encrypt the constants, strings and other variables which are still stored plaintext in a sea of binary.

Hence, my idea that doing everything WRT security just in time with a call to mothership is probably the best (but not foolproof!) guarantee that can be provided. But I'd love to be proved wrong.


Brent-

I would also love it if you can dig up that link to UA.

 

[nIGHTmAYOR]

my .. stripping out my security module would need heck of a time i am an i.s manager of a software development firm , so can you imagine the amount of tackles the internal system gets everyday ? , the system is at war with over 70 programmers and technician with wet dreams of possibilty of tampering with their time sheets , attendance or even their salaries if you are interested i might just hint you by one of the tackles i like to call the "secretery trick" but i have to warn you , after seeing it redesigning your application will become a must , so are you ready ?

 

[Banana]

Sure, if you have the time.

 

[nIGHTmAYOR]

ok let me post it in a new thread