Si aún no sabéis cómo descargarlo e instalarlo, os recomiendo nuevamente que leáis “NetHunter: Kali Linux en tu Android“, un estupendo artículo nos trae nuestro compañero Manuel Camacho en donde nos explica todo lo que necesitáis saber para tenerlo en vuestro dispositivo Nexus.
Uno de los ataques que más fácilmente nos permite hacer NetHunter es un curioso Man-In-The-Middle con el que me llevé una grata sorpresa. Vamos a centrar este artículo en explicar cómo funciona, por qué funciona, cómo explotarlo y cómo defendernos ante ello.
Este año tuve la suerte de asistir a la BackHat en Las Vegas, donde una de las más esperadas charlas era la de BadUSB y que a título personal me dejó maravillado. Ya se empiezan a ver las primeras implementaciones y vectores de ataque: Por parte de los chicos de NetHunter tenemos “BadUSB MITM Attack“. Ya podéis imaginar cual será el vector de ataque… con tan sólo conectar el móvil por USB a un ordenador con Windows conseguiremos redirigir todo el tráfico a nuestro móvil y hacer lo que queramos con él… guardarlo, modificarlo, bloquearlo… ¿interesante verdad? ¡A partir de ahora nos pensaremos dos veces cuando alguien nos pida que le carguemos el móvil en nuestro ordenador! Pero eso no es todo… seguid leyendo porque os cuento más adelante que la cosa es más grave aún.
Vamos al lío. Para ello voy a diferenciar tres secciones:
Explotando Ataque BadUSB MITM: Mostrando cómo se explota y resultado en un escenario real.
Entendiendo Ataque BadUSB MITM: Analizaremos en detalle cómo y por qué funciona el ataque.
Defendiéndonos del Ataque BadUSB MITM: Una vez hemos analizado y entendido cómo funciona, podemos tomar un serie de acciones para evitar que este ataque sea efectivo en nuestras máquinas.
Explotando Ataque BadUSB MITM
Es momento de ver en acción cómo funciona el ataque. He escogido el vídeo oficial que la gente de NetHunter ha publicando donde se puede ver una demostración del ataque de una manera muy sencilla y directa. Si no entedéis bien inglés no os preocupéis puesto que en la siguiente sección lo veremos en detalle
¿Tiene buena pinta? Pues pasemos al a siguiente sección donde vamos a entender un poco mejor cómo funciona.
Entendiendo Ataque BadUSB MITM
A continación explicaré un poco más en profundidad cómo funciona la implementación de este ataque MITM. Para ello he grabado el siguiente vídeo (no olvidéis verlo en HD para ver todos los detalles sin problema) en el que veremos con detalle paso a paso todo lo que va sucediendo desde el principio hasta el final del ataque:
,
Varios puntos a aclarar:
El dispositivo móvil debe estar conectado a internet para que esté propiamente en el medio de la comunicación.
Aunque no lo he probado, probablemente este ataque no funcione en máquinas UNIX debido a la manera en la que UNIX administra las puertas de enlace por defecto.
El ataque funciona aunque la sesión Windows del usuario esté bloqueada, es decir, nos encontremos ante la pantalla de inicio de sesión donde hay que meter la contraseña del usuario para acceder de nuevo a su sesión. Este escenario es muy común, puesto que en entornos de trabajo cuando el empleado se ausenta, una buena costumbre es bloquear la pantalla con “Windows + L”. Aún así, el ataque funcionará. Por lo tanto… imaginen un entorno donde podamos acceder a un puerto USB de una máquina importante (ufff se me ocurren tanto sítios públicos donde puertos USB son accesibles), es cuestión de enchufar el móvil, guardar el tráfico durante un tiempo y luego analizarlo en casa tranquilamente.
Defendiéndonos del Ataque BadUSB MITM
Como ha quedado demostrado, el principal problema es que Windows asigna a la métrica de la nueva ruta un valor menor al que la ruta por defecto ya tiene. ¿Qué podemos hacer entonces? Bueno se me ocurre algo bien sencillo como solución rápida y temporal: asignar un valor estático y menor a nuestra ruta por defecto y por lo tanto aunque se cree una nueva ruta para el tráfico por defecto, éste tendrá un valor mayor y por lo tanto el tráfico se seguirá enviando por nuestra interfaz de red.
Para ello nos vamos Conexiones de red y entramos en las propiedades de la interfaz de red que conecte con internet (igualmente con otras interfaces importantes, por ejemplo aquellas para tráfico de intranet).
BadUSB MITM
A continuación quitamos la opción de que la métrica de la ruta se calcula automáticamente y le ponemos un valor manual de 1:
Sin título3
De este modo, cuando Windows tenga dos rutas para el tráfico 0.0.0.0 siempre lo enviará por esta interfaz al tener una métrica mejor que la creada por NetHunter.
Es importante no olvidar que esto se debe hacer tanto para IPv4 como IPv6.
Sólo una última nota: Ojo porque el tráfico DNS se seguiría enviando por ambos y si no estoy equivocado, tráfico multicast actuaría del mismo modo. Desde luego este “parche” no soluciona el verdadero problema de raíz.
El dispositivo móvil debe estar conectado a internet para que esté propiamente en el medio de la comunicación.
Aunque no lo he probado, probablemente este ataque no funcione en máquinas UNIX debido a la manera en la que UNIX administra las puertas de enlace por defecto.
El ataque funciona aunque la sesión Windows del usuario esté bloqueada, es decir, nos encontremos ante la pantalla de inicio de sesión donde hay que meter la contraseña del usuario para acceder de nuevo a su sesión. Este escenario es muy común, puesto que en entornos de trabajo cuando el empleado se ausenta, una buena costumbre es bloquear la pantalla con “Windows + L”. Aún así, el ataque funcionará. Por lo tanto… imaginen un entorno donde podamos acceder a un puerto USB de una máquina importante (ufff se me ocurren tanto sítios públicos donde puertos USB son accesibles), es cuestión de enchufar el móvil, guardar el tráfico durante un tiempo y luego analizarlo en casa tranquilamente.
Defendiéndonos del Ataque BadUSB MITM
Como ha quedado demostrado, el principal problema es que Windows asigna a la métrica de la nueva ruta un valor menor al que la ruta por defecto ya tiene. ¿Qué podemos hacer entonces? Bueno se me ocurre algo bien sencillo como solución rápida y temporal: asignar un valor estático y menor a nuestra ruta por defecto y por lo tanto aunque se cree una nueva ruta para el tráfico por defecto, éste tendrá un valor mayor y por lo tanto el tráfico se seguirá enviando por nuestra interfaz de red.
Para ello nos vamos Conexiones de red y entramos en las propiedades de la interfaz de red que conecte con internet (igualmente con otras interfaces importantes, por ejemplo aquellas para tráfico de intranet).
BadUSB MITM
A continuación quitamos la opción de que la métrica de la ruta se calcula automáticamente y le ponemos un valor manual de 1:
Sin título3
De este modo, cuando Windows tenga dos rutas para el tráfico 0.0.0.0 siempre lo enviará por esta interfaz al tener una métrica mejor que la creada por NetHunter.
Es importante no olvidar que esto se debe hacer tanto para IPv4 como IPv6.
Sólo una última nota: Ojo porque el tráfico DNS se seguiría enviando por ambos y si no estoy equivocado, tráfico multicast actuaría del mismo modo. Desde luego este “parche” no soluciona el verdadero problema de raíz.
Varios puntos a aclarar:
El dispositivo móvil debe estar conectado a internet para que esté propiamente en el medio de la comunicación.
Aunque no lo he probado, probablemente
este ataque no funcione en máquinas UNIX debido a la manera en la que
UNIX administra las puertas de enlace por defecto.
El ataque funciona aunque la
sesión Windows del usuario esté bloqueada, es decir, nos encontremos
ante la pantalla de inicio de sesión donde hay que meter la contraseña
del usuario para acceder de nuevo a su sesión. Este escenario es muy
común, puesto que en entornos de trabajo cuando el empleado se ausenta,
una buena costumbre es bloquear la pantalla con “Windows + L”. Aún así,
el ataque funcionará. Por lo tanto… imaginen un entorno donde podamos
acceder a un puerto USB de una máquina importante (ufff se me ocurren
tanto sítios públicos donde puertos USB son accesibles), es cuestión de
enchufar el móvil, guardar el tráfico durante un tiempo y luego
analizarlo en casa tranquilamente.
Defendiéndonos del Ataque BadUSB MITM
Como ha quedado demostrado, el principal
problema es que Windows asigna a la métrica de la nueva ruta un valor
menor al que la ruta por defecto ya tiene. ¿Qué podemos hacer entonces?
Bueno se me ocurre algo bien sencillo como solución rápida y temporal:
asignar un valor estático y menor a nuestra ruta por defecto y por lo
tanto aunque se cree una nueva ruta para el tráfico por defecto, éste
tendrá un valor mayor y por lo tanto el tráfico se seguirá enviando
por nuestra interfaz de red.
Para ello nos vamos Conexiones de red y entramos en las propiedades de la
interfaz de red que conecte con internet (igualmente con otras
interfaces importantes, por ejemplo aquellas para tráfico de intranet).
A continuación quitamos la opción de que la métrica de la ruta se calcula automáticamente y le ponemos un valor manual de 1:
De este modo, cuando Windows tenga dos
rutas para el tráfico 0.0.0.0 siempre lo enviará por esta interfaz al
tener una métrica mejor que la creada por NetHunter.
Es importante no olvidar que esto se debe hacer tanto para IPv4 como IPv6.
Sólo una última nota: Ojo porque
el tráfico DNS se seguiría enviando por ambos y si no estoy equivocado,
tráfico multicast actuaría del mismo modo. Desde luego este “parche” no
soluciona el verdadero problema de raíz.
- See more at: http://hacking-etico.com/2014/10/08/ataque-badusb-mitm/#more-3730
,
