La máscara no es una resta

(N.d.E.: Interrumpimos la programación habitual de la Black Hat para hablar de máscaras en su sentido menos erótico festivo. No obstante, que reine la calma, ya que mañana continuaremos con el día 2 de la BH a cargo de Roberto)

Como ustedes saben, los permisos en las máquinas Unix/Linux se dividen en tres dominios: usuario, grupo y otros. A cada uno de estos dominios se le puede aplicar tres permisos: ejecución (x o 1), escritura (w o 2) y lectura (r o 4). Cuando un usuario en Linux crea un fichero o un directorio, éstos deben tener unos permisos. Estos permisos por defecto se establecen mediante una máscara. Hasta aquí, nada nuevo bajo el sol.

El comando para listar los permisos por defecto, la máscara, es umask:

$ umask
0022
$ mkdir directorio
$ touch fichero
$ ls -l
total 4
drwxr-xr-x 2 moxilo moxilo 4096 2010-04-15 00:07 directorio
-rw-r--r-- 1 moxilo moxilo    0 2010-04-15 00:07 fichero

Como ven, para un directorio los permisos por defectos son 755, y para el fichero 644. Estos permisos por defecto son establecidos por la máscara del usuario, en nuestro caso 0022. Para nuestro ejemplo tomamos los tres últimos números (022). Pero, ¿por qué 022? Pese a que tradicionalmente se ha creído que estos permisos se obtienen por la resta del valor 777 menos la máscara en el caso de los directorios, y de 666 menos la máscara para los ficheros, ésta es una conclusión errónea. Lo que realmente ocurre no es la operación resta, sino la operación AND de la negación de la máscara.

En el caso de los directorios la operación es 777 (111 111 111) AND ~(valor mascara en binario), y para los ficheros es igual pero con 666. Veámoslo con un ejemplo:

1º) Dada una mascara con valor 136, su representación en binario es 001 011 110.
2º) La negación de la mascara es el valor 110 100 001.
3º) Para calcular los permisos de los directorios, se realiza la operación AND entre 777 y la negación de la mascara: 111 111 111 AND 110 100 001 dando como resultado 110 100 001, es decir 641.
4º) Para el caso de los ficheros sería la operación AND entre 666 y la negación de la mascara: 110 110 110 AND 110 100 001, dando como resultado 110 100 000, es decir 640.

Si hubiéramos hecho la operación resta para directorios, veríamos que: 777 – 136 = 641, es decir el mismo que con la operación “AND ~(Mascara)”. En cambio, esto no sucede así con los ficheros, ya que 666 – 136 = 530, cuando su valor real es 640.

Por tanto, en caso de los ficheros, una máscara cuyo valor sea 136 estaría dando por defecto permisos de lectura y escritura al usuario (6), de lectura al grupo (4) y ninguno a otros (0). Pero no permisos de lectura y ejecución (5) al usuario y permiso de escritura y ejecución al grupo (3) que es el valor que obtendríamos si restáramos.

$ umask 0136
$ umask
0136
$ mkdir directorio
$ touch fichero
$ ls -l
total 4
drw-r----x 2 moxilo moxilo 4096 2010-04-21 22:09 directorio
-rw-r----- 1 moxilo moxilo    0 2010-04-21 22:10 fichero

Por tanto, recuerden que el método de la resta sirve únicamente para los directorios, pero no así para los ficheros. Es por ello que debemos tener precaución cuando realicemos una modificación sobre la máscara; mi recomendación, si me lo permiten, sería cambiar la mascara a 0027.

Black Hat Europa, 2 day briefings

En su segundo día, la Black Hat Europa comenzó con la presentación de Thai Duong y Juliano Rizzo sobre Crypto ataques a aplicaciones web. Su investigación se ha dirigido a cryptoanalizar el modo de cifrado por bloque Cipher-Block Chaining. CBC fue inventado por IBM en 1976. En este cifrado, a cada bloque de texto plano se le aplica una operación XOR con el resultado del bloque anterior. De esta manera el resultado de un módulo es dependiente de los anteriores, excepto para el primero que se utiliza un vector de inicialización IV. La siguiente imagen es muy ilustrativa:

