Warning: Cannot modify header information - headers already sent by (output started at /var/www/blogs/s3lab/wp-content/themes/responsive/core/includes/functions-admin.php:126) in /var/www/blogs/s3lab/wp-includes/feed-rss2.php on line 8 S3lab http://s3lab.deusto.es S3lab Security Blog Fri, 23 Jun 2017 09:57:36 +0000 es-ES hourly 1 https://wordpress.org/?v=4.8 Crea un binario ilegible con estas técnicas http://s3lab.deusto.es/binario-ilegible-tecnicas/ http://s3lab.deusto.es/binario-ilegible-tecnicas/#respond Fri, 23 Jun 2017 09:55:39 +0000 http://s3lab.deusto.es/?p=9190 Ya bien sea por fines maliciosos, como el caso de los autores de malware, por fines corporativos, o por otras razones, las técnicas de ofuscación son utilizadas para proteger un programa haciendo que una vez compilado, el análisis estático del

The post Crea un binario ilegible con estas técnicas appeared first on S3lab.

]]>
Ya bien sea por fines maliciosos, como el caso de los autores de malware, por fines corporativos, o por otras razones, las técnicas de ofuscación son utilizadas para proteger un programa haciendo que una vez compilado, el análisis estático del binario sea más costoso. La ofuscación por tanto, consiste en transformar un programa de forma que sea más difícil de entender, pero que al mismo tiempo mantenga la semántica original.

Estas técnicas de ofuscación pueden aplicarse a nivel de datos, de instrucciones o de flujo de control del programa, pasamos a explicar algunas de ellas. Estas son algunas de las técnicas de ofuscación de datos:

  • Cegar las constantes (constant blinding): en vez de tener un valor en claro, esta técnica busca sustituir los valores de las constantes, generalmente mediante una XOR con un valor aleatorio, por datos aparentemente sin sentido.
  • Cambio del encoding de las variables: de forma similar al constant blinding, cambiando el encoding de las variables se busca ocultar el valor original de la variable, por ejemplo un string, por su valor equivalente en otro encoding. Ejemplos típicos son la codificación en Base64 o los cifrados sencillos mediante XOR, ROT13 etc.
  • Agregación de datos: consiste en agrupar variables en estructuras más complejas, por ejemplo juntando enteros en un mismo struct.
  • Separación de datos: en contraposición a la agregación de datos, la separación de datos consiste en dividir los datos en unidades más pequeñas, por ejemplo transformando un int de 4 bytes en dos shorts de 2 bytes.

Para ofuscar el flujo de control del programa existen diversas técnicas:

  • Inserción de código muerto (dead code insertion): una de las fases de optimización que hacen los compiladores modernos por defecto es la eliminación de código que no afecta al programa  (opción -fdce en GCC); la inserción de código muerto es todo lo contrario, es decir, inserta código en el programa que es redundante. Los ejemplos más sencillos son la inserción de nops, guardar el valor de una variable, hacer operaciones matemáticas con ella para luego restaurar el valor original etc.
  • Uso de predicados opacos: un predicado es una expresión lógica que se evalúa a true o false, y que generalmente se usa para dirigir el flujo de un programa. Los predicados opacos tienen como objetivo hacer que esa decisión de si algo se evalúa a true o false no sea posible saberse en tiempo de compilación o de forma estática, aunque siempre vaya a tener el mismo resultado. De esta forma se generan más ramas en el control flow graph (CFG) y se molesta en la fase de reversing. Tratar de detectar predicados opacos y desofuscarlos es una línea de investigación abierta. Se pueden ver ejemplos en estas respuestas de Reverse Engineering Stack Exchange.
  • Aplanado del flujo de control (control flow flattening): esta técnica consiste en modificar y reordenar los bloques básicos de un programa  (basic block, BB) de forma que, en vez de tener en el CFG una estructura de decisión if-else típica en la que se sigue la ejecución a un BB o se salta a otro BB dependiendo del valor de los flags, se pasa a una estructura aplanada, en la que un BB llamado dispatcher decide a qué BB saltar en base al valor de una variable artificial. Cada BB de las ramas de decisión tiene el dispatcher como predecesor y sucesor, dificultando así averiguar la lógica del programa detrás del CFG aplanado.
  • Desenroscado de bucles (loop unrolling): en las fases de optimización de la compilación de un programa se utiliza el loop unrolling para evitar añadir instrucciones de salto condicional y variables adicionales para emular bucles. El loop unrolling, además de ser computacionalmente menos costoso (se activa con la opción -O1 en adelante en GCC) genera bloques de instrucciones muy parecidos entre ellos, lo que aumenta la confusión en el análisis estático del código.

Finalmente a nivel de instrucción se busca sustituir la instrucción original por otra serie de instrucciones equivalentes más complicadas, generalmente mediante el uso de operaciones matemáticas. Algunas de estas técnicas pueden aplicarse con Obfuscator-LLVM, una suit de compilación sobre LLVM que en vez de aplicar las optimizaciones típicas del middle-end de LLVM, permite ofuscar el programa. 

