Qué es BASHware y su uso en el WSL

Conoced al nuevo chico en la ciudad: el BASHware y su uso en el WSL

En este blog publicamos a mediados del año pasado, con ocasión de cumplirse un aniversario más -el vigésimo sexto- del lanzamiento del GNU/Linux, una curiosa incursión del SO del pingüino en el campo del software privativo, específicamente en Microsoft® Windows®. Justamente la compañía de Redmond recién había finalizado su fase beta del “Windows Subsystem for Linux”® (abreviado como WSL) y en el punto ocho del artículo referido presentamos esta novedad y cerramos ese renglón preguntándonos: “¿Hay seguridad en ese ambiente?”.

Nuestra pregunta retórica fue contestada en el Congreso de Seguridad Informática Rootedcon 2018, realizado en la ciudad de Madrid en marzo -al cual no pudimos asistir pero seguimos por las redes sociales-, y donde el equipo de Checkpoint realizó una ponencia al respecto. Os invitamos a leer nuestro análisis de la recién estrenada brecha que os describimos desde el punto de vista muy particular de un programador.

Planteamiento del marco teórico

Bien reza el refrán que “lo único constante es el cambio” y cada vez que se le añade una herramienta de trabajo a cualquier software, siempre habrá incidencias -o “bugs”- que incluso pueden ser analizados para conocer si pueden cobijar intenciones subrepticias.

Originalmente, Microsoft® explicó claramente las limitaciones que tiene el WSL: no era para producción (bases de datos, servidores web) ni tampoco tenía apoyo para programas gráficos. En pocas palabras, solo era, como nosotros decimos, un “parque de diversiones” para los programadores (tanto hackers como crackers). En el caso de nosotros, los hackers, esta característica nos ahorra mucho tiempo, ya que los guiones o scripts que tengamos escritos para GNU/Linux podremos ejecutarlos en dicho ambiente privativo, pero siempre modificando las variables de entorno (en todo caso el trabajo de adaptación es mínimo, la unidad “C:\” queda montada como “/mnt/C/usuario” y siempre recordando que las mayúsculas son diferentes de las minúsculas).

Entrando de lleno en la materia, para poder habilitar el “Windows Subsystem for Linux” -el cual, repetimos, no tiene nada que ver con el núcleo o kernel de Linux, pues las utilidades GNU realmente se ejecutan en el kernel de Windows®- se necesitan derechos de administrador e incluso reiniciar el ordenador. Aunque este hecho es reconfortante debemos tener en cuenta lo siguiente: cada día Windows 10® ocupa cada ordenador nuevo que va saliendo de los fabricantes, ya que por la agresiva política de mercadeo viene con ese sistema operativo preinstalado. ¿Quién nos garantiza que venga deshabilitado, por defecto? Este último enfoque lo derivamos del punto 15 de la Licencia Pública General GNU: “El riesgo completo tanto de la calidad y desempeño del programa corre por vuestra cuenta”, es decir siempre descansa sobre nuestros hombros la responsabilidad final de nuestros sistemas.

Debemos aclarar que el personal de Microsoft se ha pronunciado al respecto y ha refutado que esto sea una vulnerabilidad de Windows® y que no dedicarán más tiempo al asunto (han transcurrido varios meses desde la realización del congreso de seguridad y ninguna noticia nueva hay al respecto), pero aquí en Pandora FMS es nuestro deber analizar la mayor cantidad de escenarios posibles y suministrar las herramientas: es mejor tenerlas y no necesitarlas que necesitarlas y no tenerlas; la monitorización incluye también eventos a futuro en la medida de lo posible. Lo que a continuación os planteamos es algo hipotético y no pretende ser una guía para acometer en algún sistema, sino que lo escribimos desde el punto de vista de cómo podría afectar nuestros sistemas.

Monitorización con Pandora FMS

Otra posibilidad muy remota, más directa porque va dirigida a redes locales o virtuales específicas, es que un actor que tenga control sobre algún “Active Directory” ordene la habilitación de WSL en cientos o quiźas miles de máquinas que se conecten a ese dominio (empresas y sucursales completas). Todos los programas antivirus y sucedáneos no detectarán tales cambios porque simple y sencillamente son aplicaciones del propio Microsoft®, legítimas y firmadas digitalmente, de allí que nuestra responsabilidad sea tener conocimiento de tal evento.