El tamaño de bloque suele ser de 8 bytes con un cifrado DES/triple DES o 16 bytes para AES. Por lo que respecta a la clave de cifrado se utiliza 56 bits para DES, 168 bits para triple DES y 128, 192 o 256 para AES. Pero, ¿qué ocurre si el último bloque de texto plano no es del tamaño requerido? Pues que es completado con información arbitraria, normalmente 0’s por seguridad. Esta última afirmación es justamente una de las debilidades del sistema.

Thai Duong y Juliano Rizzo presentaron el ataque Padding Oracle, el cual requiere que el atacante pueda interceptar mensajes con padding y a su vez tenga acceso al sistema que lo comprueba a modo de oráculo. El proceso que un atacante podría realizar para comprobar si el rellenado de bits es correcto es el siguiente:

  • Se remite la cadena cifrada al oráculo.
  • El oráculo mediante la clave de cifrado comprueba si es correcto el padding
  • El oráculo contestará al atacante con un 0 si es incorrecto o un 1 si es correcto.

Si el lector quiere ampliar conocimientos en cuanto al proceso completo recuperación de la trama de bytes original puede consultar su paper, disponible online.

Como caso práctico de implementación del ataque, Thai y Juliano presentaron la rotura de un captcha que utiliza este modo de cifrado. El sistema utiliza CBC para albergar el texto detrás de la imagen difuminada, lo que han denominado ERC.

<img src=”/captha?token=ERC”/>

El ERC se guarda en un campo oculto del formulario o en una cookie. Cuando el usuario remite el código introducido por teclado, el servidor compara la cadena con el resultado de descifrar el ERC. Si son iguales el resultado del captcha es correcto. De esta forma el servidor que recibe el ERC es susceptible a ataques de Padding Oracle siempre y cuando respondan ante rellenados de bits incorrectos. En la mayoría de sistemas, cuando se modifica el ERC y el rellenado es correcto el servidor devuelve una imagen con un código difuso, pero el problema viene cuando el servidor ha inicializado el IV con información aleatoria dificultando la obtención de P0. Para solventarlo, Thai y Juliano proponen obtener P0 y el IV de una imagen introducida por un usuario normal.

Otros sistemas que utilizan CBC e identificados por los autores del ataque, son las View States de JavaServer Faces. Nuevamente, un 10 para estos chicos.

Black Hat Europa 1 day briefings (IV)

La BH Europa, en general nos ha dejado muy buen sabor de boca, aunque no todo fueron peritas en dulce. La única nota negativa la trajo James Arlen, que a través de un seductor titulo SCADA and ICS for Security Experts tuvo a la audiencia expectante, esperando las últimas novedades sobre seguridad SCADA. Nada mas allá de la realidad, detrás de un gran orador —todo hay que reconocerlo— la conferencia no aportó novedad alguna, vertiente técnica, o aplicación interesante.

Por el contrario, Manish Saindane de Attack and Defense Labs acudió con una propuesta sobre como atacar aplicaciones que utilizan objetos serializados en Java. Manish ha desarrollado un plugin para Burp que permite al Pentester editar objetos Java on the fly. La serialización de objetos Java es un protocolo implementado por Sun para convertir objetos en tramas de bytes, con el objetivo de guardarlos en disco o transmitirlos por la red. Este flujo de datos contiene la suficiente información para reconstruir el objeto original. A título informativo, la clase que puede instanciar objetos de este tipo son ObjectOutputStream y ObjectInputStream, cuyos métodos serializables son: readObject(), writeObject().

Cuando un objeto serializado es transmitido por la red se puede identificar por su cabecera con los bytes 0xac 0xed, aunque es posible que viaje comprimido en formato zip. Si el objeto es de tipo String, por ejemplo, éste vendrá codificado en UTF-8 modificado. El ataque funciona de la siguiente manera:

[Read more…]

Black Hat Europa 1 day briefings (III)

Continuando con la crónica de la BH Europa que estamos realizando estos días, en la cuarta exposición Paul Stone de Context (empresa de seguridad del Reino Unido) vino con una propuesta muy interesante sobre nuevas técnicas de ClickHacking, presentándonos una nueva herramienta que permite implementar este tipo de ataques. Destacar que ésta se puede descargar y juguetear con ella.

