Introducción
Las impresoras presentan un caso interesante en el mundo del Internet de las Cosas (IoT), ya que son un hardware muy potente en comparación con la mayoría de los dispositivos IoT, aunque la mayoría de los administradores no suelen considerarlas un ordenador "real". A lo largo de los años, muchos investigadores de seguridad han estudiado e informado sobre las vulnerabilidades de las impresoras. Sin embargo, la gran mayoría de estas investigaciones se centraban en cómo hackear la propia impresora para hacer cosas como cambiar la pantalla de la impresora o robar los documentos que se imprimían. En este caso, investigamos cómo utilizar el papel especial que tienen las impresoras dentro de la mayoría de las redes para infectar realmente los dispositivos de los usuarios finales y ampliar la huella de su ataque dentro de la red.
Fondo
Para entender este problema, tenemos que entender un poco sobre el Protocolo Microsoft Web Point-and-Print (MS-WPRN) y por qué funciona de la manera que lo hace.
La mayoría de las organizaciones intentan aplicar el principio del menor privilegio a los dispositivos de sus redes. Esto funciona bastante bien para cosas como ordenadores portátiles o de sobremesa, ya que el hardware que utilizan no cambia tan a menudo. Sin embargo, las impresoras son un poco diferentes. Aunque siguen necesitando controladores, las impresoras tienen que soportar prácticamente cualquier usuario que quiera conectarse a ellas. A medida que los usuarios finales se desplazan por un edificio, naturalmente quieren utilizar la impresora que tienen más cerca. Los usuarios móviles esperan poder conectarse y utilizar fácilmente una impresora cuando llegan a la oficina. Además, la mayoría de las organizaciones no se estandarizan en una sola impresora, y tendrán múltiples modelos y fabricantes a menudo dentro de una misma red.
Así que, en lugar de que los administradores de sistemas enviaran todos los controladores de impresora posibles a todas las estaciones de trabajo de la red, la solución era desarrollar una forma de entregar el controlador a un dispositivo de usuario justo antes de que se utilizara la impresora. Y aquí es donde apareció Point-and-Print. Este enfoque almacena un controlador compartido en la impresora o el servidor de impresión, y sólo los usuarios de esa impresora reciben el controlador que necesitan. A primera vista, se trata de una solución práctica y sencilla para el despliegue de controladores. El usuario tiene acceso al controlador de impresora que necesita sin necesidad de un administrador: todos salen ganando.
La cuestión
El problema es que para que este esquema funcionara bien desde la perspectiva del usuario final, era necesaria una excepción. Normalmente, los controles de cuentas de usuario sirven para advertir o impedir que un usuario instale un nuevo controlador. Para facilitar la impresión, se creó una excepción para evitar este control. Así que al final, tenemos un mecanismo que permite descargar ejecutables desde una unidad compartida, y ejecutarlos como sistema en una estación de trabajo sin generar ninguna advertencia en el lado del usuario. Desde la perspectiva de un atacante, esto es casi demasiado bueno para ser verdad, y por supuesto teníamos que probarlo.
La explotación
En nuestro caso utilizamos una impresora real. Dado que la mayoría de las impresoras están cargadas de funciones, no fue demasiado difícil encontrar un fallo que proporcionara acceso al sistema subyacente. En este caso, pudimos descomprimir una actualización de firmware para reunir algunas credenciales y comprender la disposición del sistema de archivos. En la sección Herramientas, al final de esta página, se proporciona un archivo mágico binwalk y, tras indagar un poco, encontramos el archivo relacionado con esos controladores. Tienen que estar en un controlador compartido "print$" en smb, y normalmente incluyen múltiples sabores para varios tipos de arquitectura (por ejemplo, x86, x64, ppc, alpha). Busque los directorios denominados W32X86, x64, IA64, color, etc.
Simplemente sacamos el archivo x86 dll de la impresora, lo que puede hacerse directamente o a través de rpcclient[5], y lo parcheamos con "the-backdoor-factory"[1].
Esto nos devolvió un archivo dll con un payload inyectado en su interior.
Devolver la dll al directorio original puede hacerse de varias maneras. Normalmente se puede escribir de nuevo en el recurso compartido print$ si se tienen credenciales de administrador de dominio. Alternativamente, con acceso local root a la impresora puedes sobreescribir el archivo existente con el que acabamos de crear. Sigue siendo sorprendente que los vendedores dejen las credenciales ocultas por defecto en la máquina. Si no está en tu diccionario de cracking, siempre es bueno añadir root:myroot por si acaso.
En nuestro ejemplo hemos utilizado una mezcla de Windows XP 32bit, Windows 7 32bit, Windows 7 64 bit, Windows 2008 R2 AD 64, Ubuntu CUPS, Windows 2008 R2 64 servidor de impresión y una impresora sin nombre. Para que Windows 7 funcione bien con Point-and-Print, es necesario configurarlo en el lado de Active Directory y empujado como una política. Un poco más sobre esto en la sección de Protocolo de Impresión de Internet a continuación.
Después de hacer el proceso normal de añadir impresora con autodescubrimiento y seleccionar nuestra impresora (con la dll backdoored), el sistema windows pasa por el proceso normal de adquisición e instalación de drivers.
Esta etapa permite la instalación de un controlador de impresora sin ninguna advertencia de usuario, uac o incluso verificación de firma binaria, y todo bajo los derechos del sistema.
Esto nos dio lo siguiente en el lado msfconsole:
Otros posibles vectores
Dada la naturaleza de este problema, hay muchas formas de utilizar la ejecución remota de código. En el ejemplo anterior, hemos aplicado ingeniería inversa a una impresora de sobremesa, pero la misma función de carga de controladores podría conseguirse con una pila de software diferente y utilizarse en distintos escenarios. Algunos de estos incluyen pero no se limitan a:
- Ataques a abrevaderos
- Copia de seguridad de una impresora o servidor de impresoras existente.
- Servidor de impresión Microsoft: ruta del controlador: c:\windows\system32\spool\drivers\*\3\...
- Servidor de tazas Linux: compruebe si hay un controlador compartido print$ en la configuración.
- Múltiples proveedores admiten Point-and-Printon la propia impresora.
- Re-flashear la impresora con los drivers backdoored.
- Cree un servidor de impresión falso y difúndalo con detección automática.
- Escalada de privilegios
- Utilizar la impresora add como mecanismo de escalada de privilegios para obtener acceso al sistema.
- Mitm ataca a la impresora e inyecta el driver backdoored en lugar del real.
- Globalización con IPP y Webpnp.
Infección remota mediante protocolo de impresión por Internet y web PointNPrint
Hasta ahora nos hemos limitado a una red interna en la que se introducía o infectaba un dispositivo y se utilizaba para infectar otros dispositivos que se conectaban a él. Microsoft Internet Printing Protocol (IPP) y web pointNprint nos permiten extender este problema fuera de la intranet a Internet. Microsoft IPP permite el mismo mecanismo para cargar el controlador de la impresora. Esto se puede hacer con el siguiente fragmento de código del servidor de impresión de MS.
Esta url contiene un archivo que es un ".webpnp" o webpointNprint.
Veamos el contenido de ese bonito archivo binario de 10 MB.
Aquí es donde residen los archivos que van a ser cargados. Los archivos que parcheamos del ataque anterior funcionaban igual de bien tanto si se entregaban a través de smb, Point-and-Print, o bajo webpnp.
Causa raíz del problema
El rastreo del problema nos lleva a una librería ntprint.dll, específicamente alrededor de la función "PSetupDownloadAndInstallLegacyDriver". Específicamente esta es la función responsable de comprobar la política y realizar la instalación con privilegios elevados.
Aunque hay razones válidas de despliegue para querer permitir la instalación de controladores sin derechos de administrador, probablemente siempre se debería activar una advertencia y probablemente siempre se debería comprobar la firma binaria en un intento de reducir la superficie de ataque.
Remediaciones
Vectra y Microsoft colaboraron durante la investigación de este problema, y Microsoft ha proporcionado una solución para CVE-2016-3238 (MS16-087), yCVE-2016-3239como parte deSecurity Bulletin MS16-087, que está disponible aquí.
El comportamiento de Point-and-Print puede definirse con GPO a un nivel de granularidad que debería dar al administrador el control del riesgo. Si bien es posible desactivar Point-and-Print o añadir una advertencia y solicitar UAC, esto sólo nos devuelve al primer problema de cómo gestionar los controladores para que el usuario pueda instalar el controlador sin tener que ponerse en contacto con TI cada vez.
Microsoft proporciona la documentación necesaria en [3],[4], y el desarrollo de enhancedPoint-and-Print(v4), intenta remediar algunos de estos problemas. La migración a una impresora compatible con la versión más reciente del protocolo y la versión más reciente de Windows podría minimizar una parte de la superficie de ataque. No hemos revisado las características de seguridad de v4 / enhanced Point-and-Print más allá de su especificación en este momento, sin embargo, la compatibilidad con versiones anteriores podría hacer que estos esfuerzos sean discutibles.
Comprobación de las redes
Registro de host para activarPoint-and-Print
Exploración de la red en busca del controlador Point n Print