Caso Microsoft: otras hipótesis

Si dejamos a un lado la posibilidad, bastante remota como ha quedado
demostrada, de que “Qaz” actuara como puerta trasera desde la propia
red interna de Microsoft, podemos contemplar otras hipótesis. El
fin del presente no es intentar reproducir fielmente lo sucedido,
cosa complicada al no disponer de datos fiables y dada las múltiples
posibilidades que pudieron haber acontecido, si bien se pretende
presentar situaciones más viables de corte similar con la idea
de que puedan ayudarnos a reflexionar sobre la seguridad de nuestras
redes.
– Algunos lectores, entre el gran número de mensajes que están
llegando en relación a este caso, apuntan la posibilidad de que “Qaz”,
o un backdoor similar, fuera utilizado para conectar con un ordenador
individual con acceso remoto a la red local interna. Por ejemplo, el
caso de un trabajador de Microsoft que desde su casa tuviera acceso
remoto a la red local. ¿Es viable?

Si, totalmente. En este caso, tal y como describimos en la anterior
entrega, “Qaz” se muestra efectivo al tratarse de un ordenador que
puede conectar directamente a Internet, sin necesidad de utilizar un
proxy intermedio o contar con un cortafuegos que filtre sus
conexiones. Una vez infectado el ordenador doméstico del trabajador,
“Qaz” envía la dirección IP de la máquina al atacante y abre el puerto
TCP 7597 para que pueda introducirse por él desde Internet. En
cualquier caso, nos encontraríamos con que el trabajador no cuenta con
un antivirus actualizado o un firewall personal, ya que de otra forma
habría detectado la presencia de “Qaz” en su sistema.

– ¿Qué podría hacer el atacante en el ordenador doméstico del empleado
de Microsoft a través de “Qaz”?

“Qaz” tiene unas características como backdoor muy limitadas, pero
suficientes para instalar otras herramientas más avanzadas. Los
comandos soportados como backdoor comprenden la ejecución de
programas (Run), la posibilidad de enviar ficheros al sistema
infectado (Upload), y la desactivación de “Qaz” (Quit). Aunque muy
básicos, estos comandos permiten el poder instalar herramientas más
sofisticadas para controlar de forma remota los sistemas.

– ¿Pudo robar el nombre de usuario y contraseña del empleado
utilizados para autentificarse en la red local de Microsoft y hacerse
pasar por él a posteriori?

Si, es posible, pudo descargar e instalar programas especialmente
diseñados para robar las contraseñas. Aunque los accesos remotos
ante redes seguras pueden incluir, además de un nombre y contraseña,
otros elementos añadidos durante la fase de autentificación que
puede ir desde restricciones según la dirección IP de origen, hasta
el uso de tokens vía hardware, como las smarts cards.

– Si Microsoft usa autentificación básica, basada únicamente en nombre
de usuario y contraseña, parece fácil que el atacante pueda hacerse
pasar por el usuario y entrar en la red local. Pero, ¿pudo el atacante
acceder a la red interna de Microsoft si utiliza otros sistemas de
autentificación más sofisticados?

Si, una vez vulnerado el ordenador que realiza la conexión con la
red interna, y la posibilidad de instalar herramientas de control
total, cada vez que el usuario legítimo se autentifica con la red
interna abre una puerta al atacante. Imaginemos que Microsoft
instala dispositivos biométricos en casa de sus empleados de
forma que para entrar en su red toma la huella digital o escanea
el iris para comprobar que se trata de un usuario legítimo. El
atacante tan sólo tendría que esperar a que la víctima lleve a
cabo el proceso de autentificación, la red de Microsoft le permita
su acceso, y a partir de ahí puede utilizar el ordenador personal
de la víctima como puente para llevar a cabo sus acciones o
limitarse a recopilar la información que el usuario maneja en sus
transacciones con la red local.

– Ya tenemos al atacante dentro de la red interna de Microsoft, ¿qué
puede hacer ahora?

Todo depende de los privilegios que el empleado legítimo de Microsoft
tenga desde su acceso remoto. Puede que tenga un nivel bajo y sólo le
esté permitido realizar ciertas lecturas, o puede tratarse de un
administrador de sistemas que lleva a cabo acciones más comprometidas
con privilegios de configuración, escritura, ejecución y acceso
indiscriminado.

– Si el empleado tiene acceso restringido, ¿puede ampliar sus
privilegios para acceder a otras zonas más sensibles o actuar
cómo administrador?

De nuevo depende de los privilegios iniciales con los que cuente,
aunque en sistemas Windows la escalada de privilegios no resulta
excesivamente complicada debido a la propia naturaleza de estos
sistemas. Una vez logrados privilegios de escritura y ejecución el
atacante podría instalar algún “sniffer” para escuchar el tráfico de
la red local y capturar las contraseñas de otros usuarios y datos
sensibles que viajen por la red interna.

– Bajo esta hipótesis, es “Qaz” una buena herramienta para el
atacante.

No, es un troyano reconocido por los antivirus, y sus posibilidades
como backdoor son muy básicas, lo que obliga al atacante a descargar
y ejecutar nuevas herramientas de control. Es más fácil utilizar
desde un primer momento un backdoor con características más
avanzadas, así como sería recomendable su programación personalizada
para evitar ser reconocido cómo malware.