El ClickHacking es un término relativamente nuevo (sobre 2 años), que básicamente consiste en hacer que el usuario pinche (clickee) en cierto contenido oculto a través del uso de iframes, permitiendo a un atacante realizar acciones como un usuario lícito. Un ataque típico contra versiones de Flash antiguas permitía a un usuario mal intencionado tomar el control de la cámara y el micrófono de la víctima habilitando la configuración de seguridad.

Este tipo de nuevas técnicas presentan las siguientes características:

  • Se evita la protección Anti-CSRF
  • Se inyectan Clicks no datos
  • No funciona el ataque si la distribución de la página cambia
  • Requiere de la interacción con el usuario
  • Se puede evitar con Anti-Framing

Pues bien, vamos a ver un ejemplo de cómo utilizar esta fantástica herramienta, aunque para aquellos interesados, nada mejor que probar la aplicación directamente. En primer lugar cargamos el Framework abriendo con el navegador el recurso cjtool.html. En el frame izquierdo tenemos el menú de acciones y en el derecho el entorno de acción.

En el cuadro de texto URL introducimos la dirección de la página que queremos que interactúe con el usuario de forma oculta. En el marco derecho por tanto y tras pinchar en “Go”, identificamos los campos donde queremos inyectar el Click. En este caso vamos a hacer la prueba con un entorno phpLDAPadmin. Nuestro objetivo será que cuando el usuario realice un primer Click se rellene el campo contraseña con un valor arbitrario, y en una segunda pulsación del ratón se producirá un evento sobre el botón enviar. Este ejemplo es meramente ilustrativo de cómo utilizar la herramienta, ya que no se pretende autenticarse con las credenciales del usuario legítimo. Un escenario real donde se pudiera aprovechar esta vulnerabilidad sería por ejemplo, un site bancario donde el atacante mediante una serie de acciones sobre la página pudiera completar una transacción bancaria a favor del atacante.

Volviendo al ejemplo, en el menú izquierdo encontramos las acciones que se pueden “programar” sobre la página: Cargar URL, hacer un Click, introducir texto, arrastrar contenido, o extraer contenido. Introducimos en primera instancia una cadena de texto arbitraria en el campo contraseña. Hacemos click en Enter Text, arrastramos la cruz verde desde el menú izquierdo al campo contraseña del frame derecho, y por último introducimos la cadena deseada.

Lo siguiente es establecer la acción de presionar sobre el botón “Entrar”. Pulsamos sobre el botón “Click” y nuevamente arrastramos la cruz sobre “Entrar”.

Una vez establecidas las acciones que queremos que realice el usuario, podemos simularlo con Replay Steps. Inmediatamente en el marco derecho vemos como el puntero se sitúa sobre el campo contraseña movamos donde movamos el ratón. Tras hacer click, la cadena programada es copiada en el formulario, pasando el puntero nuevamente al botón “Entrar”. Una última pulsación permite entrar en la aplicación sin que el usuario lícito se entere.

Sin ninguna duda, un gran trabajo de Paul Stone y el equipo de Context, ¡un 10!

Black Hat Europa 1 day briefings (II)

Continuando con la crónica de la BH Europa, un magistral Christopher Tarnovsky vino a presentarnos Hacking Smartcards, un trabajo de más de seis meses que ha comenzado a dar sus frutos durante este último mes y que ha expuesto en exclusiva para la Black Hat.

Para que todos nos hagamos una idea sobre que ha versado su trabajo o su impacto, comentar que en nuestra vida diaria vivimos con Smartcarts: monederos electrónicos, gestiones bancarias, soporte para albergar el certificado del DNI-e. Una Smartcard era uno de los dispositivos más seguros y donde fabricantes de tarjetas y entidades bancarias depositaban su confianza. Pues bien, este “monstruo” pensó lo que es obvio, en algún punto de la circuitería interna del chip existe un bus de datos donde la información viaja en claro antes de pasar al módulo de cifrado. Esta frase, que resulta muy fácil decir, es una tarea faraónica dado los millones y millones de transistores, puertas lógicas y buses que puede tener el integrado.

En el mundo existen prácticamente 3 fabricantes de estos tipos de tarjetas que implementan una unidad de proceso 6805 (ST), 8051 (NXP) o AVR (ATMEL). Su estudio ha sido orientado al fabricante INFINEON, aunque como él comentaba el ataque puede ser extendido a otros modelos. Las fases que ha seguido Christopher para llevar a cabo el Hack son:

