0

I admin a website at work that was the victim of a SQL injection attack. By examining the logs, it appears the attacker used sqlmap with the file-read option and grabbed a bunch of config files from the server, due to our web developer being sloppy and using the root mysql account to connect (which had the FILE permission).

Here's the wierd as hell part I'm trying to understand. The files were read - I know they were - because the attacker then used a password in one of those files to do some system infiltrating. Looking at the logs he first grabbed an index.php, which referenced config.php and a few others. They were all targeted.

To tighten up security, I grabbed sqlmap and hit our server, and after figuring out how it worked, I was able to grab the files.

Our SQL server is not outside facing, so the attacker could not have tried this. Here is the weird part:

I connected to our MySQL server from my desktop, and tried select LOAD_FILE as well as LOAD DATA INFILE into TABLE.

SOME of them worked. For example, select LOAD_FILE('/etc/passwd') returned the /etc/passwd.

But not ALL of them worked.

select LOAD_FILE('/var/www/site_name/index.php') returned NULL.

LOAD DATA INFILE '/var/www/site_name/index.php' INTO temp; returned:

ERROR 29 (HY000): File '/var/www/site_name/index.php' not found (Errcode: 13)

What? File not found? Huh?

So I ran the sqlmap against the same file and it downloaded.

I ran sqlmap with -v 6 so I could see everything - it was using LOAD_FILE to get the file.

Why would LOAD_FILE in the injection attack work, but load file from the mysql client command line return NULL or file not found? But only for SOME files? /etc/passwd and /etc/hosts was readable.

Any clue?

Abhishek Ghosh
  • 2,593
  • 3
  • 27
  • 60
InfernusDoleo
  • 139
  • 9
  • Followup: I was testing this some more and one possibility I found that really doesn't make any sense (to me): With the SQL injection, the attacker was hitting the database on localhost (the mysql server was on the web server. I know. Don't yell at me. I didnt build it ;) whereas when I was hitting it, I was connecting remotely. The weird part - there is only ONE user on the mysql database: 'root'@'%'. There is no root@localhost. No difference in permissions. Wut? – InfernusDoleo Apr 26 '15 at 21:06
  • So reading the file via SQL injection did work while it didn’t when accessing the MySQL server directly? – Gumbo Apr 27 '15 at 16:11
  • Have you read the [description of the `LOAD_FILE` function](http://dev.mysql.com/doc/refman/5.6/en/string-functions.html#function_load-file)? – Gumbo Apr 27 '15 at 16:12
  • I have. Here it is: Reads the file and returns the file contents as a string. To use this function, the file must be located on the server host, you must specify the full path name to the file, and you must have the FILE privilege. The file must be readable by all and its size less than max_allowed_packet bytes. If the secure_file_priv system variable is set to a nonempty directory name, the file to be loaded must be located in that directory. If the file does not exist or cannot be read because one of the preceding conditions is not satisfied, the function returns NULL. – InfernusDoleo Apr 27 '15 at 16:28
  • The file IS on the server host. The full path WAS specified. The user HAS the FILE privilege. It IS readable by all. The size IS less than max_allowed_packet bytes. The secure_file_prov var is NOT set. Like I said - a remote attacker using sqlmap, which utilized the LOAD_FILE function, read the file. Using SELECT LOAD_FILE locally connected through the mysql command line client fails. LOAD_FILE works, then does not. That's my question confusion. – InfernusDoleo Apr 27 '15 at 16:31

1 Answers1

0

Turns out, after days of banging my head against this, I found out that another admin moved things around so that the outside facing server, the one I thought I was hitting, was actually forwarding port 80 to a different, newer server. Both servers had a copy of the database on it. So when the SQL injection was performed, it was hitting the inside/newer database and could read files on that server. When I was hitting the same IP address with the mysql client, it was reading the older copy of the database, on a different filesystem, that did not have the same files as the other server.

Heads have since rolled. Thanks for the effort and sorry for wasting anyone's time on this.

InfernusDoleo
  • 139
  • 9