Security Art Work

Seguimos con la serie sobre Honeynets, esta vez para hablar de las tipologías, que dependerán de los recursos de los que disponemos para implantar la honeynet. Según la tipología, aún siendo válidas todas ellas, estarán más o menos limitadas en el cumplimiento de los objetivos propuestos.

Tendremos en cuenta la clasificación que propusimos en el anterior post donde se diferenciaba por localización. El tipo de honeynet a implantar, bien sea conviviendo con nuestros sistemas en producción o en un entorno totalmente aislado de la organización, marcará las directrices a la hora de decidir que tecnologías utilizar.

Entorno de PRODUCCIÓN

Si nos decantamos por una honeynet integrada en nuestra red organizativa en producción, debemos conocer las tecnologías que forman parte de nuestros sistemas para no utilizar otra que pueda interferir en el modelo productivo. En este caso y como ejemplo, si tenemos una política de seguridad donde se exige que la implantación de nuevos sistemas debe hacerse mediante virtualización, sabemos que la instalación de los diferentes honeypots no podrá realizarse en sistemas físicos convencionales.

[Read more…]

Resulta que el pasado 27 de abril la agencia de protección de datos alemana realizó una queja a Google relacionada con la información Wi-Fi recogida por la flota de coches Street View, que por si no lo sabían, además de realizar fotografías, también capta información de SSIDs y MACs. El departamento legal de Google respondió que la única información Wi-Fi que recopilaban era, en efecto, esa. Es decir, en palabras de Google, que Networks also send information to other computers that are using the network, called payload data, but Google does not collect or store payload data

El caso es que la agencia de protección de datos alemana, que es una desconfiada, se queda con la mosca detrás de la oreja, y a principios de mayo se le antoja realizar una auditoría de esa información Wi-Fi. Y en estas que estamos, Google descubre, atónita y con sorpresa mayúscula, que aunque pensaba una cosa, ha resultado otra. Pensábamos que no, y resulta que sí; qué confusión más tonta.

¿El culpable? Pues de nuevo en palabras de Google, Quite simply, it was a mistake. Al parecer, un trozo de código experimental fue a parar inexplicablemente al código del proyecto a través del que Google recopila SSIDs y MACs mediante los coches Street View, y nadie se dio cuenta. Lo que parece sugerir, si hay que creerse la explicación, que nadie en Google sabía que esa información se estaba recogiendo ni que el código responsable había sido incorporado al proyecto. Entonces, ¿mintió el departamento legal en la primera consulta? The Register dice que no, y lo justifica esto en la estructura interna de Google, eminentemente formada por ingenieros, de manera que es posible de alguna forma que el departamento legal de Google estuviese diciendo la verdad e ignorase la realidad de los hechos. Claro que no sabe uno qué es peor, si que estén mintiendo, o que no sepan cómo se trata la información dentro de Google. En cualquier caso, es razonable suponer que los abogados no sabían qué se cocía, aunque eso no les exima de culpa.

Volvamos al argumento de Google, es decir, que fue un simple error. Lo cierto es que si estuviésemos hablando de un par de semanas, el argumento de Google tendría su parte de credibilidad; quizá no mucha, pero alguna. Pero después de tres años de estar recogiendo información, que según esta nota de Google (en pdf, un certificado de destrucción de los datos recopilados por los coches Street View correspondientes a Irlanda, emitida por la consultora ISEC) ocupa cuatro discos duros, y según cita The Register podría llegar a 600 GB, el argumento no pasa casi ni por una mala excusa. Tres años es mucho tiempo.

Vale. Es cierto que 600GB no son muchos datos para el volumen de información que Google gestiona, pero no es descabellado pensar que durante ese tiempo, y dado que hablamos de treinta países y un número significativo de coches, alguien en algún momento se daría cuenta de que esa información estaba siendo recogida. *Alguien* debería haberse dado cuenta. O quizá la cuestión no era “darse cuenta de”, sino “darse cuenta de y preguntarse si”. Es decir, quizá los ingenieros trataban la información que necesitaban tratar (MACs y SSIDs) y dejaban el resto, sin plantearse qué hacía allí, si era necesaria para algo o incluso si debía ser recogida; eso no es cosa mía.

Resumiendo. Durante tres años, o el departamento legal no sabía qué pasaba dentro de Google con el tema de los coches o miente, y el personal técnico o no sabía qué datos estaba recogiendo o miente. De las cuatro posibles combinaciones, quédense con la que quieran; no estoy seguro de que haya alguna mejor que las demás. Ahora piensen en toda la información a la que Google accede, y toda la que puede estar recogiendo intencionadamente o por “descuido”; en buenas manos estamos.

Acaba de publicarse la noticia de que Microsoft dejará de actualizar la seguridad de los equipos con Windows XP y Service Pack 2 el próximo 13 de Julio, para actualizar únicamente las versiones mas modernas de este operativo. No han querido valorar cuántos equipos dejarán de estar actualizados, pero esta noticia revela la importancia de disponer de un repositorio centralizado para las actualizaciones de los equipos, y sobre todo de monitorizar que dichas actualizaciones se aplican correctamente.