[Read more…]

Black Hat Europa 1 day briefings

Como era de esperar una de las conferencias de seguridad más importantes del mundo, la Black Hat, no ha defraudado en su vertiente europea. Un gran escenario, el Palau de Congresos de Catalunya, ha servido de perfecto telón de fondo para albergar a la crème de la crème de los profesionales de la seguridad mundial, es por eso que S2 Grupo no podía faltar. Nada más llegar, un dato aportado por la organización resulta a un servidor sensiblemente preocupante, la distribución de asistentes por países refleja un escaso interés por parte del auditorio español (empresas, entidades públicas, I+D) haci las seguridad y la protección de la información. Con una participación entorno a 500 personas, tan solo 28 españoles constaban como inscritos. Por el contrario colegas de la profesión con un importante número de horas de vuelo a sus espaldas el día anterior, como Estados Unidos, aportaban 58 asistentes. Vietnam, la India, Alemania, Argentina, Francia o Rusia hacían presencia de forma significativa.

El evento fue en su primer día inaugurado por Max Kelly, máximo responsable de seguridad del bien conocido portal social Facebook. Éste introdujo los valores de seguridad que son aplicados en su política y que muchos de nosotros en nuestras organizaciones deberíamos seguir. En primera instancia, según palabras de Max, Facebook persigue mediante su equipo legal a todo aquel atacante o intruso que realice acciones ilícitas contra sus sistemas, mediante la CAN-SPAM (15 USC 7701), Computer Security Fraud And Abuse Act (18 USC 1030) y evidentemente los Facebook’s Rights and Responsabilities. Para dar soporte a acciones técnicas se apoyan en la comunidad mundial de la seguridad White-Hats, analizando los ataques recibidos con el objetivo de conocer a tu enemigo. Por último hubo una frase de su presentación que debe incitar a la reflexión colectiva: Compliance isn’t security. Ahí queda eso.

Como entrantes, Joe Grand, presentador del programa de televisión de Discovery Channel Prototype This, presentó la charla Hardware is the new Software. Mientras los pentesters normalmente suelen dirigir sus acciones contra aplicaciones, servidores de correo o páginas web, el hardware es el gran olvidado. Joe comentó que hoy en día la preocupación por la seguridad a este nivel sigue avanzando en menor medida que la relativa al software, pudiendo comprometer los dispositivos mediante simples tipos de ataques que siguen funcionando desde hace años. Esto es debido a la escasa preparación en materias de seguridad de los diseñadores de hardware. Pero, ¿cómo adentrarse en este mundo? Entre otras, sugirió dos paginas donde fundamentalmente se puede adquirir material para ello, www.adafruit.com y www.makershed.com. Es necesario básicamente: ChipQuickSMD (kit de eliminación limpia de integrados), Picoscope (osciloscopio software), microscopio y un soldador claro.

[Read more…]

GOTO VIII: LOPD a “coste cero” (¿y?)

Leía ayer en el blog de Jesús Pérez Serna que finalmente la Fundación Tripartita va a poner coto a las empresas que con las ayudas a la formación se dedican a realizar la adaptación de las empresas a la LOPD “a coste cero” [enlace directo], y al parecer hay bastante regocijo en el sector por ello. Esta situación me trae a la cabeza algo que leí o me contaron sobre la prohibición de vender foie de oca en algunos estados de los USA. Al parecer, los dueños de los restaurantes habían evitado esta prohibición regalando el preciado alimento, y cobrando una barbaridad por el pan. No sé si ven por dónde voy. Es difícil evitar que dentro de unas sesiones de formación una empresa “regale” un proyecto de adaptación a la LOPD. Pero ya lo veremos.

Quizá estén preguntándose: ¿cuál es el problema de las LOPD “a coste cero”? Pues el problema tiene principalmente dos vertientes: una más fácil de vender, y otra menos. La primera es evitar el fraude, palabra que en estos tiempos suena peor que nunca; si las subvenciones de la Fundación Tripartita son para la formación de los trabajadores, no es de recibo, ni ética ni legalmente que ese dinero se utilice para adaptar la empresa a la LOPD, porque es obvio que el beneficiario de las ayudas en ese caso no es el trabajador. La segunda, y aquí es donde viene la parte que es posible que levante algunas ampollas, es evitar el intrusismo por la vía del corporativismo y el “sindicalismo” mal entendido. El mismo propósito persiguen las certificaciones que se están promoviendo recientemente relacionadas con la protección de datos, pero de eso les prometo que hablaré otro día. Volvamos a lo nuestro.

