Notas del curso Hacking ético: descubriendo vulnerabilidades en aplicaciones web

En sus inicios, el protocolo HTTP no estaba diseñado para “securizar” los datos. Simplemente era un protocolo para intercambiar datos entre un cliente y un servidor.

• Datos enviados en texto claro.
• Sin mecanismos de protección a intercepción de datos por diseño.
• Puerto TCP por defecto: 80.

Quien tenga acceso al canal de comunicación entre cliente y servidor, podrá ver la información que se está intercambiando. Ejemplo utilizando Wireshark:

A diferencia del apartado anterior donde veíamos el uso de la herramienta Wireshark desde nuestra propia interfaz de red, la interceptación del tráfico puede llevarla a cabo un tercero en lo que se conoce como Man in the Middle.

Este ataque, a nivel de capa de enlace, consiste en envenenar las tablas ARP para hacer creer a la víctima que el atacante es el servidor legítimo, y al servidor que el atacante es la víctima legítima. Esto se hace en Linux de la siguiente manera:

echo "1" > /proc/sys/net/ipv4/ip_forward # Para que el dispositivo del atacante pueda reenviar paquetes IPv4 y IPv6

Y con la herramienta arpspoof envenenamos las tablas ARP de víctima y servidor:

arpspoof –i <interfaz> -t <víctima> -r <router a suplantar>
arpspoof –i <interfaz> -t <router> -r <víctima a suplantar>

• Implementación de mecanismos de cifrado
• Infraestructura de clave pública.
• Mecanismos de alerta ante intentos de intercepción.
• Certificados digitales.
• Puerto TCP por defecto: 443.

Si el certificado de un servidor es autofirmado, los navegadores actuales nos mostrarán una advertencia:

Un atacante podría usar un certificado autofirmado y si la víctima acepta los riesgos, el atacante podría interceptar tráfico HTTPS.

Las conexiones al servidor van por HTTP en los siguientes casos:

• La primera petición a un dominio va por HTTP.
• Si solo se indica el dominio en la URL.

La cabecera HSTS fuerza a que todas las peticiones vayan por HTTPS.

En la cabecera Strict-Transport-Security el atributo maxage indica el tiempo de validez de la misma. Trascurrido ese tiempo, la cabecera deja de ser válida y hay que hacer una nueva petición. En ese momento, podríamos ser víctimas de un ataque de Man in the Middle. Sin embargo, los navegadores modernos suelen tener ya precargados los dominios más conocidos (de buscadores, bancos…) con HSTS, evitamos que la comunicación se realice por HTTP.

Veremos las opciones de cifrado de la información entre cliente y servidor.

Para comunicarse dos entidades, cifran y descifran el mensaje con una misma clave que conocen ambos.

• Misma clave para cifrar que para descifrar.
• Debe ser conocida.
• En caso de compromiso se debe volver a compartir.
• Tiempos de operación bajo.
• Confidencialidad

El problema es la compartición de la clave. ¿Cómo se hace para que nadie la intercepte?

• Par de claves diferente por cada interlocutor.
• Proceso para derivar las claves.
• Tiempos de operación elevados.
• Ofrece: confidencialidad, integridad, autenticación y no repudio (quiere decir que el remitente no puede negar haber enviado el mensaje).

Como vemos en la imagen, A, para enviar un mensaje a B, lo cifra con su clave pública. Al recibirlo, B le aplica la clave privada al mensaje cifrado y lo descifra. En la parte de abajo de la imagen se muestra que no solo se cifra el mensaje sino que se acompaña de lo que permite verificar que viene de cierto remitente.

La clave pública de un usuario es conocida por todos, pero la privada de cada uno no comparte en ningún momento.

Como los tipos de operación de la criptografía asimétrica son elevados, en la práctica se usa una combinación de ambos:

• Criptografía asimétrica para el intercambio de clave
• Criptografía simétrica para el cifrado de las comunicaciones.

Ejemplos:

• Intercambio de claves (RSA, DH, ECDH, DHE, PSK)
• Cifrado simétrico (AES, CHACHA20, Camellia, ARIA)
• Funciones Hash (SHA-256, POLY1305)

Para acreditar que alguien/algo dice ser quien dice ser, se utiliza una estructura de árbol jerárquica que se conoce como Infraestructura de clave pública.

• Autoridades de certificación (Certification Authority).
• Cadena de confianza.
• Certificados digitales.

En España la Autoridad Certificadora raíz la FNMT (expide los certificados digitales). Las CA raíz contienen certificados autofirmados. Son entidades reconocidas por todo el mundo.

El certificado digital es la clave pública utilizada en la criptografía asimétrica firmada por las autoridades certificadores en el orden que se muestra en la imagen anterior para establecer una estructura de confianza. De esta forma podemos verificar la autenticidad aplicando las claves públicas de cada CA sobre el certificado.

Si verificamos el contenido de un certificado digital:

Podemos ver la estructura de confianza.

Según la captura anterior, trainingit.es ha sido verificado por AlphaSSL CA, que a su vez lo ha firmado GlobalSign.

Protocolo entre cliente y servidor para iniciar la comunicación cifrada.

En función de los algoritmos de cifrado que soporta el servidor, pueden existir vulnerabilidades asociadas:

• FREAK: fuerza en cliente o servidor el uso de un protocolo débil mediante la opción TLS export (CVE-2015-0204)
• LOGJAM: freak v2 (CVE-2015-4000)
• POODLE: permite descifrar un mensaje en SSLv3.0 a base de mandarlo repetidamente < 256 veces (CBC) (CVE-2014-3566)
• BEAST: client side, permite predecir los IV en un ataque MITM, lo que permite descifrar fragmentos del mensaje. (CVE-2012-4929)
• HEARTBEAT: vulnerabilidad en la función heart beat ssl. (CVE-2014-0160)
• BREACH: permite descifrar fragmentos de la petición realizando bruteforce y comparar los tamaños de respuestas. (CVE-2013-3587)
• Drown: similar a POODLE pero con SSLv2 (CVE-2016-0800)
• CRIME: client side similar a BEAST (CVE-2012-4929)
• LUCKY 13: Basado en el uso de algoritmos de cifrado en modo CBC (tiempos de respuesta).

Script en bash que solicita al servidor todos los algoritmos de cifrado que soporta y realiza peticiones de TLS handshake mostrando un resumen de las vulnerabilidades:

• Restringir las peticiones al servidor por HTTPS.
• Implementar HSTS con un tiempo de validez elevado.
• Revisar los algoritmos de cifrado que ofrece el servidor durante el proceso de negociación.
• Evitar el uso de certificados autofirmados.