A la caza del mutante, parte III

Estándar

Parte I

Parte II

Parte IV

Parte V

Esta vez, vamos a utilizar las herramientas Process Explorer y Handle, de Sysinternals, para la correcta búsqueda de Mutants (MUTEX) en el sistema.

Siempre que un objeto se crea o se abre, una referencia hacia éste, es creada. Esta referencia, llamada HANDLE, estará asociada con un proceso, a través de una tabla llamada HANDLE TABLE.

Process Explorer, permite, entre otras características, el poder visualilzar estas entradas a través de su interfaz gráfica. Para ello, tendremos que activar el panel inferior, y que sólo nos muestre la referencia.

Imagen 1.- Mostrar handle en Process Explorer

Una vez que el panel inferior se encuentra activo, es fácil encontrar las referencias a los MUTANT (MUTEX), tal y como se muestra en la siguiente figura:

Imagen 2.- Mutant visualizado con Process Explorer

Si se necesita automatizar el proceso en forma de línea de comandos, la herramienta Handle, de Sysinternals, permitirá extraer todas las referencias, incluyendo las del directorio \BaseNamedObjcts. Para ello, habrá que pasarle el parámetro –a, para que incluya todos los handle. Si se desea que pregunte por el Security Descriptor, incluiremos también el parámetro –u.

Imagen 3.- Mutant descubierto a través de Handle

En el próximo post, realizaremos esta tarea, utilizando para ello volatility framework, en un análisis offline.

Saludetes!

 

Anuncios

A la caza del Mutante. Parte II

Estándar

Parte I

Parte III

Parte IV

Parte V

La forma más sencilla de buscar mutantes (MUTEX) en nuestro sistema y en tiempo real, es utilizando las herramientas de SysInternals. Para ello, la primera herramienta que utilizaremos será WinOBJ, la cual nos permitirá visualizar, de forma jerárquica, el manejador de objetos (Object Manager) de Windows. Cada recurso de Windows, se encontrará catalogado en un espacio de nombres. Un recurso puede ser la memoria RAM, una entrada de registro o un directorio, por ejemplo.

Cada objeto administrado por el Object Manager tendrá una estructura determinada. Bajo esta estructura, se encontrará un nombre que identifique al objeto en sí (Object Name) y un Security Descriptor, el cual aportará información sobre los derechos de acceso del objeto.

Los MUTANT (MUTEX),  entre otros objetos, se encuentran catalogados en el directorio (Object Directory) \BaseNamedObjects. Dentro de este directorio, podremos realizar consultas gráficas para encontrar fácilmente Mutex maliciosos.

Imagen 1.- Acceso a objetos MUTANT a través de WinObj

A través de esta utilidad, se pueden realizar consultas al Security Descriptor, para conocer qué derechos de acceso y dueño, tiene este objeto.

Imagen 2.- Permisos de Objeto MUTANT

En la próxima entrega nos centraremos en la búsqueda de estos objetos a través de otras herramientas de Sysinternals como Process Explorer o bajo línea de comandos con Handle.

Referencias

Object Manager (PDF)

Object Manager (PPT)

Object Manager (Wikipedia)

A la caza del Mutante. Parte I

Estándar

Parte II

Parte III

Parte IV

Parte V

Un mutante, es como Windows llama de forma común a un Mutex. Un mutex ayuda a la hora de acceder a los recursos del sistema, o como mecanismo que ayude a que sólo una instancia de la aplicación se encuentre corriendo en el sistema.

Las aplicaciones pueden crear mutantes con un nombre específico o con un nombre en particular. Si una segunda instancia de la aplicación es ejecutada en el sistema, ésta intentará crear un mutex sin éxito, lo cual obligaría a la aplicación a terminar.

A menudo este tipo de técnicas son utilizadas por malware de diverso tipo para prevenir múltiples infecciones de una misma cepa. Y a menudo también nos podemos encontrar con aplicaciones que crean Mutex con la finalidad de proteger al sistema operativo. Entre los diferentes mecanismos de protección que puedan ofrecer, uno de ellos es la creación de Mutex a priori utilizados por Malware. Con esto intentan prevenir que algún tipo de virus pueda ejecutarse bajo esta técnica.

