Mostrando entradas con la etiqueta @toespar. Mostrar todas las entradas
Mostrando entradas con la etiqueta @toespar. Mostrar todas las entradas

miércoles, 26 de octubre de 2016

Piratas del corsair



Autor: @toespar

Telegram continúa buscando diferenciarse con funcionalidades que atraigan a los usuarios. Viendo que el mundo de los videojuegos cada vez reúne a más gente en teléfonos, qué mejor que poder hablar y jugar con tus amigos sin salir de la conversación. Por ello, la propia plataforma ha creado varios juegos accesibles desde el propio chat con tan solo poner @gamebot.


Viernes por la tarde, y de repente, me llega una notificación de Telegram en un chat en el que se mostraba el siguiente mensaje:


Se había abierto la veda. Y aunque he de reconocer que no soy muy de jugar, el hecho de tener más puntuación que el resto me impulsaba a ello. Tras unos breves intentos lo consigo.


Evidentemente, esto siguió varias veces más hasta que llegó un punto en el que me resultaba imposible conseguir más puntos que el primero, pero el asunto no podía quedar así. Por ello, me pongo a investigar cómo funciona la puntuación del juego abriendo la versión desktop en el ordenador que, casualmente, todavía no integra el juego en el propio chat sino que lo abre directamente en el navegador.

Lo primero que hacemos es configurar BurpSuite  y Firefox para obtener las distintas peticiones que se realizan en función de los distintos escenarios del juego.

Ahora ya estamos listos para interceptar los paquetes y observar cómo se realizan las peticiones, así que nos ponemos a jugar hasta que nos eliminan. Tras un breve periodo de tiempo, vemos como van llegando distintas peticiones a Burp, tanto del propio dominio que estamos analizando como de otros. Por lo tanto, eliminamos las peticiones que no nos interesan, quedándonos únicamente con aquellas que nos pueden ser de interés:


Tal y como vemos en la captura, la URL más interesante es aquella relacionada con la asignación de puntuación: setScore. Adicionalmente, observamos también que la primera petición se realiza para obtener el código JavaScript que ejecutará las distintas funciones del juego, por lo que si buscamos la función que realiza el setScore podremos entender cómo se realiza la asignación de puntos:


Se realiza un post a la API setScore y se le pasan como parámetros data y score. Si seguimos buscando de donde se obtienen los datos llegamos a la función main:


Dichos datos se obtienen de la URL del juego, la cual contiene una cadena codificada en Base64 que contiene algunos parámetros como el identificador del usuario, su nombre, el nombre del juego, el identificador del chat, entre otros. Esta cadena varía en función del juego y puntuación obtenida en la partida anterior.

Si ahora nos centramos en el parámetro score, podemos ver que este varía en función de las monedas obtenidas durante el juego. No obstante, si nos fijamos en BurpSuite, observamos que el parámetro se pasa sin ningún identificador que compruebe la autenticidad del valor obtenido en el juego.


De esta forma, para obtener la puntuación que queramos únicamente deberemos editar el parámetro score en el cuerpo del mensaje. Para ello, mandamos la petición al repeater de BurpSuite y editamos dicho valor:


Si todo ha ido bien, obtenemos la siguiente respuesta:


Y si nos fijamos en el chat…


Objetivo conseguido! Ahora sí somos los piratas del Corsair ;)

lunes, 9 de mayo de 2016

(IN) Seguridad en códigos QR




Autor: Toni Escamilla (toespar.me)
Twitter: @toespar


Según Wikipedia, un código QR es un módulo para almacenar información en una matriz de puntos o en un código de barras bidimensional. Inicialmente se creó para registrar repuestos en la fabricación de vehículos, pero un tiempo después y gracias al auge de los Smartphone su uso se ha extendido y hoy en día los podemos encontrar en multitud de áreas como envases alimentarios, tarjetas de presentación e incluso en carteles de información, entre muchos otros.


A diferencia de los típicos códigos de barras, que son escaneados de forma mecánica a partir del reflejo del haz de luz, los códigos QR son escaneados de forma digital mediante el reconocimiento de pequeños cuadrados blancos que posteriormente son interpretados por el procesador.



Si analizamos la estructura de los códigos QR podemos encontrar varios elementos:


La versión y el formato son importantes para que el escáner sepa el tipo de datos que se va a encontrar, así como los patrones de posición que permiten la lectura del código en cualquier ángulo. Los patrones de alineación ayudan al escáner en caso de que el QR sea demasiado grande, y los de sincronización se utilizan para determinar el tamaño de los módulos, nombre que reciben los “cuadrados” que componen la parte de los datos. Finalmente, la quiet zone es el espacio alrededor del QR que permite al escáner diferenciar el QR de los elementos que se encuentran a su alrededor.

