You have a couple options.
The first, and preferred, would be to establish a web services layer that the application calls instead of going to the database directly. This, obviously, is going to take a bit of time to build. However it would mean you could put your DB behind a firewall that only the web services layer could get through.
The second would be to use encrypt the database access portion of the app.config file. More info here: https://msdn.microsoft.com/en-us/library/zhhddkxy.aspx
The third option, which you would use in combination with the above options, would be to remove all direct sql queries from the app and replace them with calls to stored procs that require a userid or user token parameter. Then each proc would check that the id/token was valid for the given action prior to running it. At the same time you would change the database rights such that only stored procs could be executed.
A fourth option is to implement SSPI in combination with named SQL server users (whether active directory or otherwise). This would mean adding however many users (or user groups) to your database server. The upside is that you could control on an individual basis who had rights to log into the DB server AND you wouldn't have a username/password combo in the app.config file. The downside is that someone needs to maintain that.
*Bear in mind that even if you use encrypted config sections, the user has to have access to the decryption key. So the only thing this really does is protect the key from people who might read the clear text app.config file. A determined user with access to the computer the application is running on could still pull the connection string info from either the computer memory or by decrypting the section using alternate means.