Por otro lado, las técnicas de ofuscación también pueden servir para dar seguridad. Por ejemplo, PointGuard es una antigua extensión de GCC para proteger punteros. PointGuard cifra los valores de los punteros cuando estos están en memoria aplicando una XOR con una clave generada aleatoriamente cuando el proceso del programa arranca. Cuando un puntero se va a dereferenciar se descifra el valor del puntero, de esta forma, si un atacante consigue sobrescribir el valor del puntero, cuando este se dereferencie y por PointGuard se descifre, el atacante estará accediendo a una dirección de memoria aleatoria, y muy posiblemente si el acceso no es válido hará que el programa falle, frustrando así la explotación del programa.

 

The post Crea un binario ilegible con estas técnicas appeared first on S3lab.

]]>
http://s3lab.deusto.es/binario-ilegible-tecnicas/feed/ 0
Regulación penal de la suplantación de identidad (IV) http://s3lab.deusto.es/regulacion-suplantacion-4/ http://s3lab.deusto.es/regulacion-suplantacion-4/#respond Fri, 16 Jun 2017 09:55:01 +0000 http://s3lab.deusto.es/?p=9164 Continuando con los anteriores post donde hablamos de las formas de suplantación de identidad más habituales en internet, y habiendo especificado los modus operandi habituales desde que el inicio hasta el final, nos ha llegado el turno de concretar y

The post Regulación penal de la suplantación de identidad (IV) appeared first on S3lab.

]]>
Continuando con los anteriores post donde hablamos de las formas de suplantación de identidad más habituales en internet, y habiendo especificado los modus operandi habituales desde que el inicio hasta el final, nos ha llegado el turno de concretar y definir las consecuencias o responsabilidades penales, que van aparejadas a dicho tipo de conductas.

Delito de descubrimiento y revelación de secretos

¿ Se debe considerar los datos de carácter bancario como propios e inherentes esfera de la intimidad de las personas y por tanto al derecho de intimidad ? Aquí la Jurisprudencia avala en resoluciones judiciales varias, que los datos bancarios, sí pertenecen a la esfera del derecho a la intimidad de las personas. Como por ejemplo la STC 292/2000 de 30 de noviembre en su Fundamento Jurídico 6º, avala esta tesis que en relación a la nueva redacción del artículo 197.2 LO 10/1995. No deja lugar a duda sobre la existencia del delito de descubrimiento o revelación de secretos, cuyas penas oscilarían entre penas privativas de libertad de entre a uno a cuatro años y multas de doce a veinticuatro meses. Este sería el tipo penal general establecido, sin embargo, las penas variaran al alza en caso de revelación o difusión de los datos ilícitamente obtenido étc , ( Ver Articulo 197del Código Penal 10/1995 de 23 de noviembre ).

Posible delito de falsedad documental

Una vez los atacantes han logrado suplantar la personalidad y en supuesto caso de que los mismos modifiquen manipulen o simulen documentos de carácter mercantil, con los que posteriormente tengan la posibilidad de obtención de lucro, mediante la utilización de técnicas informáticas que permitan modificar todo o parte del documento, incurrían en el tipo penal tipificado en el artículo 390 y Ss del Código penal LO 10/1995 como delito de Falsedad Documental, con penas privativas de libertad, que oscilan en su tipo general desde los tres a los seis años

Delito de blanqueo de capitales recogido en el artículo 298.1 CP LO 10/1995

El que, con ánimo de lucro y con conocimiento de la comisión de un delito contra el patrimonio o el orden socioeconómico, en el que no haya intervenido ni como autor ni como cómplice, ayude a los responsables a aprovecharse de los efectos del mismo, o reciba, adquiera u oculte tales efectos, será castigado con la pena de prisión de seis meses a dos años. Especial atención a este artículo en el que a pesar de no haber participado directamente en la sustracción de datos datos se ha colaborado en el proceso tendente a la consecución del resultado contrario a la ley, y por tanto la actuación de los “muleros “ esta tipificado con penas de entre seis a dos años de pena de privación de libertad , que en función de las características y circunstancias que rodean a la misma pueden verse incrementados de forma sustancial.

The post Regulación penal de la suplantación de identidad (IV) appeared first on S3lab.

]]>
http://s3lab.deusto.es/regulacion-suplantacion-4/feed/ 0
Una denegación de servicio vale miles de peticiones http://s3lab.deusto.es/denegacion-servicio-peticiones/ http://s3lab.deusto.es/denegacion-servicio-peticiones/#respond Fri, 09 Jun 2017 17:44:37 +0000 http://s3lab.deusto.es/?p=9133 Me parece que se me había pasado comentaros pero… Los ataques de denegación de servicio (DOS, por sus siglas en ingles) son una de las “armas” digitales más utilizadas actualmente para muchos propósitos. Alguno de sus usos son el chantaje,

