SandovalPadilla_Inyecciones SQL - Fernando Cesar Sandoval Padilla

Vista previa del material en texto

UNIVERSIDAD DE GUADALAJARA 
Centro Universitario de Ciencias Exactas e Ingenierías 
 
Seguridad de la información //I5905 
“Inyecciones SQL” 
 
 
 
 
 
 
 
Docente: Franco López Velarde Emmanuel 
Sección: D01 
Alumno: Sandoval Padilla Fernando Cesar 
Código: 215685409 
 
 
 
 
 
 
 
 07 de Mayo 2021 
Inyecciones SQL 
 
Técnicas de inyección de código SQL 
• Blind SQL Injection (Inyección SQL a ciegas) 
Es en la que el atacante no sabe nada sobre el resultado de una operación. Los atacantes 
usan métodos de inferencia, para evadir este obstáculo y por lo tanto pueden tener éxito 
para recuperar los valores de algunos campos que desee. 
Este método consiste en realizar una serie de consultas booleanas al servidor, observa las 
respuestas y, finalmente, deduce el significado de tales respuestas. 
• OOB SQL Injection (Inyección SQL fuera de banda) 
Típicamente, estas técnicas implican el envío de datos de la base de datos a una ubicación 
maligna elegida por el atacante. Este proceso también depende en gran medida de las 
capacidades del sistema de gestión de la base de datos. 
Un ataque de inyección SQL fuera de banda utiliza una capacidad de proceso de archivos 
externos de su SGBD. En MySQL, las funciones LOAD_FILE() y INTO OUTFILE pueden 
ser usadas para solicitar a MySQL que transmita los datos a una fuente externa. 
• In-Band SQL Injection (Inyección SQL en banda) 
En ella se extraen los datos utilizando el mismo canal que se utiliza para inyectar el código 
SQL. Este es el tipo más sencillo de ataque, en el que los datos recuperados se presentan 
directamente en la página web de la aplicación. 
Dos formas de ataque en banda: Ataque basado en error y ataque basado en la unión. 
• Error Based SQL Injection (Ataque basado en errores) 
La idea detrás de una inyección SQL basada en errores es obtener más información sobre 
la estructura de la base de datos y los nombres de las tablas que sigue la aplicación web. 
Por ejemplo, un mensaje de error puede contener el nombre de la tabla incluido en la 
consulta y los nombres de las columnas de la tabla. Estos datos pueden ser utilizados para 
crear nuevos ataques. 
 
 
 
Inyecciones SQL 
 
• Union-Based SQL Injection (Ataque basado en la Unión) 
Cuando una aplicación es vulnerable a la inyección SQL y los resultados de la consulta se 
devuelven dentro de las respuestas de la propia aplicación la palabra clave UNION puede 
utilizarse para recuperar datos de otras tablas existentes en la base de datos. 
La palabra clave UNION permite ejecutar una o más consultas adicionales y mostrar los 
resultados junto a la consulta original. 
 
La consulta anterior nos devolverá un único conjunto de resultados con dos columnas que 
contendrían los valores de column1 y column2 de la tabla table1 y las columnas column3 y 
column4 de la tabla table2. 
• Inferential SQL Injection (Inyección SQL Inferencial) 
En esta forma de inyección SQL, el atacante envía varias consultas a la base de datos para 
evaluar cómo la aplicación analiza estas respuestas. Una inyección SQL inferencial es a 
veces también conocida como inyección SQL ciega. 
En esta forma no hay transferencia real de datos, pero el probador es capaz de reconstruir 
la información enviando peticiones particulares y observando el comportamiento resultante 
del servidor de base de datos. 
Dos tipos de inyecciones SQL inferenciales: inyección SQL booleana e inyección SQL 
basada en tiempo. 
• Boolean-Based Blind SQL Injection (Inyección SQL booleana) 
Si una consulta SQL da como resultado un error que no ha sido manejado internamente en 
la aplicación, la página web resultante puede arrojar un error, cargar una página en blanco 
o cargar parcialmente. En una inyección SQL booleana, un atacante evalúa qué partes de 
la entrada de un usuario son vulnerables a las inyecciones SQL probando dos versiones 
diferentes de una cláusula booleana a través de la entrada: 
«… and 1=1» «… and 1=2» 
Si la aplicación funciona normalmente en el primer caso, pero muestra una anomalía en el 
segundo, indica que la aplicación es vulnerable a un ataque de inyección SQL. 
Inyecciones SQL 
 