Utilizar la búsqueda de Mutex maliciosos como única técnica de detección de Malware es algo muy pobre, debido a que es muy fácil modificar este parámetro. Una prueba de ello lo tenemos en el configurador del archiconocido Poison Ivy.

Imagen 1.- Nombre de Mutex generado automáticamente por Poison Ivy

Es por ello que, unido a mi morbosa curiosidad, y dado el incremento de este tipo de técnicas en la programación de Malware, que dedicaremos 5 entradas sobre las técnicas y herramientas existentes para buscar con éxito mutantes (MUTEX) creados por aplicaciones.  Para ello, iremos realizando las operaciones desde lo más fácil, a lo más difícil, siempre desde mi punto de vista. La búsqueda de Mutex las realizaremos desde el punto de vista de:

  • Herramientas de Sysinternals (Análisis en Vivo)
  • Volatility Framework (Análisis Offline)
  • WinDBG (Debugging Tools de Windows) (Análisis Offline)

Nos vemos en la segunda parte!!

Volatility Framework Installer

Estándar

Hola a tod@s!!

Hace tiempo que salió al público el estupendo trabajo de muchos investigadores que dio como resultado la herramienta Volafility Framework.

Los que me conocéis, sabéis que yo llevo dando por saco con el tema de la memoria RAM desde hace bastante tiempo. Gracias a Dios, que conforme más tiempo pasa, más información sobre este tema hay.

Yo mismo he dado algún que otro Webcast en Microsoft sobre este mismo tema, he hablado en las FIST, y en algún que otro Asegur@IT.

El Framework está escrito en su totalidad en Python. En su día, para hacer funcionar la herramienta, tanto en Windows como en Linux o MAC, tan sólo hacía falta instalar Python y vualá! Ya teníamos el Framework en funcionamiento.

Hoy día la cosa ha cambiado bastante. Existen multitud de Plugins que hacen de la herramienta una tool muy poderosa para analizar por completo la memoria RAM, pudiendo ahorrar costes en tiempo en un análisis forense corporativo o por proyecto. E incluso por diversión!!

El problema para gente que está empezando en esto, es que a día de hoy existen tantos plugins y dependencias, que instalar la herramienta desde cero, y dotarla de una funcionalidad aceptable, puede conllevar una inversión de tiempo importante.

Esto lo pensó en su día Jamie Levy (aka Gleeda), colaboradora habitual en el desarrollo de Volatility Framework, y desarrolló, entre otros impresionantes plugins, uno con la posibilidad de descargar todos los plugins de un tirón. El script para la versión 1.4 de la herramienta, e instalación bajo Linux, lo tenéis disponible aquí.

Yo he realizado mi particular script (en batch! con dos cojones!! jaja) para la total instalación de Volatility Framework, junto con todas sus dependencias. Entre las “capacidades” del Script de instalación se encuentran los siguientes puntos:

  • Descarga e instalación de Python, MinGW
  • Descarga e instalación de YARA (Gracias Hispasec!!), PYGame, PIL (Python Image Library), Distorm3
  • Descarga e instalación de Volatility Framework 1.3 (Versión estable)
  • Descarga e instalación de Plugins válidos para la versión 1.3
  • Compilación automática e instalación de diversos plugins
  • Procesado de Logs de todo lo que se descarga
  • Procesado de HASH (MD5 y SHA1) de todo lo que se descarga
  • Inclusión de rutas en PATH para dotar de máxima funcionalidad
  • Inclusión de shell de comandos con el botón derecho del ratón para facilitar el análisis (Open cmd Here)

Ahora mismo, el script es totalmente funcional para instalarlo en Windows XP/Vista/7, y, como hoy en el FTSAI nos vamos a “pelear” con la memoria y todos sus componentes, me ha parecido buena idea colgarlo por aquí.

En su día, hablando con Lympex de opensec.es, éste me pasó una versión que desarrolló para Linux, la cual todavía no he puesto en el proyecto, debido a que tiene que actualizarse. Me ha prometido que cuando la tenga funcional la colgará en el proyecto.

El proyecto está alojado en Google, y ahora sí…. No tienes excusa para seguir ampliando conocimientos en materia Forense, porque documentación hay, y facilidades también!!

http://code.google.com/p/volatility-installer/