Aquí es cuando Pandora FMS y su flexibilidad nos pueden ayudar en nuestra labor: publicamos una introducción a la monitorización de logs (incluye enlace para comprobar el enfoque bajo Pandora FMS), como también un artículo en el que explicamos la diferencia entre filtrar y seleccionar los “syslogs” (que se generan incluso cuando activamos alguna característica de Windows®), los cuales forman parte de las métricas de monitorización comunes en los sistemas operativos modernos. Es por ello que la flexibilidad, insistimos, se hace patente: podemos configurar Pandora FMS para que informe si alguna característica le es incorporada a algún ordenador que monitoricemos.

Valga este texto para sugerir que las aplicaciones antivirus comiencen a llevar un “inventario” al ser instalados y muestren una advertencia -o de plano lo bloqueen- de las posibles debilidades. También discernimos entre lo que ya se encuentra instalado y los cambios realizados: lo primero es tarea de los antivirus, lo segundo son eventos que pueden -y deben- detectar las herramientas de monitorización.

Terminología: el BASHware

El idioma inglés es famoso por su tendencia a apocopar los términos: el que conocemos como “malware” proviene de la contracción de “malicious software” (programa malicioso) y como la primera palabra proviene del latín malitiosus nuestra lengua castellana hace uso inmediato del término. Pero he aquí nuestro punto: masificar el término “BASHware” con denotación maligna es incorrecto, lo que existe es el “malware” aplicado de diferentes formas porque las herramientas que nosotros, los administradores de red, migramos son inocentes en su totalidad. Ahora bien, si una persona con aviesas intenciones desarrolla guiones en BASH entonces sí que estaremos hablando de malBASHware (“badBASHware” en idioma inglés).

Pasos para poder utilizar el BASHware

Windows® siempre ha integrado su propia línea de comandos, pero desde Windows Vista® en adelante tiene una herramienta más poderosa creada para igualar las funcionalidades del BASH/GNU: el Powershell®.

Con esta herramienta (Powershell®) explicamos los pasos posteriores:

Habilitando el WSL en Windows 10®

Sí, el WSL solo es para Windows 10®, aunque en la última figura habilitamos las herramientas remotas para una máquina virtual con Windows 7®. Powershell viene activo por defecto, lo ejecutamos con derechos de administrador (la parte que dificulta el asunto) e introducimos el siguiente comando (deberemos luego reiniciar el ordenador o simplemente esperar que alguna otra tarea frecuente de Windows Update® lo realice):

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

También es posible habilitarlo por una ventana terminal de Windows:

dism /Online /Enable-Feature /All /FeatureName:Microsoft-Windows-Subsystem-Linux /NoRestart

WSL: habilitando el modo de desarrollador

Lo segundo que tenemos que habilitar -y que dificulta aún más el proceso que planteamos- es el modo de desarrollador y hacerlo permanente. Esto se logra modificando (o agregando) una clave en el registro de Windows®.

Advertencia: el manipular mal el registro de Windows puede conducir a la corrupción del sistema e incluso impedir su inicio y hasta su recuperación. Os rogamos hagáis vuestras pruebas siempre sobre máquinas virtuales desechables.

Para ello usamos el comando “New-Item“, para agregar la siguiente clave:

New-Item -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock" -ItemType Directory -Force

y definimos su propiedad con esto otro, un poco más largo:

New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock" -Name AllowDevelopmentWithoutDevLicense -PropertyType DWORD -Value 1

Como debemos comprobar si dicha clave existe antes de establecer la propiedad a un valor distinto de cero, a los administradores de sistemas nos gusta desarrollar guiones para ahorrarnos el repetir la tarea de nuevo y automatizar todo. En este enlace podréis leer un script completo adelantado a su tiempo -año 2016- y cuya única objeción que le hacemos es que no captura la respuesta del comando New-Item para luego registrar en el syslog el trabajo realizado con su propia función destinada a tal efecto, llamada Write-CMLogEntry. Un hacker se preocupa por dejar constancia para los registros de auditoría que mencionamos en la sección 2.1, ¡un cracker no está pendiente de esto pues se ufana de no dejar rastro!

