Franchu’s lair

Hoy he estado trasteando con el AppleTV y me he dado cuenta de lo mucho que hecho en falta un editor de texto en él cuando quiero hacer cambios en algún fichero. Así que me he decidido a instalar vi y su Para ello he seguido los pasos indicados en esta guía. Ya que estaba también he instalado un servidor TFTP para almacenar la información de aprovisionamiento de un par de teléfonos IP… pero eso es otra historia.

Desde nuestra máquina con MacOS X transferimos los ejecutables de estos tres programas al AppleTV via scp

$ scp -1 -r /usr/bin/su frontrow@<AppleTVIPAddress>:~/
$ scp -1 -r /usr/bin/vim frontrow@<AppleTVIPAddress>:~/
$ scp -1 -r /usr/libexec/tftpd frontrow@<AppleTVIPAddress>:~/

Una vez que los ficheros están en el AppleTV nos conectamos por SSH al equipo para colocarlos en su sitio correcto.

$ ssh -1 frontrow@<AppleTVIPAddress>

Montamos el sistema de ficheros con permisos de escritura tras conseguir permisos de root y ponemos el grupo y propietario correcto a cada uno de los ficheros.

bash-2.05b$ sudo -s
bash-2.05b# mount -uw /
bash-2.05b# chown root su
bash-2.05b# chgrp wheel su
bash-2.05b# chown root vim
bash-2.05b# chgrp wheel vim
bash-2.05b# chown root tftpd
bash-2.05b# chgrp wheel tftpd

A continuación movemos los ficheros a sus directorios finales dónde espera encontrarlos el sistema.

bash-2.05b# mv su /usr/bin/su
bash-2.05b# mv vim /usr/bin/vim
bash-2.05b# mv tftpd /usr/libexec/tftpd

Por último solo nos queda configurar el servidor de TFTP para decirle dónde tenemos el directorio que tiene que servir. En caso de que no lo tengamos creado, lo hacemos antes de editar el fichero. Afortunadamente, vim ya está instalado y podemos editar el fichero directamente en nuestro AppleTV

bash-2.05b# mkdir /Users/frontrow/tftp
bash-2.05b# chmod 777 /Users/frontrow/tftp

bash-2.05b# vim /System/Library/LaunchDaemons/tftp.plist

<array>
<string>/usr/libexec/tftpd</string>
<string>-i</string>
<string>/Users/frontrow/tftp </array>

Por último, iniciamos el servicio de TFTP

bash-2.05b# /sbin/service tftp stop
bash-2.05b# /sbin/service tftp start

Ahora ya solo queda probarlo, ver que todo funciona correctamente y a disfrutarlo!

He leido una reflexión interesante acerca del nuevo “navegador” de Google: Chrome.

Si lo pensamos bien, Google Chrome es un navegador hecho a cachos tomando partes de otros navegadores y añadiendo funcionalidad nueva en el manejo de Javascript mediante el motor V8. La apuesta por los estándares y hacer la manipulación del DOM rápida es lo que necesita Google para poder hacer sus aplicaciones web competitivas frente a tecnologías alternativas de Adobe (FLEX) y Microsoft (Silverlight).

La combinación de la velocidad obtenida con V8 para hacer aplicaciones ricas basadas en Javascript y de Google Gears para permitir el trabajo offline, hace que Google Chrome sea la plataforma perfecta para que las aplicaciones de Google (Google Reader, Google Docs, …) den el salto de meras aplicaciones web a aplicaciones de escritorio accesibles desde cualquier lugar.

Sin duda, se presenta ante nosotros una batalla mucho más interesante que la anunciada como nueva guerra de los navegadores… estamos ante algo que puede desestabilizar el concepto de aplicaciones de escritorio como lo hemos conocido hasta ahora. De hecho, no es casualidad que solo lo hayan sacado de momento para Windows

He encontrado una página en la que explican de forma sencilla y visual el funcionamiento del sistema DNS y la vulnerabilidad descubierta por Kaminsky.

A grandes rasgos todo se reduce a engañar al servidor DNS que se desea comprometer para que tome como válida una respuesta que no proviene de una fuente fiable. Esto que a priori puede parecer muy complicado, se ve facilitado por un fallo de diseño del sistema DNS y una implementación poco cuidadosa en el software servidor de DNS más popular a nivel mundial.

An Illustrated Guide to the Kaminsky DNS Vulnerability via kwout

El proceso se puede resumir en los siguientes pasos:

• 1 - El atacante manda una petición DNS al servidor victima para un nombre de host que quiere comprometer. En este ejemplo se asume que el servidor de nombres permite peticiones recursivas desde el mundo exterior.
• 2a - Sabiendo que el servidor victima pedirá en breve a ns1.bankofsteve.com (tal como se lo indicarán los servidores raiz/GTLD) una dirección IP para www.bankofsteve.com, el atacante comienza a inundar con paquetes de respuesta DNS con el fin de que ns1.bankofsteve.com tome por buena la respuesta fraudulenta y asigne a www.bankofsteve.com una IP falsa.
• 2b & 3 - Los servidores raiz/GTLD indican que la petición ha de redirigirse a ns1.bankofsteve.com.
• 4 - El servidor de nombres víctima pide a ns1.bankofsteve.com la dirección IP de www.bankofsteve.com y utiliza el query ID 1001 (uno más que la petición anterior).
• 5 - El servidor de nombres real (ns1.bankofsteve.com) proporciona una respuesta legítima a la petición con un Query ID de 1001, pero si el atacante ha enviado una respuesta con el mismo Query ID en el paso 2a, esta respuesta legítima llega demasiado tarde y es ignorada.
• 6 - Con la dirección IP falsa (del servidor web del atacante) en el cache el servidor ha quedado comprometido y todas las peticiones al servidor DNS para www.bankofsteve.com (la actual y futuras) redirigen al servidor del atacante.

Como podeis ver es un ataque muy sencillo y peligroso contra el que se han tomado una serie de medidas como añadir aleatoriedad al query ID y ampliar el espacio de query ID posibles desde 16K hasta aproximadamente 113M añadiendo aleatoriedad en el puerto que se utiliza para realizar las peticiones DNS. Para una explicación más detallada os recomiendo que leais el fantástico artículo original.