Backdoors after SQL injection?

Question

I just found an injection vulnerability on a live site of a client. It looks like this:

$sql = "SELECT * FROM users_dl WHERE Username = '" . $Uname . "' AND Password = '" .     $Pword . "'";

I successfully "hacked" it using wikipedia examples, so it ought to be pretty bad vulnerability.

The site has been like this for many years.

I know how to fix it, but since I don't know much sql, I am worried about backdoors.

Would I be still exposed after fixing this? What backdoors could there be left?

Eg could an attacker have already gained total access, like mysql user and pass and not even need injections in the future? Do I need to change user and pass? What else?

The Database gets used by multiple sites, so im pretty sure its cross domain enabled.

Answer 1

As @Adnan says, the worst is "Full compromise and the existence of a backdoor.". Why? While playing with SQL alon can't lead to any compromise of the system itself (just reload the datatabase from a backup and you ought to be set), the programs using SQL and interacting with the system have much higher capabilities.

For example, there's a chance that you have a table containing PHP template snippets. An attacker can edit that and add malicious code. If anything from the SQL tables is being executed (or even dumped to a file -- if the file can be dumped to the web folder, then an attacker could use it to inject and run his own PHP), then you may have a problem.

So find out where all the data in the tables is used. If, at any point, it is being saved or executed, see if this is exploitable (in the case of the former, it depends if the attacker can put arbitrary text in the web folder using it. In the case of the latter, it's almost always a problem). If so, there's a chance the system was compromised, and you may want to do a clean install.

If not, then just look for problems in the tables and fix them if present. Make sure you change your username/password (and check for rogue accounts)

---

An interesting thing to note is that in SQLite, the ATTACH DATABASE command can be used to directly introduce vulnerabilities.

Similarly, the SPOOL command in SQL* Plus can be used if the injection allows for multiple commands to be executed.

If you're using either of the above two, a clean install would be good regardless of how the data is being used.

Answer 2

An SQL injection alone CAN lead to a full system compromise. There are many ways from databases to access the local file system via read and write operations. Lets consider the database is running as 'root' then it would be trivial to read the /etc/shadow file. Also, lets assume you can read the local users table of the database (select user,pass from mysql.users for example), and after cracking trivial hashes you May be able to SSH into the host using the same credentials (abusing password reuse). Also, and probably more commonly you can execute operating system commands from the database itself. Xp_cmdshell can be used on SQL Server, User defined functions can be created on MySQL and there are a whole raft of ways to do this on Oracle - creating Java functions is just one!

If your database has been compromised and you have not gone into any steps to lock it down, or harden it then you can assume that worst - that the attacker has privilege escalated on to the operating system itself.