Nueva presentación descargable del IBM #START013

Ya tenemos disponible en nuestra sección de presentaciones la versión descargable de "La necesidad de construir software seguro" utilizada y preparada por nuestro compañero y socio co-fundador Vicente Aguilera en el evento más importante de IBM, el #START013.

Esta presentación trata de lo importante que es construir software seguro. Siempre debería haber sido una necesidad en cualquier proyecto de desarrollo y los requerimientos de seguridad deberían haber sido contemplados con la misma prioridad que los requerimientos funcionales.

Desgraciadamente, esto no ha sido la norma habitual. Aspectos como el "time to market" la inconsciencia o el desconocimiento en materia de seguridad por parte de los actores implicados ha propiciado que las aplicaciones se hayan convertido en el objetivo principal de los atacantes. Actualmente, parece que hemos adquirido consciencia de esta necesidad, en parte debido a la mayor dependiencia con el software y los riesgos derivados de su inseguridad.

Esto se ha traducido en una mayor diferencia entre aquel software diseñado con la seguridad en mente y aquel en el que la seguridad ha sido un añadido posterior o simplemente, ausente durante el ciclo de vida. La presentación también expone recursos de OWASP y cómo pueden ayudarnos para la consecución de nuestro objetivo: la creación de software seguro.

Jugando con los opcodes de Dalvik

Introducción

El objetivo de esta entrada es recoger a modo de borrador algunas notas que he ido tomando durante mi investigación con los opcodes de Dalvik, explicando algunas nociones básicas sobre el funcionamiento de los mismos.

¿Qué es Dalvik?

Extraído de la Wikipedia:
"Dalvik is the process virtual machine (VM) in Google’s Android operating system. It is the software that runs the apps on Android devices. Dalvik is thus an integral part of Android, which is typically used on mobile devices such as mobile phones and tablet computers as well as more recently on embedded devices such as smart TVs and media streamers. Programs are commonly written in Java and compiled to bytecode. They are then converted from Java Virtual Machine-compatible .class files to Dalvik-compatible .dex (Dalvik Executable) files before installation on a device. The compact Dalvik Executable format is designed to be suitable for systems that are constrained in terms of memory and processor speed."
Para información más detallada sobre cómo está diseñada la arquitectura y cuál es su funcionamiento interno, puedes leer el siguiente artículo [1].

Dalvik Bytecode

Instrucciones utilizadas para interactuar con la máquina virtual Dalvik. [2] [3] [4]

Formato de las instrucciones

Cada opcode de Dalvik está asociado a un formato de instrucción, encargado de moldear el comportamiento del mismo.
Dicho formato está compuesto por varias palabras (16 bits) separados por un espacio, donde cada carácter representa cuatro bits, leídos desde el bit más significativo al menos, utilizando el carácter “|” intercalado para facilitar su lectura.
De esta forma, encontramos:
  • Mayúsculas secuencialmente ordenadas identifican los campos dentro del formato.
  • El término “op” es utilizado para indicar la posición de un opcode de 8 bits
  • El símbolo “Ø” determinad que los bits restantes han de ser cero.


Pongamos un ejemplo

Para el formato "B|A|op CCCC":
  • Está compuesta por dos palabras de 16 bits cada una, siendo la primera "B|A|op" y la segunda "CCCC"
  • La primera palabra está compuesta por el opcode posicionado en los 8 bits menos significativos y un par de valores de cuatro bits localizados en los 8 bits más significativos.
  • La segunda palabra consiste en un único valor de 16 bits.
Un ejemplo es la instrucción "if-eq vA, vB, +CCCC" donde "vA" representa el primer registro a comprobar (4 bits), "vB" representa el segundo registro (4 bits), y "+CCCC" representa el desplazamiento a realizar (16 bits). Siendo su cometido el desplazarse a otra zona de la memoria, dada por el posicionamiento actual más el valor del offset, si el contenido de los dos registros son iguales.
Para el formato "ØØ|op"
  • Tenemos una única palabra de 16 bits.
  • Los 8 bits menos significativos están establecidos a 0.
  • Los restantes 8 bits, están reservados para el opcode
Asociado a instrucciones como "nop" o "return-void".
Para el formato "ØØ|op AAAA BBBB"
  • Está compuesto por tres palabras (16 bits/palabra), siendo la primera "ØØ|op", la segunda "AAAA", y la tercera "BBBB".
  • La primera palabra los 8 bits menos significativo están establecidos a 0, mientras que los más significativos almacenan el opcode
  • La segunda palabra almacena un único valor de 16 bits.
  • Otro valor único de 16 bits es almacenado en la tercera y última.
Un ejemplo de instrucción puede ser "move/16 vAAAA, vBBBB" donde se desplaza el contenido del registro "vBBBB" a "vAAAA".

A su vez, cada formato está asociado a un "short ID", compuesto normalmente por tres caracteres (salvo casos excepcionales), dos digitos y una letra. Donde el primer dígito simboliza el número de palabras que integran el formato, el segundo determina el número de registros que hay, o viene expresado por el carácter "r" que expresa el uso de un rango de registros dentro del formato , y por último el tercer carácter representado por una letra, es utilizado para inidicar cualquier tipo de dato extra codificado en el propio formato.

De estos podemos distinguir la siguiente tabla:
Imagen tomada de source.android.com
Utilicemos unos ejemplos, el short ID "12x" establece que se está utilizando una palabra de 16 bits, junto a dos registros de 4 bits cada uno y que no se está codificando ningún tipo de datos adicional "(x)", siendo por tanto "B|A|op" el formato especificado.