The post Una denegación de servicio vale miles de peticiones appeared first on S3lab.

]]>
Me parece que se me había pasado comentaros pero…

Los ataques de denegación de servicio (DOS, por sus siglas en ingles) son una de las “armas” digitales más utilizadas actualmente para muchos propósitos. Alguno de sus usos son el chantaje, control de competidores, prueba de poder o desvío de atención. El concepto de denegación de servicio es ampliamente conocido dentro del mundo de las redes desde hace mucho, pero no fue una realidad para el gran público hasta que Low Orbit Ion Cannon fue usado por Anonymous en diferentes ataques a gran escala. Años después, la botnet Mirai revivió esos temores realizando uno de los ataques más grandes jamás vistos hasta el momento desde dispositivos IoT vulnerables. Actualmente estos ataques se suelen ofrecer como servicio, que se monetizan por tiempo del ataque.

Empezando desde los cimientos, un ataque de denegación de servicio se basa en impedir que un servidor responda a las peticiones de un usuario legítimo, por ejemplo realizando miles sino millones de peticiones simultáneas, como comúnmente se denomina, “inundando” la red. Inicialmente estos ataques se podían realizar desde un único equipo ya que no existían protecciones al respecto, pero rápidamente empezaron a crearse soluciones que controlaban el número de peticiones por equipo y detectaban estas acciones. Por ello, apareció una nueva versión , la denegación de servicio distribuida (DDOS), que se centra en realizar peticiones desde diferentes puntos para así camuflar el ataque y que resulte difícil identificar si las peticiones son reales o son parte del propio ataque orquestado. Hoy en día la gran mayoría de ataques de éste tipo se encontrarían dentro de esta categoría. Existen diferentes formas de lograr una denegación de servicio, a continuación explicaremos brevemente los 3 grandes grupos que podemos encontrar:

  • Ataques basados en volumen: Éste grupo sería el que hemos avanzado previamente. El objetivo del ataque es saturar/consumir el ancho de banda del servicio atacado mediante peticiones masivas de paquetes spoofeados como por ejemplo podrían ser UDP o ICMP. De esta forma, el servicio estará completamente congestionado y no podrá responder a ninguna petición adecuadamente, dado que ha sobrepasado con creces el tráfico esperado para la red diseñada

  • Ataques de protocolo: Estos ataques se consideran más sofisticados que el grupo anterior, ya que en éste caso lo importante no es el número de peticiones sino la “calidad” de las mismas. El propósito de cada petición es utilizar el mayor número de recursos tanto del servidor como de cualquier intermediario (firewalls, balanceadores de carga…) que exista. El conocido como “Ping de la muerte” es el ejemplo perfecto de éste grupo. El atacante realiza varias peticiones ICMP modificadas, para finalmente lograr que el objetivo reciba un paquete IP mayor que el máximo permitido (65,535 bytes), generando un overflow.

  • Ataques a nivel de aplicación: En éste caso, el ataque se centra en realizar peticiones de capa 7 para inhabilitar servidores web. Dada su tipología de alto nivel, muchas veces resulta complejo identificar llamadas maliciosas. Un ejemplo claro sería el llamado “Slowloris”, que mantiene el mayor número de conexiones HTTP abiertas con el servidor realizando peticiones parciales sin llegar a completarlas. Finalmente el número máximo de conexiones concurrentes se alcanza, llevando consigo una denegación de servicio.

Se tiende a pensar que si alguien tiene el servidor completamente actualizado (cruzando los dedos para que nadie encuentre un zero-day) se puede lograr mantener un servicio a flote sin ningún problema. Pero no hay que olvidar que la explotación de vulnerabilidades a nivel de servidor no es el único problema que hay que tener en mente, una denegación de servicio puede hacer perder millones a una empresa si no está preparada.

El que avisa no es traidor.

The post Una denegación de servicio vale miles de peticiones appeared first on S3lab.

]]>
http://s3lab.deusto.es/denegacion-servicio-peticiones/feed/ 0
Los errores de corrupción de memoria http://s3lab.deusto.es/errores-corrupcion-memoria/ http://s3lab.deusto.es/errores-corrupcion-memoria/#respond Sat, 03 Jun 2017 20:25:06 +0000 http://s3lab.deusto.es/?p=9113 Cuando hablamos de errores de corrupción de memoria, lo primero que se nos viene a la cabeza es el clásico buffer overflow, lo cual tiene mucho sentido ya que, aunque algunos lo llamaban la vulnerabilidad de la década allá por

The post Los errores de corrupción de memoria appeared first on S3lab.

]]>
Cuando hablamos de errores de corrupción de memoria, lo primero que se nos viene a la cabeza es el clásico buffer overflow, lo cual tiene mucho sentido ya que, aunque algunos lo llamaban la vulnerabilidad de la década allá por el año 2000, a día de hoy sigue ocupando la tercera posición en el ranking MITRE de errores de software más peligrosos.