Esta semana he empezado a realizar el mismo script en PowerShell, debido a que como batch tiene muchas restricciones, he tenido que “tirar” de herramientas de terceros, como 7zip, wget y HashMyFiles para hacerla totalmente funcional. El script es muy sencillo de utilizar y no requiere parámetros. Sólo doble clic, y a jugar….

Nota: Tanto Python, como las dependencias, junto con MinGW, se instalan de manera interactiva con el usuario. Las instalaciones son del entorno Next–>Next, menos MinGW, que necesitaremos marcar las opciones de MAKE, más el compilador. Este paso de “interacción” es necesario, ya que de manera desatendida no se compilan bien algunas bibliotecas en Python bajo Windows.

Doy por supuesto (y por invitado!) que colaboraciones y ayudas, serán muy, pero que muy bien recibidas…..

Update.- Chema, de opensec, ya me ha pasado el script de instalación y está subido al proyecto. Su script soporta la instalación de Volatility Framework en los sistemas Arch, Debian y FreeBSD!

Buen fin de semana a tod@s!!

SYSTEM, causa y efecto IV de IV

Estándar

Artículos anteriores

https://windowstips.wordpress.com/2011/01/10/system-causa-y-efecto-i-de-iv/

https://windowstips.wordpress.com/2011/01/11/system-causa-y-efecto-ii-de-iv/

https://windowstips.wordpress.com/2011/01/17/system-causa-y-efecto-iii-de-iv/

Hola a tod@s!

En este último post, nos centraremos en cómo la cuenta SYSTEM se comporta a la hora de ser utilizada de forma interactiva.

Para ello, y en el banco de pruebas que hemos montado, realizaremos una elevación de privilegios, tal y como se ha comentado ampliamente por la Red. Tenéis artículos con formas de realizar este tipo de elevación en los siguientes links:

http://vtroger.blogspot.com/2005/09/mas-vale-quedarse-corto.html

http://www.securitybydefault.com/2010/12/bienaventurados-los-que-no-ven-porque.html

Al realizar el truco, (que no vulnerabilidad) y cambiar alguno de los componentes de accesibilidad por una Shell de Windows, ésta se iniciará de forma interactiva y podremos interactuar con la misma. Entre las “curiosidades” iniciales que nos encontraremos, podremos enumerar las siguientes:

  • El panel de control, no funciona
  • El explorador de Windows, junto con el escritorio, funciona de forma parcial
  • La Shell finaliza al cabo de un tiempo

El acceso total al sistema, lo tenemos única y exclusivamente a través de la línea de comandos.

Esta “irregularidad” viene dada por culpa de las claves de registro que se asocian a cada perfil de usuario.

Cuando un usuario se crea en el sistema, éste recibe un perfil de usuario. La cuenta de sistema, es decir, la cuenta SYSTEM, precarga en  memoria la clave HKEY_LOCAL_MACHINE, y el usuario que trabaja de forma interactiva en el sistema cargará a su vez la clave HKEY_CURRENT_USER, la cual se carga a través de un fichero en el perfil de usuario, que se llama NTUSER.DAT.

Si realizamos una comparación de las claves de registro que crea en el perfil la cuenta SYSTEM, con las que se crean cuando iniciamos sesión con una cuenta de usuario normal, podremos ver ciertas características que no se encuentran en el perfil de SYSTEM.

Si analizamos esas claves con alguna herramienta que permita abrir este tipo de ficheros (NTUSER.DAT), podremos ver ese tipo de diferencias, y contemplar qué claves carga la cuenta SYSTEM cuando inicia sesión en el sistema.

Para el desarrollo de este artículo, se utilizará la herramienta Windows Registry Recovery, la cual nos permite visualizar este tipo de ficheros de forma amistosa y rápida.

Imagen 1.- Claves cargadas por el usuario SYSTEM en Windows 7

Como se puede ver en la anterior imagen, la cuenta SYSTEM carga lo justo y necesario para realizar su trabajo, sin cargar más de lo necesario.

Imagen 2.- Claves cargadas por un usuario típico en Windows 7

En cuando a la imagen anterior, se puede visualizar que un usuario típico, carga lo que necesita para poder interactuar con el sistema. Algo lógico por parte del sistema operativo, ya que estos usuarios son los que están diseñados para trabajar de manera interactiva con el sistema.

