Security Art Work

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 ;)

Desde siempre el spam ha sido un problema para el buen funcionamiento de cualquier proyecto web. Tampoco es un secreto que uno de los mayores factores de generación de spam son los robots que recorren la totalidad de multitud de webs dejando huella de su paso en forma de, generalmente, comentarios y mensajes con contenido malicioso.

Pero, ¿qué medidas fiables tenemos para luchar contra el problema del spam? Muchos se basan en hacer que el usuario introduzca un texto o resultado de operación matemática, incluyéndolo de forma que una persona lo pueda procesar fácilmente pero no así un robot; estos son los conocidos Captchas. En este caso estamos dejando al usuario malintencionado (o robot de spam) entrar a nuestra web, e intentamos evitar que interactúe con ella.

Esta alternativa que les presentamos, llamada Bad Behaviour por razones obvias, partiendo de la base de la lucha contra el spam va un paso más allá, impidiendo a estos usuarios (o robots) maliciosos la entrada a su página web objetivo. Esto está muy bien pero, ¿cómo funciona Bad Behaviour? Es muy sencillo. La aplicación recibe cada petición realizada a su entorno web y comprueba diversos parámetros de la misma para detectar si la petición la ha realizado un usuario legítimo y no se trata de ningún robot ni usuario malintencionado. En caso de que encuentre una petición de este tipo, devuelve un simple error del tipo “403 Bad Behaviour”, en lugar del contenido original de la página solicitada.

Entrando más al detalle, este proceso se realiza de dos formas claramente diferenciadas. Por una parte la aplicación contiene un listado de posibles elementos o comportamientos que pueden convertir una petición en sospechosa de ser maliciosa (por ejemplo cabeceras erróneas, como la User-Agent, o peticiones que no respetan el contenido del fichero robots.txt en caso de que lo tengamos configurado), y por otra rechaza peticiones de orígenes maliciosos al conectarse a una base de datos pública de IPs maliciosas constantemente actualizada.

Este proceso puede parecer lento y su demanda de recursos alta, pero se ha demostrado que puede llegar a introducir una mejora en el tiempo de carga de las webs ya que al bloquear los accesos malintencionados se dejan de enviar páginas web completas (con todos sus elementos y contenido multimedia) y se envía un simple mensaje de error en su lugar, lo que reduce considerablemente el ancho de banda consumido por estas peticiones y la carga de los servidores.

En lo que respecta a la instalación, esta aplicación se creó inicialmente como una extensión para WordPress (motor que da vida a este mismo blog), pero su diseño modular le permite adaptarse a prácticamente cualquier aplicación basada en PHP. Actualmente existen instrucciones de instalación para otras de las aplicaciones web más comunes como MediaWiki, Drupal, DokuWiki y Geeklog, e incluso algunos CMS lo incluyen en su instalación por defecto (es el caso de LifeType).

Si no la conocían, espero que la prueben y nos dejen sus comentarios sobre la funcionalidad de esta aplicación y su funcionamiento.

Como muchos de ustedes sabrán, el pasado 6 de abril el INTECO (Instituto Nacional de Tecnologías de la Comunicación) publicó la primera versión de su aplicación ConAn, su herramienta de análisis de seguridad para entornos Windows. Se presenta como un complemento a otros sistemas de seguridad que pueda tener el cliente instalados en su máquina, ya que no interfiere en el funcionamiento de antivirus ni firewalls, sino que los complementa.

En lo que respecta a funcionalidad, ConAn agrupa la funcionalidad que hasta ahora ofrecían por separado otras herramientas, permitiendo por ejemplo revisar, entre otros, las actualizaciones del sistema y la seguridad de Internet Explorer (al estilo de MBSA), detalles sobre los procesos y servicios en ejecución (al estilo de multitud de programas, entre los que se encuentra el archiconocido Process Explorer, de Sysinternals), detalles sobre las conexiones de red establecidas y los programas que las están realizando (como en cualquier software cortafuegos), etcétera.

Para utilizar esta aplicación es necesario registrarse previamente en la web que INTECO ha preparado al respecto para posteriormente proceder a la descarga de la aplicación. La descarga es liviana (ocupa menos de 1MB) y su proceso de instalación es el típico de aplicaciones Windows.