Para finalizar esta sección, os tenemos que confesar que este paso no es absolutamente necesario, pero, ¿acaso no obtuvimos diversión analizando dicho guion? ¡Aquí nos encantó!

Escogiendo el BASH favorito

Que no son muchos para escoger, pero Microsoft se ha comportado de manera democrática al agregar más distribuciones GNU además de Ubuntu, que es la predeterminada. A la fecha hay soporte para:
openSUSE Leap.

• SUSE Linux Enterprise Server
• Debian GNU/Linux
• Kali Linux
• A corto plazo: Fedora
• Y muchas más vienen en camino

Lo más lógico es escribir para Debian y su hijo pródigo, Ubuntu. En todo caso, si queremos saber cuáles tenemos disponibles introducimos:

wslconfig /l

Si aparece listado Ubuntu, sin mayor retraso:

wslconfig /setdefault Ubuntu

O la que necesitéis o queráis, cambiando la última palabra por alguna de las que aparezca en el listado. ¡Ya estamos a mitad de camino hacia lograr nuestro BASHware de prueba!

Configurando el usuario por defecto

El objetivo aquí será garantizar el privilegio necesario, otra dificultad más y que va dando la razón a las declaraciones del personal de la casa de software de la popular ventanita; esto lo ejecutamos en una venta de comandos de Windows 10®:

• Ubuntu: «ubuntu config –default-user root»
• openSUSE Leap 42: «opensuse-42 –default-user root»
• SUSE Linux Enterprise Server 12: «sles-12 –default-user root»

Ni qué decir que ya que estamos aquí podremos crear nuestros usuarios para diferentes tareas, osea, cada usuario dejará registros diferentes según el BASHware asignado a ejecutar. Con el famoso comando para agregar usuarios lo logramos:

sudo adduser nombre_de_nuevo_usuario

La guinda que le faltaba al pastel: syslog, el encargado de registrar los eventos, aunque viene preinstalado, no está habilitado de manera predeterminada en WSL. Dicho problema permanece aún abierto en la página de Github al momento de escribir esta entrada y eso está fuera de nuestro alcance y es bueno que lo tengamos siempre presente.

Instalando Wine

Rápidamente explicamos que Wine es un software que, instalado sobre GNU/Linux, permite ejecutar ciertas aplicaciones de Windows®. Aquí es donde se presenta la muy remota posibilidad: el poder ejecutar programas fuera del alcance de los antivirus o del mismo Windows®. Precisamente, la monitorización se encarga de llevar cuenta de estas situaciones, aunque la línea que separa las tareas de seguridad y monitorización es extremadamente delgada. Para ilustrar este punto diremos que, a modo de ejemplo, una cosa son los datos y otra las informaciones: éstas últimas se obtienen de los primeros mediante un proceso o algoritmo (monitorización); esta información se vuelve a convertir en datos cuando nos es solicitada por el personal encargado de la seguridad.

Para instalar Wine, si elegimos Debian o Ubuntu:

apt-get install wine

Bien pudiéramos instalar un sistema gráfico para WSL y ejecutar Wine pero no queremos ir tan lejos; en la Wikipedia hay instrucciones sobre cómo hacerlo.

Recomendaciones finales

Si bien esta entrada la escribimos desde el punto de vista de una posible vulnerabilidad, también nos hemos enfocado en las defensas de los antivirus y los mecanismos de control del propio SO contra posibles malBASHware. Además recordad en todo momento que Pandora FMS siempre es y será una herramienta útil debido a su flexibilidad, la cual podemos adaptar hacia nuestro trabajo y las alarmas personalizadas que hayamos creado. Sus posibles resultados los podemos agregar al software de gestión de incidencias IntegriaIMS, ya que tiene la capacidad de llevar inventario de hardware, amén de registrar y categorizar las solicitudes de vuestros usuarios en vuestro centro de apoyo técnico. Diez, cien o incluso miles de ordenadores: ¡ambos programas están capacitados para satisfacer las demandas de vuestro trabajo!

Arriba tenéis los enlaces para contactarnos y abajo escribid vuestros comentarios, ideas y ¿por qué no?, vuestras críticas también, ¡animaos!