Parece lógico pensar que buscar apoyos para proteger el nicho de mercado de la protección de datos por la vía de la simpatía no resulta sencillo, y menos si la otra parte da el producto “por tu cara bonita” (o mejor, por la de los trabajadores) por lo que, como muchos colectivos y asociaciones han hecho en el pasado, se recurre a la amenaza de un trabajo mal hecho, lo que en este caso puede desembocar en significativas sanciones a la empresa cliente que ha cometido el error de contratar a una de esas empresas LOPD-a-coste-cero. Dicho de otra forma, al estilo de la DGT, el mensaje es el siguiente: las imprudencias se pagan, y con la LOPD, cada vez más; no se arriesgue y evite la LOPD “a coste cero”. El problema es que no existe, en realidad, una relación de implicación entre el coste de un proyecto y el nombre de la empresa que lo ejecuta, y la calidad del trabajo hecho. Por supuesto, existe cierta relación, pero he tenido el placer de ver informes de grandes empresas cuyo precio fue probablemente inversamente proporcional a la calidad que dichos informes atesoraban. A veces un KIA da mejores resultados que un Mercedes, y depende mucho del profesional encargado del proyecto.

Pero, ¿saben qué? La adaptación a la LOPD no es, en la mayor parte de los casos, un proceso especialmente complejo. Excepto en el caso de grandes o grupos de empresas, u organizaciones con una gestión intensiva de datos de carácter personal (por ejemplo, mutuas de prevención de riesgos laborales, hospitales, empresas de trabajo temporal, y esas grandes desconocidas: las ONGs), la adaptación a la LOPD es algo relativamente sencillo; quizá laborioso, pero sencillo. No requiere grandes conocimientos legales ni técnicos, y en muchos casos la agencia está lista para contestar, a su forma (es decir, manteniendo un adecuado nivel de ambigüedad), a las preguntas y dudas que se le plantean. Expresado de otra forma, me atrevo a decir que prácticamente cualquier empresa dispone de personal que con la necesaria preparación sería capaz de abordar su propia adaptación a la LOPD; excepto en casos particulares (que no son muchos, en los millones de empresas que tenemos en este país), en una organización sencilla, la adaptación será sencilla y podrá llevarla a cabo personal sin grandes conocimientos, y en una organización compleja, será compleja pero también habrá perfiles profesionales de calidad, legal e informático más cualificados.

El mensaje que les estoy intentando transmitir es el siguiente: la LOPD y su Reglamento de Desarrollo no son mecánica cuántica, y el que diga lo contrario, miente. Después de todo, aunque no sea totalmente significativo, la LOPD son 12 páginas y el RDLOPD 34 páginas (aunque contiene mucha “paja”).

Es posible que piensen que una empresa especializada puede detectar más salvedades que una persona “de la casa” sin demasiada experiencia en protección de datos. No les quepa la menor duda de ello. Pero tampoco de que su organización no estará dispuesta a cubrir todas esas no conformidades por el coste que implican. Por mi experiencia personal, al final la mayoría de organizaciones buscan tapar los “agujeros grandes”, llámense Documento de Seguridad, consentimiento informado, contratos con proveedores, o inscripción de ficheros, porque el coste de tapar los pequeños, llámense registro de acceso a aplicaciones con datos de nivel alto, registro de E/S de soportes, Documento de Seguridad como Encargado del Tratamiento, o copia de equipos personales, acostumbra a ser demasiado alto. Que hay organizaciones que persiguen ambos, cierto, pero como en toda organización, existen prioridades. En definitiva, que la intención de una empresa es tapar los “agujeros grandes”, el resultado de un externo y un interno puede ser sin muchos problemas el mismo.