Una vez instalada, la aplicación pide de nuevo los datos de conexión utilizados para descargar la aplicación, dado que tras el análisis del sistema (proceso que realiza con bastante celeridad, al menos en las máquinas probadas) la aplicación vuelca el informe a la web de INTECO, para que pueda ser accedido posteriormente con mayor facilidad. Si no disponemos de conexión a Internet en la máquina a analizar tampoco hay ningún problema, ya que podremos realizar el análisis sin conexión y enviarlo posteriormente en el apartado correspondiente de la web de ConAn.

Dejando aparte los posibles problemas de privacidad y robo de datos que este envío de informes pudiera suponer y que discutiremos en otras entradas, cabe remarcar que los informes destacan por su buena estructura, el uso de iconos para mostrar los distintos niveles de seguridad y el uso de un lenguaje claro y directo que los usuarios poco familiarizados con los entresijos de la informática seguro que podrán entender. Además, en cada punto del informe se proporcionan una serie de recomendaciones de seguridad proporcionadas por la Oficina de Seguridad del Internauta, y también información adicional de organismos y otras fuentes externas, que complementan la información proporcionada por el propio INTECO. A continuación hemos incluido algunas pantallas del programa, aunque es recomendable que lo prueben ustedes mismos.

Más información y noticia original en INTECO.

Descarga del programa: ConAn

Siguiendo con la entrada sobre la inseguridad de sentirse seguro, me gustaría ahora describirles 3 tecnologías de uso habitual que dan una falsa sensación de seguridad:

– Antivirus: Siempre que le explico a algún no especialista que es un antivirus, le explico que no es un “antivirus”. Es muy sencillo; un antivirus es la forma abreviada (o comercial) de decir que es un antivirus de virus conocidos. Sí, existen módulos heurísticos y otras historias de ciencia ficción, pero la realidad es que los virus nuevos no son detectados por los antivirus hasta que son conocidos. Esto implica que si tenemos la mala suerte de toparnos con un virus de relativa novedad no conocido por nuestro antivirus, éste será de poca utilidad. Obviamente, aunque el antivirus que utilizamos lo reconozca, si el nuestro no se encuentra actualizado, la consecuencia es la misma, de ahí la importancia de actualizar las firmas del AV.

– IDS de red: Los IDS tienen el mismo problema que los antivirus: son “IDSs de patrones conocidos”, pero son mucho peores que los AV ya que por lo general no toman medidas inmediatas, sino que se limitan a registrar e informar. Además, existen numerosas ocasiones en las que están “ciegos”, como por ejemplo en el tráfico cifrado en el que funcionan todas nuestras web corporativas importantes. Además únicamente registran intrusos en base a patrones “técnicos”, pero no a nivel de “negocio”, de modo que alguien puede estar haciendo transferencias bancarias de forma masiva, y el IDS sólo vera un usuario utilizando la aplicación de transferencias.

– Los auditores de vulnerabilidades (Nessus / OpenVAS / etc): Volvemos a lo mismo. No podemos estar tranquilos con haber pasado un scanner de vulnerabilidades y ver que todo queda corregido, dado que éstos únicamente lo son de vulnerabilidades conocidas y en su gran mayoría de software conocido, por lo que todos los desarrollos adhoc pueden ser completamente vulnerables a ataques de todo tipo y pasar inadvertidos. Es cierto que en este campo las herramientas están evolucionando y cada vez son mas capaces de analizar desarrollos desconocidos, pero cualquier auditoria automática de este tipo debería incluir un disclaimer en el que se indique que la herramienta sólo comprueba vulnerabilidades en versiones y configuraciones de programas conocidos, por lo que no incluye la detección de problemas en desarrollos propios, programas no conocidos o partes no públicas que pueden ser facilmente explotables por usuarios maliciosos. De aquí la necesidad e importancia de que una auditoría de este tipo sea complementada con auditorías manuales, tanto de los desarrollos a nivel de código, como a nivel de interacción con el usuario final.

Dicho esto, ¿cómo actuar en estos casos? El planteamiento es muy sencillo: se debe trabajar con el supuesto de que las herramientas no existen:

– Antivirus: Debemos actuar como si no se dispusiera de antivirus. En un entorno de oficina, por ejemplo, no ejecutar programas de los que no se conozca el origen, limitar la ejecución de binarios y código externo, eliminar los ejecutables que llegan por correo electrónico, restringir la descarga de ejecutables a través del proxy web, y deshabilitar el acceso a programas en unidades CD/USB.