Por otra parte, el usuario SYSTEM, opera desde la instancia HKEY_USERS\.DEFAULT. Esta instancia, es en realidad un alias de HKEY_USERS\S-1-5-18, instancia que identifica al SID de la cuenta SYSTEM. Al inicializar la elevación de privilegios, y siempre que no se inicie otro usuario en el sistema, la cuenta SYSTEM, utilizará una instancia que se cargará en 3 sitios diferentes. La ruta de carga es la que se muestra a continuación:

  • HKEY_CURRENT_USER
  • HKEY_USERS\.DEFAULT
  • HKEY_USERS\S-1-5-18

Para verificar lo anterior, desde la Shell de comandos arrancada cuando se realiza la elevación de privilegios, se puede crear una clave en HKEY_CURRENT_USER. Esta clave, se mostrará a su vez en las claves HKEY_USERS\.DEFAULT y HKEY_USERS\S-1-5-18.

Imagen 3.- Instancias cargadas por el usuario SYSTEM

Imagen 4.- Instancias cargadas por el usuario SYSTEM

Estas instancias, a su vez, contienen la información para interactuar con el sistema, es decir, contienen las claves de registro necesarias para lanzar un escritorio interactivo, pero tienen pequeñas diferencias. Estas diferencias, analizadas con cualquier herramienta de monitoreo, muestran como a la hora de lanzar el escritorio interactivo, éste falla al intentar encontrar ciertas claves de registro, necesarias para mostrar iconos, accesos directos, y rutas de lanzamiento a las aplicaciones. El efecto final es que el sistema operativo es capaz de “pintar” el escritorio, pero al no encontrar rutas a las aplicaciones, ni accesos directos que llamen a un programa, éste se queda “a medias”.

Imagen 5.- Rutas no encontradas

 

Como habréis podido observar a lo largo de estos cuatro artículos, es que una elevación de privilegios en Windows implica el conocimiento de muchos factores a la hora de lanzar un posible ataque, y las posibles consecuencias de que este funcione, o no…

Un saludo a tod@s!

SYSTEM, causa y efecto. II de IV

Estándar

SYSTEM. causa y efecto I de IV

SYSTEM, causa y efecto III de IV

SYSTEM, causa y efecto IV de IV

Hola a tod@s!!
En la primera entrega dedicada a las diferencias entre la cuenta SYSTEM y una cuenta de tipo administrador, estuvimos repasando las diferencias a nivel de privilegios que tienen estas cuentas, diferencias a nivel de ficheros, directorios y registro.
Este capítulo, lo dedicaremos a repasar las diferencias que tienen estos usuarios, pero a nivel de sesión de usuario.
A la hora de administrar un equipo basado en Windows, siempre hay que pensar, como mínimo, en la existencia de dos usuarios iniciados como mínimo en el sistema operativo. Uno de estos usuarios podrá ser una cuenta, como máximo, con un privilegio de cuenta administrativa, y como mínimo, con el mínimo privilegio posible, o lo que es lo mismo, con una cuenta de usuario o usuario de dominio. La otra cuenta, será la cuenta SYSTEM, que será la encargada de administrar las operaciones internas que necesite realizar el sistema.
Cuentas como SYSTEM o LOCALSYSTEM, son cuentas que no tienen contraseñas asociadas a ellas, y cualquier intento de asociar una credencial a ellas, como por ejemplo a la hora de utilizar estas cuentas para iniciar un servicio, serán ignoradas por el propio sistema operativo.
También este tipo de cuentas, al ser internas del propio sistema operativo, tampoco tienen un perfil asociado en el administrador de cuentas del sistema (SAM), tal y como se puede ver en la siguiente imagen.


Imagen 1.- Cuentas extraídas a través de la SAM

