Los que trabajamos en servicios de atención al cliente nos enteramos de todos los tipos de problemas que pueden llegar a tener los usuarios informáticos. Las situaciones a veces son muy interesantes. Un problema digno de mención que venimos encontrando últimamente es un extraño tipo de secuestro de DNS (DNS hijacking) que configura el equipo de la víctima para que utilice servidores DNS específicos.
DNS UNLOCKER CAMBIA LA CONFIGURACIÓN DE RED PARA UTILIZAR SERVIDORES DNS MALICIOSOS
Aunque pueda parecer poco interesante e incluso fácil de solucionar, ¿qué pasaría si te dijera que el DNS no es visible para el usuario? ¿Y si hubiera una manera de configurar entradas estáticas de DNS para que los servidores DNS primario y secundario no aparecieran en el orden previsto en la interfaz gráfica del usuario?
O peor aún, la configuración mostraría que estabas utilizando DHCP, como era de esperar, cuando no es así. Esto es exactamente lo que hace una reciente aplicación potencialmente no deseada (PUA) llamada DNS Unlocker, entre algunas otras amenazas.
DNS Unlocker cambia la configuración de red de la víctima para utilizar servidores DNS maliciosos. Cuando los navegadores de las víctimas buscan google-analytics.com, el servidor DNS falso apunta a un servidor malicioso que inyecta código JavaScript adicional. El propósito de DNS Unlocker es insertar anuncios publicitarios en las páginas web a través de Google Analytics.
Normalmente, el usuario del equipo afectado por DNS Unlocker verá la siguiente leyenda en la parte inferior de la publicidad: “Anuncios por DNSUnlocker” (Imagen 1) o algo similar, así como diversas variantes de ventanas emergentes de “estafas de soporte técnico” (Imagen 2).
Modificaciones de la configuración DNS
Los DNS hijackers (secuestradores de DNS) no son para nada nuevos, y en general ni siquiera vale la pena comentar estos casos. Lo que hace que estas versiones recientes de DNS Unlocker sean interesantes es la táctica que utilizan para cambiar la configuración DNS del equipo de la víctima sin ser detectados.
Al examinar las propiedades de TCP/IPv4 en Windows, uno esperaría que se muestren algunas entradas de DNS en la parte inferior de la ventana del Panel de control, como se aprecia en la Imagen 3. Si la opción “Usar las siguientes direcciones de servidor DNS” está seleccionada, debe haber siempre una dirección IP en el campo “Servidor DNS preferido” y, opcionalmente, podría haber otra en el campo “Servidor DNS alternativo”.
Sin embargo, si estás utilizando DHCP para obtener tus direcciones DNS (como en la mayoría de entornos domésticos y oficinas en el hogar), aparecerá seleccionada la opción “Obtener la dirección del servidor DNS automáticamente”, como se muestra en la Imagen 3.
Ésta es la táctica más común: La PUA DNS Unlocker modifica las configuraciones DNS estáticas de sus víctimas de tal manera que el panel TCP/IPv4 mostrará que está obteniendo tu DNSautomáticamente. De hecho, el comando “ipconfig/all” de la línea de comandos también indicará que se está usando DHCP; sin embargo, verás las direcciones DNS establecidas de forma estática.
Cuando se utiliza ipconfig, aunque puedas ver las direcciones DNS estáticas, no hay forma de asegurar si se está utilizando una dirección DNS estática o si se está obteniendo automáticamente; en la interfaz gráfica de usuario, sin embargo, aparece que estás utilizando una asignada automáticamente, cuando en realidad estás utilizando la dirección estática (que no se muestra).
¿Cómo puede ser que la interfaz gráfica del usuario no sea capaz de ver que estás usando un DNS estático? Para entenderlo, primero debemos analizar cómo Windows busca el DNS estático en el registro.
DNS en el registro de Windows…
Fíjate en la siguiente ubicación en el registro de Windows:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\
Seguramente verás que hay configuraciones para varias interfaces de red, cada una identificada con un GUID. Los ajustes para cada adaptador de red diferente pueden contener valores DhcpNameServer y NameServer.
Lo que vamos a examinar ahora es el valor NameServer. Normalmente, si quieres utilizar un DNS estático, lo debes configurar en el Panel de control (o mediante el comando netsh) y las direcciones DNS estáticas se almacenarán en el valor de registro NameServer como una lista delimitada por comas, de la siguiente forma:
192.168.1.21,192.168.1.22
¿Qué pasa si, en cambio, se utiliza una lista delimitada por espacios?
192.168.1.21 192.168.1.22
Es un cambio pequeño y Windows aún será capaz de utilizar ambas direcciones de dominios: una como DNS primario y la otra como secundario. Sin embargo, la interfaz gráfica del usuario de Windows no muestra en la mitad inferior del Panel de control que el equipo está usando un DNS estático, como se ve en la Imagen 3. Lo que se muestra es que el equipo está utilizando DHCP para establecer tu DNS, cuando en realidad no es correcto.
Y lo más frustrante de todo es que, si estás trabajando con un cliente que a cada rato visualiza anuncios inyectados en los sitios web o lo redirigen constantemente durante la navegación, cuando decida probar ingresar los servidores DNS conocidos en forma manual en el Panel de control, notará que no soluciona el problema.
Como Windows considera que los servidores DNS primario y secundario ya están configurados (pero no te los muestra), cuando completas los campos “Preferido” y “Alternativo”, Windows simplemente añade estas nuevas direcciones al final de la lista en el registro, de la siguiente manera:
192.168.1.21 192.168.1.22,208.67.222.123,208.67.220.123
Como se puede ver, Windows utiliza la delimitación por comas para la tercera y cuarta entrada del servidor DNS, pero deja el delimitador existente por espacio entre la primera y la segunda dirección.
Ahora que sabemos cómo funciona, la verdadera pregunta es: ¿por qué se permite que ocurra algo así, en primer lugar? Lamentablemente, no tengo una buena respuesta. Mi hipótesis se basa en que el valor DhcpNameServer intenta utilizar una lista separada por espacios y Microsoft explica su comportamiento en TechNet:
Si el valor de NameServer es válido, éste tendrá prioridad sobre el valor de DhcpNameServer.(Fuente: DhcpNameServer en Microsoft TechNet)
Como a DhcpNameServer se le permite tener delimitación por espacio, a NameServer también. Además, hay evidencia de que el valor NameServer estaba pensado para utilizar listas delimitadas por espacios, como se indica aquí en TechNet; de hecho, este documento sugiere que la única delimitación permitida es por espacios. Sin embargo, no es más que una suposición.
En realidad, es una propiedad no estándar de Windows y el Panel de control simplemente no sabe cómo manejarla en forma adecuada en su interfaz gráfica del usuario. El Panel de control no te permitirá ingresar una lista delimitada por espacios ni por comas. Por el contrario, crea lalista separada por comas a partir de lo que el usuario escribió en los campos de servidor DNS “Preferido” y “Alternativo” en su interfaz gráfica del usuario, pero el resto del código (que lee este valor del registro) acepta la forma delimitada por espacios y simplemente “funciona sin errores” con cualquiera de ambos delimitadores.
Sin embargo, el Panel de control de la interfaz gráfica del usuario no funciona de la misma manera, ya que no muestra las entradas delimitadas por espacios que no estén en la pestaña “Avanzado“.
… y DNS en la configuración de red
Peor aún es el hecho de que esta funcionalidad también está siendo utilizada por otras aplicaciones no deseadas con el fin de forzar el uso de sus servidores DNS en los equipos infectados. En resumen, se trata de un secuestro de DNS, que obliga a usar servidores DNS “ocultos”. Los llamo ocultos porque los servidores DNS establecidos de forma estática no se muestran en los campos Primario y Secundario correspondientes, en las Propiedades de TCP/IPv4.
Ahora que ya sabemos cómo se establece el DNS incorrecto en el registro, vamos a analizar un área más de las Propiedades de TCP/IPv4. El área de interés es la ventana “Configuración avanzada de TCP/IP” en la pestaña DNS, como se muestra en la Imagen 4. La parte superior de esta pestaña tiene una lista que determina el orden de uso de los servidores DNS y te permite especificar el uso de más de dos direcciones IP como servidores DNS. Cada dirección debe estar en su propia línea. Pero si tu DNS fue secuestrado y está oculto, la configuración de TCP/IP se parecerá a lo que muestra la Imagen 4:
Figure 4: Panel de control de Windows para la Configuración avanzada de TCP/IP, con la configuración DNS “oculta”
Como se puede observar, hay dos direcciones en una única línea separada por un espacio. Si quisieras intentar usar el botón “Agregar…” para ñadir dos direcciones separadas por un espacio, obtendrías un error con la leyenda “Dirección IP no válida” y no te dejaría agregarla. Si quisieras especificar manualmente los servidores DNS en el “Servidor DNS preferido” y “Servidor DNS alternativo” en la página de propiedades de TCP/IPv4, mientras el DNS se encuentra oculto, verás que lo que especificaste aparece debajo de las entradas DNS ocultas, algo similar al ejemplo de la Imagen 5.
Imagen 5: Configuración manual de entradas DNS conocidas cuando la configuración del DNS en vigor se encuentra “oculta”
Desinfección
Por suerte, se pueden eliminar las entradas DNS maliciosas de la pestaña de DNS en la página Configuración avanzada de TCP/IP. Solo debes acordarte de fijarte allí.
Revelación responsable
ESET comunicó el problema al Centro de Respuesta de Seguridad de Microsoft (MSRC) el 10 de mayo de 2016. Un representante del MSRC reconoció el problema, pero dijo que no fue clasificado como una vulnerabilidad de seguridad. Su razonamiento para justificar la decisión es el siguiente: “Como la modificación del registro requiere privilegios de administrador, no queda amparada por los estándares del servicio de seguridad del MSRC”. Reenviaron este problema a los equipos correspondientes para que lo tengan en cuenta en futuras versiones.
Resumen
Para resumir, dado que Windows leerá y usará una lista delimitada por espacios de direcciones de servidores DNS en el valor “NameServer“, en lugar de exigir que las direcciones únicamente estén separadas por comas, las aplicaciones no deseadas pueden aprovechar este método para ocultar su configuración DNS en el sistema.
Esta táctica se ha comenzado a detectar en diciembre de 2015, en DNS Unlocker en Windows XP, Vista, 7, 8/8.1 y 10 (x86 y x64). Por último, de especial interés: la aplicación de la misma técnica para ocultar direcciones DNS establecidas en forma estática mediante una lista delimitada por punto y coma también funciona, aunque no hemos visto que lo utilizara ningún malware o aplicaciones no deseadas hasta el 31 de mayo de 2016, fecha en que se escribió este artículo.
Indicadores de sistemas comprometidos
La versión de DNS Unlocker descrita en este documento es detectada por ESET como la aplicación MSIL/Adware.CloudGuard.C. Utiliza las siguientes direcciones IP para secuestrar DNS:
- 203131145
- 203.131.150 a 199.203.131.152
- 163.142.2 a 82.163.142.7
- 163.142.66 a 82.163.142.70
- 163.142.130 a 82.163.142.189
- 163.143.131 a 82.163.143.190
- 211.158.129 a 95.211.158.135
- 211.158.145 a 95.211.158.151
Las siguientes direcciones IP se utilizan como servidores HTTP para inyectar el código de JavaScript malicioso que muestra los anuncios en las páginas web:
- 163.143.23 a 82.163.143.250
- 88.193.133 a 209.88.193.141
Muestras de malware que usan esta técnica
| SHA-1 | Detección de ESET | Valores de NameServer usados |
|---|---|---|
| E7108973D9AE0BDB97801C959622E1ECECDCE80E | Aplicación MSIL/Adware.CloudGuard.C | 82.163.143.17 182.163.142.173 |
| AEEEA6C3697D983337598E2D3B940DB0225A05CB | Troyano Win32/Agent.XSF | 199.203.131.145 82.163.143.167 |
| A9AC712B4D31F20AC3DEFC066D66C2982A4ADC0C | Troyano Win32/DNSChanger.NDI | 199.203.131.151 82.163.143.181 |
| 1A1764F7AA3E9F81B23997982E1BDB300D3707B1 | Aplicación Win32/Adware.Adposhel.F | 82.163.142.3 95.211.158.130 |
Fuente:https://www.welivesecurity.com/
Entusiasta de la seguridad cibernética. Especialista en seguridad de la información, actualmente trabajando como especialista en infraestructura de riesgos e investigador.
Experiencia en procesos de riesgo y control, soporte de auditoría de seguridad, diseño y soporte de COB (continuidad del negocio), gestión de grupos de trabajo y estándares de seguridad de la información.
Envía tips de noticias a info@noticiasseguridad.com o www.instagram.com/iicsorg/.
También puedes encontrarnos en Telegram www.t.me/noticiasciberseguridad