En muchas organizaciones se siguen políticas centralizadas para la instalación de los parches del sistema operativo, para ciertas aplicaciones corporativas, para el uso de los antivirus corporativos con reglas restrictivas, para el uso de accesos externos a la empresa como VPN, etc. Sin embargo, no hay que dejar de lado que la mayor parte de las aplicaciones no permiten una actualización por políticas centralizadas, y que en la mayor parte de los entornos, un equipo suele tener instalados una infinidad de programas (necesarios) cuya actualización no es para nada sencilla, y que van mucho más allá del sistema operativo, Microsoft Office y el navegador. Tampoco conviene olvidar que la aplicación final de las actualizaciones suele depender del usuario, por varias razones.

En primer lugar, aunque las actualizaciones del SO se descarguen e incluso instalen de manera automática, el reinicio posterior que a menudo es necesario suele postergarse días o incluso semanas, porque esa es una de las cosas que al usuario más le molestan; tampoco es recomendable que dicho reinicio se fuerce, porque eso puede provocar algún que otro roce y problemas con personal interno. En segundo lugar, muchos usuarios evitan las actualizaciones de programas de adobe, o los propios navegadores, aunque son relativamente sencillas, ya sea por el consabido “si funciona no lo toques”, por simple pereza o por evitarse interrupciones “innecesarias”. En tercer lugar, tenemos aquellos programas que no proporcionan una actualización a través de una opción “Buscar actualizaciones”, sino todo lo más avisan de la existencia de ésta, tras lo cual es necesario ir a la página del producto en cuestión y volverlo a instalar; ni que decir tiene que si en las situaciones anteriores el usuario evita por todos los medios una actualización relativamente sencilla y transparente, en este caso las molestias son casi inconmensurables. En cualquier caso, hasta aquí el usuario tiene un medio, más o menos fiable, más o menos rápido, más o menos transparente, de actualizar sus aplicaciones y sistema operativo, y el que no lo hace es porque no quiere. Ahí es donde entran las herramientas de inventario automático y las campañas de concienciación y sensibilización de los departamentos de TI.

No obstante, hay un cuarto caso mucho más complicado que el resto, y cuya actualización puede suponer, justificadamente, un dolor de cabeza para usuarios experimentados. Este es el caso de algunas aplicaciones Open Source para Windows, con dependencias específicas de librerías, versiones de programas, entornos, etc. Es decir, básicamente lo que sucede en los entornos GNU/Linux, que han sabido solucionar a través de herramientas como APT, que se encargan de verificar las dependencias de librerias, programas, incompatibilidades, etc. Sin embargo, parece lógico que esto no existiese para Windows, por ser en teoría la antítesis de los entornos Open Source; aunque Microsoft proporciona la herramienta WSUS para la centralización de actualizaciones, lo cierto es que ésta se limita a sus propios programas y al sistema operativo, algo que resulta normal después de todo.

Afortunadamente, para eliminar o mitigar en lo posible este problema, Garret Serrack, desarrollador del departamento de código abierto de Microsoft, ha desarrollado CoApp, que viene a solucionar lo que nos puede suponer un gran quebradero de cabeza, proporcionando un sistema por paquetes similar al APT, pero para entornos Windows. La idea es facilitar la actualización de las aplicaciones de código abierto que tengamos instaladas, solucionando conflictos con múltiples versiones de librerías o 32/64 bits, e incluso ayudar a la actualización conjunta de programas y librerías. Si ustedes hacen un uso habitual de estas herramientas, vale la pena que le echen un ojo, seguro que les resultará interesante.

Como ven, a veces, la seguridad no depende de grandes proyectos, sino de pequeños pasos. Pasen un buen fin de semana, les vemos el lunes.

Aunque la tecnología RFID va siempre asociada —al menos en estos ámbitos, cosa lógica por otro lado— a peligros sobre la privacidad y la intimidad de las personas, lo cierto es que cuando se descubren las posibilidades de futuro de esta tecnología, es fácil quedar abrumado con las infinitas posibilidades que ésta puede proporcionar en innumerables campos, tanto de ámbito logístico y comercial como de seguridad y comodidad. De hecho, gran parte de las cosas que a menudo nos dejan boquiabiertos y nos ponen los pelos de punta en las películas son posibles gracias a esta tecnología. Sirva esta entrada para des-demonizar esta tecnología… de momento al menos.

Podemos empezar con nuestros “vecinos” los japoneses, que como saben en esto de las tecnologías de película siempre están al pie del cañón. Al parecer, existen ya tiendas de ropa en las que todas las prendas están etiquetadas con tags RFID pasivos, a partir de los cuales la infinidad de aplicaciones que pueden desarrollar es casi infinita. Una de éstas es la instalación de probadores con monitores en los espejos y antenas que interactuan con la ropa, de manera que al detectar la prenda podemos ver en la pantalla una imagen de la misma con toda la gama de colores posibles, todos los accesorios a juego con dicha prenda o incluso el mismo catálogo de la tienda. De esta manera, el cliente desde el mismo probador puede seleccionar lo que quiere probarse y qué tallas, mientras los vendedores, que monitorizan toda la información, les hacen llegar al probador las prendas solicitadas. De esta forma, con llevar una sola prenda al probador se puede salir de él con toda la temporada primavera-verano. Hasta el momento, los resultados han sido satisfactorios, ya que se ha conseguido aumentar la cesta media del cliente y destacarse frente a la competencia. Por supuesto, esto impone requisitos en cuanto al personal disponible para la atención de los probadores, y sería interesante ver esta tecnología en acción en una tienda estilo Bershka un sábado por la tarde.

