Cuando se va a atacar un sistema, lo último que se quiere es que
salten todas las alarmas. Es por eso que usar fuentes online son una
buena herramienta. Se puede utilizar hacking de buscadores
para localizar URLs con paso de parámetros, para comprobar si éstos
están correctamente validados, para buscar correos electrónicos u otra
información que pueda extraerse de un determinado sitio: ficheros de
backup o de configuración que hayan quedado indexados, etc.
Un buscador muy utilizado es Shodan. Este buscador
almacena toda la información pública que puede obtener de aquellos
dispositivos que están expuestos a Internet. Entre otras cosas, podemos
encontrar dispositivos con sus claves por defecto (routers, cámaras ip,
etc), direcciones IP con los puertos que tienen abiertos, servicio y
versión del mismo que corre en cada uno, certificados SSL, con sus
respectivas suites de cifrado, etc. Una vez indexada una determinada IP
en Shodan, evita tener que hacer una comprobación directa sobre el
sistema, de manera que permite a un atacante conocer si un sitio web
está correctamente actualizado, sin necesidad de lanzar un escaneo de
puertos, que pueda delatarle a él.
METADATOS
Otra fuente de información importante son las fugas de información
que se producen por culpa de los metadatos, que van incluidos en los
documentos que se publican en Internet.
Con estos datos, es posible conocer nombres de usuario, equipos,
sistemas operativos, versiones de software, etc. que se utiliza en la
organización.
Si no se tiene cuidado, con estos datos es posible incluso realizar
un mapa interno de la organización, desde los equipos cliente, con los
usuarios de cada uno, hasta los servidores de los que se dispone,
pasando por impresoras, etc.
Es por esto que es muy importante, antes de subir un documento o publicarlo, realizar una limpieza de metadatos del mismo.
Herramientas como FOCA, son de gran utilidad para comprobar qué
información sensible estamos publicando, sin que seamos conscientes.
Principales vulnerabilidades web
Una vez que hemos visto lo importante que es la información acerca de
nosotros que tenemos publicada, y que debemos intentar controlar,
veamos qué vulnerabilidades más importantes puede presentar un sitio
web.
En primer lugar nos situamos en el escenario, tenemos una plataforma
montada sobre un sistema operativo, con su motor de base de datos,
lenguajes, normalmente interpretados, certificados, etc. Ésta es la
parte del servidor web en sí. Las vulnerabilidades que tendrá desde ese
punto de vistas serán:
–Configuración débil, por defecto o mal configurado.
Esto suele producirse por intentar desplegar el servicio lo más rápido
posible o por una confianza excesiva en el software utilizado, incluso
por desconocimiento. Cuando se expone a Internet un sistema con su
configuración por defecto, si se encuentra una vulnerabilidad en el
mismo, el exploit por defecto funcionará. Es necesario revisar el
servicio a desplegar y buscar una configuración suficientemente fuerte.
– Comunicación insegura entre cliente y servidor. Es
muy importante que la comunicación entre cliente y servidor esté
cifrada, sobre todo, cuando se trata de envíos de formularios, por
ejemplo, para autentificarse en sitio web. En muchas ocasiones, se
configura el sitio web para usar cifrado, con una configuración débil,
permitiendo protocolos inseguros, como SSLv2 y SSLv3, o suites de
cifrado vulnerables, como MD5. Esto dará una falsa sensación de
seguridad, el cliente verá que hay un certificado, que el sitio web,
aparentemente está cifrado, y, sin embargo, por culpa de los protocolos
permitidos, podría ser relativamente fácil descifrar esta comunicación.
Es por ello que es necesario revisar el estado de la calidad en la
configuración de nuestros certificados.
– Software desactualizado. Una vez desplegado el
sistema, independientemente de que se hiciese el trabajo correctamente,
pasado el tiempo, el software se desactualiza. Se localizan
vulnerabidades, se corrigen en versiones posteriores, etc. Es necesario
llevar un control de las versiones utilizadas, así como mantener el
software actualizado, en el menor tiempo posible, desde que se libera
una nueva versión. En caso contrario, al cabo de un tiempo, nuestro
sistema será vulnerable y existirán exploits públicos que permitirán
atacarlo.
Vulnerabilidades de la aplicación
Estas vulnerabilidades son propias de la aplicación que se quiere
desplegar, del código de la misma. Independientemente de que la
plataforma sobre la que despleguemos la aplicación esté correctamente
fortificada, si la aplicación posee vulnerabilidades, corremos el riesgo
de que puedan encontrarse y ser atacadas.
Las vulnerabilidades más comunes en una aplicación web son:
Cross-Site Scripting (XSS), ésta es una
vulnerabilidad o, mejor dicho, un conjunto de vulnerabilidades, que
permiten, utilizando los parámetros de entrada de la aplicación,
modificar y añadir código a la misma.
Son vulnerabilidades que se encuentran en el servidor, pero que están destinadas a atacar al cliente.
Generalmente, se necesita que el cliente sigua un enlace de la
aplicación, en el que se ha modificado algún parámetro, para permitir
añadir código, que se ejecutará en el navegador del cliente.
Normalmente, el código inyectado será html o JavaScript y la
intención será un robo de cookies del cliente, predicción del id de
sesión, etc.
Esta vulnerabilidad se aprovecha de la confianza en el cliente en el
sitio web: Verá que es el dominio de la aplicación y que, al seguir el
enlace, llega realmente al sitio web que quería, no hay suplantación del
mismo.
Básicamanente, podemos agrupar los XSS en dos grupos:
– XSS reflejados: El código modificado se elimina al cargar la página
de nuevo. Está basado en la URL y, por tanto, al recargar la página, se
elimina el mismo.
-XSS persistentes: El código modificado queda almacenado en la web.
La forma de corregir esta vulnerabilidad es filtrar y validar todas
las entradas de la aplicación. No se debe utilizar nunca una variable
que se recibe desde el cliente, confiando en que ésta tendrá un valor
correcto. Los lenguajes de programación incluyen diferentes funciones
que permiten filtrar el contenido de las variables, dependiendo de dónde
las vayamos a utilizar.
Cross Site Request/Reference Forgery (CSRF)
Esta vulnerabilidad es una evolución de los XSS. En este caso, se va a
explotar la confianza en el servidor sobre el cliente. Es decir, nos
haremos pasar por un cliente legítimo, utilizando datos parciales del
mismo.
Esta vulnerabilidad está presente en formularios. Cuando estos se
envían al servidor, es necesario asegurarse que la petición es legítima y
debemos asegurarnos que el cliente ha realizado la petición, realizando
los pasos previos necesarios.
La forma más común para eliminar esta vulnerabiliad o, al menos,
mitigarla, es la inclusión de tockens dinámicos. En los actuales
FrameWorks, suelen incluirse mecanismos para añadir esta protección a
los formularios, de una forma muy sencilla. En algunos, por ejemplo,
Laravel (utilizado para desarrollo de aplicaciones en PHP), basta añadir
una etiqueta a la plantilla del formulario, para que se añada al mismo
el tocken anti-csrf.
A continuación os muestro los nombres de los diferentes XSS más
comunes, que dependen del lugar donde se consiga inyectar el código
deseado.
- DOM Cross Site Scripting (DOM XSS)
- Cross Site Flashing (XSF)
- Cross Frame Scripting (XFS)
- Cross Zone Scripting (XZS)
- Cross Agent Scripting (XAS)
- Cross Referer Scripting (XRS)
- …
SQL INJECION
Si los ataques XSS son peligrosos, ya que pueden provocar un robo de
sesión, los SQLi son aún más porque permiten acceder y manipular la
BBDD. La idea es modificar las consultas que hace la aplicación a la
base de datos, aprovechando las entradas de usuario a la aplicación.
Veamos una estructura de una consulta SQL típica.
SELECT [Columnas] FROM [Tabla] WHERE [Condiciones]
Primero se seleccionan las columnas que queremos mostrar, después se
indica la BBDD y la tabla de la que queremos obtener las columnas y, por
último, las condiciones para filtrar esos datos.
Cuando se van a realizar consultas, se realizan con un usuario de BBDD. Este usuario tendrá diferentes permisos.
Otra cosa a tener en cuenta es que, los motores de BBDD, tienen sus
propias tablas para almacenar metadados, por ejemplo, las bases de datos
que hay, qué tablas tiene cada BBDD, las columnas y tipo de cada una,
información de usuarios, etc.
Hay que tener presente que, cuando se puede hacer un SQL injection,
se hará con los permisos que disponga el usuario con el que se ejecuta.
Existen diferentes ataques de SQL injection, dependiendo de cómo se
consiga inyectar y modificar la consulta, para obtener los datos que se
desean.
- Bypass de un login mediante SQL Injection
- SQL Injection (Mediante UNION)
- Serialized SQL Injection
- Boolean-Base SQL Injection
- Time-Base SQL Injection
- Heavy-Queries SQL Injection
- Stack-Queries
- …
Ahora vamos a explicar cómo se realizaría un SQLi.
Empezaremos explicando un SQLi de tipo Union.
Lo primero es tener claro cómo sería la estructura de la consulta que
se desea modificar. Cuando se va a utilizar Union para realizar la
inyección, lo primero que debe hacerse es negar la consulta original,
para que esa no sea la que devuelva la información.
Por lo tanto, se debe añadir una condición que siempre sea falsa.
SELECT ID, Nombre FROM Clientes WHERE ID=1 AND 1=0
Una vez que sabemos cómo negar la consulta legítima, vamos a testear
cuantas columnas devuelve la consulta original. Esto es importante,
porque los SQLi deben devolver exactamente el mismo número de columnas.
Para ello, vamos probando mostrando un valor constante, luego dos, etc.
hasta que veamos que tenemos un resultado.
http://dominio/index.php?id=1 AND 1=0 UNION SELECT 1 http://dominio/index.php?id=1 AND 1=0 UNION SELECT 1,2 ...
Hecho esto, ya sabemos cuantas columnas debe devolver nuestra
consulta, a partir de aquí, habrá que intentar obtener información de
los nombres de tablas que hay en la BBDD, luego de los nombres de
columnas por cada tabla y, una vez tengamos esa información, podremos ir
extrayendo aquello que necesitemos.
user(): usuario que ejecuta las consultas en la aplicación
database():la base de datos usada actualmente
http://dominio/index.php?id=1+and+1=0+union+select+1,2,user(),database()
Otro escenario común es utilizar un consulta para validar la
autentificación de un usuario. Se consulta en la BBDD si el nombre de
usuario y password existen y, si devuelve un registro, entonces se le
permite el acceso. Si alguna de estas variables es vulnerable a un SQLi,
se puede forzar la consulta para que siempre devuelva algo, de manera
que podremos saltar el login de la aplicación.
Por supuesto, existen herramientas que automatizan esto. Por ejemplo,
SQLMap, nos permite automatizar los SQLis y, una vez detectado un
parámetro vulnerable, nos permite extraer información de una manera muy
cómoda. Incluso nos permitirá abrir una shell en el servidor, si esto es
posible con el usuario actual, subir ficheros, realizar elevación de
privilegios, etc.
Para prevenir los SQLi, se deben parametrizar las consultas y es
necesario filtrar y comprobar el valor de las entradas. También es muy
importante restringir al máximo los permisos del usuario con el que la
aplicación se conecta a la BBDD y, por supuesto, para cada BBDD,
utilizar un usuario diferente. Esto es muy importante y, aunque es una
mala práctica usar una misma instancia del motor de BBDD para diferentes
aplicaciones, es un escenario muy común. Por este motivo, si un usuario
de la BBDD tiene permisos sobre varias BBDD de diferentes aplicaciones y
una de éstas presenta esta vulnerabilidad, el atacante podría obtener
los datos del resto de aplicaciones.
Además de esto, es muy importante ocultar los errores provocados por
consultas en BBDD. Esto es porque la forma de detectar un SQLi es
intentar forzar un error (la típica ‘) y, una vez se comprueba que
existe, si se muestra al usuario, éste puede extraer información, como
el motor de BBDD usado, etc., con lo que se le facilitará la realización
del ataque.
He intentado explicar de una forma sencilla las principales vulnerabilidades. ¡Espero que os haya gustado!
https://hacking-etico.com/2017/04/04/las-principales-vulnerabilidades-web/#more-5489
