Resumen de este año que toca a su fin 2012

Un año más acaba y toca hacer un balance de lo que ha sido el 2012.
Lo primero, es que si usted está leyendo esto, alguien ha cometido un gran error o los mayas con sus premoniciones o nosotros interpretando éstas.

Dejando de lado esta broma, que hay que decir que sólo puede hacerse cada 3000 años (y por eso la licencia), ya queda lejos la premonición local que dijo que la crisis sería cuestión de dos años "como máximo" (y esto se dijo el año 2009). Está claro que los analistas económicos deben emplear las mismas fórmulas que los mayas (o que los que leyeron las premoniciones mayas). Y es que el tsunami de la crisis, como el de la película de "Lo Imposible", está consiguiendo eso, lo imposible o, mejor dicho, lo inimaginable, hundiendo algunas economías hasta puntos donde nunca creíamos que se iba a llegar. Y que no se sabe todavía si hemos llegado.

Pero esta crisis ha demostrado que sólo la tecnología (el I+D) de James Cameron, con una vieja historia de Pocahontas, pero un gran 3D, ha superado la calidad, profesionalidad y saber hacer españoles, traducido en lo que ha recaudación se refiere.

¿A dónde se podríamos escalar si, de una vez, se apuesta por el I+D? Está claro que más lejos que donde las muletas de la crisis nos permiten.

Dejando el mundo del cine a un lado, el mundo de la Seguridad TIC ha tenido mucho más de lo mismo y también algo novedoso. Casi siempre recordamos, en estos epílogos anuales lo malo. Sobre todo porque en cuanto a seguridad tecnológica se refiere, siempre es lo malo lo que más páginas (o bytes) ocupa en cualquier medio de difusión. Y más en un país dónde con tanta ligereza, los problemas son siempre "por problemas informáticos".

Está claro que un año en el que hemos visto cambiar (o intentando cambiar) el mundo más cercano más allá de nuestro pequeño Mediterráneo, o hemos visto matanzas incomprensibles en cines, colegios y calles (en EEUU y también en las olvidas Siria, Congo, etc.), pensar que el señor McAfee (padre de uno de los más legendarios antivirus, convertido en un emporio de la Seguridad que Intel compró por casi 6.000 millones de dólares) fuera portada por matar a su vecino en su retiro paradisíaco en Belice, nos ha resultado hasta cómico.

Pero muchas cosas han pasado el 2012, relacionadas con la libertad en Internet, o con su regulación, con la Ley SOPA en EEUU, con la protección y persecución de aquellos que se lucran con las creaciones de otros (en Internet y en la SGAE, ahora reinventada) en España con lo que fue la Ley Sinde. No se puede dejar de mencionar Wikileaks, la detención de Julian Assange (autorecluido en Londres en la embajada de Ecuador), y todas las campañas (ataques) que han llevado a cabo Anonymous, con un lema tan inquietante para algunos o motivador para otros que reza "Somos Anonymous. Somos Legión. No perdonamos. No olvidamos. Espéranos." sembrando la intranquilidad entre estados, organismos y empresas que se han visto observadas más que nunca por este tipo de movimientos a los que se les ha puesto cara: una máscara copyright de Time Warner, el segundo mayor conglomerado de medios contra los que esos mismos movimientos "luchan". Contradicciones de la vida.