Pasando a los supermercados, las ventajas tampoco se quedan cortas. Por un lado, sería un consuelo poder llegar con el carro de la compra hasta los topes a la caja y que en unos segundos o fracciones de segundo pudiéramos saber el total de la compra, sin necesidad de tener que sacarlo todo, poner primero lo duro y luego lo blando en la cinta, cuidado con los huevos,… y sobre todo, ¡sin esperar haciendo colas de horas! Por otro, aunque intuyo que comercialmente no sería interesante, los carros podrían, mediante una sencilla pantalla de cristal líquido, indicar cuál es el importe total de lo que llevamos en el carro, y facilitar así la planificación de presupuestos (echando al traste toda esa ingeniería que hace que salgamos del super con dos docenas de productos con los que inicialmente no contábamos).

Además, si han sido como yo, de los que han trabajado en comercios, recordarán los inventarios, que se hacían en nuestras muy preciadas 8 horas de los domingos y que luego era compensado con un martes libre que no valía para nada. Pues bien, si todo utilizara tags RFID y antenas óptimamente posicionadas se podrían realizar inventarios en minutos sin necesidad de hacer que todo el personal acudiera a la tienda, lo que reduciría las molestias, los costes y con la posibilidad de generar un inventario mensual, semanal e incluso diario teniendo el stock actualizado en todo momento, reduciendo de nuevo los costes y de manera que nunca faltara producto para el cliente.

Aunque parezcan situaciones a décadas vista, lo cierto es que cada vez son funcionalidades que empezamos a asumir como posibles. Actualmente ya están desarrollando carros de plástico que no interfieran con las señales de radiofrecuencia, y muchas compañías están insertando etiquetas en los productos, primero a nivel de palets para disponer de la trazabilidad del producto en su recorrido logístico, pero en breve comenzarán a nivel de unidades, de manera que en los centros comerciales se puedan aprovechar de este potencial.

Fuera del ámbito comercial tenemos la comodidad de, por ejemplo, el forfait que cada vez más estaciones de esquí han convertido en una simple tarjeta RFID que podemos llevar en el bolsillo. Así, con sólo acercarse al torno, este se abre para pasar al telesilla, no teniendo que llevar el dichoso gancho en la cremallera y evitando tener que disponer de personal que vigile quién lleva y quién no la pegatina. Un ejemplo más reciente y real es la tarjeta del bus que nos ahorra el tiempo perdido en las colas, o las tarjetas de identificación de la oficina que nos permiten acceder al recinto… etc.

No obstante, siempre tiene que haber un pero ligado a una nueva tecnología. Cuanto más se lee, más fácil es encontrar detractores del RFID, que dicen que esta tecnología provocará que perdamos nuestro derecho a la intimidad, o que sólo la utilizarán para crear patrones de conducta del cliente y así poder “atacarnos” con publicidad personalizada y poder tener un control de nuestros hábitos… Ante esto, sólo puedo decir que RFID es el futuro y que no es posible negar la innumerable cantidad de ventajas que puede ofrecernos, muchas de ellas ni siquiera alcanzamos a vislumbrar. Como siempre, la tecnología no es el problema, sino la finalidad con la que se utiliza, y el uso de los datos que se pueden obtener.

RFID está aquí para quedarse, y en lugar de luchar contra ella, es mejor que desarrollemos mecanismos de seguridad y legales para proteger nuestra identidad e intimidad. Es necesario evitar la creación de bases de datos que relacionen al cliente con sus hábitos, que pueda ser explotada con fines malintencionados o simplemente ilegales. Es más, incluso en algunos entornos es deseable dejar de lado la intimidad y la privacidad si eso sirve para incrementar la seguridad de las personas. Piensen en ciertas minas, donde el personal lleva un chip insertado, de manera que en caso de desprendimiento se puede localizar con mayor rapidez a los mineros que han quedado sepultados permitiendo así un rescate mucho más rápido.

Es muy difícil encontrar un compromiso entre seguridad y funcionalidad de la información obtenida con esta tecnología, pero espero que se encuentre pronto para que la seguridad no haga de freno a lo que sin duda es el futuro. Les dejo con un pequeño vídeo explicativo, vía Paloma Llaneza, que aunque está en inglés, no tendrán problemas para seguir:

Lo prometido es deuda, y hoy vamos a explicar un poco que es SELinux [Security-Enhanced Linux, enlace de la NSA] y cómo opera. Recomiendo releer la entrada sobre MAC y DAC para recordar conceptos. Tras esto, ¿qué es SELinux? SELinux es una implementacion del MAC que funciona a nivel de kernel, lo que implica que las aplicaciones no necesitan ser modificadas para aprovechar toda su potencia, ya que para ellas SELinux es transparente, algo muy importante a la hora de que el sistema sea desplegado en un entorno real.

