m313 Security Blog

===============================
- Rooted CON 2010 -
C A L L F O R P A P E R S
===============================

.: [ INTRO ]

Rooted CON es un Congreso de Seguridad que se celebrará en Madrid
(España) en Marzo de 2010. Nuestro objetivo es promover la seguridad,
ofreciendo charlas altamente técnicas con un enfoque práctico (combinación
de teoría / demo) y neutralidad (aunque apostamos por las empresas y
queremos que éstas participen en el congreso, deberá primar el contenido
técnico y objetivo).

También deseamos que la gente participe, se divierta… ¡y hasta se
lleve un premio a casa! Por ello, llevaremos a cabo diversos eventos
(aparte de las conferencias), siendo uno de los más importantes el
concurso CTF (”Capture the flag”), que contará con importantes premios
en metálico y que ha sido diseñado por ni más ni menos que uno de los
“Sexy Pandas” (equipo finalista del tradicional “Defcon CTF”).

Y por supuesto si todavía te quedan fuerzas también podrás aprovechar
para vivir a tope el encanto de las noches madrileñas…

.: [ FORMATO ]

Nos gustaría recibir dos tipos de propuestas:
- charlas rápidas. Duración: 20′.
- charlas normales. Duración: 50′.

Si tienes una idea loca/interesante y fresca que se puede contar en
poco tiempo, por favor, no lo dudes y propón una charla rápida. Si tu
idea es más loca todavía y necesitas más tiempo para explicarla en
profundidad usa la segunda modalidad: la charla normal.

Sólo aceptaremos propuestas en español e inglés. Haremos todo lo
posible para tener traducción simultánea en la sala pero no podemos
prometer nada ya que dependerá del presupuesto y de los patrocinadores.

.: [ TEMÁTICA ]

Nos interesa cualquier tema puntero del mercado de la seguridad. Éstos
son sólo algunos ejemplos:
- técnicas innovadoras tanto defensivas como ofensivas.
- todo lo relacionado con el fraude, phishing, troyanos en entornos
financieros, mecanismos de protección asociados, etc.
- “ingeniería inversa”, técnicas de bajo nivel, kernel, …
- descubrimiento de vulnerabilidades, “fuzzing” y técnicas relacionadas.
- ataques en entornos virtualizados, sistemas de cluster, “cloud
computing” y nuevos productos de seguridad “en la nube”.
- criptografía y criptoanálisis.
- seguridad en entornos móviles.
- herramientas de hacking: desarrollos propios.
- seguridad documental.
- voz sobre IP, “phreaking”, …
- análisis forense y contramedidas.
- seguridad en dispositivos inalámbricos.
- esteganografía y todo tipo de canales subliminales.
- seguridad en aplicaciones web.
- …

.: [ PROCEDIMIENTO PARA PRESENTAR UNA PROPUESTA ]

¿Te gustaría hablar en Rooted CON? ¡No te olvides de hacer las charlas
ilustrativas e incluir demos!

Envíanos tu solicitud por correo electrónico a:
cfp -AT- rootedcon.es

Para que tu charla sea aceptada en el proceso inicial de selección
*deberá* respetar el formato descrito previamente e incluir *toda* la
información siguiente:

- título
- autor (nombre completo y opcionalmente nick/apodo)
- bio (unas líneas diciendo quién eres)
- duración (¿charla normal o rápida?)
- resumen (deberá ser lo suficientemente extenso como para poder ser
correctamente evaluado)
- ubicación/nacionalidad
- medios necesarios para impartir la charla
- ¿tienes pensado dar la misma (o similar) charla en otras conferencias?
¿En cuál?

.: [ FECHAS ]

1 Octubre, 2009 – Se abre el CFP.
20 Diciemebre, 2009 – Se cierra el CFP.
31 Diciembre, 2009 – Ponentes seleccionados.
10 Enero, 2010 – Entrega del “paper” final y materiales de la presentación.

.: [ PRIVILEGIOS PARA PONENTES ]

