Nueva vulnerabilidad permite a atacantes secuestrar conexiones VPN en distribuciones Linux, variantes UNIX, iOS y Android

Una nueva vulnerabilidad descubierta permite a los atacantes secuestrar conexiones VPN en Linux, FreeBSD, OpenBSD, MacOS, iOS y Android

William J. Tolley conjunto con Beau Kujath y Jedidiah R. Crandall reportó en  SecLists la vulnerabilidad catalogada como [CVE-2019-14899] – Inferir y secuestrar conexiones TCP tunelizadas VPN.

[CVE-2019-14899] Inferring and hijacking VPN-tunneled TCP connections.

From: «William J. Tolley» <william () breakpointingbad com>
Date: Wed, 04 Dec 2019 19:37:07 -0700

Hi all,

I am reporting a vulnerability that exists on most Linux distros, and
other  *nix operating systems which allows a network adjacent attacker
to determine if another user is connected to a VPN, the virtual IP
address they have been assigned by the VPN server, and whether or not
there is an active connection to a given website. Additionally, we are
able to determine the exact seq and ack numbers by counting encrypted
packets and/or examining their size. This allows us to inject data into
the TCP stream and hijack connections.

Most of the Linux distributions we tested were vulnerable, especially
Linux distributions that use a version of systemd pulled after November
28th of last year which turned reverse path filtering off. However, we
recently discovered that the attack also works against IPv6, so turning
reverse path filtering on isn't a reasonable solution, but this was how
we discovered that the attack worked on Linux.

Adding a prerouting rule to drop packets destined for the client's
virtual IP address is effective on some systems, but I have only tested
this on my machines (Manjaro 5.3.12-1, Ubuntu 19.10 5.3.0-23). This
rule was proposed by Jason Donenfeld, and an analagous rule on the
output chain was proposed by Ruoyu "Fish" Wang of ASU. We have some
concerns that inferences can still be made using slightly different
methods, but this suggestion does prevent this particular attack.

There are other potential solutions being considered by the kernel
maintainers, but I can't speak to their current status. I will provide
updates as I receive them.

I have attached the original disclosure I provided to 
distros () vs openwall org and security () kernel org below, with at least
one critical correction: I orignally listed CentOS as being vulnerable
to the attack, but this was incorrect, at least regarding IPv4. We
didn't know the attack worked against IPv6 at the time we tested
CentOS, and I haven't been able to test it yet.


William J. Tolley
Beau Kujath
Jedidiah R. Crandall

Breakpointing Bad &
University of New Mexico


*************************************************

A fecha de hoy no se ha publicado ningún parche.

Esta vulnerabilidad funciona contra OpenVPN, WireGuard e IKEv2/IPSec, pero no ha sido probada a fondo contra Tor. Pero se sospecha que no es vulnerable ya que opera en una capa SOCKS e incluye autenticación y cifrado que ocurre en el espacio de usuario.

Actualización: Según ha salido publicado en el boletín de Hispasec hasta las fechas parece ser que hasta la fecha esta vulnerabilidad puede ser explotada en las siguientes distribuciones Linux.

Hipsasec del 9 de Diciembre de 2019

Hasta la fecha, se ha confirmado que esta vulnerabilidad puede ser explotada con una gran cantidad de distribuciones Linux, especialmente en aquellas que usan la versión de systemd posterior al 28 de noviembre de 2018 (momento en el que se desactivó el filtrado de ruta inversa), por ejemplo:

  • Ubuntu 19.10 (systemd)
  • Fedora (systemd)
  • Debian 10.2 (systemd)
  • Arco 2019.05 (systemd)
  • Manjaro 18.1.1 (systemd)
  • Devuan (sysV init)
  • MX Linux 19 (Mepis + antiX)
  • Linux vacío (runit)
  • Slackware 14.2 (rc.d)
  • Deepin (rc.d)
  • FreeBSD (rc.d)
  • OpenBSD (rc.d)

La estrategia de mitigación propuesta por el equipo de investigación que descubrió la vulnerabilidad consiste en:

  • Activar el filtrado de ruta inversa,
  • Implementar el filtrado de direcciones de IP falsas (bogons), y
  • Cifrar el tamaño y el tiempo del paquete.

Fuente original