Entonces, ¿cuál es la razón para contratar a una empresa especializada? Por supuesto, hay muchas, como en cualquier proyecto de consultoría: experiencia, capacidad de adaptación, respaldo de dirección, etc. Pero en mi opinión, la primera y principal es exactamente la misma por la que una empresa contrata un servicios de limpieza o un electricista: la LOPD no es su negocio, y “sacar” a alguien de sus tareas habituales para realizar la adaptación a la LOPD durante dos o tres meses (en el mejor de los casos) no es rentable, porque alguien deberá hacer su trabajo. Piensen, por ejemplo, en una gran empresa que se dedica a fabricar tornillos a nivel mundial. Probablemente dispone de un departamento de calidad, un departamento informático y un departamento legal. ¿Tienen alguna duda de que una persona de cualquiera de estos departamentos (o mejor, un comité formado por personas de cualquiera de ellos), cualificada y con experiencia tendría problemas para adaptar su organización a la LOPD si se le da el tiempo necesario? Si la respuesta es que sí, piénsenlo de nuevo. Si vuelve a ser afirmativa, es que se han tomado la LOPD (y quizá a si mismos) demasiado en serio. Por suerte, la LOPD no es ingeniería aeroespacial.

Cuando oigo historias como estas, no puedo evitar acordarme de las discográficas. Todos estamos dispuestos a criticar esa particular forma de proteger su negocio por la vía judicial y política, pero la realidad es que a nadie le gusta que le pisen el césped. No se dejen engañar; es necesario erradicar las LOPD “a coste cero” porque son un fraude que perjudica directamente a los trabajadores, no a las consultoras. Nosotros ya nos buscaremos la vida.

Introducción a la esteganografía (I)

La esteganografía —del griego steganos (oculto) y graphos (escritura)—, en términos informáticos, es la disciplina que estudia el conjunto de técnicas cuyo fin es la ocultación de información sensible, mensajes u objetos, dentro de otros denominados ficheros contenedores, normalmente multimedia: imágenes digitales, vídeos o archivos de audio, con el objetivo de que la información pueda pasar inadvertida a terceros y sólo pueda ser recuperada por un usuario legítimo.

A lo largo de la historia, se ha demostrado que la esteganografía ha estado presente desde antes del siglo XV y se encuentra en constante evolución. Ejemplos tales como la escritura con “tinta invisible” fabricada con vinagre, zumo de limón, leche, etc., o la ocultación de mensajes en libros como Sueño de Polífilo escrito por Francesco Colonna en el 1499, en el que se puede obtener la frase ‘Poliam frater Franciscus Columna peramavit‘ (‘El hermano Francesco Colonna ama apasionadamente a Polia’) si se toma la primera letra de los treinta y ocho capítulos, ponen de manifiesto la presencia de la esteganografía en nuestro entorno desde tiempos antiguos.

Las técnicas esteganográficas han ido evolucionando de manera acorde al desarrollo tecnológico, y así por ejemplo durante la Segunda Guerra Mundial se utilizaban los periódicos para el envío de señales ocultas mediante la realización de marcas en ciertas letras, que aunque por si solas pasaban inadvertidas en conjunto trasmitían una información. Este ejemplo es una muestra de los sectores en los que habitualmente la esteganografía ha estado más presente, y que como podéis imaginar son el entorno militar, agencias de inteligencia o espionaje entre otros.

En la actualidad, cuando hablamos de esteganografía nos referimos principalmente a la ocultación de información dentro de un entorno de canales digitales: protocolos de comunicaciones, archivos ejecutables, documentos de texto, audio digital, imágenes, etc. En la mayoría de los casos, el fichero contenedor es conocido pero lo que se ignora es el algoritmo o técnica de inserción de la información en dicho objeto contenedor. En tiempos recientes, la esteganografia ha adquirido un gran interés porque ya no sólo se usa para enviar mensajes de amor ocultos en libros como Sueño de Polífilo, sino que dichas técnicas se presupone que han sido y son utilizadas con fines muy diferentes por organizaciones terroristas y criminales, y están muy relacionadas con técnicas de anonimato como el voto o el dinero electronico entre otras. Según el diario USA Today, el FBI y la CIA descubrieron que Bin Laden empleaba imágenes esteganografiadas colgadas en paginas web públicas para comunicarse con sus oficiales.