Sin embargo, la corrupción de memoria abarca todo tipo de alteración involuntaria que se produce en el contenido de una o varias direcciones de memoria, como sucede al operar con un array fuera de sus límites. Por otra parte, dentro de los errores de corrupción de memoria también se incluyen aquellos que producen comportamientos indefinidos o revelación de información al hacer un uso indebido de la propia memoria. Todos estos errores comúnmente se clasifican en dos tipos: espaciales y temporales.

Los errores espaciales son violaciones causadas al operar con un puntero que apunta a una dirección fuera de los límites, superiores o inferiores, de su referente. El buffer overflow/underflow se encuentra en esta categoría puesto que cualquier tipo de operación que resulte en un acceso de memoria fuera de los límites se considera un error espacial.

Los errores temporales se caracterizan por ser causados por el uso de un puntero cuyo referente no es un objeto válido debido a que no ha sido inicializado o ha sido liberado anteriormente (mediante una operación free). Los ejemplos más claros son el use-after-free, en el que se incluyen el double-free y la desreferencia de dangling pointers, y por otro lado el use-before-initialization, como son las lecturas no inicializadas.

Como se ha podido ver en la serie de hardening de binarios de este mismo blog, existen y se siguen desarrollando numerosas soluciones que tratan de mitigar este tipo de errores, ya que desencadenar un error de corrupción de memoria es el primer paso que toman gran cantidad de exploits.

The post Los errores de corrupción de memoria appeared first on S3lab.

]]>
http://s3lab.deusto.es/errores-corrupcion-memoria/feed/ 0
PackerInspector: Nuestra sandbox para packers http://s3lab.deusto.es/packerinspector-sandbox-packers/ http://s3lab.deusto.es/packerinspector-sandbox-packers/#respond Fri, 26 May 2017 17:35:54 +0000 http://s3lab.deusto.es/?p=9092 Tenemos el placer de presentaros un nuevo servicio on-line para el análisis de packers, resultado del trabajo conjunto de S3Lab y S3 Eurecom. PackerInspector surge como consecuencia del trabajo de investigación presentado en la conferencia IEEE Security & Privacy en

The post PackerInspector: Nuestra sandbox para packers appeared first on S3lab.

]]>
Tenemos el placer de presentaros un nuevo servicio on-line para el análisis de packers, resultado del trabajo conjunto de S3Lab y S3 Eurecom. PackerInspector surge como consecuencia del trabajo de investigación presentado en la conferencia IEEE Security & Privacy en 2015: SoK: Deep Packer Inspection: A Longitudinal Study of the Complexity of Run-Time Packers. Tras más de un año de desarrollo,  ponemos nuestra investigación al servicio de la comunidad.

Las sandbox ejecutan cada muestra en un entorno controlado para observar su comportamiento malicioso, pero normalmente estos sistemas carecen de información acerca de cómo está empaquetada la muestra. Si recordamos entradas previas de este blog, los autores de malware generalmente empaquetan sus programas para evitar su detección y dificultar la ingeniería inversa. A grandes rasgos, un programa empaquetado contiene una rutina encargada de descomprimir o descifrar una sección de código protegida, que más tarde será ejecutada. A menudo, los autores de malware utilizan varias capas de empaquetado, fuertes métodos de ofuscación de código para cada una de las capas, así como métodos para evadir herramientas como sandbox, debuggers, frameworks de instrumentación, etc.

En muchas ocasiones, el analista de malware necesita analizar en profundidad de forma estática la totalidad del código de la muestra. Si la muestra está empaquetada, es necesario desempaquetarla para obtener un volcado del código original. Para ello, existen diversas alternativas. Por un lado existen unpackers específicos, que son capaces de lidiar con un número limitado de packers conocidos. Por otro lado, existen algunas herramientas de desempaquetado generico basadas en heurísticas. Desafortunadamente, estas heurísticas en ocasiones no presentan una gran efectividad. Como último recurso, el analista debe desempaquetar manualmente la muestra, lo que requiere analizar el empaquetador y averiguar cómo protege el código original.

Si bien existen multitud de sandboxes que permiten analizar malware para extraer indicadores de su comportamiento, no hay apenas herramientas que permitan entender el funcionamiento de un packer. PackerInspector pretende llenar este hueco, de tal modo que se especializa en este tipo de análisis y ofrece un informe detallado sobre diferentes características del packer, obtenidas de forma estática y dinámica. Estas caracteristicas (número de capas, interacción entre las mismas, número de procesos e interacción entre ellos, estructura de las diferentes capas…), nos permiten categorizar la estructura del packer en 6 niveles de complejidad estructural. Por ejemplo, UPX, uno de los packers más sencillos tiene una complejidad de tipo 1 (Type-I), mientras que Armadillo con la protección CopyMem activada, presenta una estructura de complejidad 6 (Type-VI).

