Analytics

lunes, 31 de diciembre de 2012

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

lunes, 10 de diciembre de 2012

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

martes, 4 de diciembre de 2012

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