Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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.

share|improve this question
2  
Without a detailed forensics process it's very difficult to tell what happened. In your case, assume the worst. –  Adnan Jun 17 '13 at 0:35
1  
I think the question is basically "What is the worst?" –  KenB Jun 17 '13 at 2:01
    
@KenB Exactly what the OP is thinking. Full compromise and the existence of a backdoor. –  Adnan Jun 17 '13 at 3:03
    
Exactly, there may or may not be a compromise. The question is what to do? Would changing mysql user and pass be sufficient? –  user1721135 Jun 17 '13 at 4:46
    
Practical example: Some university here left port 80 open for users so that they could host servers there. Someone had an unprotected wamp installation (windows, apache, mysql, php, phpmyadmin), and I was able to compromise his laptop entirely (admin account) by using a simple INTO OUTFILE statement and then calling the php script remotely. LIke Adnan said, without analysis you should assume the worst. –  Luc Jun 17 '13 at 7:19

2 Answers 2

up vote 3 down vote accepted

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.

share|improve this answer

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.

share|improve this answer
    
it has not been compromised (afaik) but, an attacker could have quitely had access for years. Thx for info! So basically, would it be enough to change user pass on mysql + close injection? I guess not really :/ –  user1721135 Jun 17 '13 at 9:00
    
It may be enough - it may not. Its hard to tell without seeing how it is configured. For example, if its running as the mysql user and not root, then thats good, also if its patched to a fairly recent version, thats also good. Review the mysql general query log and see what has been executed - may show what has been compromised in the past! –  fixulate Jun 17 '13 at 9:03

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.