Investigadores de la universidad de Oxford han presentado este año en USENIX Security Symposium un estudio en el que describen un método para automatizar las manipulaciones necesarias del heap layout para explotar buffer overflows (o underflows) en el heap. El enfoque propuesto trata de buscar los valores de entrada necesarios para colocar el origen de un buffer overflow/underflow en el heap junto a objetos que a un desarrollador de exploits o un sistema de generación automática de exploits le interesa leer o corromper. En el artículo se presentan dos sistemas:

• SIEVE: Un framework para construir benchmarks que permite una evaluación flexible y escalable de nuevos algoritmos de búsqueda o algoritmos existentes en distintos allocators, secuencias de interacción (series de llamadas a funciones de allocation o deallocation), o nuevos estados iniciales del heap.

• SHRIKE: Un sistema de manipulación automática del heap layout en el intérprete de PHP para construir control-flow hijacking exploits. Principalmente se divide en tres fases: (1) un componente que identifica fragmentos de código PHP que proporcionen distintas secuencias de interacción; (2) un componente que identifica estructuras que pueden ser interesantes para leer o corromper como parte de un exploit y un medio para desencadenar su allocation; (3) un procedimiento de búsqueda que junta los fragmentos que desencadenan las interacciones para producir programas candidatos.

La evaluación la dividen en dos grupos de experimentos: primero con una serie de benchmarks sintéticos (construidos con su propio framework de evaluación) compuestos por distintas combinaciones de estados iniciales del heap, secuencias de interacción, tamaño de los buffers de origen y destino, y allocators (tcmalloc v2.6.1, dlmalloc v2.8.6, avrlibc v2.0); y en segundo lugar, con tres vulnerabilidades reales conocidas en el intérprete de PHP (CVE-2015-8865, CVE-2016-5093, CVE-2016-7126).
~

The post Automatic Heap Layout Manipulation via #UseSec18 appeared first on S3lab.

Investigadores de la universidades de Vrije en Amsterdam, Ruhr de Bochum y del instituto tecnológico Stevens han presentado en EuroS&P  (European Sysmposium on Security and Privacy) un estudio en el que demuestran que un nuevo tipo de ataque de reutilización de código, al que han llamado Position-Independent ROP (PIROP), se puede llevar a cabo de forma práctica sin necesidad de information disclosure para superar ASLR, basándose en la posición relativa en lugar de la absoluta de los gadgets en memoria. El ataque que proponen se puede dividir conceptualmente en 4 pasos:

• 1. Stack massaging: El primer paso consiste en ejecutar el programa variando las entradas para buscar datos y punteros a código masajeables en el stack que puedan proporcionar gadgets que ejecuten operaciones críticas como llamadas al sistema o stack pivoting.

• 2. Parcheo de punteros a código: Para poder realizar algunas operaciones necesarias o evitar que la ejecución de determinados gadgets dificulte la explotación, los punteros a código se parchean en el ROP payload para que apunten a distintas ubicaciones de código. Parcheando solo algunos bits específicos (los bits menos significativos) en los punteros a código usando una primitiva de escritura relativa (un buffer overflow no lineal como el ejemplo de la imagen) se pueden redirigir los punteros a una ubicación relativa al objetivo original, de forma que se garantice que el ROP payload permanece independiente de la aleatorización mientras se expande el conjunto de gadgets usables.

• 3. Parcheo de operandos: En el mejor de los casos, los datos sobre los que operan los gadgets se pueden establecer directamente controlando los valores de entrada del programa. Sin embargo no siempre es posible o puede que el payload también contenga punteros a datos aleatorizados, por lo que al igual que en el paso anterior, se puede aprovechar una primitiva de escritura relativa.

• 4. Ejecución del ROP payload: Finalmente, una vez que el payload se ha preparado es necesario dirigir el flujo de control para su ejecución, por ejemplo sobrescribiendo el byte menos significativo de una dirección de retorno en el stack mediante un buffer overflow.

Para validar la viabilidad de esta nueva técnica construyen exploits para Firefox y Asterisk  y evalúan su efectividad en presencia de defensas contra information disclosure, ASLR y otras técnicas fine-grained de aleatorización (por ejemplo, a nivel de función), demostrando que puede superar las implementaciones más comunes de ASLR y debilitar considerablemente las defensas más avanzadas sin necesidad de information disclosure.

The post Position-independent Code Reuse via #EuroSP18 appeared first on S3lab.