• Time-Based Blind SQL Injection (Inyección SQL basada en tiempo) 
Un ataque de inyección SQL basado en el tiempo también puede ayudar a un atacante a 
determinar si una vulnerabilidad está presente en una aplicación web. Un atacante utiliza 
una función predefinida basada en el tiempo del sistema de administración de la base de 
datos que es utilizada por la aplicación. Por ejemplo, en MySQL, la función sleep() le 
indica a la base de datos que espere un cierto número de segundos. 
 
Si tal consulta resulta en un retraso, el atacante sabrá que es vulnerable. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Inyecciones SQL 
 
Vulnerabilidades de inyección de SQL 
CVE-2019-10211 
Descripción 
“El instalador de Postgresql Windows anterior a las versiones 11.5, 10.10, 9.6.15, 9.5.19 y 
9.4.24, es vulnerable por medio del código de ejecución de OpenSSL integrado desde un 
directorio desprotegido” (National Institute of Standars and Technology, 2019). 
Sistemas y versiones afectados 
Versión afectada Solucionado en Solución publicada 
11 11.5 2019-08-08 
10 10.10 2019-08-08 
9.6 9.6.15 2019-08-08 
9.5 9.5.19 2019-08-08 
9.4 9.4.24 2019-08-08 
 
Productos afectados: 
IBM Sterling Connect:Direct for Microsoft Windows: 4.8.0.0 - 4.8.0.2_iFix002 
IBM Connect:Direct for Microsoft Windows: 6.0.0.0 - 6.0.0.2_iFix013 
Impacto 
• Vector de acceso: A través de red 
• Complejidad de Acceso: Baja 
• Autenticación: No requerida para explotarla 
• Tipo de impacto: Afecta parcialmente a la integridad del sistema + Afecta 
parcialmente a la confidencialidad del sistema + Afecta parcialmente a la 
disponibilidad del sistema 
Métrica de impacto v2 
 
Inyecciones SQL 
 
Métrica de impacto v3 
 
Soluciones propuestas por el fabricante 
Actualizar a las versiones 11.5, 10.10, 9.6.15, 9.5.19 y 9.4.24. 
Uno puede evitar la vulnerabilidad estableciendo la variable de entorno OPENSSL_CONF 
en "NUL:/openssl.cnf" o cualquier otro nombre que no pueda existir como un archivo.libpq 
CVE-2020-2780 
Descripción 
“Se encontró un fallo en PostgreSQL versiones anteriores a 13.1, 12.5, 11.10, 10.15, 
9.6.20 y 9.5.24, si una aplicación cliente que crea conexiones de base de datos 
adicionales solo reutiliza los parámetros de conexión básicos mientras elimina los 
parámetros relevantes para la seguridad, una oportunidad para un ataque de tipo man-in-
the-middle, o la capacidad de observar transmisiones de texto sin cifrar podrían existir.” 
(Instituto Nacional de Ciberseguridad de España, 2020). 
La mayor amenaza de esta vulnerabilidad es la confidencialidad e integridad de los datos, 
así como la disponibilidad del sistema. 
Sistemas y versiones afectados 
Versión afectada Solucionado en Solución publicada 
13 13.1 2020-11-12 
12 12.5 2020-11-12 
11 11.10 2020-11-12 
10 10.15 2020-11-12 
9.6 9.6.20 2020-11-12 
9.5 9.5.24 2020-11-12 
 
 
Inyecciones SQL 
 
Productos afectados: 
Impacto 
• Vector de acceso: A través de red 
• Complejidad de Acceso: Media 
• Autenticación: No requerida para explotarla 
• Tipo de impacto: Afecta parcialmente a la integridad del sistema + Afecta 
parcialmente a la confidencialidad del sistema + Afecta parcialmente a la 
disponibilidad del sistema 
Métrica de impacto v2 
 
Métrica de impacto v3 
 
Solución propuesta por el fabricante 
Actualizar a las versiones 13.1, 12.5, 11.10, 10.15, 9.6.20 y 9.5.24. 
La vulnerabilidad solo se produce si se invoca una aplicación cliente afectada con una 
cadena de conexión que contiene un parámetro relevante para la seguridad. 
.clusterdbpg_dumppg_restorepsqlreindexdbvacuumdb 
Esto también corrige el comando de reutilizar los parámetros de conexión, es decir, todos 
los parámetros no invalidados de una cadena de conexión anteriorahora se 
reutilizan.\connectpsql 
 
 
Inyecciones SQL 
 
Práctica de inyección SQL 
Inyecciones SQL 
 
Inyecciones SQL 
 