La razón de usar SELinux es limitar el acceso que tienen las aplicaciones a otras aplicaciones y a los ficheros, impidiendo que un proceso pueda modificar cualquier fichero del usuario con el que se lanzó. Por ejemplo, Firefox jamas debería ser capaz de cambiar los permisos de mi clave privada ssh, lo cual con un sistema de control de acceso DAC sí sería posible si un atacante toma el control del navegador.

¿Cómo funciona SELinux? Pues se basa en atributos extendidos del sistema de ficheros que indican el tipo de usuario (que no tiene porque ser usuario del sistema), el rol, y el tipo del objeto. Por ejemplo, si hacemos un ls -lZ para ver los atributos extendidos del directorio /etc/httpd, podremos ver que permisos le asigna una distribución Red Hat a los ficheros de configuración de Apache (la quinta línea se ha partido para facilitar su presentación):

[root@localhost httpd]# ls -lZ
drwxr-xr-x root root system_u:object_r:httpd_config_t conf
drwxr-xr-x root root system_u:object_r:httpd_config_t conf.d
lrwxrwxrwx root root system_u:object_r:httpd_log_t logs -> ../../var/log/httpd
lrwxrwxrwx root root system_u:object_r:httpd_modules_t modules -> 
           ../../usr/lib/httpd/modules
lrwxrwxrwx root root system_u:object_r:httpd_config_t run -> ../../var/run

Como podemos ver, el usuario y rol es el mismo, pero el tipo cambia. Estos atributos son los que en función de las políticas definidas en SELinux, indican las interacciones entre ellos y los diferentes objetos del sistema. Estos atributos están definidos en el sistema, y puede haber cientos, tantos como la granularidad que queramos obtener. La mayoría de distribuciones que usan SELinux vienen ya con varios tipos predeterminados para ayudarnos en su administración, pero nosotros podemos definir más. Si queremos ver todos los tipos disponibles, lo podemos hacer con el comando

#getsebool -a

Ahora que ya conocemos los atributos, ahora nos falta conocer un poco las políticas que utilizan estos atributos. Al más alto nivel, existen dos tipos de políticas básicas: targeted y strict:

• strict: En modo estricto, por defecto todo está denegado, y tan sólo se permite lo especificado en la políticas. Esto, que sigue el principio de mínimo privilegio, es complicado de administrar y llevaría a la mayoría de los sysadmins a desactivar SELinux.
• targeted: Tan sólo ciertos servicios están bajo la supervisión de SELinux, como por ejemplo los demonios httpd, bind, postgresql, etc. El resto están libres de restricciones. La denominacion Targeted proviene del hecho de que tan solo los servicios señalados serán vigilados.

Para saber qué tipo de política tenemos configurada, en un sistema Red Hat podemos averiguarlo en el fichero /etc/sysconfig/selinux.

Por debajo de estos modos, se sitúan las políticas en sí, que definen las interacciones entre objetos. Dichas políticas pueden usar diferentes controles de acceso, en función de los atributos extra que utilicen. Normalmente se suele usar Type Enforcement en el cual tan solo se utiliza el atributo tipo, y es el modo usado por la política targeted. Existen otros métodos como el Role-Based Access Control que utiliza los atributos de usuario y rol pero normalmente, dado que como política se utiliza targeted, el modo de acceso mas común es el Type Enforcement.

Ya tan sólo nos queda saber qué es lo que exactamente permite o impide que podamos acceder a un objeto. Aquí entran en juego las políticas, que dependiendo del control de acceso utilizado y los atributos de los objetos, permiten o deniegan un acceso. Así pues, si usamos el modo de Type Enforcement, es el tipo de un objecto el atributo determinante. En este caso, si un servicio esta en el modo vigilado tan solo podrá acceder a objetos con un tipo similar. En las políticas se definen los tipos similares y las excepciones que permiten que el sistema funcione. Así, por ejemplo, si inspeccionamos con que permisos se ejecuta el demonio Apache (la segunda línea se ha partido para facilitar su presentación):

[root@localhost etc]# ps auxZ | grep httpd
user_u:system_r:httpd_t  root  2869 0.3 0.5 10548 2924 ? Ss 15:46 0:00 
          /usr/sbin/httpd

Vemos que dicho demonio tan solo podrá interactuar con objetos de un tipo similar, como por ejemplo los que están en el directorio /etc/httpd. Esto implica que aunque nosotros tuviéramos un fichero con permisos de lectura y escritura para todos, como por ejemplo:

[root@localhost jvela]# ls -lZ /home/jvela
drwxr-xrwx jvela jvela user_u:object_r:user_home_t  prueba_selinux

Un atacante que comprometiera el demonio de httpd no podría acceder porque dicho demonio esta en el dominio de SELinux y el tipo de nuestro archivo no pertenece a la “familia” httpd.

Hemos visto por encima que es SElinux, cómo esta estructurado y como consigue aplicar el MAC a un sistema GNU\Linux. Por supuesto, como pasa siempre, la mejor manera de comprender su funcionamiento es jugando con él y poniéndolo en marcha, algo a lo que les invito. No obstante, si les queda alguna duda o hay algo de lo dicho sobre lo que les gustaría que incidiese, no tienen más que indicarlo en los comentarios y estaré encantado de aclarar las dudas que tengan. En la siguiente entrada pasaremos de la teoría a la práctica, con ejemplos de su funcionamiento y las múltiples opciones de configuración que lo convierten en un sistema tan flexible.

