Hi

I’m currently learning abut SQL Injection and as luck happens I was asked to have a poke around at an internal web application that we have to see if it has any problems.  I’m by no means a pen tester just someone who likes to poke around at stuff.

I was quickly able to find a way to return logon names and passwords from the SQL database using SQL injection but password seem to be encoded/encrypted.

Is there a way to tell what encoding/encryption is used?

What I could see was that many accounts have the same stored password (12 characters and always starting with a = symbol) which I guessed correctly is “password”. However, my stored password (which isn’t “password”) is 16 characters and also starting with a = symbol. Other accounts that I now are not “password” are also 16 characters.

I have verified my findings with the backend database but I would like to demonstrate that although I can retrieve information on all the accounts I can then use the credentials to log in.

I have run the stored passwords through encoders on clez.net but it doesn’t decode my password to what I know it should be.

Thanks in advance for any help.

Regards

Syn

PS. I have permission to do this testing.

Here is a list of MySQL's encryption and compression functions:
http://dev.mysql.com/doc/refman/5.1/en/encryption-functions.html

Id say most of them in the link are pretty common.

Heres a good tut on PHP encryption and salts:
http://www.onlamp.com/pub/a/php/2001/07/26/encrypt.html

I'd say that the fact of storing passwords is a bad practice, what you'd like to store are hashes of them

I'll caveat this by saying that the only web applications I've done any pentesting on were government and on "secure" networks.

I see one of three things done with web application authentication.  The first is PKI, which is becoming more and more common.  The second is storing the password hashes (I most often see SHA1 being used when used with MySQL).  Storing the hashes helps some, but they can be cracked offline with a dictionary attack if you can get them dumped via SQL injection.  These two are the methods I see when a "professional" has developed the web application.

When someone has read the PHP/mysql programming for dummies book and sets out to leave their mark on the organization, I see LOTS of SQL injection errors and plain text passwords stored in the database (or worse in a text file in the application directory).  One of the first things I do with these web applications is to try to get a directory listing of the location of the web app.  The second thing is that if they are using poorly designed classes that don't have an extension the server recognizes, I try to download those directly.  They often contain the database passwords (which often makes user passwords unnecessary).  The final thing I do before even trying SQL injection is to try to induce an error in the application with URL hacking to get it do display some of the logic (if error reporting isn't turned off).

At any rate, passwords in the clear and SQL injection are way to common.  They are becoming even more common (in my experience) with the multitudes of inexperienced web "programmers" out there.  My only consolation is that these systems don't touch the Internet so they are only vulnerable to insider attacks.