El grafo que mostramos corresponde a un packer con un único proceso (P0), y 4 layers (0 a 3). Cada layer contiene una serie de regiones (áreas de memoria escritas y ejecutadas). Por ejemplo, si una determinada región Ra es escrita por otra región situada en la layer 1 (Rb), y Ra es después ejecutada, entonces Ra formará parte de la layer 2. Cada región contiene una primera línea que nos indica el tipo de memoria (M (módulo), S (stack), H (heap)) y su comienzo mientras que la segunda línea indica su tamaño. La tercera línea muestra 3 valores separados por “#”, que indican: el número total de llamadas a la API realizadas desde la región, el número de funciones de la API diferentes utilizadas, así como la presencia de llamadas a ciertas funciones relacionadas con el código bootstrap insertado por compiladores. Finalmente, la última línea muestra el número de frames (cuando una región ha sido escrita y ejecutada en varios turnos). Además, los colores diferencian las regiones, siendo la región roja la última en ejecutarse en nuestra sandbox.

Estamos ante un packer que descifra una primera capa, y tras ello pasa a ejecutarla (la región situada en 0x401000). A continuación, la rutina situada en la región 0x4079b1 (layer 1), descifra una segunda capa y la ejecuta, que a su vez descifra el código original (layer 3), y lo ejecuta. Los conectores grises nos indican que solamente ha habido una transición del flujo de ejecución entre cada par de capas, mientras que los conectores verdes y rojos nos indican el número de bytes escritos por cada región a regiones en la siguiente capa (de color verde, excepto cuando existe una transición de ejecución además de la escritura, en cuyo caso se muestra en rojo). Finalmente, vemos que la región roja de la última capa contiene un número muy superior de llamadas a la API, además de llamadas a la API relacionadas con el código inicial insertado por el compilador. Todo ello nos indica que el binario original se encuentra en esta capa.

Si quieres aprender más sobre cómo funciona PackerInspector, puedes visitar la página de referenciaEn nuestro estudio original, medimos la evolución de la complejidad del empaquetado de muestras enviadas a la sandbox Anubis a lo largo de varios años. Hoy, al publicar este servicio, damos continuidad a este estudio recogiendo estadísticas globales de la complejidad de las muestras que compartáis con nosotros.

PackerInspector permite el envío de muestras de forma pública y privada. Para poder hacer uso del envío privado, deberás iniciar sesión con una cuenta de Google (OpenID). Con este registro, no almacenamos información más allá de un identificador único por cuenta y aplicación. Para las muestras enviadas de forma pública,  el resultado del análisis será accesible por cualquiera en posesión de la url correspondiente. Sin embargo, si envías la muestra de forma privada, solamente tú podrás acceder al informe generado. Además, si estás registrado, podrás realizar un seguimiento de las muestras enviadas para su análisis, así como localizar informes de muestras enviadas anteriormente y utilizar la API pública para automatizar el envío de muestras y recopilación de resultados.

Por último, si tienes cualquier duda o comentario, no dudes en ponerte en contacto con nosotros a través de cualquiera de los medios que disponemos.

Happy reversing!

 

The post PackerInspector: Nuestra sandbox para packers appeared first on S3lab.

]]>
http://s3lab.deusto.es/packerinspector-sandbox-packers/feed/ 0
¿Cómo funciona un compilador? http://s3lab.deusto.es/como-funciona-compilador/ http://s3lab.deusto.es/como-funciona-compilador/#respond Sat, 13 May 2017 18:28:41 +0000 http://s3lab.deusto.es/?p=9069 En la serie de posts de Hardening de binarios hemos visto que muchas defensas vienen implantadas en los propios compiladores, pero ¿cómo se implementan? Tomando el caso de GCC, The GNU Compiler Collection, vamos a explicar la infraestructura general de

The post ¿Cómo funciona un compilador? appeared first on S3lab.

]]>
En la serie de posts de Hardening de binarios hemos visto que muchas defensas vienen implantadas en los propios compiladores, pero ¿cómo se implementan? Tomando el caso de GCC, The GNU Compiler Collection, vamos a explicar la infraestructura general de GCC y en grandes rasgos, cómo funciona un compilador.

Si hemos tenido una asignatura de Compiladores en nuestra vida, en muchos casos nos habrán simplificado el proceso de compilación diciéndonos que se divide en dos componentes, por un lado el front-end y por otro el back-end. El front-end es el encargado de parsear el código fuente y traducirlo a un lenguaje intermedio que el compilador entienda; finalmente en el back-end es donde se traduce ese lenguaje intermedio a ensamblador.

La realidad, en el caso de GCC, es algo más complicada, siendo la primera diferencia el número de componentes de los que se compone el compilador y la segunda que utiliza varios lenguajes intermedios. GCC se divide en tres componentes, el front-end, el middle-end y el back-end.