También ha sido el año de vulnerabilidades sonadas en Instagram, que además en diciembre quiso vender "sus" fotos (o no); ha sido el año en el que tu teléfono Android podía dejarse "frito" por una vulnerabilidad en el incorrecto tratamiento de mensajes USSD (esos típicos *#0129# con los que nuestro operador nos da servicios casi desconocidos); WhatsApp ha sido objeto de análisis profundos y hemos sido conscientes de su inseguridad; el siguiente objetivo será Line (por que el objeto de deseo de todo investigador es "el más usado"). El 2012 se siguió hablando de Samsung por sus litigios (contra Apple), sus móviles, sus tabletas y sus impresoras, que incluían una vulnerabilidad que permitía un acceso a la red explotando una vulnerabilidad y un defecto vía SNMP.

El 2012 también fue año de Juegos Olímpicos, en Londres, y el phising tuvo una excusa más de difusión. Y es que el malware ha dado un poco más de lo mismo (seguimos hablando de Zeus), usando métodos conocidos de Ingeniería Social pero poniendo "el ojo de Sauron" en los dispositivos móviles (con Android e iOS principalmente) como el mejor método de obtener la preciada información del usuario de a pie. Este también ha sido el año en el que la mayor economía del mundo recelaba de su mayor fábrica y recomendaba (o prohibía) el uso de sistemas de comunicaciones de los grandes fabricantes chinos Huawei y ZTE.

Sonados fueron incidentes en Zappos (moda y complementos de EEUU) donde 24MM de datos de usuarios quedaron comprometidos, Care2 (productos de alimentación saludables) con casi 18MM, LinkedId pedía el reseteo a sus usuarios tras comprometerse sólo 6MM de contraseñas, Barnes & Noble Stores sufría un ataque a través de sus puntos de venta y Global Payments en Canadá sufría una intrusión que comprometía 1,5 MM (aunque posteriormente se publicó que fueron 7MM). Y la lista es muy larga. Y lo ha sido mucho más (del doble al cuádruple según las fuentes) el 2012 respecto el 2011. Por lo que nadie puede mirar a quien ha sufrido un incidente creyendo que, como las enfermedades raras, siempre le tocan a otro.

Si un año se ha hablado de la nuevas amenazas ha sido el 2012, los APTs parece que se han descubierto ahora (que no), pero sí se ha hablado de ellos más que nunca, cuando el BYOD muy posiblemente sea la gran amenaza de las empresas, que siguen sufriendo robos de información por problemas conocidos desde hace 10 años, el archiconocido SQL Injection. Eso sí es una amenaza y no el mosquito del Nilo, que atemorizó también a los estadounidenses este año con 65 muertes. Donde 26 mueren al día por armas de fuego y donde el director de la mayor agencia de investigación del mundo es espiado por su amante leyendo el correo electrónico. Tendría su password, ¿no?
En diciembre hemos conocido que la UE está estudiando exigir la regulación a los estados miembros que los incidentes significativos de seguridad relacionados con las tecnologías de la información (probablemente aquellos que afecten a infraestructuras críticas inicialmente) o quién sabe si todos ellos, deban hacerse públicos. Algo que en EEUU ya es ley y que aquí nos parece absurdo. Tampoco creamos que todo el monte es orégano: 4 estados no tienen legislación al respecto, 35 (incluyendo D.C.) la tienen sin un registro centralizado y 12 la tienen y centralizan la información. Probablemente de la misma forma, la publicación de vulnerabilidades en EEUU es algo que los fabricantes ven con buenos ojos -cuando se lleva a cabo de forma coordinada con el investigador descubridor- y, en España, sólo se ve como un daño a la imagen de la empresa fabricante, sea una red social, un CMS o un ERP. Y sabemos muy bien de lo que hablamos. Queda un camino largo por recorrer en este aspecto.

En España hemos tenido congresos y encuentros del mundo de la Seguridad TIC donde se ha podido disfrutar de expertos de España, que nada tienen que envidiar a los de fuera, y no podemos dejar de mencionar la No cON Name (con nuestro recuerdo a los que ya no están) y la Rooted Con; y con otros enfoques, eventos relevantes del ISMS Forum, la prensa especialista del sector (SIC y Red Seguridad), eventos de itSMF, ISACA, etc.

En cuanto a lo que en Seguridad en Tecnologías de la Información y la Comunicación se refiere, podemos decir que el 2012 ha generado noticias y material para escribir y eso no es malo, demuestra que hay trabajo por hacer y que es uno de los sectores que, a pesar de la crisis, se ha visto como imprescindible en una época como esta, como espada, como escudo o como pluma. Sólo podemos esperar que el 2013 (que aunque con dos dígitos muy gafes) veamos que el sector de la Seguridad TIC tenga la consideración estratégica que debe tener. La otra cuestión será que tengamos la capacidad económica para situarlo donde ha de estar. Esperamos que así sea, por la parte que nos toca.
*___Feliz 2013___*


Autor: Daniel Fernández - CISM, CISA, CISSP, ISO27001 Lead Auditor, CHFI, CEI, OPST/A
Departamento Comercial

Seguridad en Sistemas de Ficheros en BSD

Por lo general, los sistemas derivados de BSD4.4 usan la implementación de Fast File System (FFS - algunas veces llamado también UFS Unix File System) como método de gestión de sistemas de ficheros. Dependiendo del sistema operativo, se hacen algunas mejoras orientadas hacia optimización de almacenamiento, rendimiento e interacción con discos, pero el concepto en BSD sigue siendo homogéneo. Por otro lado, para sistemas de ficheros de gran tamaño, se cuenta con la implementación de FFS2 (actualmente no soportada para particiones del sistema).

FFS fue diseñado para ser rápido y confiable. Divide los ficheros en dos grupos: Bloques ("blocks") y Fragmentos ("Fragments"), siendo los bloques grandes pedazos de datos, mientras que los fragmentos son pedazos más pequeños. Un fichero esté compuesto de muchos bloques y usa fragmentos para almacenar restos pequeños de información. A medida que el fichero crece, el sistema le asigna bloques adicionales. En este órden de ideas, los ínodos contienen información básica del fichero ("metadata") incluyendo datos de ubicación de bloques y fragmentos, permisos, fechas y tamaños.
Para compatibilidad con sistemas Windows, existen implementaciones de drivers para permitir acceso de lectura a particiones de tipo FFS, como es el caso del proyecto "FFS File System driver for Windows" http://ffsdrv.sourceforge.net/index.php

Al igual que en la mayoría de sistemas de ficheros actuales, FFS incorpora múltiples variables de seguridad, como se discute a continuación:

Opciones de Montaje de FFS/UFS
En FFS/UFS se usan los siguientes métodos de montaje, que pueden garantizar unos niveles adicionales de integridad, disponibilidad y confidencialidad en la información almacenada:

Read-Only:
Empleando esta configuración, un administrador puede montar un sistema de ficheros en modo de lectura únicamente, previniendo potenciales cambios, eliminación o reemplazo de ficheros.

Noexec, Nosuid y Nodev:
Al igual que el anterior, estos parámetros evitan el uso de ciertas características, restringiendo el ámbito de un potencial ataque. Noexec previene que ficheros ejecutables sean "ejecutados". Esto incluye scripts y binarios, pero no previene que un script sea interpretado desde la shell actual con el prefijo ".". Nosuid previene la ejecución de ficheros que tengan activado el flag SUID, mientras que Nodev previene que un fichero de dispositivo sea reconocido.

Soft Updates (o SoftDep):
Mediante esta característica, se pretende mantener una integridad en los datos almacenados en disco después de un apagado intempestivo o cortes de energía electríca. Es una alternativa al "journaling", ya que no emplea un log auxiliar (journal) para almacenar operaciones con metadatos sino que "ordena" parcialmente la escritura para asegurar la consistencia de metadatos y gestionando dependencias, optimizando el desempeño del disco. En implementaciones particulares, Sun Solaris combina Journaling con UFS en UFS Logging, disponiendo de ambas características para optimizar la consistencia en los datos. En sistemas BSD, Soft Updates no viene habilitado por defecto, por compatibilidad con arquitecturas antiguas.

No access Time
FFS registra la última vez que un fichero fue accedido para ejecución, lectura o escritura. Estas actualizaciones consumen una pequeña cantidad de tiempo y desempeño de disco que en gran medida pueden ser considerables. Montando la partición como "noatime" se puede ahorrar este tiempo.

File System Flags

Como complemento a las opciones de montaje, los sistemas BSD bajo FFS/UFS permiten aplicar una serie de restricciones adicionales de permisos sobre los ficheros, permitiéndole al administrador proteger ficheros clave de accesos o modificaciones no autorizadas o corrupción mediante el comando "chflags". Estas características a nivel de filesystem permiten definir controles de acceso (ACL) granulares más allá de los permisos normales de otros sistemas Unix. Esto se hace mediante el uso de "flags" o parámetros, dentro de los cuales se destacan:

System Change flag (schg)
Este flag previene que los ficheros sean movidos, cambiados o eliminados (inmutabilidad). Solamente puede ser habilitado por root y no puede ser removido si el sistema se encuentra ejecutándose en SecureLevel 1 o superior.

User Change flag (uchg)
Este flag actúa igual que el anterior, salvo que el dueño del fichero y root pueden habilitarlo o deshabilitarlo.

System append-only flag (sappnd)
Este flag previene que los ficheros sean modificados, de forma muy similar a como lo hace el flag immutable, con la única excepción que los datos pueden ser añadidos al final del fichero. Esta característica es útil en ambientes de gestión de ficheros de registro (logs) o en ficheros .history, en los cuales se quiere que se añada información pero que no se modifiquen los datos que estaban previamente. Es importante tener en cuenta que cuando se aplica este flag, el fichero no puede ser eliminado.

User append-only flag (uappnd)
Igual que el anterior, con la única diferencia que éste flag puede ser deshabilitado por el dueño del fichero o por root en cualquier momento, sin importar el securelevel en el que esté el sistema. Esta característica es útil cuando se quiere permitir que los usuarios puedan usar este nivel de protección en sus propios ficheros.

System no unlink flag (sunlnk)
Este flag previene la eliminación de un fichero y únicamente puede ser habilitado por root cuando el security level es superior a 0.

User no unlink flag (uunlnk)
Este flag le permite a un usuario indicarle al sistema que un fichero no debe ser eliminado, independientemente de sus permisos Unix tradicionales o los permisos de su directorio padre. Puede ser habilitado/deshabilitado por el usuario o por root.

Archived flag (arch)
Este flag permite que programas de backup o respaldo (dump, por ejemplo) ignoren determinados ficheros. Útil cuando se quiere evitar el almacenamiento de ficheros clave en otros lugares. Actualmente sólo se eucnetra activado por compatibilidad.

No Dump Flag (nodump)
Igual que el anterior. Es el flag actual a ser empleado.
Es importante tener en cuenta que mediante la utilidad "find" es posible hacer búsquedas de ficheros con base en los flags de los ficheros, lo cual le puede facilitar la vida a un administrador.

Sysctl y Kernel Security Levels

Una característica importante de los kernels BSD es que permiten la alteración de variables en el kernel durante la ejecución. Esto es necesario en la administración diaria de aplicativos, gestión de conexiones y buffers y seguridad del sistema. Para esta gestión se emplea el comando "sysctl". La variable sysctl más importante es kern.securelevel. El valor que tenga dicha variable en el sistema define los comportamientos generales de determinadas funciones y características posterior al inicio del sistema operativo (boot process):

kern.securelevel=-1 (Permanentemente inseguro):
Bajo este nivel, el sistema se comporta como un Unix tradicional en modo multiusuario, permitiendo al usuario root hacer cualquier operación. Todos los flags del filesystem pueden ser habilitados y deshabilitados, todos los dispositivos pueden ser leídos y escritos conforme con sus permisos normales, las reglas de filtrado pueden ser modificadas y el relój del sistema puede ser cambiado. Por lo general, éste securelevel es empleado en actividades de mantenimiento y/o depuración del sistema y nunca es recomendado para producción.

kern.securelevel=0 (Transicional):
Igual comportamiento que el anterior y empleado temporalmente cuando el sistema está en proceso de boot e ingresa en modo monousuario.

kern.securelevel=1 (Seguridad operativa mejorada):
En este nivel, el kernel aplica las restricciones tradicionales de sistemas Unix, habilita los flags "immutable" y "append-only" en los filesystems, bloquea la escritura en /dev/mem y /dev/kmem y evita el cargue/descargue de módulos y drivers.

kern.securelevel=2 (Alta Seguridad):
En este nivel se activan las protecciones de niveles anteriores y se agregan otras restricciones, como evitar la creación o modificación de tamaño de filesystems, permite el acceso a dispositivos de red y de cinta solamente a procesos con privilegios de root, no permite los cambios de relój en el sistema, evita que las reglas de filtrado y NAT sean cambiadas y evita que las variables de depuración de kernel (DDB) sean cambiadas.

En sistemas como FreeBSD, existe el securelevel 3, que por lo general tiene las mismas funcionalidades del securelevel 2 pero evitando la modificación de reglas de filtrado.

Se puede cambiar de un nivel inferior a uno superior mediante el cambio de variable con sysctl, pero no se puede cambiar de un nivel superior a uno inferior sin reiniciar el sistema.

A pesar de los controles implementados en los securelevels, es importante tener en cuenta que las configuraciones de securelevels son implementadas posterior al proceso de inicio del sistema (boot process). Por lo tanto, si un atacante logra tener acceso antes que el securelevel sea activado, sus protecciones serán inválidas.

Encriptación de Memoria Virtual (SWAP)

Después de aplicar controles de confidencialidad en filesystems mediante técnicas criptográficas, aún queda una ubicación vulnerable: la memoria virtual. Después que un proceso autorizado a accedido a datos encriptados en un filesystem cifrado, dichos datos aparecen temporalmente en texto plano en la memoria virtual hasta que el sistema es apagado (e incluso, pudiendo dejar rastros aún después). Para ello, se emplea la encriptación/desencriptación de páginas (pages) que necesitan ser intercambiadas (swapped). En este sentido, sistemas operativos como OpenBSD permiten el uso de particiones swap cifradas por defecto y se permite habilitar o deshabilitar esta característica mediante "sysctl" con el uso de la variable vm.swapencrypt.enable.



Autor: David Eduardo Acosta - CISSP, CISA, CISM, PCI QSA, CCNA Security, OPST, CHFI Instructor, BS25999 Lead
Departamento Consultoría

El Gobierno estudia pedir el DNI a menores para su acceso a redes sociales

La problemática del acceso de los menores a las redes sociales podría tener solución a corto plazo, actualmente se está estudiando la posibilidad de establecer el uso del DNIe como medio de comprobación de la edad.

Debemos recordar los informes que la Agencia de Protección de Datos ha emitido sobre el tratamiento de datos de menores, según los cuales:
…los mayores de catorce años disponen de las condiciones de madurez precisas para consentir, por sí mismo, el tratamiento automatizado de sus datos de carácter personal”.
Caso distinto es el de los menores de catorce años  donde  se requiere el consentimiento de sus tutores o representantes legales.

El menor de catorce años, no reúne  las  condiciones de madurez “suficientes” descritas en el Código Civil, y por tanto no dispone de la capacidad de obrar, para la celebración de determinados  actos civiles como pueda ser otorgar su consentimiento.

Según lo anteriormente expuesto, un mayor de catorce año si está en disposición de ejercer determinados actos, como la aceptación de condiciones de uso en una red social, ¿dónde surge entonces el problema?, en la carga que se impone a la persona que recaba el dato para la comprobación efectiva de la edad.

Quienes deseen hacer un tratamiento de datos de un mayor de catorce años, debe facilitar en un lenguaje fácilmente comprensible para el menor la información de los contenidos del art 5.1 de la LOPD.

Los interesados a los que se soliciten datos personales deberán ser previamente informados de modo expreso, preciso e inequívoco:
a. De la existencia de un fichero o tratamiento de datos de carácter personal, de la finalidad de la recogida de éstos y de los destinatarios de la información.
b. Del carácter obligatorio o facultativo de su respuesta a las preguntas que les sean planteadas.
c. De las consecuencias de la obtención de los datos o de la negativa a suministrarlos.
d. De la posibilidad de ejercitar los derechos de acceso, rectificación, cancelación y oposición.
e. De la identidad y dirección del responsable del tratamiento o, en su caso, de su representante.
"
Para los responsables de las redes sociales frecuentadas por menores, la traba no es dar cumplimiento al derecho de información, sino implantar un medio válido que permita la comprobación de que dicho menor es mayor de catorce años y por tanto, puede consentir por si mismo en el tratamiento de sus datos, garantizando de esta forma la protección jurídica exigida por la LOPD. 
 
La actual Declaración de Prácticas de Certificación del DNI electrónico, establece que los certificados electrónicos pueden utilizarse como medio de Autenticación de la Identidad.
Por eso el Gobierno, a propuesta de la Agencia de Protección de Datos (AEPD), estudia la posibilidad de incorporar al DNI electrónico de los menores, el certificado de autenticación, permitiendo de esta forma la verificación de su edad.

Así, el titular (menor) del DNI electrónico podrá, a través del certificado, acreditar su identidad frente a cualquiera, al encontrarse en posesión del certificado de identidad y de la clave privada asociada al mismo, dándole a conocer como “firmante” autorizado.

La propuesta realizada por la AEPD que ha sido acogida por el Ejecutivo favorablemente y actualmente se encuentra en fase de estudio.


Referencias

 www.madrid2noticias.com


Autor: María del Carmen Areces
Departamento Comercial

 

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.

Un paso más contra el fraude en Internet

Visa Europa está solicitando a todos las Entidades Adquirentes -Acquirer- que informen a los comercios -Merchants-  de la necesidad de utilizar Merchant Agents que estén debidamente registrados en su web:
www.visamerchantagents.com

Casi todos ya nos habíamos hecho a la idea de las listas públicas en PDF de Visa, Visa europe y Mastercard (en la web de Visa recientemente migrada a una web 2.0). En sus webs aparecen los proveedores de servicio que han superado auditorías por parte de un QSA pero, ciertamente, son pocos los que conocen o han sido informados por las entidades bancarias o las propias marcas de la existencia y necesidad de gestionar el alta en el portal de Visa Merchant Agents.
Por ello, desde Internet Security Auditors queremos ofreceros una pequeña guía sobre qué pasos hay que seguir para poder conseguirlo.

¿Qué es un MERCHANT AGENTS?

Merchant Agent es aquel a quien un comercio o un minorista, contrate la prestación de servicios que impliquen el procesamiento, el almacenamiento o la transmisión de datos de tarjetas de crédito (directa o indirectamente).

¿Cuánto tiempo tengo para registrarme la web de Visa Europa?

La fecha, a partir de la que será obligatorio ser un Merchant Agent registrado por VISA Europe en dicha web, es el 31 de diciembre de 2012.

¿Qué debe hacer un Merchant Agent?

Registrarse en la web de Visa, para lo cual deberá ir facilitando una serie de datos, a través de los pasos que indicamos a continuación:

Paso 1 -
Al iniciar el registro se solicita:
  • Nombre de la empresa.
  • URL.
  • Persona de Contacto.
  • VAT  y número de registro de la empresa.
Paso 2 -
Aceptación del Acuerdo Legal:
  • Se le pedirá que confirme si captura, almacena o transmite datos de tarjeta Visa o si tiene una obligación contractual de hacerlo.
  • También le pedirán que lea y  acepte los términos y condiciones para registrarse y ser catalogado como Merchant Agent.
Paso 3 -
Información de la empresa, debe proporcionar:
  • Una breve descripción de la empresa:
  • Propietario o propietarios.
  • Número de empleados.
  • Áreas geográficas y sectores industriales que opera.
  • El ámbito de aceptación de pago en el que proporciona servicios (por ejemplo, Face-to-face, internet, MOTO, etc.).
  • Nombres y / o URL de cualquier comercio para los que liquide fondos si usted lo hace en nombre del banco adquirente.
  • Si opera en el ámbito de comercio electrónico, que solución de pago integrada ofrece a sus clientes (por ejemplo plena, re direccionamiento a una página  de pago o una API).
  • Si usted proporciona productos o servicios  de seguridad/riesgo a sus clientes.
  • Cuántas transacciones se almacenan, transmiten o procesan anualmente.
  • A cuantos Merchants presta servicios.
Paso 4 -
Información de cumplimiento de PCI DSS:
Si almacena, procesa o transmite números de cuenta Visa, tendrá  que demostrar que cumple con la Payment Card Industry Data Security Standard (PCI-DSS).
Debemos diferenciar dos situaciones:
  1. Si procesa más de 300.000 transacciones al año, necesitará que externamente un QSA haya  evaluado el cumplimiento PCI DSS y aportar copias escaneadas en formato PDF de estos documentos:
    • Formulario de Alcance de Auditoría -  que es un resumen de los detalles sobre el  entorno de pago pagos que ha sido evaluado como PCI DSS y cuáles no.
    • Un escaneo trimestral realizado por un (ASV).
    • Su Declaración de cumplimiento (AOC).
    • El nombre y datos de contacto del QSA que utilizó para validar el cumplimiento.
  2. Si procesa menos de 300.000 transacciones al año, puede autoevaluar su entorno de servicio o utilizar un QSA que lo haga por el. La documentación que tendrá que aportar en este caso será:
    • Cuestionario de Autoevaluación (SAQ) y la fecha en que se presentó al Acquirer. El  SAQ debe confirmar que tiene medidas de seguridad para reducir al mínimo los riesgos identificados por la norma.
    • Un escaneo trimestral realizado por un (ASV).
    • Su Declaración de cumplimiento (AOC).
Una vez aportada vía web esa documentación, se recibe en el plazo de dos días hábiles un acuse de la recepción de la misma.

Visa Europa revisará los archivos remitidos y efectuará una verificación de alto nivel de los documentos.

Cuando se comprueba que todo es correcto, Visa Europa  informa de la cuota exacta de inscripción inicial y proporciona los detalles sobre la forma de pago.

En 2012, la cuota de inscripción inicial podría no aplicarse a algunos Merchant Agent, (discrecional de VISA),  pero en todo caso  no será superior a  5.000 € (IVA no incluido) para los que sí tienen que abonarla.

Este proceso de registro debe efectuarse de manera anual, se paga una cuota de inscripción inicial el primer año y una cuota en años sucesivos, que será la mitad del importe de la cuota de inscripción inicial.

Paso 5 - Publicación en las listas
Una vez revisada la documentación y efectuado el pago de la cuota, VISA Europa publicará al nuevo Merchant Agent en su web:
http://www.visamerchantagentslist.com/

Visa Europa se reserva el derecho de rechazar la inscripción de un Merchant Agent si:
  • Hay una sospecha razonable de que el agente ha participado en una actividad que infrinja la ley, o que pudiera dañar la reputación de la marca Visa, o  por ser una amenaza potencial a la integridad y seguridad del Sistema de Visa.
  • También si se proporcionan datos insuficientes o incompletos.
  • Los documentos remitidos no estén al día.
Para cualquier consulta sobre el proceso de registro que no sea de carácter técnico puede contactarse con Visa en el correo agentcompliance@visa.com.

Para consultas técnicas puede utilizar support@visamerchantagents.com.

Para cualquier consulta sobre servicios relacionados con el cumplimiento de las normas PCI DSS y PA-DSS, contacte con nosotros en pcidss@isecauditors.com

Os adelantamos las novedades sobre la No cON Name 2012

Cómo ya hemos mencionado en entradas anteriores, este año volvemos a participar en el evento más esperado del año por expertos, profesionales en el campo de la informática en general, redes telemáticas, programación o ingeniería de protección de software.

Pero a parte de participar como patrocinadores del evento, este año impartiremos talleres y realizaremos los ya clásicos concursos del congreso:

Hemos preparado un Wargame organizado como una serie de retos de exploiting que los participantes al concurso tendrán que solucionar aplicando sus conocimientos de hacking, reversing, etc.

El concurso presenta un reto principal de análisis de dispositivos móviles junto a algunos retos satélite que deben descubrirse. No existe un único objetivo en el juego, por lo que cualquier puntualización o hallazgo será valorado por el jurado. Los participantes deberán demostrar que disponen de los conocimientos suficientes sobre el funcionamiento de diversos aspectos como la ingeniería inversa, el análisis de comunicaciones o criptografía.

Realizaremos un Quiz, en el que podrán participar los asistentes al congreso, donde podrán demostrar sus conocimientos en seguridad, desarrollo, tecnologías móviles, etc. al más puro estilo de un millón para el mejor, pero sin millón. Eso sí, el reconocimiento de saberse el más sabio en Seguridad TIC.

Vicente Aguilera en el mayor evento de IBM Software en España

Vicente Aguilera, chapter leader del capítulo español de la OWASP, ha sido invitado a participar en el mayor evento de IBM alrededor de las tecnologías y productos software de este gran fabricante americano.

Vicente presentará las actividades principales de la OWASP en cuanto a la seguridad en el desarrollo de software, qué consideraciones sigue siendo necesario tener presente para conseguir que el software desarrollado sea seguro y las mejores prácticas y herramientas que la OWASP provee a los desarrolladores.

El IBM Software Summit, #START013, se celebrará el 6 de noviembre de 2012 en el Palacio Municipal de Congresos de Madrid.
Más información en IBM Software Summit #Start013

Cursos y concursos en la No cON Name 2012

De nuevo, desde sus inicios, Internet Security Auditors colaborará como sponsor y participando activamente en No cON Name 2012 del 31 de octubre al 3 de Noviembre en el CosmoCaixa de Barcelona.

Sebastián Guerrero impartirá un taller bajo el título "Desmitificando Android" sobre seguridad, reversing y análisis de malware y aplicaciones en sistemas Android. También, de nuevo este año, hemos preparado un concurso en el que todo aquel que quiera participar podrá intentar superar todos los niveles basados en retos donde probar sus conocimientos de hacking, reversing y muchas cosas más. Y en el Quiz, los concursantes que crean saber más sobre seguridad, desarrollo, tecnologías móviles, etc. podrán buscar "la gloria" de la sabiduría.

Encontrarás toda la información en la web del congreso y, si no lo has hecho todavía, inscríbete ya en No cON Name 2012.