– ¿Responsabilidad del trabajador o de Microsoft?

No conozco la política de seguridad de Microsoft en relación a los
sistemas de acceso remoto, no podría decir si el problema ha surgido
por una falta de previsión de Microsoft o por dejación del trabajador.
Lo que queda claro, bajo esta hipótesis, es que la cadena se rompe
por el eslabon más débil, y que las políticas de seguridad deben
contemplar todos los elementos que forman parte de sus sistemas,
incluido los ordenadores domésticos utilizados para trabajar.

– En la anterior entrega comentaste que era posible introducirse
en la red interna de Microsoft de forma similar a la descrita en
las primeras hipótesis, de forma más optimizada, y salvando las
dificultades con las que “Qaz” se habría encontrado, ¿cómo?

En primer lugar, “Qaz” se presenta de forma visible, necesita que
la víctima ejecute el fichero adjunto, y además es reconocido por
los antivirus. Una forma más elegante de llegar a la víctima podría
ser mediante algunas de las vulnerabilidades descubiertas por
Guninski, que son públicas antes de que Microsoft facilite solución
alguna. Muchas de estas vulnerabilidades permiten introducir código
de forma interna en un mensaje HTML, ejecutarse con tan sólo
visualizar el mensaje, y sin necesidad de que el usuario abra un
fichero adjunto.

Para asegurar que el usuario de la red interna de Microsoft lea el
mensaje, el atacante, haciendo uso de la Ingenieria Social, escribiría
un asunto muy sugerente, para terminar escribiendo en el cuerpo del
mensaje un texto publicitario. Esta combinación provoca que el
trabajador de Microsoft abra el mensaje y tras comprobar que se trata
de publicidad termine por eliminarlo. Durante este proceso, el código
del atacante se habrá ejecutado e instalado en el sistema, y además
se consigue que el mensaje tenga bastantes opciones a ser eliminado,
con lo que se borrará el rastro de entrada.

– Bien, has conseguido entrar en la red interna de Microsoft, de
manera similar, aunque más optimizada, a cómo lo podría haber hecho
“Qaz”, pero, ¿cómo conectas con el ordenador de la víctima en la red
local si no puedes interrogar su dirección IP interna y además hay un
cortafuegos entre ambos?

La solución es fácil, no es necesario abrir puertos TCP en el
ordenador del usuario ni conectar de forma directa con él. El código
instalado a través de algunos de los agujeros de Guninski podría ser
una especie de backdoor offline, que recoja las instrucciones a
través de macros que lee de forma periódica desde un fichero vía web.
Es decir, el atacante situaría las instrucciones en una web, el
backdoor se conecta regularmente a esa dirección vía el servidor
proxy para recoger el fichero y ejecutar los comandos. Tanto el
servidor proxy como el cortafuegos de Microsoft, en teoría, no deben
encontrar nada irregular en estas conexiones, ya que son exactamente
iguales a las conexiones que el usuario realiza mientras navega por
Internet.

– En las primeras hipótesis algunos medios contemplaron la posibilidad
de que se tratara de piratas rusos, ya que supuestamente enviaban
la información obtenida a una dirección de correo en Rusia. ¿esta
lectura es correcta?

Es muy probable que no, ya que una de las técnicas básicas en estos
casos consiste en contar con diferentes ordenadores que actúan
como puentes, a ser posible en diferentes países, con el fin de
dificultar el rastreo hasta el origen del ataque. Lo más probable es
que los atacantes se encuentren en un país distinto al que apunta la
primera evidencia.

No siempre es necesario utilizar un buzón de correo para enviar la
información, ya que facilita la monitorización en caso de que el
ataque fuera descubierto. Otra opción consiste, por ejemplo, en
utilizar como destino de la información algún foro público. Siguiendo
con nuestra hipótesis, supongamos que la información sensible obtenida
por el backdoor es almacenada en un fichero en un formato comprimido
propietario y/o cifrado. Es fácil por ejemplo implementar una versión
de ZIP que no pueda ser descomprimida por una utilidad estándar. Este
fichero podría ser enviado a una news de mucho tráfico y donde es
normal se adjunten ficheros. Por ejemplo, podríamos renombrarlo como
xxxx.jpg y enviarlo a una news de gráficos de sexo. Los usuarios que
descargaran el fichero creerán que se encuentra corrupto, ya que
no lo pueden visualizar. El atacante podrá descomprimirlo con
su versión de ZIP y acceder a la información sensible. Si la
víctima descubre el ataque, le sería imposible monitorear e intentar
el rastreo entre cientos o miles de usuarios que acceden a diario
al fichero.
Por último, agradecer los mensajes que los lectores me han hecho
llegar respecto a este caso, cuyos comentarios y consultas son la
base de este guión, a la espera de que el presente haya servido
de ayuda.

Más información:

Declaración oficial de Microsoft
http://www.microsoft.com/technet/security/001027.asp

26/10/2000 – Caso Microsoft: la filtración
http://www.hispasec.com/unaaldia.asp?id=732

27/10/2000 – Caso Microsoft: debilidades en el planteamiento
http://www.hispasec.com/unaaldia.asp?id=733