Los ponentes gozarán de los siguientes beneficios:
- Alojamiento gratuito.
- Acceso gratuito al congreso.
- Gastos de viaje (en la medida de lo posible).
- Tickets/bebidas gratis durante la fiesta.

.: [ PATROCINADORES ]

Todavía tienes la oportunidad de ayudarnos a organizar el mejor
congreso de seguridad de España y a la vez obtener un interesante ROI.
Si estás interesado en ser uno de nuestros patrocinadores, por favor
contacta con nosotros:

patrocinio -AT- rootedcon.es

.: [ ENLACES ]

- Sitio Web
http://www.rootedcon.es/
- Grupo en Facebook
http://www.facebook.com/group.php?gid=96410924798
- Grupo en LinkedIn
http://www.linkedin.com/groups?gid=1969438
- Lista de correo “sólo-anuncios”
https://listas.rootedcon.es/mailman/listinfo/rooted-announce

-=EOF=-

Compártelo

La red Tor no se centra únicamente en capas de cebolla para permitir anonimato en las conexiones. Una de las características más interesantes es la que trataremos hoy: los servicios ocultos.
Un servicio oculto consiste fundamentalmente en un aplicativo en el servidor (web, bbdd, irc, etc) que está accesible únicamente desde dentro de la red TOR. La característica que hace interesante a estos servicios es que no es posible saber en qué máquina física se encuentra ejecutándose el servicio en cuestión.

Imaginemos un país en el que la libertad de expresión no esté asegurada, España por ejemplo. Resulta interesante crear una web en la que pueda asegurarse la libertad de expresión puesto que no es posible saber la máquina física en la que se ejecuta el aplicativo web. Otro enfoque interesante puede resultar crear un servicio con la intención de que nadie acceda a él, esto es posible con TOR ya que la dirección de acceso a los servicios ocultos no es publicada, ni indexada por arañas o buscadores web por el simple hecho de estar levantadas. Evidentemente si alguien publica en una web la dirección de acceso una araña conseguirá indexarlo. La principal finalidad es mantener anónima la máquina física que ejecuta el servicio.

Si te interesa el tema te estarás preguntando cómo funcionan tecnicamente los servicios ocultos. Lo explico brevemente:
Cuando un servicio oculto se crea localmente en la máquina se producen un par de claves: pública y privada. Asímismo se crea lo que se llama un descriptor de producto, que consiste en la lista de direcciones de acceso al servico junto con la clave pública del mismo. Este descriptor se publica anónimamente en los servidores de directorio de TOR, y son estos los que redireccionan al sistema en concreto (no directamente) cuando un cliente de TOR solicita acceso a la dirección del servicio oculto solicitada.

En el presente artículo crearemos un servicio web oculto. Nos basamos en la guía oficial de creación de servicios ocultos.
El primer paso es crear ese servicio de manera normal en el sistema, en nuestro caso un simple servidor web con Apache en el que colocamos una página estática, como podemos ver a continuación:

Ahora nos centraremos en Torificar dicho servicio para hacerlo oculto. Partimos de la base de que tenemos un repetidor TOR instalado, para hacerlo podemos consultar el artículo al respecto que publiqué recientemente.
Una vez hecho simplemente tenemos que modificar dos variables en el fichero /etc/tor/torrc:

HiddenServiceDir /var/lib/tor/hidden_service/
HiddenServicePort 80 127.0.0.1:80

La variable HiddenServiceDir sirve para indicar un directorio del sistema en el que TOR guardará información necesaria para trabajar con el servicio oculto. Entre dicha información se encuentran la dirección de acceso al servicio, certificados, etc. Es necesario que solo root tenga acceso a dicho directorio, por ejemplo permisos 700.
La variable HiddenServicePort sirve para indicarle a TOR dónde se enucentra dicho servicio, el formato es “puerto IP:Puerto“, de esta manera indicamos el puerto al que deben referenciar los accesos y la IP y puerto real en la que el servicio se encuentra escuchando. esto es importante porque si bien en nuestro ejemplo el servicio se pide en el mismo puerto y máquina, podríamos referenciarlo a otro sistema y/o puerto.

