If an attacker knows my database username and password, what can he possibly do if he doesn't have access to my server? Let's say my database is using Microsoft SQL Server. Is there a way he can use those credentials to manipulate my database?
- You're 100% sure that your database server only accepts local connections.
- You're 100% sure that the attacker doesn't have access to the local environment from which connections are allowed.
- You're 100% sure that the application that uses the database is otherwise secure.
- You're 100% sure that those credentials aren't used for anything else directly or indirectly related to the system.
Then, there's no problem in them being exposed.
Of course, as you can see, those are very big assumptions. If you're willing to take the bet, then go ahead and allow the credentials to be exposed. If not (I wouldn't), then work as best as you can on your security, and keep those credentials secret.
If he can't access the database, the credentials are meaningless. It's like having a key to a door that's inside a guarded military bunker hidden in a remote location in the Gobi desert. The key is only useful if you can get to the door.
That being said, it'd be very bad practice to let your credentials leak out like this. If you suspect that they're compromised, go change them.
As long as the DB server is properly secured and the credentials are properly linked to IP addresses that he doesn't have access to, then he can't do anything with them, but it removes one level of protection and if he does find a way to access the DB, then you are hosed.
This is called defense in depth. Multiple mechanisms prevent a compromise, however if one level is suspected to be compromised, you are less secure until you fix the compromise.
In practise, almost all sql databases (MsSql, MySql, Oracle etc) have ability to execute operating system commands. So if attacker knows your DB password, he can execute OS commands on DB machine. If process which runs your db engine has high privileges then attacker can takeover your whole machine. Beyond this is limited with your imaginary. For example:
- He/she can attack other computers in your network from the db machine.
- If you are using virtualization, attack can be extended to VM engine and other OSes on virtual environment can be compromized.
- Collect very important sensual data for future social engineering attacks.
- Take user account names and passwords and try them for other information systems on your organisation. People mostly use same strong? password on multiple systems.
- Listen traffic in your network and sniff important data.
- Insert a trojan or backdoor for future access etc.
What you can do to protect yourself although attacker knows your db password:
- You can limit db user account's privileges. Don't forget attacker can sometimes also increase his/her privileges on machine by special exploits using vulnerabilities on your OS.
- Disable shell execute abilities of DB server (but mostly db user accounts have privilege to enable it again)
- Limit db engine process privileges. Most of the time sql injection attacks are successfull because of wrong installation of db servers. Especially MsSql setup lets easily setting admin accounts as db process owner.
- Isolate your db machine from network. Only let incoming requests. You need to do this by an outer firewallish machine. Remember attacker has access to OS so he/she can enable it if you limit it from DB Server.
- Protect your users' accounts by hashing (with a salt of course) and if your CPU resource is available protect sensitive data with symmetric encryption at application level.
This is not a complete list. It can be grow larger.