jueves, 22 de febrero de 2018

Scripteando con Meterpreter: Sacando un screenshot y algunas cosas más

Estamos en semana PRE-RootedCON y quería seguir hablando sobre el Meterpreter y los scripts que nutren a este magnífico payload. Quería hacerlo desde otro punto de vista que es la creación de estos scripts que hacen que las funcionalidades que Meterpreter nos ofrecen un pentest sean infinitas. Hace unas semanas hablamos sobre cómo funcionaba el IRB en un Meterpreter y también en Metasploit, ya que también se puede utilizar desde la consola msfconsole. 

Figura 1: Scripteando con Meterpreter: Sacando un screenshot y algunas cosas más
En el artículo de hoy ampliaremos el uso del IRB del pasado artículo para ver qué tipo de acciones podemos hacer y cómo sacarle el máximo rendimiento y poder hacer nuestros primeros scripts. Sobre todo, ir cogiendo ideas para todo lo que se os pase por la cabeza hacer con una sesión de Meterpreter

Figura 2: RootedLabs
Hoy comenzaremos con la posibilidad de crearnos nuestro propio script que nos permita capturar la pantalla de la máquina comprometida. Para ello, estudiaremos las diferentes funciones y el uso de estas para lograr nuestro objetivo. Respecto a la RootedCON, no dejes pasar la oportunidad y apúntate en estos últimos días al Lab de Metasploit que tengo el honor de impartir allí. 

Los métodos para el estudio 

Meterpreter dispone de un comando propio que se llama screenshot, por lo que sabemos que se puede capturar la pantalla de la máquina comprometida de manera sencilla. Ahora vamos a localizar el método que se puede utilizar para llevar a cabo esta acción desde el objeto client en el IRB de Meterpreter

Hay una clase llamada UI, User Interface, con la que Meterpreter puede acceder a diferentes dispositivos de interacción como, por ejemplo, el teclado, el ratón o la pantalla. Si observamos la imagen podemos ver como el objeto client dispone de una serie de métodos que cuelgan de ui. En estos métodos ya podemos ver cosas interesantes como idle_time, screenshot, keyscan_start, keyscan_dump, keyscan_stop, etcétera. Ya podemos imaginar las cosas que podemos hacer con ello, y todo desde el IRB y acabar generando nuestra funcionalidad en forma de script de Meterpreter

Figura 3: Clase UI

Vamos a hacer uso de client.ui.screenshot. Antes de generar el código, vamos a probar que tipo de salida facilita el método. Para ello lo invocamos y lo almacenamos en una variable del intérprete. Como se puede ver, la salida es un array de bytes, los cuales representa la captura de pantalla de la máquina remota. 

Figura 4: Datos de la captura de pantalla
Con la opción conf.echo podemos indicarle al IRB si queremos que la salida de ejecución se muestre por pantalla. En el caso de la obtención del screenshot, no queremos ver la representación en bytes, solamente queremos que se almacene en una variable, en este caso en la variable screen. Con el método lengthvemos el tamaño de la captura. 

Ahora, volcaremos el contenido a un fichero utilizando para ello la clase fs y file en el objeto client. Utilizaremos la instrucción client.fs.file.methods y obtenemos un listado de métodos disponibles. Descubrimos el método download, el cual nos permitirá descargar a nuestra máquina, en este caso, un Kali Linux. Hay que tener en cuenta como generamos el fichero y con qué modo de apertura. Para este ejemplo, lo abrimos con 'wb', es decir, que podemos escribir en él. 

Lo primero será crear un fichero en la máquina remota con client.fs.file.new, tal y como se puede ver en la imagen. Una vez creado el fichero en remoto, utilizaremos el método client.fs.file.download para descargarlo desde la máquina comprometida hacia nuestra máquina. 

Figura 5: Descarga de la captura de pantalla a fichero
Recapitulando, en la máquina Windowscomprometida se debe haber creado un fichero en el escritorio del usuario. Como se puede ver en la imagen, el fichero, ahora mismo, ocupa 0 bytes, ya que aún no hemos volcado los bytesde la variable screen en el fichero. Además, si el fichero se intenta eliminar actualmente no se podrá, ya que está siendo utilizado por el proceso. En otras palabras, el fichero está abierto. 

Figura 6: Primero creamos el fichero con 0 bytes
Ahora volcamos el contenido de screen al fichero mediante el uso del método write. Este método lo encontramos en client.fs.file. Una vez hecho esto, hay que cerrar el fichero con el método close