A cada cuenta de usuario, se le asocia un perfil, una vez que se autentica correctamente en el sistema por primera vez. Este perfil, será el que utilice para las tareas comunes del sistema, y será en su perfil, en donde se guardará toda la información y modificación que sobre esta sesión realice.
Los perfiles de usuario, en sistemas basados en Windows XP/2003 se almacenan en el directorio DOCUMENTS AND SETTINGS. En sistemas basados en Windows Vista/7/2008, estos perfiles se almacenan en la raíz del sistema operativo, en el directorio USERS.
Cada cuenta, a su vez, puede iniciar sesión en el sistema de forma independiente, y compartir sesiones entre diferentes usuarios al mismo tiempo, con la única diferencia de que cada cuenta cargará única y exclusivamente su perfil.
Cuando el sistema operativo arranca, éste necesita cargar en memoria aplicaciones y claves de registro en el inicio del mismo. Estas tareas, las realiza la cuenta SYSTEM por diseño. A la hora de autenticarse en el sistema, Windows carga un subsistema de autenticación llamado MSGINA (Componentes de identificación y autorización). Este subsistema, es el que utilizaremos para autenticarnos debidamente en el sistema.
Por diseño, Windows también carga componentes de accesibilidad, necesarios para personas con carencias físicas, tales como falta de visión, miembros amputados, etc, etc…

Por otra parte, la cuenta SYSTEM, también es utilizada a nivel de políticas de grupo en equipos que formen parte de los servicios de Directorio Activo, para asuntos relacionados con la instalación y desinstalación de aplicaciones, ejecución de scripts, etc…, ya que existen políticas de grupo a nivel de máquina, y a nivel de usuario.
Windows también tiene otras cuentas de usuario asociadas a la creación y administración de servicios. En sistemas basados en Windows XP/2003, estas cuentas, tienen sus perfiles de usuario ubicados en el siguiente directorio:


Imagen 2.- ubicación de perfiles de sistema en Windows XP/2003

En sistemas basados en Windows Vista/7/2008, los perfiles de estas cuentas se almacenan en:


Imagen 3.- Ubicación de perfiles de sistema en Windows Vista/7/2008

Dicho esto, y para resumir, si en un sistema basado en Windows XP por ejemplo, existe como mínimo una cuenta SYSTEM arrancada en el sistema antes de iniciar sesión, ésta cargará con su perfil única y exclusivamente, pero… Dónde se encuentra ese perfil??
La cuenta SYSTEM, al ser una cuenta especial de usuario del propio sistema, tiene una ubicación propia. A partir de Windows XP, la ruta en donde se encuentra este perfil de usuario, es la siguiente:


Imagen 4.- Ubicación del perfil de usuario de la cuenta  SYSTEM

A nivel de sesiones, las cuentas de sistema, se comportan de diferente manera a las cuentas de usuario normales, ya que cada cuenta se ejecuta en una sesión diferente, y por ende, en diferentes espacios de memoria.
Si por ejemplo un usuario normal, crea un objeto nuevo en el sistema operativo, y tiene control total sobre el mismo, puede que la cuenta de SYSTEM, no pueda tener privilegios para tener acceso a ese objeto.
Un ejemplo válido lo tenemos con el comando SUBST. Este comando, permite asociar una unidad física del sistema a un determinado PATH. Dependiendo de quién cree este objeto en el sistema, y en qué sesión de usuario se haya ejecutado el comando,  un usuario podrá tener control total sobre él, y el otro no.

 
Imagen 5.- Acceso a objetos. El usuario SYSTEM no accede al objeto

Pero como toda ley, tiene su trampa. Si se necesita obtener acceso a ese objeto, siempre se puede recurrir a la impersonalización, es decir, utilizar la capacidad de poder ejecutar código bajo un contexto de seguridad distinto al de nuestro usuario.
Para que un usuario pueda suplantar a otro cliente tras la autenticación, es necesario tener un determinado privilegio. Este privilegio se llama SeImpersonatePriviilege, y en Windows Vista/7/2008 se puede visualizar con el comando WHOAMI /PRIV.


Imagen 6.- Privilegios para impersonalizar a otro usuario

En el siguiente capítulo, hablaremos de los SID de usuario en Windows, cómo se forman, cuál es su estructura, y la forma de acceso a ellos.  
Saludos!!

REFERENCIAS

Personalización de GINA
http://msdn.microsoft.com/en-us/magazine/cc163803.aspx
Comando SUBST
http://www.computerhope.com/substhlp.htm
Perfiles Locales
http://msdn.microsoft.com/en-us/library/bb776894(VS.85).aspx
Cuenta LOCALSYSTEM
http://msdn.microsoft.com/en-us/library/ms684190(v=vs.85).aspx
Derechos de usuario en Windows
http://technet.microsoft.com/en-us/library/bb457125.aspx
Impersonalización y secuestro de Tokens
http://www.argeniss.com/research/TokenKidnapping.pdf