En el front-end se parsean los diferentes códigos fuente y se traducen a un lenguaje independiente de la máquina, GIMPLE. GIMPLE es un lenguaje basado en la representación de un código de tres direcciones (three-address code), donde todas las instrucciones tienen como máximo tres operandos. En esta fase es donde el compilador nos avisará si tenemos errores sintácticos en el programa a compilar. Cuando GCC compila C ó C++ la traducción pasa directamente de C/C++ a GIMPLE, si se trata de otro lenguaje, como FORTRAN, se traduce primero a GENERIC, otro lenguaje intermedio de GCC basado en árboles de sintaxis abstracta (ASTs de sus siglas inglesas), que a su vez es traducido a GIMPLE.

En el middle-end es donde se producen todas las optimizaciones, tanto intra-procedurales (propias de cada función) como inter-procedurales (que tienen en cuenta el estado de todas las funciones). En esta fase el compilador nos avisará si hemos cometido errores semánticos, si tenemos variables sin usar etc. En el middle-end se utilizan tres lenguajes diferentes, que son tres formas de GIMPLE: high-GIMPLE, low-GIMPLE y SSA-GIMPLE. En el high-GIMPLE los programas no tienen una representación de tres direcciones pura y en el low-GIMPLE sí. Finalmente el SSA-GIMPLE es un lenguaje intermedio también de tres direcciones, en el que se utiliza la forma de Static Single Assignment (SSA form) para hacer optimizaciones de forma más sencilla. La forma SSA tiene la particularidad de que las asignaciones “generan” una versión de la variable nueva, por ejemplo:

a = 10; a_1 = 10;
a = a + 1; a_2 = a_1 + 1;
b = a; b_1 = a_2;

Las funciones típicas de este componente son la propagación de constantes y la optimización de tail-calls, además UBSan, VTV y ASan son implementadas en este componente. Finalmente, en el back-end se traduce el SSA-GIMPLE a un lenguaje dependiente de la máquina, RTL (Register Transfer Language) que ya se va pareciendo más a el lenguaje ensamblador, pero con la particularidad de que es funcional y deriva de Lisp.

The post ¿Cómo funciona un compilador? appeared first on S3lab.

]]>
http://s3lab.deusto.es/como-funciona-compilador/feed/ 0
Regulación penal de la suplantación de identidad (III) http://s3lab.deusto.es/regulacion-suplantacion-3/ http://s3lab.deusto.es/regulacion-suplantacion-3/#respond Sat, 06 May 2017 19:22:46 +0000 http://s3lab.deusto.es/?p=9056 Continuando con el anterior post en donde identificamos las conductas típicas de suplantación de identidad, más conocidas y una vez hemos identificado el fundamento jurídico que recoge tipo penal con base en el artículo 248.1 LO 10/1995 del Código Penal

The post Regulación penal de la suplantación de identidad (III) appeared first on S3lab.

]]>

Continuando con el anterior post en donde identificamos las conductas típicas de suplantación de identidad, más conocidas y una vez hemos identificado el fundamento jurídico que recoge tipo penal con base en el artículo 248.1 LO 10/1995 del Código Penal , vamos pasaremos a explicar qué modus operandi suele seguir el ilícito señalado que como anteriormente indicábamos se comente de forma habitual a través de estas tipos penales anteriormente señalados: phishing, farming y smishing.

Como ya habíamos comentado en el anterior, El punto de partida es el momento en el que el atacante ya se encuentra en posesión de las claves de acceso y firma de la víctima disponiendo de las señas de identidad para el acceso para suplantar su identidad y como ocurre de forma habitual obtener de forma ilícita un lucro mediante el acceso no consentido por el legítimo titular cuentas bancarias y realizar actos de disposición económicas en la misma en perjuicio del legítimo titular de las cuenta bancaria.

Pero, una vez sustraído el bien pecunario, que aunque normalmente suele ser dinero, pudiera ser documentos con equivalentes valores admitidos como medios de pago y cobro étc.. ¿Cuál es el destino final de la dichas , disposiciones? Las cuentas destinatarias suelen ser:

  • Cuantas nacionales abiertas con identidades de personas físicas o jurídicas falsas y generalmente, como sucede en la mayoría de los casos con pasaportes extranjeros falsificados.
  • Cuentas bancarias extranjeras, o abiertas fuera del país de origen de la sucursal de la entidad financiera donde se comete el ilícito.
  • Cuentas de “ muleros “, prestaremos, especial relevancia a este tipo de cuentas como forma de finalización de proceso de fraude, por entender que son menos conocidas pero, no por ello menos utilizadas por los ciberdelincuentes con alto grado de eficacia a la hora de lograr hacerse con el botin derivado del ilícito.