Figura 7: Volcando los datos de la captura al fichero creado
Ahora toca descargar el fichero mediante el uso de client.fs.file.download. Realmente, existen dos métodos download y download_file. En este caso, vamos a utilizar el método download_file, el cual, si vemos el código fuente vemos que recibirá dos parámetros. ¿Dónde encuentro las declaraciones de las funciones? En este caso, podemos encontrarlo en /usr/share/metasploit-framework/lib.

Figura 8: Descarga del fichero
El fichero se llama file.rb y contiene la definición de los métodos de la clase file comentada anteriormente. Ahí podemos ver como el método necesita dos argumentos y qué tipo de argumentos necesita. Por último, ejecutamos la instrucción client.fs.file.download_file("/root/screenW7.jpg", "c:\\users\\ieuser\\desktop\\screen.jpg").

Automatizando todo: Generando el script para Meterpreter 

Por último, vamos a crear un script para Meterpreter. Hay algún cambio como, por ejemplo, la no necesidad de hacer el download. ¿Por qué? Cuando hacemos el client.ui.screenshot, ya se dispone en local del array de bytes, por lo que, directamente, se puede volcar a un fichero local. 

La primera parte del script, que se puede ver más abajo, comprueba si la plataforma en la que se está ejecutando el paylaod es Windows. En caso de que no, el script no se ejecuta. Si la ejecución sigue adelante, se hace el procesamiento de los argumentos que el scriptpuede recibir. La clase Arguments se encarga de recibir un listado en formato clave-valor, dónde la clave es un valor del parámetro, en este caso será '-h' e 'i'. El valor asociado a la clave es un array con dos elementos. En el caso de '-h' se ejecutará la opción de ayuda. 

Figura 8: Script del payload que automatiza la captura
La variable opts tiene el método parse, con el que se "parsea" la entrada del script. La variable args con los argumentos del script es pasada al método parse. Cuando se ejecuta el script, utilizando run myScreen -i, la variable argsalberga la línea de entrada dónde se encuentra, en este caso, -i. Si el usuario ejecuta el parámetro -i, se cambiará el estado de la variable idle a true y, posteriormente, se ejecuta las instrucciones necesarias para obtener el screenshot

Para ejecutar el script en nuestra sesión de Meterpreter, simplemente podemos ejecutar la siguiente instrucción con el comando run o, directamente, podemos introducir nuestro scripten la carpeta dónde se encuentran el resto de scripts de Meterpreter, para evitar utilizar el run. 

Figura 9: Ejecución del script
Sin duda, el IRB nos proporciona un mundo lleno de posibilidades para el desarrollo de funcionalidades nuevas para el framework de explotación más utilizado. Atrévete y juega con el IRB de Metasploit y Meterpreter y plasma tus ideas.

Créditos: Pablo González Pérez

miércoles, 14 de febrero de 2018

ATENCION!!! El secreto que esconde el juego "¿Cómo te verías siendo del sexo opuesto?"

Seguro has visto durante los últimos días un juego en Facebook que modifica tus fotos para que veas cómo serías si fueras del sexo opuesto, sin embargo esta entretenida aplicación esconde un secreto.

No se trata de un virus ni un malware que dañará tu teléfono, pero es importante tener claro cuáles son los riesgos de este tipo de juegos.

La aplicación que se ha viralizado en los últimos días tomará todos tus datos personales, usándolos para el fin que la empresa detrás de la aplicación estime conveniente. El gran problema es que lo hacen con tu consentimiento, ya que antes de empezar te pide una autorización, ingresando así a todos tus datos personales, los que pueden ser revisados por la empresa que maneja el juego

 

Este no es el primer caso parecido, ya que la empresa creadora de ¿Cómo me vería del sexo opuesto?, Kueez, ha creado varios juegos del mismo tipo como el que te dice el nombre de tu ángel guardián o cómo te verías en 20 años más. Todas con el mismo fin, obtener datos para más tarde venderlos a empresas de publicidad.

Pero hay un lado más oscuro aún, ya que hay otras aplicaciones del mismo tipo que piden aún más datos, pudiendo acceder incluso a tu información bancaria. El gran problema es que muchos ni siquiera se fijan lo que están aceptando.

Ahora, si fuiste uno de los que jugaron, hay una solución, ya que se puede revocar los accesos que has dado a tu información personal. Para eso debes ingresar a la configuración de Facebook, seleccionar la opción "aplicaciones" y buscar la que tenga el nombre "kueez" y hacer click en eliminar. De esta manera la empresa ya no podrá acceder a tu perfil.

