Posted in SSOO, Tips on June 10th, 2009 by m313
Fedora 11 acaba de salir con el sobrenombre de Leónidas. Entre sus grandes novedades destacan la autenticación mediante huella digital, mejoras en el sonido con pulseaudio, en la paquetería con Presto, modesetting, etc.
Este sencillo post pretende exponer tres sencillos comandos necesarios para actualizar nuestros sistemas a Fedora 11:
yum update
yum install preupgrade
preupgrade-cli “Fedora 11 (Leonidas)”
Posted in Forensic on June 8th, 2009 by m313
Los chicos de la distribución forense DEFT Linux han publicado recientemente la herramienta Deft Extra. Este conjunto de herramientas vienen a rellnenar el hueco dejado por las herramientas de Helix para Windows.
La apariencia de este toolkit es muy buena, tenemos las herramientas clasificadas en pestañas según la funcionalidad:
La pestaña de “Forensics Tools” aglomera una gran cantidad de programas:
Al igual que en la Helix se puede navegar el sistema de ficheros y escanear el sistema en busca de imágenes. Por último tenemos una pestaña dedicada a multitud de software diverso que puede resultarnos util en una investigación:
DEFT Extra se puede descargar desde la siguiente dirección.
Posted in Fraude on June 5th, 2009 by m313
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.
Posted in Fraude on May 3rd, 2009 by m313
La privacidad en internet no es un tema nuevo. Hace ya más de 15 años que Phil Zimmermann se las vió y se las deseó por sacar PGP a la red. Debian Lin
ux ofrecía distintas versiones del CD1 en función del país debido a la exportación de algoritmos criptográficos. Slackware Linux se estableció en Canadá por temas similares. Y es que a la NSA no le gusta que utilzemos algoritmos que no puedan romper facilmente. Telnet forever, ¿para qué SSH?
Simplemente leer un poco de la actualidad nos basta para intuir que se están produciendo movimientos en favor de controlar la red. Y aunque los que desean el control del la red siempre tendrán lacayos que disfracen la verdad lo cierto es que caminamos hacia una red en la que nuestra privacidad está en peligro. Y es que recientes estudios indican que pasamos más tiempo en la red que en los medios tradicionales: TV, radio, etc ¿Tendrá esto algo que ver?
La falsa sensación de anonimato que proporciona la red juega en su favor. También el pasotismo que hay tras las simples reflexiones de: “que me registren, yo no tengo nada que esconder“. No me imagino a nadie en un probador de un centro comercial al descubierto, sin cortina, para dificultar el trabajo a los ladrones, ya que no tenemos nada que esconder y así pillaran a los malos más facilmente.
Es el viejo truco de siempre, esparce un poco de miedo y la gente olvidará sus derechos y libertades en favor del salvador que los proteja.
Las opciones que tenemos pasan por dos vías fundamentalmente, integrar la criptografía en el mayor número de transacciones que llevemos a cabo a través de la red y en las redes anónimas. En las siguientes entradas trataré de hacer un repaso a la red de anonimato más conocida en la actualidad: la red TOR. Repasaremos sus virtudes y sus miserias y trataré de que al menos algunos de los que me leéis centréis vuestra atención en lo que es un problema importante, de actualidad y que nos afecta a todos.
Posted in Forensic on April 29th, 2009 by m313
Hace poco leí un artículo muy interesante en el blog Forensics from the sausage factory que trataba sobre los rastros que dejan las conversaciones en Facebook en los sistemas y cómo recuperar fragmentos y conversaciones en los mismos.
La idea utilizada es muy simple: el chat de Facebook utiliza tecnología JSON por lo que realizando busquedas mediante patrones en expresiones regulares sería posible encontrar rastros que hayan podido quedar en cualquier parte del sistema, ficheros temporales, memoria, etc.
El artículo es muy interesante y recomiendo su lectura acompañada de algo de trasteo. Curiosamente pocos días después de publicar este artículo el blogger daba cuenta de una herramienta automática existente que realiza estas tareas, añadiendo algunos sistemas de mensajería instantánea adicionales: msn y yahoo. La herramienta se llama Internet Evidence Finder y funciona sobre plataformas Windows. Es una herramienta de facil uso, como podemos ver a continuación:
Sin embargo he estado realizando pruebas con ella y no ha sido muy eficiente buscando conversaciones de chat en facebook, o quizá sea que el sistema que he utilizado para las pruebas no ha dejado migas de pan durante la conversación, cosa que sí ha hecho en el caso del archiconocido Windows Live Messenger, del que recolectó abundantes datos como el que muestro a continuación:
jajaajajjaMSG correo@hotmail.com nick_sesgado 93
MIME-Version: 1.0
Content-Type: text/x-msmsgscontrol
TypingUser: correo@hotmail.comMSG correo@hotmail.com nick_sesgado 141
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
X-MMS-IM-Format: FN=Verdana; EF=B; CO=986332; CS=0; PF=22eso si que es cierto
== Referencias ==
http://forensicsfromthesausagefactory.blogspot.com
http://www.jadsoftware.com/home/ief.htm
http://es.wikipedia.org/wiki/JSON