Los “muleros” forman parte del final de la cadena del delito de la estafa através de internet, y se encargan de intermediar en cobros y pagos entre empresas, muchas veces, aunque no siempre, en transferencias de carácter internacional, y a diferencia del hacker o atacante que permanece en la anonimato, los muleros que les prestan sus servicios a modo de “empleo”, para elciberdelincuente, o dicho en otras palabras, trabaja para elciberdelincuente.

Los muleros no ocultarán nunca su personalidad, son legítimos titulares de las cuentas bancarias de destino de las transferencia económica objeto del ilícito, y por último estarán siempre a inmediata disposición para cobrar la citada transferencia y acto seguido, transferir nuevamente la misma según las instrucciones recibidas delciberdelincuente, generalmente a través entidades de intermediación monetaria internacional con capacidad y legitimidad para transferencias internacionales tanto en el país de origen como en el país de destino.

The post Regulación penal de la suplantación de identidad (III) appeared first on S3lab.

]]>
http://s3lab.deusto.es/regulacion-suplantacion-3/feed/ 0
Ese malware sabe que lo están vigilando http://s3lab.deusto.es/malware-sabe-vigilando/ http://s3lab.deusto.es/malware-sabe-vigilando/#respond Thu, 27 Apr 2017 18:29:15 +0000 http://s3lab.deusto.es/?p=9000 Me parece que se me había pasado comentaros pero… Es extremadamente común que un malware avanzado no se dedique únicamente a esconder su código con diferentes packers, sino que también intente detectar si está siendo analizado de forma dinámica mediante

The post Ese malware sabe que lo están vigilando appeared first on S3lab.

]]>

Me parece que se me había pasado comentaros pero…

Es extremadamente común que un malware avanzado no se dedique únicamente a esconder su código con diferentes packers, sino que también intente detectar si está siendo analizado de forma dinámica mediante una sandbox. En caso de darse cuenta de que lo están vigilando, modificará su comportamiento para esconder su funcionalidad maliciosa y mostrar funciones completamente inocuas. De esa forma, el sistema de análisis clasificará la muestra como benigna y podrá infectar el sistema objetivo sin problema alguno.

Muchas veces, conseguir detectar al vigía no es sencillo, por lo que los autores de malware suelen comprobar si efectivamente el malware está siendo detectado o no por determinadas sandbox. Para ello, hacen uso de las diferentes herramientas publicas. Van enviando las versiones de su malware hasta lograr una que pase completamente desapercibida. De todas formas, esto puede llegar a ser contraproducente, ya que como se ha mostrado en un trabajo reciente, el envío consecutivo de estas muestras permite la detección temprana de esos malware primigenios. Ahora, nos centraremos en explicar las ideas generales de cada una de las principales técnicas que se usan actualmente en el malware para detectar sandbox:

  • Interacción de usuario: Como cabe esperar, los análisis dinámicos en sandbox no se realizan de forma manual, sino de una forma completamente automatizada. Basándonos en eso, es posible detectar el análisis simplemente fijándonos en la interacciones que hace o debería hacer un usuario (movimientos de ratón, pulsaciones de teclado…). Esto se puede hacer tanto incitando al usuario ha realizar dichas acciones mediante un instalador falso o comprobándolas sin ningún tipo de incentivo.

  • Penalización de tiempo: Monitorizar un sistema y su comportamiento no es sencillo y hace uso de un gran número de herramientas de forma interna para lograrlo. Esta vigilancia tiene un castigo: el tiempo. La cantidad de pasos que tiene que dar cada ejecución es mayor, por lo que si analizamos el tiempo necesario para realizar cada acción podemos darnos cuenta que algo “extra” está ocurriendo, permitiéndonos detectar la presencia de una sandbox.

  • Sistemas artificiales: Esta técnica no se basa en la detección de propiedades que puedan identificar una sandbox, sino en detectar que la máquina no se trata de un sistema de producción normal. Algunos de los ejemplos más sencillos serían la ausencia de ciertos drivers, tamaños de disco, memoria extremadamente pequeña o la falta de aplicaciones indispensables para cualquier usuario. Ya comentamos algo similar al hablar de honeypots de baja interacción, siendo éste uno de sus mayores problemas.

  • Tecnologías específicas: Al contrario que en el punto anterior, en este caso nos centraremos en detectar situaciones anómalas que muestran un comportamiento fuera de lo común. La gran mayoría de sandbox usan hooks para capturar las comunicaciones entre diferentes componentes del sistema. Con una simple verificación del hash de ciertos ficheros del sistema se puede detectar que han modificado el código de los mismos. Para casos de emulación, realizar llamadas a instrucciones de CPU no incluidas puede ser muy útil.

De todas formas, estas técnicas no funcionan en todos los casos, ya que de la misma manera que el malware intenta detectar que lo vigilan, el que vigila intenta esconder lo que está haciendo. Si algo queda claro después de todo esto, es que las sandbox genéricas han quedado obsoletas y que confiar en un análisis así no es algo que haya que hacer si no queremos llevarnos ningún susto.

El que avisa no es traidor.