Una vez configurado levantamos el servicio en cuestión y el servicio TOR. Para saber mediante qué dirección URL podemos acceder al servicio simplemente consultamos el nombre del mismo en el directorio local del sistema:

Para acceder a dicho servicio configuramos el navegador en la red TOR y pedimos la URL indicada:

Si observamos los ficheros de log de Apache podemos apreciar que no apareceran las IP’s de acceso de los visitantes, ya que estarán referenciadas por la IP que marcamos en el fichero de configuración de TOR:

Hasta aquí la creación de servicios ocultos, en próximos artículos me gustaría indagar sobre desventajas del uso de esta red y posibles defectos en ella. Pero eso será probablemente tras unas merecidas vacaciones.

Compártelo

La red de anonimato de TOR se basa fundamentalmente en dirigir el tráfico a través de una serie de nodos o repetidores que forman parte de la red TOR y que encapsulan el paquete en sucesivas capas, de manera que “nadie” sabe el destino del mismo hasta que el paquete llega a un repetidor de salida. Para ello se utiliza el concepto de Onion Routing.

No voy a explayarme porque no creo que pueda expresarlo mejor que la página oficial, con gráficos y demás. Analizar en profundidad esto queda fuera del objeto de este post pero quisiera remitir a los interesados unas URL’s para profundizar sobre el tema:

https://wiki.torproject.org/noreply/TheOnionRouter
https://git.torproject.org/checkout/tor/master/doc/design-paper/tor-design.pdf
https://git.torproject.org/checkout/tor/master/doc/spec/tor-spec.txt
https://git.torproject.org/checkout/tor/master/doc/spec/control-spec.txt
https://git.torproject.org/checkout/tor/master/doc/spec/rend-spec.txt
https://git.torproject.org/checkout/tor/master/doc/spec/dir-spec.txt
https://git.torproject.org/checkout/tor/master/doc/spec/path-spec.txt

Entre las características interesantes que esta red ofrece destacan de manera especial los “servicios ocultos”, que son distintos tipos de servicios (web, irc, etc) que sólo son accesibles para y desde la red TOR, y que tienen la propiedad de que teóricamente no es posible saber el sitio físico o PC concreto en el que está alojado dicho servicio. En próximos post crearemos uno y hablaremos de ellos.

Una de las cosas importantes a tener en cuenta es que la “calidad” de la privacidad es directamente proporcional al número de repetidores que haya en la red. Este post se centrará en explicar brevemente cómo crear de manera sencilla un nodo repetidor de TOR sobre un sistema Linux, concretamente sobre un Fedora Linux 10.
Primero hay que destacar que hay dos tipos de repetidores, los internos y los de salida. Configurar un nodo de salida puede traer algunas complicaciones que explicaremos en un futuro post, y veremos cómo hacerlo. De momento nos centraremos en un repetidor interno, que basicamente sirve para marear peticiones con el objeto de conseguir una privacidad aceptable.

La página oficial de TOR tiene abundante documentación, recomiendo mirar la guía para configurar repetidores, aunque aquí explicaré brevemente como hacerlo en dos patadas.

== Instalando TOR ==

Tor está en los repositorios de Fedora por lo que instalar el software es tan sencillo como ejecutar el siguiente comando con privilegios de administración:

yum install tor

== Configurando TOR como repetidor interno ==

El fichero de configuración de TOR se encuentra en /etc/tor/torrc y para crear un sencillo repetidor interno basta con las siguientes opciones:

