Trabajo Práctico
Seguridad Informática
1° Entrega – Selección de la aplicación
Integrantes: Julián Joaquín Colaiacovo
Brenda Liz Shapiama Martinez
María Soledad Amore
Nicolás Lannert
Grupo: E
Docente: Matías Mevied
Fecha 1° entrega: 29/8/2020
Consigna: Se debe seleccionar una aplicación para poder realizar la investigación sobre
una vulnerabilidad existente y de conocimiento público. En esta etapa se debe tener en
cuenta que la aplicación seleccionada tenga diversas vulnerabilidades y que las
vulnerabilidades tengan asignados CVE (Common Vulnerabilities and Exposures). Se
necesita en esta entrega informar a los docentes la aplicación seleccionada y cuales
vulnerabilidades seleccionaron como candidatas. Elegir e informar por lo menos 3
vulnerabilidades.
Aplicación Seleccionada: Mozilla Firefox
Vulnerabilidades:
○ A3:2017-Sensitive Data Exposure
○ A7:2017-Cross-Site Scripting (XSS)
○ A2: 2017-Broken Authentication
Sensitive Data Exposure:
Esta vulnerabilidad hace referencia a todos los datos que puedan quedar expuestos, debido
a que no fueron encriptados como corresponde, que puedan ser significativos para una
empresa o la persona a la que pertenezcan estos datos, por ejemplo información personal,
datos bancarios, usuarios y contraseñas, etc.
Si bien no está considerada una vulnerabilidad muy peligrosa, ésta es normalmente
utilizada para combinar con algún otro tipo de vulnerabilidad, como puede ser SQL injection,
para causar un mayor daño a la persona o empresa.
Ejemplo cve con esta vulnerabilidad: https://www.cvedetails.com/cve/CVE-2018-
18511/
Broken Authentication:
Esta vulnerabilidad habla de los fallos que pueda tener la aplicación web en las
implementaciones de gestión o inicio de sesión que permite al atacante conseguir las
credenciales o contraseñas, e incluso evadir los mecanismos de autenticación para
conseguir acceso a las aplicaciones.
Un ejemplo muy común es el robo de sesiones por medio de ataques del tipo MITM (man in
the middle).
Ejemplo cve con esta vulnerabilidad: https://www.cvedetails.com/cve/CVE-2018-
18505/
Cross-Site Scripting (XSS):
La vulnerabilidad XSS se presenta cuando un atacante logra inyectar código HTML y/o
javascript en una aplicación que no realiza una adecuada validación de los datos de
entrada.
El código de ataque es ejecutado cuando la víctima visita el sitio vulnerable.
Existen 3 tipos principales de XSS:
REFLEJADO: Atacante envía un link con el código incrustado, el cual será ejecutado una
vez la víctima abra el link. Para que esto funcione, se combina con un poco de ingeniería
social.
PERSISTENTE: El atacante puede plantar un script persistente en una página web, así
cada persona que visite la página, ejecutará código en su navegador.
DE MODELO DE OBJETOS DE DOCUMENTO (DOM): Para este tipo no se requieren
peticiones HTTP, el script es directamente inyectado como resultado de modificar el DOM
del sitio web vulnerable, lo que hace que se ejecute en el navegador de la víctima.
Ejemplo cve con esta vulnerabilidad:
https://www.cvedetails.com/cve/CVE-2018-5124/
Trabajo Práctico
Seguridad Informática
2° Entrega – Selección de la vulnerabilidad
Integrantes: Julián Joaquín Colaiacovo
Brenda Liz Shapiama Martinez
María Soledad Amore
Nicolás Lannert
Grupo: E
Docente: Ing. Matías Mevied
Fecha: 05/09/2020
INTRODUCCIÓN
Aplicación Seleccionada: OpenEMR
Vulnerabilidad elegida: A7:2017-Cross-Site Scripting (XSS)
Esta vulnerabilidad permite ejecutar código de un atacante dentro del navegador del
usuario. Normalmente es explotada en conjunto con otras vulnerabilidades como
puede ser inyección SQL, exponer datos sensibles, robo de sesión, para causar un
mayor daño a la persona o empresa.
Ejemplo cve con esta vulnerabilidad
https://www.cvedetails.com/cve/CVE-2019-17179/
Contramedidas
Hay tres acciones que podemos implementar en el input para evitar el XSS:
1. Escapar
Consiste en obtener la representación del valor ingresado para evitar que se
interprete como código ejecutable.
2. Validar
Rechazar los inputs que contengan código que pueda ser ejecutado.
Para esto podemos crear reglas que determinen que input es válido:
a. Whitelist
Determina qué cadenas son válidas
b. Blacklist
Determina qué cadenas son inválidas
3. Sanitizar
Se encarga de modificar el contenido del input para que no represente una
amenaza.
INFRAESTRUCTURA
Usuario Apache MySQL
Server
La aplicación tiene un front, donde el usuario puede autenticarse y realizar acciones (según
su rol) en el servidor.
Nuestro objetivo es poder ejecutar nuestro código en la máquina del usuario para realizar
acciones sin su consentimiento y/o acceder a información personal.
ESCENARIO DE ATAQUE
Explotando XSS en Panel de Login
En un panel de login se pueden probar diversas vulnerabilidades, hasta poder
encontrar la correcta. Gran parte de las vulnerabilidades se dan por una mala
validación de datos, tanto entrantes como salientes.
En el panel de login introduciremos datos aleatorios, cualquier cosa, sabemos que
no tenemos las credenciales de acceso, nosotros queremos ver, cuál es la reacción
(la respuesta) del formulario. La respuesta es la siguiente:
Nos muestra el mensaje de Nombre de usuario o contraseña inválidos. Lo curioso,
es que este mensaje no lo muestra también en la propia URL. Esto se da cuando los
datos se tratan con el método GET y no el POST.
La cuestión es... ¿Podemos modificar el mensaje en la URL?
Como podemos ver en la imagen superior, podemos modificar a gusto el mensaje,
eso se debe a una mala validación de datos, aunque en otro punto el usuario no
debería poder modificar este mensaje, ni mucho menos ver el mensaje en la URL.
Ahora, usaremos un payload para iniciar un alert, esto nos confirmara que el panel
de login es vulnerable a XSS (Cross Site Scripting).
La carga resultó exitosa, no necesitamos de técnicas para realizar un bypass a un
posible filtro anti-xss.
Carga Util (Payload) utilizado
<svg onload=alert("XSS")>
Trabajo Práctico
Seguridad Informática
3° Entrega – Preparación del entorno de trabajo
Integrantes: Julián Joaquín Colaiacovo
Brenda Liz Shapiama Martinez
María Soledad Amore
Nicolás Lannert
Grupo: E
Docente: Ing. Matías Mevied
Fecha: 26/09/2020
DESCRIPCIÓN DE LA ENTREGA
En esta entrega se debe tener listo el entorno de trabajo donde se va a explotar la
vulnerabilidad y aplicar su contramedida. Para demostrar el cumplimiento de esta entrega
se solicitarán capturas de pantalla del entorno conformado y la explicación de cada una de
las capturas.
ENTORNO DE LA APLICACIÓN
Preparamos un servidor con Windows 10 Home en donde va a estar hosteada la aplicación
OpenEMR, en la cual vamos a recibir los ataques y aplicar la contramedida.
Creamos la máquina virtual
Instalación de OpenEMR
Descargamos e iniciamos la aplicación v5.0.0
https://sourceforge.net/projects/openemr/files/OpenEMR%20Windows%20XAMPP
%20Package/5.0.0/
Validamos que la aplicación funcione correctamente
Exponemos la aplicación
Para poder acceder a OpenEMR desde otra computadora, exponemos el puerto.
ENTORNO DEL ATACANTE
Para explotar la vulnerabilidad creamos una máquina virtual con Kali Linux para realizar la
explotación de la vulnerabilidad (XSS) en OpenEMR.
Instalamos Kali en la máquina virtual
Comprobamos la conectividad con la VM de Windows
Comprobamos el acceso a la aplicación
Trabajo Práctico
Seguridad Informática
4° Entrega – Investigación de la vulnerabilidad y
su contramedida
Integrantes: Julián Joaquín Colaiacovo
María Soledad Amore
Nicolás Lannert
Grupo: E
Docente: Ing. Matías Mevied
Fecha: 17/10/2020
DESCRIPCIÓN DE LA ENTREGA
Se debe realizar una investigación exhaustiva de la vulnerabilidad elegida y hacer
un informe técnico detallado de dicha vulnerabilidad. Por otra parte, analizar
alternativas de contramedidas para proteger o mitigar la explotación de la
vulnerabilidad seleccionada.
VULNERABILIDAD ELEGIDA
A7:2017-Cross-Site Scripting (XSS)
Esta vulnerabilidad permite ejecutar código de un atacante dentro del navegador del
usuario. Normalmente es explotada en conjunto con otras vulnerabilidades como
puede ser inyección SQL, exponer datos sensibles, robo de sesión, para causar un
mayor daño a la persona o empresa.
VARIANTES DE LA VULNERABILIDAD
Hay tres formas, generalmente dirigidas a los navegadores de los usuarios:
1. XSS reflejado o no persistente
La aplicación o API incluye entrada de usuario no validada y sin escape como
parte de la salida HTML. Un ataque exitoso puede permitir al atacante
ejecutar HTML y JavaScript arbitrarios en el navegador de la víctima. Por lo
general, el usuario deberá interactuar con algún enlace malicioso que apunta
a una página controlada por el atacante, como sitios web, anuncios o
similares. Es decir que el código que se inserta no se queda almacenado en
la web, sino que va insertado dentro de un enlace que llega de algún modo a
la víctima para que pinche en él. Una vez hecho eso, el navegador lo dirigirá
a una página donde el usuario tenga una cuenta o deba rellenar algún
formulario, allí ejecutará el código (malicioso) insertado y el atacante le
robará la cookie de la sesión, o los datos insertados en el formulario.
2. XSS almacenado o persistente
La aplicación o API almacena la entrada de usuario no desinfectada que otro
usuario o administrador ve en un momento posterior. El XSS almacenado a
menudo se considera un riesgo alto o crítico.
3. DOM XSS
Es similar al XSS reflejado ya que permite la manipulación del DOM a través
del input no validado. Los marcos de JavaScript, las aplicaciones de una sola
página y las API que incluyen dinámicamente datos controlables por el
atacante en una página son vulnerables a DOM XSS. Idealmente, la
aplicación no enviaría datos controlables por atacantes a API de JavaScript
inseguras.
IMPACTO
Los ataques XSS típicos incluyen:
● Robo de sesiones
● Robo de información sensible
● Toma de control de cuentas
● Omisión de MFA
● Reemplazo o desfiguración del nodo DOM
Ej: paneles de inicio de sesión de troyanos
● Ataques contra el navegador del usuario
Ej: descargas de software malicioso
● Cambio en la apariencia del sitio web
Ej: dañar la reputación del sitio webç
● Utilizar los recursos de hardware de la víctima
Ej: minería de criptomonedas
El impacto de XSS es moderado para el caso de XSS Reflejado y XSS en DOM
porque las víctimas son aquellas a las que el atacante logró comprometer (a través
de phishing por ejemplo), y severa para XSS Almacenado, ya que en este caso el
servidor fue comprometido y le permite al atacante ejecutar secuencias de
comandos en el navegador de todos los clientes que accedan al sitio, para robar
credenciales, secuestrar sesiones, o la instalación de software malicioso en el
equipo de la víctima.
La severidad de la vulnerabilidad va a depender de qué acción puede realizar el
atacante sobre la víctima, ya sea el acceso a información sensible o modificar el
layout del sitio.
EVOLUCIÓN DE LA VULNERABILIDAD XSS
Ya sabemos el peligro que conlleva el XSS y qué tan presente es hoy en día esa
vulnerabilidad, viéndola por ejemplo en el top 10 de OWASP, pero ¿cómo era hace
unos años?
El gráfico anterior muestra la tendencia de crecimiento de distintas vulnerabilidades
a lo largo de los años desde 2007 a 2011 y podemos notar cómo XSS no solo tuvo
un crecimiento menor que el resto, sino que fue decreciendo, llegando a la
conclusión que desde 2007 a 2011 no creció nada. Sin embargo, hoy en día XSS es
la vulnerabilidad más encontrada y más explotada en el mundo, lo cual habla del
poco control que ésta misma tuvo a lo largo de los años.
FACTORES POR LOS CUALES ESTA VULNERABILIDAD
SIGUE TAN PRESENTE
● Muchos desarrolladores piensan que JavaScript no representa gran
peligro para sus aplicaciones, es por eso que le prestan mayor atención a
otras vulnerabilidades más agresivas que a XSS.
● Los desarrolladores que son principiantes se enfocan en la funcionalidad
de su programa dejando de lado la seguridad.
● Falta de actualización de muchos softwares por parte de los usuarios y
desarrolladores.
● Facilidad de ataque que presenta el XSS.
EXPLOTACIÓN DE LA VULNERABILIDAD
En un panel de login se pueden probar diversas vulnerabilidades, hasta poder
encontrar la correcta. Gran parte de las vulnerabilidades se dan por una mala
validación de datos, tanto entrantes como salientes.
En el panel de login introduciremos datos aleatorios, cualquier cosa, sabemos que
no tenemos las credenciales de acceso, nosotros queremos ver, cuál es la reacción
(la respuesta) del formulario. La respuesta es la siguiente:
Nos muestra el mensaje de Nombre de usuario o contraseña inválidos. Lo curioso,
es que este mensaje no lo muestra también en la propia URL. Esto se da cuando los
datos se tratan con el método GET y no el POST.
La cuestión es... ¿Podemos modificar el mensaje en la URL?
Como podemos ver en la imagen superior, podemos modificar a gusto el mensaje,
eso se debe a una mala validación de datos, aunque en otro punto el usuario no
debería poder modificar este mensaje, ni mucho menos ver el mensaje en la URL.
Ahora, usaremos un payload para iniciar un alert, esto nos confirmara que el panel
de login es vulnerable a XSS (Cross Site Scripting).
La carga resultó exitosa, no necesitamos de técnicas para realizar un bypass a un
posible filtro anti-xss.
Carga Útil (Payload) utilizado
<svg onload=alert("XSS")>
CONTRAMEDIDAS
Dado que los ataques XSS ocurren debido a inyecciones de código, es necesario
que se manejen adecuadamente las entradas de información que la aplicación
utilizará.
Es importante que todos los parámetros de entrada sean correctamente validados y
filtrados de acuerdo a distintos criterios.
Hay tres acciones que podemos implementar en el input para evitar el XSS:
1. Escapar
Consiste en obtener la representación del valor ingresado para evitar que se
interprete como código ejecutable.
2. Validar
Rechazar los inputs que contengan código que pueda ser ejecutado.
Para esto podemos crear reglas que determinen que input es válido:
a. Whitelist
Determina qué cadenas son válidas
b. Blacklist
Determina qué cadenas son inválidas
3. Sanitizar
Se encarga de modificar el contenido del input para que no represente una
amenaza.
La prevención de XSS requiere la separación de los datos que no son de confianza
del contenido activo del navegador.
Esto se puede lograr mediante:
● El uso de marcos que escapen automáticamente de XSS por diseño
Por ejemplo Ruby on Rails o React JS. Conocer las limitaciones de la
protección XSS de cada framework y manejar adecuadamente los casos de
uso que no están cubiertos es fundamental para prevenir este tipo de
ataques.
● Escapar datos de solicitud HTTP no confiables
En la salida HTML (cuerpo, atributo, JavaScript, CSS o URL) se resuelven las
vulnerabilidades reflejadas y almacenadas XSS. Es necesario escapar
manualmente la información que se va a mostrar, para esto se pueden seguir
las recomendaciones actualizadas en la hoja de trucos de OWASP
'Prevención XSS' la cual tiene detalles sobre las técnicas de escape de datos
recomendadas.
● La aplicación de codificación sensible al contexto
Al igual que es necesario escapar las entradas no confiables, es necesario
prevenir las modificaciones en el documento del navegador (DOM XSS) en el
lado del cliente. Cuando esto no se puede evitar, se pueden aplicar técnicas
de escape sensibles al contexto similares a las API del navegador como se
describe en la hoja de trucos de OWASP 'Prevención XSS basada en DOM' .
● Habilitar una Política de seguridad de contenido (CSP)
Como un control de mitigación de defensa en profundidad contra XSS. Es
eficaz si no existen otras vulnerabilidades que permitan colocar código
malicioso a través de archivos locales incluidos (por ejemplo bibliotecas
vulnerables de redes de entrega de contenido permitidas).
