La seguridad end-to-end de las comunicaciones es fundamental para proporcionar privacidad y prevenir buena parte de los ataques MiTM (ataques de hombre en el medio).
Se reconoce como ataque MiTM a un ataque donde una tercera parte (el atacante) logra posicionarse en medio de una comunicación entre por ejemplo cliente y servidor. Durante esta intervención el atacante es capaz de ver la comunicación, alterarla y/o interrumpirla. Por definición, una red que se encuentre en poder de un atacante es vulnerable a un ataque MiTM.
El ataque MiTM más conocido es ARP spoofing. En este caso el atacante enviando tramas ARP falsificadas logra engañar a la víctima y se hace pasar por el gateway de la LAN.
Existe dos medidas muy utilizadas para atenuar/evitar los ataques MiTM y son el cifrado y el uso de certificados digitales. Estas medidas protegen principalmente la confidencialidad y la integridad de la información en tránsito, complicando claramente el escenario para un atacante. Pero ni lerdos ni perezosos, los atacantes apuntan ahora contra las debilidades en los mecanismos de protección, por ejemplo atacando las CAs, los algoritmos de cifrado o los protocolos que los utilizan. Algunos de esos ejemplos son:
-Ataques a CAs como Comodo o DigiNotar.
-Ataques como BEAST, CRIME and POODLE han dejado a SSL al borde del Knock Out.
Pareciera que la única opción es sentarnos a beber y llorar, pero no! Hay maneras de complicar aún mas el camino a los atacantes. Porque al final del día siempre se trata de eso, la seguridad absoluta no existe.
Según US-CERT estas son las mejores prácticas para aspirar a seguridad End-to-End y mitigar así ataques MiTM.
Actualizar TLS/SSL:
Se recomienda utilizar TLS 1.1 o superior y en lo posible desterrar el uso de TLS 1.0 y SSL 1, 2 y 3.x. Algunos clientes TLS 1.0 pueden usar SSL 3.0 el cuál es vulnerable al ataque POODLE cuando se utiliza el modo de cifrado de bloques encadenado.
Empresas como AWS, CloudFlare y Twitter ya cumplen esta recomendación o están en proceso.
Usar Certificate Pinning:
Esta técnica consiste en asociar un certificado X.509 y su clave pública a por ejemplo un host/servicio. Generalmente, los certificados son validados corroborando la cadena de confianza hasta el certificado raíz. Certificate Pinning esquiva ese proceso de validación y permite al usuario confiar en un certificado particular o en la firma de un certificado particular.
Browsers como Chrome o Firefox utilizan esta técnica. Una de las maneras en que la aplican es pre-cargando los hashes de las claves públicas aceptadas; luego limitan los certificados válidos a aquellos cuyo hash de la clave pública coincida con alguno de los pre-cargados. Chrome por su lado mantiene una lista blanca de las claves públicas válidas para los servicios de Google.
Certificate Pinning destruye en cierta manera el esquema de cadena de confianza que plantea PKI, ya que una aplicación que asocia un certificado o clave pública a un host ya NO depende de otros servicios como DNS o CAs a la hora de aceptar la identidad del mismo.
OWASP lo plantea muy clarito:
The pandemic abuse of trust has resulted in users, developers and
applications making security related decisions on untrusted input. The
situation is somewhat of a paradox: entities such as DNS and CAs are
trusted and supposed to supply trusted input; yet their input cannot be
trusted. Relying on untrusted input for security related decisions is
not only bad karma, it violates a number of secure coding principals
DNS-Based Authentication of Named Entities (DANE):
DANE es un protocolo que permite asociar un certificado X.509 a un registro DNS que use DNSSEC. Confiar en un gran número de CAs es un problema, ya que una de ellas podría ser comprometida y emitir certificados para dominios que no fueron solicitados. DANE permite al administrador del dominio definir qué CA puede emitir certificados en su nombre.
Network Notary Servers:
Esta solución apunta a mejorar la seguridad en la comunicación entre clientes y sitios web permitiendo a los navegadores verificar la autenticidad de un sitio sin depender de una CA. Un Network Notary Server se encarga de monitorizar sitios web y construir un historial de sus certificados a través del tiempo. Entoces cuando un navegador web, utilizando network notary, obtiene el certificado de un sitio web puede comunicarse con su Network Notary Server para corroborar el historial de certificado del sitio. Si el certificado provisto por el web server no coincide con el historial del Notary Network Server, se podría tratar de un ataque MiTM.
Fuentes:
https://www.us-cert.gov/ncas/alerts/TA15-120A
http://en.wikipedia.org/wiki/ARP_spoofing
https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning
http://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities
http://perspectives-project.org/
https://www.dnssec-validator.cz/