SocksPort 9050 # puerto para las conexiones locales
SocksListenAddress 127.0.0.1 # aceptar conexiones de localhost
Log notice file /var/log/tor/notices.log # fichero de log notice
Log debug file /var/log/tor/debug.log # fichero de log de depuracion
Log notice syslog # facility del syslog
RunAsDaemon 1 # ejecutar el servicio como demonio
DataDirectory /var/lib/tor/.tor # directorio de datos
Nickname mordor # nombre del repetidor
RelayBandwidthRate 50 KBytes # Throttle traffic to 100KB/s (800Kbps)
RelayBandwidthBurst 50 KBytes # But allow bursts up to 200KB/s (1600Kbps)
ORPort 9001 # puerto en el que se esperan conexiones
DirPort 9030 # puerto para solicitar conexiones, ideal si tienes mucho ancho de banda para compartir
Group toranon # grupo con el que se ejecutará
User toranon # usuario con el que se ejecutará

hay que destacar que si tienes una conexión ADSL normal y corriente tendrás que hacer NAT contra tu sistema para los puertos definidos en las variables ORPort y DirPort.

== Comprobar que funciona ==

Para comprobar que está en ejecución sin problemas debemos recurrir al log, que se encuentra en la ruta /etc/tor/torrc, para que funcione debería tener un aspecto similar a esto:

May 02 01:12:06.368 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
May 02 01:12:06.368 [notice] Now checking whether ORPort 83.44.185.90:9001 and DirPort 83.44.185.90:9030 are reachable… (this may take up to 20 minutes — look for log messages indicating success)
May 02 01:12:11.307 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
May 02 01:12:11.528 [notice] Self-testing indicates your DirPort is reachable from the outside. Excellent.
May 02 01:12:30.024 [notice] Performing bandwidth self-test…done.

Adicionalmente una vez que el servidor es accesible a la red sus datos serán subidos a los llamados “descriptores de servidor” y en ellos podremos comprobar que nuestro nodo forma parte de la red TOR, en mi caso he usado un descriptor (http://moria.seul.org:9032/tor/status/authority) para comprobar que mi nodo “mordor” forma parte de la red:

== Funcionando ==

Una vez que funcione hay varias recomendaciones que pueden leerse en la guía oficial. Por mi parte simplemente he querido ver un poco qué es lo que se mueve en esta red y para ello he levantado un sniffer (tcpdump) y he inspeccionado el tráfico que pasa por mi nodo.
Tenemos por tanto un fichero .cap con el tráfico interceptado. Para analizarlo utilizaremos Wireshark. Vamos a distinguir dos tipos de comunicaciones:

1. Tráfico de solicitud de conexiones.
Este tipo de tráfico se transmite entre los nodos internos y los servidores de directorio y es necesario para poder calcular las rutas por las que viajarán los paquetes. Este tráfico utilza el puerto que hayamos definido en la variable DirPort, en nuestro caso el 9030, asique aplicaremos el siguiente filtro al Wireshark:

tcp.port == 9030 || udp.port == 9030

Si ensamblamos la comunicación TCP tenemos dos tipos de comunicaciones, en el primer tipo tenemos una comunicación parcialmente cifrada

La IP de nuestro repetidor es la 192.168.1.33 y por lo que podemos ver una IP perteneciente a otro repetidor (podemos contrastarlo consultando en el descriptor de servidor comentado anteriormente) realiza una petición http GET a la que nuestro repetidor contesta con un 200 OK.
El contenido de dicha respuesta está cifrado.

En el segundo tipo de petición tenemos algo similar a la anterior, pero con una respuesta negativa (400 NOT FOUND):

2. Tráfico entre repetidores.
Este es el tráfico más abundante y se realiza mediante el puerto definido en la variable ORPort, en nuestro caso el 9001, asique aplicaremos el siguiente filtro al Wireshark:

tcp.port == 9001 || udp.port == 9001

Como podemos comprobar en las siguientes capturas el tráfico va cifrado y se produce únicamente entre IP’s que pertenecen a repetidores (podemos contrastarlo consultando en el descriptor de servidor comentado anteriormente):

En las próximas entradas configuraremos un nodo de salida y comprobaremos cómo en este caso sí pueden inspeccionarse los datos de salida.

Compártelo