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.

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.

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.

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.

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.

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

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

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:

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:

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.