The post Ese malware sabe que lo están vigilando appeared first on S3lab.

]]>
http://s3lab.deusto.es/malware-sabe-vigilando/feed/ 0
Investigación en seguridad (VIII) – Papers, Lenguaje http://s3lab.deusto.es/investigacion-en-seguridad-8/ http://s3lab.deusto.es/investigacion-en-seguridad-8/#respond Wed, 12 Apr 2017 08:16:36 +0000 http://s3lab.deusto.es/?p=8985 Retomamos uno de los aspectos fundamentales de la vida científica: escribir contribuciones o papers. Anteriormente, habíamos hablado de la estructura que se suele seguir en Computer Science y en System Security en particular: (i) abstract, (ii) introducción, (iii) [background], (iv)

The post Investigación en seguridad (VIII) – Papers, Lenguaje appeared first on S3lab.

]]>
Retomamos uno de los aspectos fundamentales de la vida científica: escribir contribuciones o papers. Anteriormente, habíamos hablado de la estructura que se suele seguir en Computer Science y en System Security en particular: (i) abstract, (ii) introducción, (iii) [background], (iv) método, (v) evaluación, (vi) discusión, (vii) related work, y (viii) conclusiones. En este caso vamos a dar unas pequeñas pinceladas sobre cómo tiene que ser el lenguaje empleado y cómo hacer que nuestra contribución que suponemos substancial, sea reconocida como tal, de un modo que también facilite su compresión e incluso entretenida de leer.

Como caso particular, en System Security es MUY habitual que los títulos de los artículos sigan la siguiente estructura Nombre de Broma o Referencia Pop: Nombre serio. No sé si es porque es una disciplina joven, pero es habitual encontrarse artículos con nombres de broma como Internet Jones & the Raiders of the Lost Trackers o How the ELF ruined Christmas. No es que sea algo obligatorio, pero si algo característico a mencionar.

Pero vayamos al grano, da igual lo gracioso que sea el título, si no es capaz de transmitir lo relevante de la contribución, el revisor se reirá una sola vez (o dos si es malvado). La clave para escribir bien un artículo es comenzar sabiendo cuál o cuáles son los aspectos más importantes de nuestra contribución. A partir de ahí haremos un outline de cada una de las secciones, a un nivel cada vez profundo. La premisa inicial, es que leyendo el paper se podría replicar completamente la investigación.

Después, es importante utilizar un lenguaje sencillo y con palabras sencillas: no estamos escribiendo una novela, estamos con un paper. Siendo así evitaremos frases largas y rebuscadas y siempre escogeremos la palabra más habitual para el significado que queramos. Tenemos que tener en cuenta que el Inglés es la lingua franca de la Ciencia, pero los lectores y revisores no tienen porqué ser duchos en él y menos nativos.

Por otro lado, es importante reseñar que si estamos hablando de una artículo para una top-tier conference, éstos son de mucha longitud, por lo que cuánto mayor número de apartados con títulos claros, mucho mejor para facilitar su lectura (los títulos se quedan antes en la cabeza). Además, de este modo, nos aseguramos que el revisor (que tendrá que revisar 20+ papers en dos semanas) se quede con la idea.

Por último, un aspecto importante, es que pese a que tengamos muchos datos, no hemos de volcarlos en el paper, sino extraer su relevancia y discutir sus implicaciones. Si no, volvemos loco al lector, con datos que no le interesan.

En resumen, tenemos que escribir no para nosotros, si no para los lectores del paper, teniendo claro que queremos transmitirles.

The post Investigación en seguridad (VIII) – Papers, Lenguaje appeared first on S3lab.

]]>
http://s3lab.deusto.es/investigacion-en-seguridad-8/feed/ 0
console.log(blog 1095 days up) http://s3lab.deusto.es/blog-1095-days/ http://s3lab.deusto.es/blog-1095-days/#respond Fri, 31 Mar 2017 09:55:49 +0000 http://s3lab.deusto.es/?p=8974 Aunque parece que fue ayer cuando empezamos, ya han pasado 3 años. Hemos aprendido mucho durante este tiempo, y esperamos que vosotros tambien. Muchas gracias a todos los que habeis colaborado, y por supuesto, a todas esa personas que nos

The post console.log(blog 1095 days up) appeared first on S3lab.

]]>
Aunque parece que fue ayer cuando empezamos, ya han pasado 3 años. Hemos aprendido mucho durante este tiempo, y esperamos que vosotros tambien.

Muchas gracias a todos los que habeis colaborado, y por supuesto, a todas esa personas que nos leen semana tras semana. El año pasado dijimos que no habia dos sin tres, pero si seguimos el refran… tampoco hay tres sin cuatro.

PD:  Este post guarda el mismo secreto que los de años anteriores.

The post console.log(blog 1095 days up) appeared first on S3lab.

]]>
http://s3lab.deusto.es/blog-1095-days/feed/ 0