En relación con este campo de estudio, podemos distinguir los siguientes actores implicados:

  • El objeto contenedor o encubridor, que en la mayoría de los casos suele ser una imagen y que es utilizado para ocultar la información,
  • el estego-objeto, que se trata del fichero contenedor mas el mensaje encubierto,
  • el adversario, que serian todos aquellos entes sean pasivos, activos o maliciosos a los que se les quiere ocultar la información, y
  • el estegoanálisis, que es la ciencia que estudia la detección de información oculta.

Es importante no confundir criptografía con esteganografía, puesto que el objetivo de cada uno de estos dos campos es diferente. En el caso de la criptografía el objetivo es asegurar la confidencialidad de la información ante un interceptor que es capaz de ver el criptograma. En cambio, la esteganografia busca ocultar la presencia del mensaje en sí. Sin embargo, aunque persigan objetivos diversos, para que la esteganografía sea de mayor utilidad se debe combinar con la criptografía, de modo que el mensaje a ocultar debe cifrarse robustamente y luego ser introducido en el objeto contenedor. De este modo, aunque un interceptor descubriese el patrón esteganográfico, no podría llegar a conocer el mensaje intercambiado.

En la siguiente entrada daremos un vistazo a las técnicas de esteganografía, pero pueden encontrar información en la Wikipedia y en el artículo que el Inteco le dedicó, aparte de los numerosos recursos que existen en Internet.

(El estereograma en tamaño real se encuentra en el Blog AFT Escuela Básica “Los Navíos”)

Claves del pasado para una web del futuro

Existe una regla no escrita de la seguridad (como todas las demás) que dice que no se deben repetir contraseñas en diferentes sitios, servicios, cuentas de correo y demás. Es una de esas “normas” que nos gusta recordar de vez en cuando, y que hasta hace unos años era relativamente sencilla de cumplir.

Con poca memoria que tengan en esto de la informática, recordarán que hace menos de una década el número de claves que un usuario normal tenía que recordar se limitaba a una cuenta de correo o a lo sumo dos, y algún foro. Poco más; no hacía falta demasiada memoria para ello. Pero un buen día empezaron a surgir los foros, la web 2.0, y hoy en día cualquier persona que haga un uso habitual de Internet dispone de usuario en más de una docena de servicios y sitios diferentes: Facebook, Google, Hotmail, Tuenti, Delicious, Twitter, Ebay, Amazon, LinkedIn, Xing, WordPress, GoDaddy, Meetic, Menéame, Flickr, etc. Ahora súmenle dos o tres foros, páginas de descarga de contenidos digitales, páginas de venta online, y sitios a los que acabamos accediendo un puñado de veces pero para los que solemos crear una cuenta de usuario, y tenemos una veintena de cuentas diferentes, y bastantes más en el caso de personas que hagan un uso “intensivo” de la red.

Dicho de otra forma, actualmente el número de claves que debemos recordar excede la capacidad de memorización de la mayor parte de nosotros si queremos utilizar claves diferentes y cumplir esa otra norma que dice que éstas no deben ser deducidas unas de otras y tener unos requisitos mínimos de sintaxis, longitud y complejidad, por muchas reglas nemotécnicas que utilicemos. De caducidad de contraseñas ni hablamos, porque si cada uno de nosotros tuviese que ponerse a cambiar veinte claves cada dos o tres meses, iba a ser para volverse loco.

¿Qué provoca esta situación? Que el número de claves que los usuarios utilizamos sea limitado y se repita entre diferentes servicios, sin diferenciar a menudo ni siquiera entre sitios “seguros” (o relativamente seguros) y sitios “menos seguros”. Para colmo de males, a esto hay que añadirle la reticencia de la mayor parte de las personas (incluido un servidor) a variar las contraseñas “habituales” que lleva utilizando desde tiempos inmemoriales, o en todo caso a cambiar de nemotécnico, por dos razones básicas: el pánico a olvidar una clave (y no poder acceder al correo exactamente en el momento que lo “necesitamos”, y no cinco o diez minutos después, una vez la hemos recuperado) y el estrés que nos provoca tener que recordar nuevas contraseñas totalmente diferentes de las habituales y con las que todavía no estamos familiarizados (¿soy el único que retrasa hasta el último momento el cambio de la clave de acceso al correo corporativo cuando ésta caduca?).