Investigadores de TAMU (Texas A&M University) presentaran, en S&P (IEEE Symposium on Security and Privacy), un estudio para identificar cuando aparecen estas inconsistencias de validación entre aplicación y servidor en un set de 10.000 aplicaciones populares del Google Play Store. El estudio se centra principalmente en analizar el código fuente de la aplicación Android para detectar las comunicaciones entre los dos puntos. Posteriormente, comprueban si los controles que se realizan en la aplicación también se realizan en el servidor, analizando las respuestas que devuelve la propia API.

Dado que puede resultar algo complejo imaginarse situaciones en la que este tipo de ataques pueden tener un impacto directo en la seguridad y privacidad de los usuarios de dichas aplicaciones móviles, vamos a mostraros un par de ejemplos que fueron capaces de encontrar:

• SQL injection: Estaba claro que uno de los grandes protagonistas en este caso iban a ser este tipo de ataques. Una aplicación enviaba únicamente el email del usuario como forma de autenticación y autorización. A pesar de que se realizaba un control a la hora de enviar el mail a nivel de aplicación, este control era completamente inexistente en el servidor. Por lo tanto, era posible obtener el contenido de la base de datos de todos los usuarios registrados.

• Comprando gratis: Descubrieron que existía un vulnerabilidad de este tipo en un SDK de ecommerce utilizado por muchas aplicaciones (millones de usuarios). A pesar de que la aplicación ponía «1» como el valor mínimo de compra, el servidor aceptaba «0» como opción (para devoluciones y reembolsos). Por tanto, era posible enviar al servidor las comprar con una cantidad de «0», logrando así que el coste total de dicha compra se igualara a cero.

A través de este método, fueron capaces de encontrar mas de 4.000 apps con dicho problema de lógica de validación de datos consistente. Mediante una validación manual de 1.000 aplicaciones, lograron identificar 884 que efectivamente eran vulnerables a este tipo de ataques.

The post Web-To-Mobile Vulnerabilities via #SP18 appeared first on S3lab.

Inspirados por una web publicada en el año 2010 sobre lo que se denominó “benchmarking crimes”, investigadores de la universidad de Vrije en Amsterdam han realizado un estudio para analizar su magnitud en el área de seguridad de sistemas, tomando como referencia 50 artículos de defensas publicados en las conferencias top. Han ideado una serie de requisitos de benchmarking y han propuesto una clasificación de dichos “crímenes”, además de un análisis sistemático para mostrar que este fenómeno es un problema cada vez más relevante en artículos sobre mecanismos de defensa publicados en las conferencias top de seguridad de sistemas.

Para permitir la comparación con otras soluciones, una evaluación debe cumplir con una serie de requisitos. En primer lugar, debe ser completa en el sentido de que debe verificar todas las contribuciones declaradas sobre el sistema y mostrar el alcance de cualquier impacto negativo que pueda producir. Todos los resultados presentados deben ser relevantes en el sentido de que realmente le digan al lector algo significativo sobre el sistema. Por otra parte debe ser sólida, lo que requiere que todos los números midan lo que se pretende con una precisión y repetibilidad razonables. Por último, uno de los principios generales de la ciencia requiere que los artículos sean reproducibles. Es decir, la información provista debería ser suficiente para permitir que otras personas construyen el sistema y lo evalúen de la misma manera que el original.

En la investigación han identificado 22 fallos (“benchmarking crimes”) más o menos comunes que afectan a la validez de los resultados por violar alguno de los requisitos mencionados. Dichos fallos se agrupan en las siguientes categorías (Para la lista completa echar un vistazo al artículo original):

• 1. Benchmarking selectivo. Sucede cuando, por ejemplo, se escoge arbitrariamente un subconjunto de benchmarks y se presenta como un único valor total de sobrecarga de rendimiento.
• 2. Manejo inadecuado de los resultados. En este grupo se encuentran los casos en los que incluso ejecutando los benchmarks correctos la presentación de los resultados puede ser engañosa si se procesan e interpretan de manera incorrecta.
• 3. Uso de benchmarks incorrectos. Como por ejemplo escoger benchmarks que no son adecuados para medir la sobrecarga esperada.
• 4. Comparación inadecuada de los resultados. Para que los números tengan sentido es necesario un punto de referencia común, por lo que en este grupo se encuentran fallos como calcular la sobrecarga en comparación con un punto de referencia inadecuado.
• 5. Omisiones. Por ejemplo al medir únicamente la sobrecarga de tiempo de ejecución pero no la de memoria.
• 6. Falta de información. No incluir información importante en el artículo, como por ejemplo no especificar la plataforma sobre la que se han ejecutado los experimentos.