Saludos, y hasta la próxima.

Par acabar con esta breve serie sobre esteganografía, entraremos brevemente en el concepto de estegoanálisis, que como ya se ha comentado en alguna entrada anterior, es la técnica que se usa para recuperar mensajes ocultos o para impedir la comunicación por esteganografía. Básicamente, podríamos hablar de dos tipos principales de estegoanálisis:

Estegoanálisis manual: Consiste en buscar de forma manual diferencias entre el objeto contenedor y el estego-objeto buscando cambios en la estructura para localizar datos ocultos. En este caso es imprescindible disponer del objeto contenedor, y aunque en muchas ocasiones se detecta información oculta resulta imposible recuperarla. Un estegoanálisis manual podría consistir en un escenario en el que a partir de un archivo BMP donde el bit menos significativo de las componentes de algunos de sus píxeles hubiese sido sustituido por información oculta, aplicásemos un filtro de modo que sólo se considere el bit menos significativo de cada componente RGB de cada píxel.

Estegoanálisis estadístico: Consiste en detectar modificaciones esteganográficas mediante la observación de desviaciones respecto a la norma de algunas propiedades estadísticas (por ejemplo, la entropía siempre aumenta). En el caso de tener como contenedor una imagen, se realizaría un cotejo de la frecuencia de distribución de colores del estego-objeto a través de un software especializado. Una de estas técnicas es el ataque Chi-Square, que permite estimar el tamaño de la posible información oculta en un estego-objeto. Es aplicable cuando un conjunto fijo de parejas de valores conmutan de un valor al otro de la pareja cuando se insertan los bits del mensaje oculto. Como indican Arturo Ribagorda, Juan M.Estevez-Tapiador y Julio César Hernández en el documento que les apuntábamos el otro día, Esteganografia, esteganalisis e Internet (PDF), este tipo de estegoanálisis presenta limitaciones importantes, como son a) falsos positivos al procesar gran cantidad de contenidos, b) dificultad en la elección de la norma, y c) gran dependencia del tamaño del mensaje oculto y del medio.

Casualmente hace unas semanas la comunidad científica se ha hecho eco de una nueva técnica que se puede usar para un estegoanálisis. Dicha técnica revela imágenes en objetos ocultos y puede que algún día mejore la capacidad de los pilotos para volar a través de condiciones de poca visibilidad por niebla, o a los médicos a ver con mas precisión en el cuerpo humano sin necesitad de cirugía. Desarrollado por ingenieros de la Universidad de Princeton, el método se basa en la alta capacidad para aclarar una imagen mediante rayos de luz que normalmente hacen que la imagen sea irreconocible (europapress, tendencias21). Dichos resultados han sido publicados en Nature Photonics.

En sus experimentos, los investigadores Fleischer y Dmitry Dylov, empleando materiales ópticos no lineales, restauraron una imagen oculta en un patrón claro de números y lineas. Según Dylov “Es como si hubiésemos tomado una foto de una persona en la oscuridad, y hayamos hecho a la persona mas brillante y el fondo mas oscuro. El contraste hace que la persona se destaque”. Personalmente espero y confío que en el futuro se pueda perfeccionar esta técnica y pueda ser útil y de gran ayuda para por ejemplo diagnósticos precoces en el ámbito médico, o incluso combinándola con otras técnicas sea útil para operar sin cirugía, a través de láser u otro tipo de método ya que el nivel de visión interno sería mucho más preciso.

Para acabar, y en cuanto a software, existe una gran variedad tanto para esconder mensajes (HIP, MP3Stego, JPHide y JPSeek, BitCrypt, S-Tools,BlindSide Cryptographic Tool, StegoVideo, Xiao steganography,OpenStego,…) como para descubrirlos a través del estegoanálisis (Stegdetct, StegSecret, Stego Suite, Stegkit, Digital Invisible Ink Toolkit, StegSpy, SteGUI, Stepic, StegAlyzerSS,…). Queda como ejercicio para el lector interesado indagar en las características y propiedades de cada una de estas aplicaciones. Para ampliar esta y otra información, pueden tirar de la Wikipedia, el documento indicado previamente, el artículo de INTECO, y por supuesto, de los innumerables recursos que aporta Internet.

Tras la introducción a la esteganografía de la entrada anterior, vamos a dar un repaso general a las técnicas esteganográficas más utilizadas, enfocadas sobre todo a que nuestro objeto contenedor sea una imagen, son las siguientes:

• Enmascaramiento y filtrado: la información se oculta dentro de una imagen digital empleando marcas de agua. El watemarking o marca de agua digital tiene como objetivo poner de manifiesto el uso no legal de un cierto servicio digital por parte de un usuario no autorizado. Esta técnica consiste en insertar un mensaje (un grupo de bits que contiene información sobre el autor por propietario intelectual) en el interior de un objeto digital. Otra técnica relacionada es el fingerprinting o huella digital, donde se introduce en el mensaje no sólo información sobre el autor o propietario sino además información del usuario que ha adquirido los derechos de uso de ese objeto. Así se puede perseguir la distribución ilegal de servicios digitales.
• Sustitución de bits del objeto contenedor: Consiste en sustituir ciertos bits del fichero contenedor por los de la información a ocultar. El tamaño del fichero no se ve alterado y, generalmente tampoco se ve mermada su calidad. En un fichero de sonido se podrían emplear los bits que no son audibles por el oído humano para ser reemplazados por los bits del mensaje a ocultar. Si se trabaja con imágenes, lo habitual seria sustituir los bits menos significativos (LSB), en una escala de color de 24 bits. Esto se traduce a que en un pixel con un tono rojo se ve un 1% mas oscuro, un cambio inapreciable para la vista humana.

  Como hemos comentado antes, el contenedor más usado es el de las imágenes digitales, concretamente en formato BMP por su sencillez; es un formato estándar de imagen de mapa de bits en sistemas operativos DOS, Windows y válido para MAC y PC, que soporta imágenes de 24 bits y 8 bits, y puede trabajar en escala de grises, RGB y CMYK. Cada pixel de un archivo BMP de 24 bits está representado por tres bytes, cada uno de los cuales contiene la intensidad de color rojo, verde y azul (RGB). Combinando los valores en esas posiciones podemos obtener los más de 16 millones de colores que puede mostrar un pixel. A su vez, cada byte contiene un valor entre 0 y 255, es decir entre 00000000 y 11111111 en binario, siendo el dígito de la izquierda el de mayor peso, por lo que se pueden modificar los bits menos significativos de un pixel sin producir mayor alteración. El hecho es que cambiando un bit en cada componente de un pixel, se pueden meter tres bits de información oculta por cada pixel de una imagen sin producir cambios importantes en la imagen. Teniendo en cuenta que se necesitan ocho pixeles para ocultar tres bytes de información, en codificación ASCII esto son 3 letras de información oculta, por lo que en una imagen BMP de 502×126 pixeles se puede ocultar un mensaje de 23.719 carácteres ASCII.

• Inserción de bits en el objeto contenedor: Se añaden los bits de información a partir de una determinada marca estructural del fichero (fin de fichero, espacios de padding o alineamiento, etc.). El problema de esta técnica es que se incrementa el tamaño del fichero contenedor, por lo que no es muy discreta.

  Por ejemplo, en una imagen BMP los primeros 54 bytes contienen los metadatos de la imagen. Cuatro de esos bytes se destinan al offset, o distancia entra la cabecera y el primer pixel de la imagen. Así pues, la forma mas fácil de ocultar datos consiste en introducirlos justo después de los metadatos y antes de los datos de la imagen en sí, y modificar el campo offset. De esta manera, se puede dejar espacio para todo el contenido adicional que se desee añadir.

• Creación de un fichero contenedor propio partiendo de la información a ocultar: Consiste en crear un fichero contenedor con la propia información que se quiere ocultar. Por ejemplo, dado un algoritmo especifico de reordenamiento de los bytes de los datos a ocultar se puede generar una secuencia de pixeles de un archivo BMP que tenga cierto significado visual.

  En vídeo suele utilizarse el método DCT (Transformada de coseno discreta) basada en la DFT (Transformada de Fourier discreta), pero haciendo uso únicamente de números reales. DCT funciona cambiando ligeramente cada uno de los fotogramas del vídeo, de manera que no sea perceptible por el ojo humano. Por ejemplo, en la completa presentación titulada Esteganografia, esteganalisis e Internet (aquí en PDF) de Arturo Ribagorda, Juan M.Estevez-Tapiador y Julio César Hernández se muestra un procedimiento para ello, cuya extracción sería sencilla aplicando el procedimiento inverso:

  1. Calcular la DCT de la imagen
  2. Sustituir los coeficientes menores que un cierto valor umbral por bits de la información a ocultar
  3. Calcular la inversa de la DCT de la imagen
  4. Almacenar

Utilizando estas técnicas, existen múltiples escenarios en los cuales podría emplearse la esteganografia. Por un lado, empleando el protocolo TCP/IP, ya que éste es apropiado para crear canales encubiertos de comunicación enviando datos relevantes a través de las cabeceras entre dos entidades que hayan acordado un protocolo encubierto. De la misma manera, con la finalidad de fortalecer los canales de comunicación maliciosa, la esteganografia es de gran utilidad. De hecho, los creadores del gusano Waledac ya han empleado esteganografia para que éste tenga la capacidad de descargar e interpretar un archivo de imagen JPEG especialmente manipulado. Dicho archivo es una imagen JPEG normal a la que se le ha añadido un ejecutable tras la imagen en sí, después de un determinado marcador JPEG para ser coherente con el estándar. Por supuesto, no todas las aplicaciones de la esteganografia tienen que ser maliciosas. Estas técnicas se pueden usar para meter información de pacientes en radiografías , TACs, etc… pero seguramente no les parecerán tan interesantes.

En la siguiente entrada finalizaremos con un vistazo al estegoanálisis, pero como les decíamos en el artículo anterior, pueden encontrar información en la Wikipedia, en el artículo que el Inteco le dedicó, y en la excelente presentación que les señalábamos arriba. Por supuesto, siempre tendrán los innumerables recursos que aporta Internet.