SYSTEM, causa y efecto. I de IV

Estándar


SYSTEM, causa y efecto II de IV

SYSTEM, causa y efecto III de IV

SYSTEM, causa y efecto IV de IV

Hola a todos!!

En esta serie de 4 capítulos, examinaremos las sutiles diferencias entre un usuario administrador y un usuario de sistema (SYSTEM). Estas diferencias, serán cruciales a la hora de decidir qué tipo de cuenta será necesaria para la explotación de un fallo en el sistema, o decidir si es o no imprescindible el uso de técnicas para ganar una posible elevación de privilegios. También nos ayudarán a conocer el porqué de ciertos comportamientos dispares entre cuentas aparentemente similares.
A nivel de sistema operativo, tanto la cuenta Administrador como la cuenta de sistema, son cuentas con los mismos privilegios. Esta equidad, sólo se manifiesta a nivel de ficheros. A nivel de directorios, la cuenta SYSTEM tendrá, obligatoriamente por diseño del sistema operativo, mayores privilegios que una cuenta de tipo Administrador.
La cuenta SYSTEM, es usada por el sistema operativo para la carga o precarga de elementos cruciales en el inicio del sistema operativo. Servicios y procesos que necesita Windows para el buen funcionamiento del sistema, y para el inicio del mismo. La cuenta, diseñada para ese propósito, es una cuenta interna, y por tal motivo, no podemos administrarla utilizando funciones básicas de administración, como por ejemplo las siguientes:

  • Administración de usuarios
  • Añadir o eliminar de grupos
  • Derechos especiales de usuario

Para demostrar esto, se pueden utilizar dos ejemplos básicos. Uno es a nivel de ficheros, y otro por ejemplo, es a nivel de Registro.
En Windows XP, por defecto la cuenta SYSTEM tiene control total en todos los ficheros y directorios del sistema operativo, y no como la cuenta Administrador, que tiene control total en casi todos los elementos del sistema. Un ejemplo válido es la carpeta SYSTEM VOLUME INFORMATION, ubicada en la raíz del sistema instalado, y que tiene como objetivo el almacenamiento de las copias de seguridad o puntos de restauración. Si se intenta obtener acceso a este directorio a través de una cuenta con privilegios únicamente de administrador, obtendremos un bonito error, ya que a nivel NTFS, no tenemos privilegios.

 
Imagen 1.- Acceso denegado en SYSTEM VOLUME INFORMATION

Otro ejemplo válido lo tenemos a la hora de visualizar elementos del registro de Windows. La cuenta SYSTEM tiene, por diseño del propio sistema operativo, control total sobre ciertas claves de registro, imprescindibles para el buen funcionamiento del mismo. Algunos de estos ejemplos son la clave SAM, en donde se almacenan los datos de los usuarios existentes en el sistema, y la totalidad de los permisos en la clave SECURITY, ubicada en la clave HKLM (HKEY LOCAL MACHINE). En la siguiente imagen, se puede visualizar un ejemplo de este tipo.


Imagen 2.- Elementos de registro visibles a través de la cuenta SYSTEM


A partir de Windows Vista en adelante, en el apartado referente al control de ficheros y directorios, y siempre hablando a nivel NTFS, se añade una nueva entidad con control total en el sistema. Esta entidad, llamada TrustedInstaller, es la encargada de una nueva característica en Windows Server 2008 y Windows Vista/7, llamada Windows Resource Protection.

Imagen 3.- Lista de control de acceso discrecional en Windows 7

En el siguiente post, repasaremos el funcionamiento de ambas cuentas a nivel de sesiones de usuario, evaluando el funcionamiento de las mismas en base a los perfiles que éstas crean.
Saludos!!
Referencias
Funcionamiento de ICACLS
http://technet.microsoft.com/es-es/library/cc753525(WS.10).aspx
Mecanismos reemplazados en Windows Server 2008
http://msdn.microsoft.com/en-us/library/aa382540(v=vs.85).aspx
Cómo es usada la cuenta SYSTEM en Windows
http://support.microsoft.com/kb/120929/en-us