Para el short ID "22s", podemos discernir que se están utilizando dos palabras de 16 bits, dos registros, y como dato adicional, que se incluye un ‘signed short’ de 16 bits. En este caso estamos hablando de "B|A|op CCCC".

Por último, con la intención de orientar todo esto a una sintáxis más legible, se propone utilizar para cada instrucción una construcción mucho más sencilla. Donde se comienza utilizando el nombre de cada opcode, y una lista de parámetros aceptados por el mismo, utilizando el carácter "," como separador, teniendo en consideración los siguientes aspectos:

  • Todo argumento etiquetado en el formato, recibirá la misma etiqueta en la sintáxis. Para "AA|op BB|CC" su homólogo será "op vAA, vBB, vCC" (23x)
  • Aquellos registros que tengan la forma "vX", utilizando el prefijo "v" intencionadamente en lugar de "r", es para evitar conflictos con arquitecturas (no virtuales) de Dalvik que sí lo utilicen.
  • Los argumentos que indican un valor inmediato presentan la forma "#+X".
  • Aquellos que indican un desplazamiento relativo se muestran con "+X".
  • Los que muestran un "literal constant pool index", lo hacen utilizando "kind@X" donde "kind" señaliza qué "constant pool" es indicada, existiendo: "string" (string pool index) | "type" (type pool index) | "field" (field pool index | "meth" (meth pool index).
  • También es posible indicar "prelinked offsets" existiendo de dos tipos: "vtaboff" (vtable offsets). | "fieldoff" (field offsets).

Por último, en aquellos formatos cuyo "short ID" es "35c", "35ms” y “35mi
Poniendo como ejemplo, la sintáxis “op vAA, #+BBBB” cuyo ‘short ID’ es “21s” y su formato “AA|op BBBB“, a su vez también acepta otras construcciones como “op vAA, vBBBB” para el ‘short ID’ “22x” o “op vAA, +BBBB” para 21t.

Todas ellas tienen el mismo formato inicial (AA|op BBBB) a pesar de que su representación es distinta:
op vAA, vBBBB” en este caso vBBBB hace referencia a un registro.
op vAA, +BBBB” aquí BBBB representa el offset añadido a la posición base.
"op vAA, #+BBBB” es interpretado como un valor inmediato.


REFERENCIAS

Fuente: http://blog.seguesec.com
[1] The Dalvik Virtual Machine Architecture [Eng]
[2] Dalvik Opcodes.
[3] Dalvik VM Instruction Formats
[4] Bytecode for the Dalvik VM



Autor: Sebastián Guerrero
Departamento de Auditoría

Nuevo material descargable en nuestra sección de presentaciones

Publicadas en nuestra sección de presentaciones tres nuevos descargables sobre la Rooted Con celebrada en marzo de este año 2012, preparadas por nuestro compañero de auditoría Sebastián Guerrero que participó como ponente en el evento,  con la presentación “Pimp your Android” en la que se repasa la seguridad en plataformas Android. Donde se profundiza en aspectos como: análisis estático de aplicaciones, análisis dinámico, análisis forense, detección de malware, descubrimiento de vulnerabilidades 0-day y desmantelamiento de centros de control de botnets.

Y el Taller sobre Ingeniería Inversa, una sesión formativa que contiene material para obtener el conocimiento necesario para realizar ingeniería inversa sobre aplicaciones Android, ver cómo realizar peritaje forense y trabajar en local con la información de un dispositivo smartphone. Analizando varias muestras de malware y desarrollando una vulnerabilidad de tipo 0-day.

A demás otra de nuestras nuevas publicaciones, “Desarrollo de software seguro OpenSAMM” de nuestro compañero y co-fundador Vicente Aguilera. En el que se presenta OpenSAMM como iniciativa para ayudar a las organizaciones a diseñar e implementar una estrategia para la creación de software seguro. Los recursos facilitatos por OpenSAMM ayudan a evaluar las prácticas de seguridad existentes, demostrar mejoras concretas, definir y medir actividades relacionadas con la seguridad, así como construir un programa que garantice la seguridad en el desarrollo de software.

Nuevos artículos de prensa publicados

Ya tenemos en nuestra sección de prensa tres nuevos artículos publicados por dos de nuestros compañeros, "Usando la segmentación de red para reducir el alcance de PCI DSS" publicado en el número 101 de la revista SIC, de Marc Segarra, en el que se explica la importancia, desde el punto de vista de la simplificación del cumplimiento de PCI DSS como herramienta, la reducción del ámbito de afectación y aplicación del estándar siguiendo unas buenas prácticas y una correcta interpretación de los controles de la norma.

Y por otro lado, los artículos:
"Uso de tácticas de interrogación militar en una entrevista de auditoría" y "Primero en Responder (First Responder)" de David Eduardo Acosta. El primer artículo, publicado en la revista número 98 del Instituto de Auditores Internos nos presenta cómo pueden aplicarse técnicas de interrogación que han sido ampliamente desarrolladas en el ámbito militar enfocadas a la recolección de información útil, fiable y de la forma más rápida posible en entrevistas en una auditoría.

Lo que podemos encontrar en el segundo artículo, también publicado en la revista número 101 del Instituto de Auditores Internos, es la figura del primero en responder, como elemento clave para desencadenar todo el procedimiento de respuesta a incidentes en una organización y su papel fundamental en la gestión de la cadena de custodia.