Continuando con la serie sobre Honeynets que empezamos hace un mes, en esta entrada vamos a identificar y clasificar los diferentes tipos de Honeypots, los elementos esenciales de las “redes trampa”. Un honeypot no es más que una aplicación, servicio o sistema que simula ser lo que no es. No tiene un valor productivo para quien lo implanta y está preparado para ser sondeado, atacado y comprometido. Es básicamente un señuelo con el objeto de engañar al atacante que pretenda amenazar nuestros sistemas, al mismo tiempo que ayuda a entender las técnicas de ataque utilizadas.

Por estas razones, es lógico pensar que cualquier actividad que se genere desde o hacia un honeypot, será muy probablemente una actividad ilegítima o no autorizada. Existen diversas formas de clasificar los honeypots. Aquí lo haremos basándonos en dos de sus propiedades principales: la localización concreta dentro de una red y la interacción que permite con el atacante.

Según la LOCALIZACIÓN, pueden situarse en un entorno de:

• Producción: El objetivo que se pretende alcanzar al implantar un honeypot en una red en producción no es otro que la obtención de información sobre las técnicas empleadas para tratar de vulnerar los sistemas que componen dicha infraestructura.

  El abanico de posibilidades que nos ofrece un honeypot en una red en producción es muy amplio. Desde la posibilidad de ubicar el honeypot en el segmento de la red de servidores internos de la compañía, con el objetivo de detectar posibles accesos por parte de usuarios internos a recursos críticos de la organización (por ejemplo al fichero de nóminas), hasta la publicación de un servicio web con idéntica configuración y diseño que el mismo servicio que está en producción o preproducción.

  El mayor inconveniente que supone esta elección es el peligro que supone para los sistemas organizativos el permitir (incluso provocar) que el tráfico malintencionado conviva con el legítimo.

• Investigación: En este caso, el principal objetivo es la recopilación de la mayor cantidad de información que permita al investigador poder analizar las nuevas tendencias en los métodos de ataque, así como los principales objetivos perseguidos y los distintos orígenes de los ataques. El resultado de este análisis es recogido en informes cuyo objetivo es respaldar la toma de decisiones en la implantación de las medidas de seguridad preventivas.

  La principal ventaja de situar el honeypot en una red independiente, dedicada únicamente a la investigación, es la separación del sistema vulnerable del resto de sistemas productivos y evitar así la posibilidad de sufrir un ataque a través del propio honeypot. Por el contrario, el inconveniente es la cantidad de recursos necesarios. Sobre la arquitectura a emplear profundizaremos en próximos posts.

Otro método de clasificación de los “tarros de miel” es el que define la INTERACCIÓN con el atacante. En este caso, los honeypots se agrupan en dos tipos:

• Baja Interacción: El honeypot emula un servicio, una aplicación o un sistema vulnerable. Sus características principales son su sencilla instalación y configuración, junto con lo limitado de su capacidad para obtener diferentes tipos de datos. Unos ejemplos de honeypots de este tipo son:
  • Honeyd: Quizás uno de los honeypots más sencillos y populares. Es un demonio que crea hosts virtuales en una red. Los anfitriones pueden ser configurados para ejecutar servicios arbitrarios, y su comportamiento puede ser adaptado para que simule estar en ejecución en ciertos sistemas operativos.
  • HoneyC: El objetivo de este honeypot es la identificación de servidores web maliciosos en la red. Para ello emula varios clientes y recaba la mayor cantidad posible de información de las respuestas de los servidores cuando estos contestan a sus solicitudes de conexión. HoneyC es ampliable de diversas formas: pueden utilizarse diferentes clientes, sistemas de búsqueda y algoritmos de análisis.
  • Nephentes: Honeypot de baja interacción que pretende emular vulnerabilidades conocidas para recopilar información sobre posibles ataques. Nepenthes está diseñado para emular vulnerabilidades que los gusanos utilizan para propagarse y cuando estos intentan aprovecharlas, captura su código para su posterior análisis.
  • Honeytrap: Este honeypot está destinado a la observación de ataques contra servicios de red. En contraste con otros honeypots, que se suelen centrar en la recogida de malware, el objetivo de Honeytrap es la captura de exploits.
  • Glastopf: Emula miles de vulnerabilidades para recopilar datos de los ataques contra aplicaciones web. La base para la recolección de información es la respuesta correcta que se le ofrece al atacante cuando intenta explotar la aplicación web. Es fácil de configurar y una vez indexado por los buscadores, los intentos de explotación de sus vulnerabilidades se multiplican.
