I am taken over support on a VB.Net WinForms application and the company that I am doing the support for has lost the source code for the application. I have the installation CD for the application and the installation steps for a network install are:
- Copy the access database for the application to a location on the server.
- Create a share on the folder that contains the database and give Everyone full access.
- Install the application on the client desktops via a ClickOnce installation.
- The first time the application runs it requests the location of the database. If the database is found in the specified location, then the database path is saved in the registry and used for the database connections.
From a decompile of the application assembly I am able to determine that the following code is being used for establishing the database connections (I would have preferred that the connection string were in the application settings, but no such luck, unfortunately).
OleDbConnectionStringBuilder builder = new OleDbConnectionStringBuilder();
builder.ConnectionString = "Data Source=" + sDatasource;
builder.Add("Provider", "Microsoft.Jet.Oledb.4.0");
builder.Add("Jet OLEDB:Database Password", "....");
builder.PersistSecurityInfo = true;
gconn = new OleDbConnection(builder.ConnectionString);
Now the problem I am having is the following: this application is being used at college and step 2 in the setup is causing a security problem for the college, as opening the folder to this extent allows anyone to copy and execute code on the server. And the college has experienced students finding and exploiting such security issues. Is there some way that access can be restricted to the folder containing the database so that students can't copy and execute code on the server, but so that the application is still able to connect to and use the access database? Bear in mind that I don't have the source code at this stage to change the connection string being used for the connections.
UPDATE:
Someone I know has suggested that I use Runas in a batch file to run application with a particular user in the domain and then give only that user rights to the folder with the access database. Would this be a feasible solution?
I don't think that you can really make this setup secure but you can do something to contain it better:
Put the access db into a "local folder" inside a VM... Put that folder on a separate volume inside the VM which only contains that folder... make that volume persistent...
then create a share as needed...
This way anything students might do is restricted to the VM (not taking into account Blue Pill or similar)... you could even use some VMWare Workstation features to rollback the VM to a known good state etc. if need be...
Why not use the decompiled code to rebuild the application? Then for a proxy, consider introducing a web service. Maybe this is far too much work... but the web service would allow for more security in the connection from the client app to the data, while hiding the MDB behind the service.
In case anyone is interested, I will outline here is how I managed to get this application working without any changes to the source (considering that I don't yet have a working source!) and yet have the database folder secured for all the users.
- I created a user on the server which would be the user that would have full rights to the database folder. I created the same user on my client machine with exactly the same password as on the server, but this is only because I do not have a domain controller setup.
- I changed the ClickOnce installation and changed it into a MSI installation and installed the application to Program Files on the server.
- I then shared this folder (which also included the Access database) and gave read rights to everyone, but full rights to the user that I created in the first step.
- Then I created a wrapper application in .Net that launched the main application with the credentials of the user that has full rights to the application folder. My wrapper application reads the user and password details from an encrypted file stored on the server. I obfuscated the launcher application to hide the decryption algorithm for reading the username and password.
- Lastly, I created a shortcut to the launcher application on every workstation.
Well, that is how I solved it and it works well... almost 100%!! ;) The only minor (and very weird) hiccup that I have is this... after a reboot of a client machine, launching the application within the first 4 minutes of startup will result in an access denied message when the application running with the specified user tries to write to the registry. If the application is started after 4 minutes into the boot (yes, i timed it!!), then suddenly writing to the registry works flawlessly. Very weird problem indeed, and one that maybe I will put in a separate question on stackoverflow... maybe someone here knows the reason for this strange anomaly at startup.
Anyway. Thanks everyone for your thoughts and ideas, they helped a lot in getting me to a solution.
