inyección sql - lawebdejespi.files.wordpress.com inyección sql sucede cuando se inserta o...
TRANSCRIPT
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?
Hacer DañoAlterar, dañar or borrar informaciónDenegar servicioDañar la imagen pública
Motivos PersonalesDesquitarseFundamentos políticos o terrorismoGastar una bromaLucirse y presumir
Motivos FinancierosRobar informaciónChantajeFraudes 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/WASC-TCv1_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