– Detección de intrusos de red: Al IDS de red le pasan desapercibidas muchas cosas, y potencialmente puede generar un gran número de falsos positivos. No obstante, si conoce su negocio y sus aplicaciones seguro que sabe dónde mirar para detectar cosas extrañas; trate de añadir IDS de host, o integrados dentro de la lógica del negocio, ya que serán mucho más efectivos. Y por supuesto no los utilice como excusa para no tener en perfecto estado de revista la seguridad de sus servidores.

– Auditorías de vulnerabilidades: Como se ha comentado, no es suficiente con los análisis que se limitan a los datos de la caja negra. Debemos revisar de manera no exclusivamente automática las actualizaciones de versiones de los programas, su funcionamiento cuando interactúan con el usuario, la configuración de las aplicaciones con respecto a la seguridad (usando guías de buenas practicas, o mediante el análisis de todas sus funcionalidades), y por supuesto controlar el desarrollo desde su orígenes, incluyendo la seguridad en todo el ciclo. La idea es que el hecho de que la herramienta de auditoría que utilizamos no haya encontrado un problema de seguridad no significa que no exista, e incluso puede estar más cerca de lo que pensamos.

Entonces, ¿dejamos de utilizar estas incompletas e imperfectas medidas de seguridad? Repasemos de nuevo los tres puntos:

– Antivirus: Hoy en día, en ninguna cabeza cabe el no disponer de antivirus en cualquier entorno Windows, así que además de aplicar las prácticas seguras descritas previamente, hay que asegurarse de su correcta actualización de este, para que al menos esté al día de los virus conocidos. Es decir, que obviamente sí lo debemos de tener.

– IDS: Mi opinion sobre los IDS (no compartida por muchos miembros de este blog) es que son bastante inútiles (esta entrada que va un poco en esa línea), y si no tienen funcionalidad automática de IPS sirven para muy poco (aunque eso puede generar otro tipo de problemas diferentes). En todo caso, la mayor utilidad que le veo a un IDS es la de detectar malware interno poco sofisticado, es decir intrusos internos, con lo que sí pueden ser positivos, aunque el objetivo debería ser que no llegaran dentro. También puede ser útil como herramienta de diagnóstico, para buscar algún patrón concreto en difusión amplia de malware. En definitiva, para ciertas finalidades contar con un IDS es sumamente interesante.

– Auditor de vulnerabilidades: Aunque sean herramientas imperfectas, por su bajo coste de ejecución (se realiza de manera centralizada) pueden ser un primer paso para auditar una red. Aunque es verdad que cada vez son mas inteligentes y son mas capaces de auditar desarrollos genéricos (sqlmap es una maravilla), siguen siendo potencialmente peligrosas en cuanto a que la visión de auditoria de caja negra dista mucho de ser todo lo completa que la puede realizar un “humano” y puede generar una percepción de seguridad inexistente, además de ser infinitamente mas incompleta que una auditoria de caja blanca.

Como creo que era de esperar, usen todas ellas, pero tengan en cuenta siempre los disclaimers correspondientes y no se queden tranquilos con estos “false friends“. En una entrada posterior veremos qué pasa con las certificaciones: ¿”false friends“, o no?

(Continuamos con la interrupción de las entradas de la Black Hat, en este caso para hablar de PVLANs. El lunes que viene sin falta retomamos el día 2 de la BH)

Hace unas semanas, José Luis introducía el concepto de Private VLANs (PVLANs) para la securización de las DMZ. Vamos a ver en esta entrada algunos aspectos interesantes de esta tecnología.

Como vimos, las PVLANs (Private Vlan’s) consiguen el objetivo propuesto de aislar los servidores de la DMZ unos de otros. Lo que no está claro es qué rango de direcciones IP, o mejor dicho a qué subred va a ir asociado cada servidor. Hay gente que tiene la falsa creencia de que para conseguir aislar los servidores unos de otros tenemos que gastar subredes distintas, utilizando una para cada servidor, e incluso gastando para ello las PVLAN’s. Y aquí es donde radica la ventaja de dicha tecnología: sólo necesitamos una subred para asignar direcciones IP a nuestros servidores alojados en la DMZ. Por ejemplo, si disponemos de 50 servidores en la DMZ, y no queremos que se vean unos a otros, en lugar de utilizar 50 subredes diferentes (por ejemplo, 192.168.1.x, 192.168.2.x., …, 192.168.50.x) podemos utilizar una única subred para todos ellos (por ejemplo, 192.168.1.1, 192.168.1.2, …, 192.168.1.50), y con PVLANs conseguiríamos el objetivo de aislar los servidores, dando la sensación de que cada servidor está aislado del resto.

[Read more…]

(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.

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.