Para empeorar aún más esta situación, la mayoría de usuarios acabamos tirando del recurso fácil que son los navegadores y la funcionalidad habitual de “recordar contraseña”, olvidando en la gran mayoría de casos que las claves se guardan en texto plano, y que cualquier persona con acceso al navegador dispone de acceso inmediato a nuestras cuentas de correo, foros, y servicios 2.0 de todo tipo. Si esto no fuese suficiente, para acabar de rematar la faena, DragonJar indica que es posible robar contraseñas del gestor de claves de Firefox por XSS.

Afortunadamente, poco a poco empiezan a surgir soluciones para este problema, aunque mucho me temo que actualmente son accesibles, como muchas otras funcionalidades “avanzadas”, a usuarios con determinada experiencia y soltura en el uso de Internet (o dicho de otra forma, no esperen que el usuario básico —de los que hay muchos millones— los utilice o siquiera los entienda). Aparte de los habituales KeePass o Password Gorilla, cuyo ámbito es mucho mayor que el de los servicios de Internet, en primer lugar tenemos (vía DragonJar) a LastPass, que parece prometedor aunque no he tenido ocasión de probar. Por otra parte, Mozilla está experimentando con un gestor de cuentas que está pensado para revolucionar el acceso a las webs, y que se encuentra aún en fase de prototipo.

No obstante, incluso con los gestores “seguros” de contraseñas como los que les comentaba hay un aspecto preocupante y bastante frecuente: aquellas webs o servicios que no te dejan introducir carácteres “extraños” en la contraseña (léase !, ?, #, $, %, &, /, (, ), o los propios signos de puntuación) o esas otras que te remiten la clave en texto plano cuando la “recuperas”, indicando que no utilizan cifrado para el almacenamiento de las claves de los usuarios (entre ellas, la web de ISACA). Esto puede provocar, debido a las malas prácticas que hemos indicado, que las cuentas de muchos usuarios en otros sitios web se vean comprometidas en caso de robo de información. Claro que uno puede asumir que con los sistemas que les comentaba, lo razonable es utilizar una cuenta diferente por servicio, pero ya saben que lo razonable no es siempre lo común.

Para ir acabando, entre todas las cuentas diferentes que un usuario puede manejar en Internet, a pesar de la (relativa) marginalidad cada vez mayor que va adquiriendo frente a las redes sociales y servicios más populares y colectivos y su inseguridad intrínseca, el correo electrónico sigue manteniendo una importancia crítica, al ser el repositorio virtual de recordatorios o cambios de clave de otros muchos servicios; procuren mantener su cuenta a salvo y no compartan la clave de acceso con foros y servicios 2.0 de escasa (o desconocida) reputación.

En definitiva, a pesar de que en la última década el funcionamiento de Internet ha avanzado de manera muy significativa, y su utilización se ha extendido a sectores de la población muy alejados de los ámbitos especializados y universitarios, los sistemas de autenticación siguen siendo los mismos de los comienzos: un usuario y una contraseña. ¿No es hora ya de que vayamos pensando en algo diferente y sobre todo, más seguro?

ACL en GNU/Linux

Hoy vamos a introducirnos en el fascinante mundo de las ACL (Access Control List) en Linux. En este punto ya habrá alguien que piense que eso es más viejo que el mismo Unix, pero mucha gente, entre que los que me incluyo, no tenia ni idea de que existían las ACL en Linux, y menos cómo usarlas. Empecemos, como siempre, con un poco de teoría cortesía de la Wikipedia:

Una Lista de Control de Acceso o ACL (del inglés, Access Control List) es un concepto de seguridad informática usado para fomentar la separación de privilegios. Es una forma de determinar los permisos de acceso apropiados a un determinado objeto, dependiendo de ciertos aspectos del proceso que hace el pedido.

Así pues, las ACL nos permiten determinar si una entidad puede acceder o no a un objeto, y qué acciones puede realizar contra dicho objeto. Bien, hasta aquí suena exactamente igual que los típicos controles de acceso de Linux, y es normal, dado que la instancia mas simple de una ACL son los permisos habituales de propietario/grupo/otros que tan bien conocemos. La diferencia radica en que con las ACL se puede hilar mucho más fino, especificando varios grupos y usuarios y detallando para cada uno sus permisos específicos.

[Read more…]