• Alta Interacción: En este caso el honeypot es una aplicación con la cual se puede interactuar y que responde como se espera, con la diferencia de que su diseño está orientado a realizar un registro exhaustivo de la actividad que se lleva a cabo sobre ella y de que la información que contiene no es relevante en ningún caso.
  • HI-HAT (High Interaction Honeypot Analysis Toolkit): Herramienta que transforma aplicaciones php en aplicaciones honeypot de alta interacción. Además ofrece una interfaz web que permite consultar y monitorizar los datos registrados.
  • HoneyBow: Herramienta de recopilación de malware que puede integrarse con el honeypot de baja interacción Nephentes para crear una herramienta de recolección mucho más completa.
  • Sebek: Funciona como un HIDS (Host-based Intrusion Detection System) permitiendo capturar una gran variedad de información sobre la actividad en un sistema ya que actúa a muy bajo nivel. Es una arquitectura cliente-servidor, con capacidad multiplataforma, que permite desplegar honeypots cliente en sistemas Windows, Linux, Solaris, *BSD, etc., que se encargan de la captura y el envío de la actividad recopilada hacia el servidor Sebek. Podríamos decir que forma parte de una tercera generación de honeypots.
  • Capture-HPC: Del tipo cliente, como HoneyC, identifica servidores potencialmente maliciosos interactuando con ellos, utilizando una máquina virtual dedicada y observando cambios de sistema no previstos o autorizados.

Otra opción a destacar en cuanto a la elección de un honeypot es la de la web Project HoneyPot. Se trata de un portal que facilita un recurso web para usarlo como honeypot. Este genera una página con un código script, la cual utiliza diversas técnicas para la recopilación de información (IPs, logins usados en ataques de fuerza bruta, spammers, etc…).

Para acabar con esta entrada, no quisiéramos dejar pasar la oportunidad de destacar un honeypot, creado por un español, que emula un servidor SSH y que se despliega con la intención de recopilar información de los diversos ataques que existen contra este servicio. Su nombre no podía ser más explícito: Kojoney. Pasen un buen fin de semana; nos vemos el lunes, aquí mismo.

(Entrada escrita en colaboración con Raúl Rodriguez, co-autor de la serie)

En el anterior post descubrimos las bondades de las ACL en GNU/Linux, i.e. cómo se podía aumentar la seguridad de nuestro sistemas a través de la granularidad que este sistema de acceso nos ofrecía. Hoy toca la parte menos bonita de las ACL, que en parte son la razón de que no sean ampliamente utilizadas en todo los sistemas Linux.

Una de las primeras cosas que saltan a la vista al usar ACL es que no son fáciles de administrar, al menos no tanto como los tradiciones controles de acceso. La información no está a la vista, y hay que usar comandos para inspeccionar cada fichero. Dado que cada objeto puede tener un numero variable de ACLs, puede resultar tedioso averiguar que permisos tienen los ficheros de un directorio determinado. Esto nos obliga a intentar reducir las ACL al mínimo, intentando usar las mismas ACL en todos los ficheros de un directorio e intentar usar tan sólo ACL de grupo para no tener casos demasiado específicos, lo que obviamente va contra la filosofía de las ACL.

En segundo lugar están los temas puramente técnicos. Como buenos administradores, deberemos hacer copias de seguridad, y es aquí cuando nos encontramos que el comando cp no funciona adecuadamente si no usamos la opción preserve:

# cp --preserve=all  ./ACL/prueba ./ACL2/

Así, al hacer copias de seguridad muchas veces usaremos el comando tar para empaquetar, y aquí es cuando nos damos cuenta de que tar no soporta los atributos extendidos en el sistema de ficheros. Investigando un poco aparece star, un tar “posix compliant” que permite realizar, usando un sistema de empaquetado especial, manejar dichos atributos. Para comprimir y empaquetar usaríamos:

# star -c acl2 -file=acl2.tar -H=exustar -acl 

-c: Directorio a archivar
-file: Nombre del fichero de salida
-H: formato del archivo tar, en nuestro caso exustar que es el que soporta ACL
-acl: Archiva los atributos extendidos de ACL

Para desempaquetar, más sencillo:

#star -vx file=acl2.tar

También querremos poder heredar permisos de las carpetas padre, para facilitar la tarea de asignar ACL y forzar a que dichos archivos tengan unos determinados permisos. Para ello debemos de recurrir a las “default ACL” que nos permiten indicar las ACL por defecto que heredará un objeto al crearse dentro de una carpeta padre, lo cual en Unix con los controles de acceso tradicionales se hace con el bit setgid.

#setfacl -d --set u:jvela:rw-,g:jvela:r--,o::- prueba_dir
# file: prueba_dir/ 
# owner: jvela 
# group: jvela 
user::rwx 
group::r-x 
other::r-- 
default:user::rw- 
default:group::r-- 
default:other::---

Aquí estamos asignando una ACL por defecto, sobrescribiendo las anteriores (se usa –set, no -m) para que todos los archivos que se creen en dicho directorio tengan una ACL para el usuario y grupo jvela
En este caso volvemos a toparnos con el mismo problema. Las posibilidades son enormes, pero su administración es compleja. Las ACL permiten mucho más, desde asignarlas recursivamente con la opción -R como con cualquier comando Unix, hasta clonar ACL desde un objeto. Podremos realizar casi cualquier tarea que realizamos con los controles de acceso normales, y con mucha más flexibilidad, pero con la contrapartida de una administración más compleja.

Hasta aquí todo lo básico para manejar ACL, donde hemos visto desde sus virtudes y la versatilidad que proveen hasta los problemas que conllevan y el cuidado que hay que tener con ellas. Nada más sobre este tema. Sean buenos y no acaben en un Active Directory por usar ACL ;)