Los resultados de la investigación han demostrado que los “benchmarking crimes” son un fenómeno extendido en seguridad de sistemas cuya prevalencia no ha cambiado con el tiempo, pero que la mayoría puede prevenirse fácilmente.

The post Benchmarking Crimes via #arXiv appeared first on S3lab.

Investigadores de Google y SAP han presentado en CCS (ACM Conference on Computer and Communications Security) un novedoso método a traves del cual son capaces de saltarse todas esas protecciones y lograr una ejecución controlada. La idea se basa en abusar de los llamados script gadgets (código JavaScript legitimo dentro de la propia aplicación). Generalmente, estos gadgets son selectores DOM que interactuan con diferentes elementos de la página. Por tanto, partiendo de un punto de injección inicial, un atacante puede introducir código HTML con apariencia benigna que es ignorado por los métodos de protección previamente indicandos, pero que lograrían desencadenar la ejecución de código no controlado gracias a los gadgets. Pongamos un ejemplo:

<div id="button" data-text="I am a button"></div>
<script>
var button = document.getElementById("button");
button.innerHTML = button.getAttribute("data-text");
</script>

En este caso, se puede ver cómo el attributo ‘data-text’ acaba siendo incluido sin ningún tipo de control. Por tanto, simplemente introduciendo una imagen svg con un onload, se podría llegar a ejecutar código.

<div id="button"
data-text="&lt;svg onload=exploit()&gt;">
</div>

Los investigadores analizaron este tipo de problemas en los 16 frameworks más populares de JavaScript, y mostraron cómo varios de ellos tenían gadgets que permitían saltarse alguna de las protecciones propuestas. También comprobaron su existencia en algunas de las páginas más visitadas (5000) y cómo un alto porcentaje de ellas era vulnerable en alguna medida a este tipo de ataques.

The post Ataques de code-reuse en la web via #CCS17 appeared first on S3lab.

Una función variádica es aquella que puede recibir un número variable de argumentos, el ejemplo clásico en C es la función printf:

• int printf(char *format, arg_1, arg_2, ….)

Que permite especificar un número variable de argumentos que se aplicarán a los conversores (%) en el char *format.

La flexibilidad que aportan las funciones variádicas tiene un coste, ya que estas funciones no son type-safe, y por tanto de forma estática (en tiempo de compilación) no se pueden detectar errores asociados al uso equivocado de tipos (por ejemplo confundir un float con un entero). Estos errores de tipos pueden ser explotados para ejecutar código malicioso; concretamente los investigadores proponen dos vectores de ataque.

Dado un error de memoria que nos permite sobrescribir el objetivo de una llamada indirecta: Podemos llamar a cualquier función variádica que comparta parte de la firma de la llamada indirecta. Por ejemplo, si esperamos llamar a una función con firma int (* función_a) (int, …), se podría explotar para llamar a otras funciones con firmas tan diferentes como void (* función_b) (int, …), u a funciones variádicas con una firma igual, pero que esperen diferentes argumentos, por ejemplo int (* función_c) (int, …). Se pueden sobrescribir los argumentos de la función variádica, por ejemplo los ataques de format-strings son parte de este vector de ataque.

Esta clase de ataques son los que los investigadores tratan de evitar con una herramienta llamada HexVASAN. Esta combina el análisis estático con un chequeo en tiempo de ejecución para asegurar que las llamadas a funciones variádicas no sean explotadas. Para ello, añaden un nuevo pase de compilación en LLVM que po run lado, extrae información sobre dónde van a ocurrir llamadas variádicas y además hace que el compilador inyecte instrucciones adicionales encargadas de recolectar información sobre los tipos y número de argumento de estas llamadas. En tiempo de ejecución, un segundo componente, una biblioteca, se engancha a el programa que se quiere proteger y haciendo uso de las instrucciones añadidas por el compilador va tomando nota de los tipos y número de parámetros de las funciones variádicas, para que en el momento en que se vayan a llamar hacer un chequeo de lo que realmente se está llamando frente a lo que se debería de haber llamado.

The post Variadic Vulnerabilities Vanquished via #UseSec17 appeared first on S3lab.