Tarea 4

PARTE I

Comenzamos la unidad 2 abriendo wireshark para ver una captura de tráfico:

Enunciado: En esta tarea no vamos a realizar capturas en vivo de tráfico, sino que vamos a analizar trazas (capturas) ya realizadas con anterioridad y salvadas en archivos. En este caso, vamos a usar la traza telnet-raw.pcap, del repositorio de capturas disponible en Wireshark.

Preguntas:

• ¿Qué usuario y contraseña se ha utilizado para acceder al servidor de Telnet?
• ¿Qué sistema operativo corre en la máquina?
• ¿Qué comandos se ejecutan en esta sesión?

Respuestas:

Lanzamos Wireshark, abrimos el fichero pcap que nos indican y filtramos por el tráfico telnet como se nos indica. Una vez hecho esto, clicamos con el boton derecho sobre ese tráfico y escogemos la opcion "Follow TCP Stream". Nos sale la siguiente pantalla:

Aqui podemos ver que el nombre de usuario parece ser "ffaakkee" y la contraseña "user". Como vemos abajo que un comando resulta ser "llss", que realmente se trata del comando "ls" de windows, nos damos cuenta de que aparecen las letras duplicadas y que "ffaakkee", realmente se trata del usuario "fake" y la contraseña "user".

En cuanto al sistema operativo vemos algo más abajo que se trata de un Open BSD.

Por ultimo, para ver los comandos lanzados tenemos que hacer un poco de scroll down:

...para ver que se lanzó un :

• ls
• ls -a
• /sbin/ping www.yahoo.com
• exit

PARTE II: Analizando SSL

Para la realización de este ejercicio, descarga esta traza con tráfico SSL y abrela con Wireshark.

Preguntas:
• ¿Puedes identificar en qué paquete de la trama el servidor envía el certificado?
• ¿El certificado va en claro o está cifrado? ¿Puedes ver, por ejemplo, qué autoridad ha emitido el certificado?
• ¿Qué asegura el certificado, la identidad del servidor o del cliente?

Respuestas:

Como vemos en esta imagen, es el propio Wireshark el que nos indica la respuesta a la primera pregunta. Vemos el segundo paquete que tiene como origen el servidor y del que Wireshark nos indica "Server Hello, Certificate, Server Hello Done". Ese es el paquete en cuestion:

Al extender la información, vemos el lugar exacto donde va el certificado dentro del paquete.

Para responder a la segunda pregunta, tenemos que hacer, igual que antes, click con el boton derecho sobre el paquete y escoger "Follow TCP Stream". Nos sale esta pantalla:

Como vemos, aqui no entendemos nada. Va casi todo cifrado. La parte azul de principio donde va algo en claro, ese es el certificado. Como vemos el usuario debio visitar www.microsoft.com o alguna web perteneciente a la MSN y propiedad de Microsoft (hotmail, outlook, etc). El certificado, como vemos es de Verisign.

Para la tercera pregunta no hace falta captura de pantalla. El certificado verifica la identidad de la página web, es decir, del servidor.

Parte III. Analizando SSH

Una alternativa a usar Telnet a la hora de conectarnos a máquinas remotas es SSH, que realiza una negociación previa al intercambio de datos de usuario. A partir de esta negociación, el tráfico viaja cifrado. Descarga esta traza con tráfico SSH y...

Preguntas:

• ¿Puedes ver a partir de qué paquete comienza el tráfico cifrado?
• ¿Qué protocolos viajan cifrados, todos (IP, TCP...) o alguno en particular?
• ¿Es posible ver alguna información de usuario como contraseñas de acceso?

Respuestas:

1.- Como vemos, tras filtrar por "ssh", el tráfico comienza a estar cifrado tras intercambiar los tipos de cifrado soportados, intercambiar las claves públicas y establecer una clave de cifrado para la comunicacion. Es decir, en el paquete 20 de la comunicacion:

2.- El protocolo que viaja cifrado es sólo SSH, de hecho, como vemos, seguimos pudiendo ver (y entender) los paquetes TCP (y dentro de ellos los datagramas IP), sobre los que va el SSH:

3.- No. No es posible, básicamente porque la clave nunca se envia, lo que se intercambian son valores de numeros primos. El proceso es el siguiente:

    SSHv2 Client: Key Exchange Init --> Negociación de algunos parámetros como la compresión o protocolo de cifrado
    SSHv2 Server: Key Exchange Init --> Respuesta al anterior paquete. El servidor indica que tipos de cifrado acepta
    SSHv2 Client: Diffie-Hellman GEX Request --> Negociación de los parametros del cifrado DH (cifrado, mac y compresion)
    SSHv2 Server: Diffie-Hellman GEX key exchange Reply --> Respuesta al anterior 
    SSHv2 Client: Diffie-Hellman GEX Init --> El cliente envia "e" al servidor 
    SSHv2 Server: Diffie-Hellman GEX Reply --> El otro extremo envia "f"
    SSHv2 Client: New Keys --> Posiblemente un ACK. No estoy seguro

Al recibir el mensaje DH_GEX_INIT (que contiene un numero muy largo "e"), el servidor genera su propio numero aleatorio "y", y calcula f = g^y mod p, y le envia "f" al cliente. También calcula k = e^y mod p, que será el valor de la clave secreta compartida. El cliente, al recibir "f" hace lo mismo, usando la formula k = f^x mod p. Si todo va bien, el cliente y el servidor tendrán el mismo valor de k. Con esta clave ambas partes establecen un canal seguro:

A partir de aqui, el tráfico viaja cifrado, y el proceso consiste en el intercambio de claves publicas entre cliente y servidor, la autenticación del usuario SSH, el establecimiento de los canales de datos, etc.