Inyecciones SQL 
 
Inyecciones SQL 
 
 
 
 
 
 
 
 
 
Inyecciones SQL 
 
Análisis y conclusiones del impacto de las inyecciones SQL 
En base a todo lo que investigue sobre las inyecciones SQL puedo decir claramente que 
este tipo de vulnerabilidades son capaces de comprometer a las paginas web y sus bases 
de datos, puesto que ponen en riesgo tanto la integridad de la información como la 
estabilidad de los servidores, tomando así al servidor y junto a el la base de datos, afectando 
en ella las estructuras de sus tablas y con ello la información, viéndolo desde otras 
perspectivas se puede decir que aunque no todas estas vulnerabilidades tengan el mismo 
potencial de riesgos, si que tienen un grado alto de importancia, ya que si no sabemos como 
proteger nuestros gestores de bases de datos, la información podría filtrarse con estos 
métodos de inyección y puede ocurrir tanto el peor de los casos como el menor de estos, 
aun así no podremos asegurar el uso que algún externo pueda darle a la información que 
obtenga de nuestros registros de información que pueda contener nuestro servidor web. 
Entonces, el impacto que pueden llegar a tener las inyecciones SQL puede ser tan grande 
como para dañar económicamente y de forma considerable a una empresa, esto es debido 
principalmente a que en muchas empresas lo que realmente vale es la información y al 
verse afectada su integridad esta podría ser manipulada, robada o eliminada por los 
atacantes, este tipo de impacto claramente es el sucesor de muchos otros como el impacto 
que afecta al rendimiento del sistema, integridad, confidencialidad y su disponibilidad. En 
cuanto a la disponibilidad, aunque no lo parezca es importante tomarla en cuenta, ya que 
si se llega a caer el servicio podría llegar a causar pérdidas económicas en tiempo real, un 
ejemplo de esto puede ser enfocado en una pagina de ventas en línea, en la que si su 
disponibilidad llega a ser afectada por este tipo de inyecciones, podría significar la perdida 
de potenciales clientes y por ende perdida de ventas. 
Finalmente puedo concluir esta investigación diciendo que es de vital importancia mantener 
los sistemas, dispositivos y cualquier software que utilicemos actualizados sin importar cuan 
seguros estemos de las defensas que contenga nuestro servidor, ya que este tipo de 
vulnerabilidades y muchas otras pueden seguir apareciendo. Muchas veces la mejor forma 
de solucionar estas vulnerabilidades es obteniendo las versiones más recientes del 
software que contienen los parches de seguridad y se encargan de reparar las 
vulnerabilidades o errores de seguridad que son encontradas y reportadas día con día para 
su solución en futuras actualizaciones. 
 
Inyecciones SQL 
 
Bibliografía 
Daityari, S. (06 de Febrero de 2020). Kinsta. Obtenido de https://kinsta.com/es/blog/inyeccion-
sql/ 
IBM Sterling Connect:Direct. (24 de Julio de 2020). IBM. Obtenido de 
https://www.ibm.com/support/pages/security-bulletin-multiple-vulnerabilities-
postgresql-affect-ibm-sterling-connectdirect-microsoft-windows 
Instituto Nacional de Ciberseguridad de España. (29 de Octubre de 2019). Incibe-cert_. Obtenido 
de https://www.incibe-cert.es/alerta-temprana/vulnerabilidades/cve-2019-10211 
Instituto Nacional de Ciberseguridad de España. (15 de Noviembre de 2020). Incibe-cert_. 
Obtenido de https://www.incibe-cert.es/alerta-temprana/vulnerabilidades/cve-2020-
25694 
Minero, J. J. (22 de Julio de 2011). CIMAT. Obtenido de 
https://cimat.repositorioinstitucional.mx/jspui/bitstream/1008/412/1/ZACTE16.pdf 
National Institute of Standars and Technology . (15 de Noviembre de 2020). Nist. Obtenido de 
https://www.incibe-cert.es/alerta-temprana/vulnerabilidades/cve-2020-25694 
National Institute of Standars and Technology. (29 de Octubre de 2019). Nist. Obtenido de 
https://nvd.nist.gov/vuln/detail/CVE-2019-10211#vulnCurrentDescriptionTitle 
The PostgreSQL Global Development Group. (08 de Agosto de 2019). Postgresql. Obtenido de 
https://www.postgresql.org/support/security/CVE-2019-10211/ 
The PostgreSQL Global Development Group. (2020). Postgresql. Obtenido de 
https://www.postgresql.org/support/security/CVE-2020-25694/