Sin embargo, la parte que a nosotros más nos interesa es aquella referida al almacenamiento de los datos, puesto que va a ser aquí donde vamos a poder aprovechar todo el potencial del QR. Por ello, vamos a ver como la información se almacena en forma de matriz.

En los códigos QR hay diferentes formas de codificar la información, es decir, hay diferentes formas de representar un conjunto de datos como una cadena de caracteres. Los datos codificados se agrupan en conjuntos de 8, denominados codewords, que adoptan diversas formas según su ubicación y se colocan empezando por la parte inferior derecha, subiendo primero hacia arriba hasta llegar al patrón localizador, luego pasamos a la columna adyacente izquierda y bajamos.



Adicionalmente, el orden de los bits de cada codeword varía cuando el codeword se coloca hacia arriba o hacia abajo, y gracias a la información de formato, obtendremos la máscara que posteriormente aplicaremos, mediante la operación XOR, a los codewords para obtener los datos en binario.

Finalmente, una vez aplicada la máscara debemos interpretar los datos resultantes; los primeros 4 bits nos indican el modo que debemos usar para interpretar los datos y nos condicionará para realizar la agrupación de bits. Una vez realizada dicha agrupación, el siguiente bloque nos indicará la longitud del mensaje.

Ahora que ya conocemos como funciona un código QR, ¿podemos aprovecharlo como vector de ataque? Lo dejamos para el siguiente post que este ya se está extendiendo demasiado ;) 

domingo, 13 de marzo de 2016

Give me your TLS session! (Drown attack)

Autor: Toni Escamilla (toespar.me)
Twitter: @toespar



Marzo, mes valenciano por excelencia, y con ello no solo llegan las fallas, sino también un nuevo ataque criptográfico a HTTPS llamado DROWN Attack (Decrypting RSA with Obsolete and Weakened eNcryption) y que nos permite ser capaces de interceptar y descifrar información transmitida. Realizando varios escaneos, podemos hacer una estimación en la que alrededor del 33% de los servidores HTTPS incluyendo servicios de correo electrónico están afectados por esta vulnerabilidad.

¿A qué se debe la vulnerabilidad?
La mayoría servidores y clientes actuales usan TLS como protocolo de cifrado. Sin embargo, y debido a malas configuraciones muchos servidores todavía soportan SSLv2, protocolo considerado inseguro debido a algunas de sus características. 


¿En qué consiste DROWN attack?
Este ataque permite explotar la criptografía de los años 90 (SSLv2), la cual utiliza un cifrado simétrico muy débil de 40 bits. Para ello, el atacante necesita capturar aproximadamente 1000 intercambios de claves RSA entre el usuario y el servidor vulnerable, independientemente del protocolo de cifrado que se utilice. Una vez capturados dichos intercambios, el atacante deberá realizar unas miles de conexiones SSLv2 y realizar 2^50 operaciones de cifrado simétrico para descifrar una sesión TLS.



¿Cómo se si un servidor es vulnerable?
Un servidor es vulnerable a DROWN si cumple alguna de las siguientes dos características:
  1. Permite conexiones SSLv2
  2. Su clave privada es usada en otro servicio que permite conexiones SSLv2
Si realizamos un simple escaneo en Shodan podremos ver como, en el momento de escribir este artículo, hay casi 5 millones de equipos conectados directamente a internet y que actualmente utilizan el protocolo SSLv2, es decir, cumplen la característica para ser sometidos a este tipo de ataques.



Finalmente, y como curiosidad, comentar que este ataque es una extensión del Bleichenbacher attack (1998), cuyas contra-medidas fueron introducidas en SSLv2. Hoy, dos décadas después y con DROWN attack, se ha podido comprobar que dichas contra-medidas son inefectivas.

“Aunque nuestra visión hacia adelante es muy corta, podemos damos cuenta de que hay mucho por hacer” – Alan Turing

Referencias:
  • http://www.elladodelmal.com/2016/03/drown-attack-descifrar-https-tls-por.html
  • https://drownattack.com/drown-attack-paper.pdf
  • https://drownattack.com/
  • http://thehackernews.com/2016/03/drown-attack-openssl-vulnerability.html
  • http://www.theguardian.com/technology/2016/mar/02/secure-https-connections-data-passwords-drown-attack
  • https://en.wikipedia.org/wiki/DROWN_attack