Inyección SQL - WordPress.com

Inyección SQL
Juan Manuel Espinoza Marquez
[email protected]
CFT San Agustín – Linares -2012
Introducción
➲
Una inyección SQL sucede cuando se inserta o "inyecta" un código
SQL "invasor" dentro de otro código SQL para alterar su
funcionamiento normal, y hacer que se ejecute maliciosamente el
código "invasor" en la base de datos.
➲
Se asume que los datos provistos siempre tendrán el formato
esperado.
➲
Se crean datos del lado del cliente que tienen un contenido semántico
del lado del servidor.
➲
El cliente mediante la manipulación de las entradas puede modificar el
comportamiento de la aplicación del lado del servidor, por ejemplo,
incluyendo sintaxis de algún lenguaje en particular.
¿Por qué Atacan?
Motivos Personales
Hacer Daño
Alterar, dañar or borrar información
Denegar servicio
Dañar la imagen pública
Desquitarse
Fundamentos políticos o terrorismo
Gastar una broma
Lucirse y presumir
Motivos Financieros
Robar información
Chantaje
Fraudes Financieros
El Impacto de los Ataques
➲
Pérdida de Beneficios
➲
Deterioro de la confianza de los inversores
➲
Daños en la confianza de los clientes
➲
Daños en la reputación
➲
Datos comprometidos
➲
Interrupción de los procesos de Negocio
➲
Consecuencias legales
Que habilidades necesitas tener y que herramientas debes
utilizar?
➲
Herramientas comerciales son muy caras...
●
HP WebInspect (anteriormente SPIDynamics)
●
Sanctum AppScan
●
Cenzic Hailstorm
●
Acunetix
●
NTOSpider
Utilizando Software Libre
No existen muchas herramientas de software libre para
hacer web app testing estilo caja negra.
➲
➲
➲
●
●
●
Blackbox webapp scanner
Wapiti - wapiti.sourceforge.net/
Proxies
WebScarab
Paros
Burp Suite
Firefox pluggins y misceláneos scripts de perl/python
(usualmente hacen test en una sola cosa)
Como hago un Web App Test
Es necesario seguir una metodología
➲
Metodologías populares:
●
OWASP
http://www.owasp.org/
https://www.owasp.org/index.php?title=Chile&setlang=es
●
WASCTC
http://www.webappsec.org/projects/threat/v1/WASCTCv1_0.pdf
OSSTMM
www.osstmm.org/
●
Paso a Paso
➲
➲
➲
➲
Detección de Load Balancer e IPS
Scanners (Wapiti, various SQL Injection/XSS scanners,
stompy)
Proxy (Hacer que estudie el sitio y chequee
vulnerabilidades)
Comenzar análisis manual
Repaso el sitio completo con 3 preguntas en mente:
➲
➲
➲
Puedo hablar con un DB, o con otro sistema? (Injection
Vulnerabilities)
Puede alguien ver lo que estoy escribiendo? (Scripting
Vulnerabilities)
Es el recurso local o remoto? (Includes/Redirects)
3 Clases de SQLI
SQL Injection puede ser dividido en 3 clases
➲
Inband – data es extraída utilizando el mismo canal que
se utilizo para inyectar el SQL code. Esta es la manera
mas directa de atacar, en la cual la información extraída
es presentada directamente en la pagina web.
➲
Out-of-Band – data es extraída utilizando un canal
diferente (ej.: un correo con el resultado del query es
generado y enviado al tester).
➲
Inferential – En este método no hay transferencia de data.
El tester puede deducir la información mediante queries y
observación del resultado del website/DB Server.
Inband
➲
Data es extraída utilizando el mismo canal que se utilizo
para inyectar el SQL code.
➲
Esta es la manera mas directa de atacar, en la cual la
información extraída es presentada directamente en la
pagina web.
➲
Esta es nuestra Error-Based, y Union-Based SQL
Injections
Out-of-band
➲
Data es extraída utilizando un canal diferente (ej.: un
correo con el resultado del query es generado y enviado al
tester).
➲
Esta es otra manera de obtener data de un servidor (ej.:
http, o DNS)
Inferential
Independientemente de la clase de ataque, un ataque
exitoso de SQL Injection requiere que el atacante crea un
SQL Query correcto.
Si la aplicación presenta un error generado por un query
incorrecto, este error nos permite, de manera lógica,
reconstruir el query original y de esa manera se aprende
como llevar a cabo la inyección correctamente.
Pero si la aplicación no muestra un error detallado, el
tester deber ser capaz de deducir la lógica del query
original. Esto es conocido como "Blind SQL Injection".
Vulnerabilidades
➲
Existen miles de website con vulnerabilidades, incluyendo
websites de corporaciones, como también del gobierno y
militar.
Ejemplo:
La caja de Username/Password
...le pregunta a la DB “Tiene un usuario con el nombre
“joe” con la contraseña “contraseña””
Si la DB dice “sí yo tengo ese registro, el usuario tiene
acceso al website.”
El Tradicional 1=1 Login Bypass
➲
1=1
➲
5=5
➲
a=a
➲
q=q
➲
Estas son todas declaraciones VERDADERAS...
➲
Cuando usted dice “Tiene un usuario llamado “joe” o
‘a’=‘a”
➲
Usted le esta preguntando a la BD:
➲
“Usted tiene un usuario joe o un registro valido?”
El Poder de '
➲
SQL utiliza un apostrofe (') para marcar el principio y final
del un string.
➲
Usando un string que contiene un apostrofe puede causar
errores porque la BD piensa que el string ha terminado y
espera comandos de SQL.
➲
El website hace un query a la DB. Cuando se inyecta un '
usted hace que el website envíe su query junto con el
query de ella a la DB.
Viendo el Código
➲
var sql = "SELECT * FROM users WHERE login = '" +
formusr + password = '" + formpwd + "'";
➲
Si un atacante inserta: ' or 1=1 – en el campo de formusr
el va a cambiar la ejecución del query.
➲
Insertando un apostrofe, el campo username se cierra y el
string final concatenado termina interpretando or 1=1
como parte del comando.
➲
El --(doble línea) se utiliza para comentar todo después
del or 1=1 y evita un error de sintaxis.
➲
Podía haber hecho lo mismo insertando el siguiente
comando: ' or '1'='1
Por qué OR 1=1
➲
➲
➲
➲
➲
➲
➲
Inyectando cualquiera de los siguientes comandos:
' or 1=1 -' or '1'='1
Un atacante seria logged in como el primer usuario en a
tabla.
Este pasa por que el WHERE termina validando el
username= ' ' (nada) OR 1=1 (OR '1'='1' en la segunda
declaración).
El primer condicional es Falso pero el segundo es
Verdadero.
Utilizando OR la condición entera es Verdadera y todas
las filas de la tabla de usuarios son recibidas.
GET vs. POST
➲
POST o no POST....Esa es la pregunta.
➲
Browser Address Bar Attacks & Website Forms Attacks
➲
Si es en el browser address bar (es un GET)
➲
Generalmente formularios en los que hay que hacer click
para entregar, funcionan como POST
➲
Esto es MUY importante para recordar!!!!
Local Save/Proxy
➲
Mire el código fuente y busque por cualquier parámetro
que es entregado al website
- Archive la pagina localmente
* Substituye cualquier variable entregada al website
con tu SQLI
* Ejemplos de variables:
- username/passwords
- check boxes
- radial buttons
- cookie data
- session data
- referrer
- Utilice un proxy local para substituir las variables con
tu inyección
Tipos de SQL Injection
➲
➲
➲
Error-Based SQL Injection
Union-Based SQL Injection
Blind SQL Injection
➲
Error:
Haciendo pregunta a la DB que cause un error, y obteniendo
información del error.
➲
Union:
El SQL UNION se utiliza para combinar los resultados de dos o tres
SELECT SQL en un solo resultado. Un SQL Injection muy útil
➲
Blind:
Preguntándole a la BD una pregunta tipo Verdad/Falsa y utilizando si
recibió o no una pagina valida. O el tiempo que tomo para recibir la
pagina como respuesta a su pregunta.
Terminando con lo Básico
➲
Como ataco un sitio?
* Browser Address Bar
* Local Save/Proxy
* SQL Vuln Scanners
➲
Cuáles son las clases de inyecciones?
* Error-Based SQL Injection (Más fácil)
* Union-Based SQL Injection (Fantástico para extraer
data)
* Blind SQL Injection (El peor, utilícelo si no tiene otra
alternativa)
SQL Injection
➲
http://[site]/page.asp?id=1 or 1=convert(int,(USER))-Error de Sintaxis convirtiendo el valor de nvarchar '[DB
USER]' a una clase de dato entero.
➲
➲
➲
➲
Agarre el usuario de la database con USER
Agarre el nombre de la database con DB_NAME
Agarre el nombre del servidor con @@servername
Agarrar la versión del Windows/OS con @@version
Código Fuente y Poder
➲
El código fuente es poder
➲
Tanto para defenderse como para atacar.
➲
Compartir el código es compartir el poder.
➲
Con los atacantes y defensores
➲
Publicar el código fuente sin hacer nada más degrada la
seguridad
➲
Por el contrario, publicar el código fuente permite a los
defensores y a otros elevar la seguridad al nivel que les
convenga.
Proceso explotación Vulnerabilidad
➲
1.- Se descubre una vulnerabilidad
●
a) Por el fabricante
●
b) Por un tercero
➲
2.- Se aprende a explotarlo
●
a) Ingeniería inversa de Código.
●
b) Ingeniería inversa de Patch.
➲
3.- Se usa un Payload para automatizar.
Impacto
➲
Permiten al atacante:
➲
Saltar restricciones de acceso.
➲
Elevación de privilegios.
➲
Extracción de información de la Base de Datos
➲
Parada de SGBDR.
➲
Ejecución de comandos en contexto usuario bd dentro del
servidor.
Conclusiones – Cómo Frenar el ataque
➲
No confianza en medias de protección en cliente.
●
Comprobación de datos de entrada.
●
Construcción de sentencias SQL con componentes
seguros.
●
●
Fortificación de Servidor Web.
●
Códigos de error.
●
Restricción de verbos, longitudes, etc…
●
Filtrado de contenido HTTP en Firewall (WAF)
Fortificación de SGBD.
●
Restricción de privilegios de motor/usuario de acceso desde web.
●
Aislamiento de bases de datos.
Conclusiones – Cómo Frenar el ataque