viernes, 2 de febrero de 2018

Almacenamiento Inseguro de Claves en Software SCADA (Rockwell y GE)

Todos sabemos que en los ambientes SCADA se suele utilizar sofware antiguo, obsoleto, y muchas veces sin parches, ya que si las cosas funcionan bien en un ambiente industrial no se suelen tocar mas (no muchos se animan a actualizar sistemas de control, con el riesgo que conlleva para el ambiente productivo).

Haciendo un análisis en un cliente, me encontré con un software de Rockwell Automation denominado Desklock. Es un software que se utiliza, básicamente, para restringir a los operadores de los sistemas industriales de forma que solo puedan acceder a la aplicación SCADA y bloquear todo el resto (aplicaciones de windows, barra de tareas, escritorio, apagado de la maquina). También tiene la funcionalidad de autologon, para iniciar sesión automáticamente con el usuario local o de dominio que indiquemos en la configuración.

Autologon...me trae recuerdos =D imagino que las credenciales las debe estar guardando en algún lado para para poder iniciar sesión en el equipo, ya sea en un archivo o en la registry, dado que el host es un Windows 7. En conclusión, que es lo primero que voy a mirar? El archivo de configuracion DESKLOCK2000.CFG


Abriendo el archivo de configuración nos encontramos con lo siguiente:


Con el objeto de realizar pruebas, le había puesto como contraseña para poder abrir el Desklock y modificar su configuración "abcdefg". Analizando la contraseña "encriptada" claramente se esta utilizando un cifrado cesar o cifrado monoalfabetico por desplazamiento, en este caso "la clave" o el numero de espacios a desplazar es -4 que convierte por ejemplo una letra "e" en una letra "a" y una letra "a" en el símbolo "]" según la tabla de caracteres ascii imprimibles. En base a esto la clave original "abcdefg" se convierte en "]^_`abc"


Y la contraseña del usuario utilizado para el autologon? También esta guardada en el archivo de configuración, cifrada de la misma manera que la clave de desklock:


Esta clave no la puedo mostrar porque ya estaba configurada y no la había elegido yo, pero fíjense que sigue el mismo esquema que la clave anterior, la ultima coma de la clave cifrada corresponde a un 0 en la clave original.

Igualmente decidí revisar la registry a ver si la clave también se guardaba ahí, y resulta que en la key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon el autoadminlogon estaba activado y se encontraba en texto plano el nombre de usuario en DefaultUserName y su correspondiente contraseña también en texto plano en DefaultPassword. 

Entiendo que Rockwell soluciono el almacenamiento inseguro de la clave, ya que hubo un advisory con respecto a este tema en el software Rsview32 (del cual DeskLock es parte, es una de las herramientas incluidas en las tools):

https://ics-cert.us-cert.gov/advisories/ICSA-15-132-02

En un test de intrusión interno en otro cliente nos había pasado algo parecido con el sofware de GE Proficy Ifix.

El tema es este, Ifix guarda las credenciales en un archivo de configuración denominado xtcompat.utl, aparentemente cifrado, pero la realidad es que Ifix solo realiza una operación matemática de XOR entre el valor de los campos descripción, usuario y password y tres claves estáticas predefinidas:



A continuación se puede ver en hexadecimal el archivo xtcompat.utl, los campos que nos interesan son los marcados en colores, el resto es relleno (ahora se los cuento así ligeramente, pero la verdad es que estuve un buen rato mirando los archivos hexa hasta descubrir bien donde estaba cada campo y cual era el relleno). 


Si llegan a encontrar un Ifix por ahi, ya no van a tener que hacer el análisis manualmente como hice yo en un principio, pueden utilizar la herramienta que desarrollo mi amigo lbrug que directamente lee el archivo xtcompat.utl, realiza la operacion de XOR con las claves estaticas correspondientes y muestra el usuario, password y descripción:

https://github.com/lbrug/ifixpwdump

Entiendo que también hubo un advisory al respecto y GE soluciono este tema, pero como les dije al principio no es raro encontrar software desactualizado en entornos SCADA en el cual estas vulnerabilidades sigan presentes:

https://ics-cert.us-cert.gov/advisories/ICSA-16-336-05B

Saludos y espero que les haya gustado!

Créditos

Ing. Yamila V Levalle 

Microsoft lanza su app Copilot para Android

  Microsoft lanza su app Copilot para Android Microsoft lanza su app Copilot para Android Microsoft está probando las actualizaciones Window...