msf15-100: crea tu módulo de Metasploit

El pasado martes 15 de septiembre tuve que viajar a las I Jornadas Nacionales de Investigación en Ciberseguridad en León. A veces es un poco duro el tener que estar cogiendo trenes o aviones para ir y volver en el mismo día, pero a los que nos gusta… nos gusta. Cuando volvía a casa me puse a revisar cosas pendientes que tengo por ojear, y vi la vulnerabilidad ms15-100 de Microsoft. Esta vulnerabilidad me llamó la atención por varias cosas: la primera porque es una ejecución de comandos remota y segundo por lo sencilla que es, es decir cualquier usuario puede entender lo que ocurre con ella.

Decidí comprobar lo fácil de la explotación de la vulnerabilidad así que realicé una pequeña prueba y verifiqué en una máquina virtual con Windows 7 SP1 que todo funcionaba como indica la vulnerabilidad, ¿Fácil, no?

Una vez hecho esto hay que ponerse manos a la obra y quería aprovechar el tiempo de tren para picarme un módulo de Metasploit para esta vulnerabilidad. Lo curioso es que una vez terminado me di cuenta que la gente de Rapid7 ya lo había implementado, lo cual es lógico, ya que la vulnerabilidad es del día 8 de Septiembre.

¿Qué hace la vulnerabilidad?

La vulnerabilidad es tan sencilla que se resume en la existencia de un fichero de tipo mcl que permite instalar cosas en Windows Media Center. Este fichero es utilizado para ejecutar, por ejemplo, plugins y permite ejecutar aplicaciones. Esto abre un campo a la ejecución de código remoto, ya que permite la ejecución a través de UNC, Universal Naming Convention. Como se puede ver en la siguiente imagen el mcl es muy sencillo de entender.

En este pequeño ejemplo rápido, cuando se ejecute un fichero mcl con este contenido se accederá a la dirección IP 192.168.1.14 para solicitar el fichero ubicado en ms15/p.exe y se ejecutará, provocando la ejecución remota y, por supuesto, maliciosa.

El módulo que realicé está subido a mi github, el cual uso como almacén. El módulo tiene la función Initialize, como siempre, y que comentamos brevemente a continuación:

• En DefaultOptions se indica qué atributos del módulo tendrán una configuración por defecto, y en este caso se han configurado EXITFUNC para que sea process y en el atributo InitialAutoRunScript se configura el comando migrate –f, para que cuando se ejecute el payload se cree un nuevo proceso y la ejecución del payload se realice en el nuevo proceso y no en el proceso comprometido.
• En Targets se indica a qué software afecta la vulnerabilidad y con DefaultTarget se indica qué target es el elegido.
• La función register_options da de alta nuevos atributos en el módulo. En este caso se han dado de alta los siguientes atributos: FILENAME para indicar el nombre con el que se creará el fichero que contiene la ruta del código malicioso, PoC_BINARY el cual indica la ruta al binario que se quiere ejecutar, PoC es un booleano que indica el tipo de ejecución, ya que el módulo tiene 2, una en modo prueba de concepto que abre una calculadora y otra que genera un binario con un payload y prepara el fichero con esa ruta. Por último tenemos el atributo EXE el cual indica el nombre o ruta en el que se creará el binario malicioso, generalmente utilizaremos una Meterpreter dentro del binario.

Hasta aquí la parte más administrativa y más sencilla del módulo. En este caso, el módulo no será complejo, pero ¿Qué queremos que haga el módulo? Como se mencionó anteriormente el atributo PoC es un enumerado que representa a un booleano, el cual solo puede coger dos valores true y false. Por defecto es false, es decir, se ejecutará una pequeña prueba de concepto que genera un fichero mcl con la siguiente instrucción . Cuando el usuario ejecute el archivo se abrirá una calculadora en su sistema Windows.

En la siguiente imagen se puede ver la definición de la función exploit y la definición de la función make_poc_mcl, la cual es utilizada en la primera función. La función exploit comprueba el modo en el que se lanza el módulo por parte del usuario, empezando por el atributo PoC. Si la ejecución es con el valor false se crea un fichero solamente con la instrucción file_create(mcl) en la que la variable mcl vale “<application run=”[valor de PoC_Binary]”/>.

Si la ejecución vale true se utiliza el objeto framework, el cual está disponible en el intérprete de Ruby que se puede ejecutar desde la consola de Metasploit. Este objeto nos da acceso a todo lo que podemos hacer con el framework desde la consola de comandos. En este caso buscamos crear una instancia del módulo de tipo payload que haya indicado el usuario en la variable PAYLOAD. Por ejemplo, si el usuario configura PAYLOAD como windows/meterpreter/reverse_tcp la instrucción m = framework.modules.create(datastore[‘PAYLOAD’]) crea una instancia de dicho módulo.

Después se configura la variable interna del módulo de tipo payload con la instrucción m.datastore[‘LHOST’] = datastore[‘LHOST’], por si el módulo seleccionado por el usuario requiere este atributo.

Queremos generar un ejecutable del payload, por ello se utiliza la función interna generate_simple. En las opciones que se pasan a la función se utiliza la clave ‘Format’ para indicar que será un exe. Una vez generado y almacenado en memoria el ejecutable hay que pasarlo a disco para ello se utilizar funciones básicas de Ruby. Por último, la ejecución del módulo acaba generando un fichero mcl el cual puede apuntar a un recurso compartido dónde nosotros almacenaremos el binario que acabamos de crear.

¿Cuál es el objetivo? Por ejemplo, si el atributo PoC_BINARY vale \\<dirección IP>\ruta al binario.exe y se crea un fichero mcl que invoque este binario automáticamente al abrir el fichero tendremos la ejecución de comandos de la vulnerabilidad que Microsoft acaba de parchear hace pocos días. Configurando el exploit/multi/handler después podremos recibir las conexiones.

Todo esto en el viaje de vuelta de León, ha sido divertido. Ya sabéis de 17 a 20 se puede hacer muchas cosas…