La Cápsula Verde

Acceso total y Enviar como | Buzones Exchange 2010

2012-02-08T10:46:00.014+01:00

Dos de los permisos más utilizados en los buzones de los usuarios de Exchange 2010 es el Acceso total, para que uno, varios o grupos de usuarios puedan acceder al buzón de correo deseado desde su Outlook y Enviar como, para que uno, varios o grupos de usuarios puedan enviar correo suplantando al dueño del buzón mediante el campo DE en un nuevo email (desde Outlook y OWA).

En la consola de administración de Exchange 2010 puedes gestionar ambos permisos por separado. Para agilizar la gestión de ambos permisos, he creado una herramienta (buzon_permisos.exe) que, iniciada con un usuario con permisos de administración en Exchange 2010, puedes introducir el nombre de la cuenta de un buzón (samaccountname), pulsar ENTER y aparecerán los permisos de Acceso total y Enviar como del buzón proporcionado (este proceso tarda unos segundos y el estado lo verás en el texto del título de la ventana):

Los permisos del buzón proporcionado terminarán de aparecer cuando en el texto del título de la ventana ponga: Permisos del buzón: ... y el samaccountname del buzón proporcionado (indicado en la siguiente imagen como samaccountname del buzón actual):

Ahora, en el buzón proporcionado (buzón actual que aparece en el texto del título de la ventana) puedes:

Dar el permiso de Acceso total a un usuario o grupo, introduciendo su samaccountname en el campo Cuenta y clicando en el botón Acceso total.
Dar el permiso de Enviar como a un usuario o grupo, introduciendo su samaccountname en el campo Cuenta y clicando en el botón Enviar como.
Eliminar un usuario o grupo y su permiso correspondiente, seleccionando la línea donde aparezca y clicando en el botón Eliminar permiso.

Ten en cuenta que:

En los tres casos anteriores, después de clicar en el botón deseado, tardará unos segundos en actualizar la nueva información de permisos (aparecerá un texto de carga en el título de la ventana).
Al agregar o quitar el permiso de Enviar como y después de la carga de los permisos es posible que no aparezca el cambio realizado (debido al tiempo de replicación en el Directorio Activo). Para solucionarlo, clica en botón Actualizar (en la parte superior de la ventana) hasta que aparezca el cambio actualizado.
Los permisos que puedes ver, agregar o quitar no son permisos heredados, son permisos que sólo afectan al buzón en sí.

Requisitos:

.Net Framework 3.5 o superior
PowerShell 2.0

Averigua el tamaño de una carpeta con C

2012-01-05T20:52:00.020+01:00

El objetivo de este post es ver cómo funciona un programa en C que averigua el tamaño de una carpeta de Windows dada (subcarpetas incluidas), ya sea en el sistema de archivos local o en red.

Por ejemplo, con esta herramienta (fsize.exe, una vez compilado y enlazado) y el siguiente script:

@echo off
fsize c:\windows
fsize "c:\Archivos de programa"
fsize \\server-1\datos\pepe

obtuve los siguientes resultados:

c:\windows:
6.48 GBytes - 28332 archivos - 2459 carpetas.

c:\Archivos de programa:
2.13 GBytes - 14883 archivos - 2834 carpetas.

\\server-1\datos\pepe:
1.48 GBytes - 3659 archivos - 91 carpetas.

El código fuente de fsize.c está disponible en:

http://sites.google.com/site/ramiroencinas/soft/fsize.c

e incluye comentarios explicando el funcionamiento.

El archivo fsize.exe junto con el código fuente también está disponible en:

http://sites.google.com/site/ramiroencinas/soft/fsize.zip

Notas:

El compilador de C que he utilizado es lcc-win32.
El compilado-linkado lo realizé con: lc fsize.c -o fsize.exe -s
El archivo generado ejecutable fsize.exe tiene un tamaño de 32KBytes (es lo bueno de programar directamente con la API de Windows).
Funciona a partir de Windows XP.

Securing Debian Manual en castellano

2011-11-21T16:56:00.005+01:00

Lo que tiene que saber un sysadmin de Debian en cuanto a la seguridad está en este documento.

Y para los vagos con el inglés, he comenzado la traducción al castellano de sus capítulos más relevantes, comenzando con el tercero, que trata sobre los aspectos a tener en cuenta antes y durante la instalación de un Debian:

Contraseñas
Particionamiento
Control de servicios
Control de software instalado

PDF disponible en este enlace.

Exchange 2010 | ¿Quién está fuera de la oficina?

2011-08-16T12:58:00.005+02:00

Con Outlook puedes averiguar si alguien de tu organización está fuera de la oficina, pero no puedes saber quienes son todos ellos.

Para obtener un fichero de texto "fuera_oficina.txt" con la lista con todos estos usuarios podemos ejecutar el siguiente script de Powershell desde un host que tenga instalada la consola de administración de Exchange o desde un servidor Exchange.

--- comienzo del script ---

# guarda fecha actual

$fecha_actual = Get-Date

# guarda los samaccounts de todos los buzones

$buzones = Get-Mailbox | %{$_.SamAccountName}

# crea una lista para guardar los samaccounts de todos los buzones fuera de oficina

$buzon_fuera_oficina = New-Object System.Collections.ArrayList

# procesa cada buzón (samaccountname)

foreach ($buzon in $buzones)

{

# extrae la configuración de "fuera de la oficina"

$fuera_oficina = Get-MailboxAutoReplyConfiguration $buzon

# si "fuera de la oficina" está activado y la fecha de activación es hasta hoy

if (($fuera_oficina.AutoReplyState -eq "scheduled") -and ($fuera_oficina.StartTime -le $fecha_actual))

{

# agrega a la lista el samaccount actual

$buzon_fuera_oficina.add($buzon)

}

# crea un fichero txt con la lista de samaccounts ordenada

$buzon_fuera_oficina | sort | out-file ./fuera_oficina.txt

--- fin del script ---

Actualizaciones pendientes | Windows Update

2011-08-08T14:16:00.008+02:00

Una forma rápida y sencilla de averiguar qué servidores de un Directorio Activo tiene pendientes las actualizaciones de Windows Update es conocer los que tienen corriendo el proceso wuauclt.

Si además puedes enviarte un email semanal con esa información, garantizas que los servidores estén actualizados bajo tu supervisión con una frecuencia razonable.

Esto se puede hacer con un script PowerShell como el siguiente:

---- comienzo del script ---

# Busca el proceso wuauclt.exe para ver si hay actualizaciones pendientes

# en servidores Windows encontrados en Directorio Activo

# y reporta resultados por email

# 2011 - ramiro.encinas

$emailFrom = "from@dominio.es" # origen email

$emailTo = "to@dominio.es" # destino email

$subject = "Servidores con Windows Update activo" # asunto

$smtpServer = "smtp.dominio.es" # servidor SMTP destino

# Búsqueda de servidores Windows en Directorio Activo:

$strOperatingSystem = "Windows*Server*" # patrón a buscar para SO

$objDomain = New-Object System.DirectoryServices.DirectoryEntry # acceso servicio directorio

$objSearcher = New-Object System.DirectoryServices.DirectorySearcher # buscador

$objSearcher.SearchRoot = $objDomain # búsqueda desde el raíz del directorio

$objSearcher.Filter = ("OperatingSystem=$strOperatingSystem") # filtro LDAP

$colProplist = "name" # propiedad name del SO

foreach ($i in $colPropList){$objSearcher.PropertiesToLoad.Add($i)} # carga de la propiedad name

$colResults = $objSearcher.FindAll() # búsqueda

$r = "`n" # texto del informe

$enviar = "no" # switch de envío

foreach ($objResult in $colResults) # Extracción de procesos por servidor encontrado

{

$objComputer = $objResult.Properties; # propiedades del servidor

$Server = $objComputer.name # nombre del servidor

$ErrorActionPreference = "SilentlyContinue" # no visualiza excepciones (servidores sin conexión)

Write-Host "Procesando $Server..." # mensaje

$encontrado = Get-Process -Name wuauclt -ComputerName $Server # búsqueda del proceso wuauclt

if ($encontrado) # si existe el proceso wuauclt

{

$r = $r + $Server + "`n"

$enviar = "si" # si uno al menos, envía email activando el switch

}

#envío email si procede

if ($enviar -eq "si")

{

$body = $r

$smtp = new-object Net.Mail.SmtpClient($smtpServer) # objeto smtp

$smtp.Send($emailFrom, $emailTo, $subject, $body) # envío del mensaje

}

--- fin del script ---

El script también está disponible desde aquí.

Los únicos parámetros que tienes que cambiar son los de las 4 líneas que hay al comienzo:

$emailFrom = "from@dominio.es" # origen email

$emailTo = "to@dominio.es" # destino email

$subject = "Servidores con Windows Update activo" # asunto

$smtpServer = "smtp.dominio.es" # servidor SMTP destino

Después puedes crear una tarea programada en un servidor que siempre esté encendido para ejecutar el script semanalmente y a esperar...

Exchange 2010 | Seguimiento de mensajes

2011-04-16T12:33:00.023+02:00

La consola de administración de Exchange 2010 incorpora el seguimiento de mensajes para ver el recorrido de un mensaje por los servidores de Exchange. La interfaz que trae es bastante complicada, así que he implementado una herramienta autónoma:

Seguimiento_mensajes_EX2010.exe

que trae un formulario más sencillo y práctico:

El campo obligatorio es Servidor, pues en su registro de mensajes se realiza la búsqueda teniendo en cuenta el resto de criterios.

Elegido el servidor, clicas en Buscar y aparecerán los resultados debajo (si los hay).

El informe resultante puedes imprimirlo, y también puedes guardarlo en html. Para esto último, introduce un nombre para el archivo del informe y clica en Guardar informe. El archivo html correspondiente lo encontrarás en la carpeta Seguimiento_Mensajes ubicada en el escritorio.

Con esta herramienta serás mucho más rápido y además podrás presentar informes por escrito del movimiento de cualquier mensaje.

Requisitos:

.Net Framework 3.5 o superior
PowerShell 2.0

Las colas de Exchange 2010

2011-01-27T16:52:00.004+01:00

Supervisar las colas de un Exchange 2010 es una tarea clave para detectar cuellos de botella producidos por mensajes acumulados en algún servidor de Transporte. Exchange 2010 ofrece dos formas de ver el contenido de las colas:

Mediante la consola de administración de Exchange 2010.
Mediante los cmd-lets de Exchange 2010 de PowerShell.

Para simplificar el acceso a las colas también puedes utilizar colas_exchange_2010.exe. Esta utilidad puede correr en cualquier equipo conectado al mismo dominio que el servidor Exchange 2010 y como requisitos necesita .NET 3.5 o superior y PowerShell 2.0:

Esta utilidad conecta con cualquier servidor Exchange 2010 y después tienes que elegir el servidor de Transporte que quieres consultar. Cambiando "Intervalo" modificas la frecuencia de la consulta. Los campos que muestra son los mismos que ofrece por defecto el visor de colas de la consola de administración de Exchange 2010. Recuerda que esta utilidad tiene que ser ejecutada con un usuario que pueda realizar estas consultas.

Perl: mitos y ventajas

2011-01-19T22:46:00.011+01:00

Hace poco di con un interesante artículo escrito por Simons Cozens que trata sobre los diez mitos de Perl. Ese artículo data del año 2000 y tristemente todavía veo que esos mitos persisten.

Al margen de los mitos, yo veo a Perl como un C de buen rollo y a lo bestia: con pocas líneas y algunas expresiones regulares estás leyendo sólo lo que necesitas y a la vez de una base de datos, de un router, de una impresora, de un fichero de texto plano y de una web, lo pones todo en un informe y lo guardas donde quieras y en el formato que quieras (por ej. en HTML).

Luego el sistema operativo te da igual: el único sistema operativo que no soporta Perl yo creo que es el de las lavadoras (y no se yo). Allí donde haya una línea de comandos hay Perl, casi seguro. En concreto, para Windows recomiendo la distribución Strawberry Perl (también recomendada por Larry Wall que es el creador de Perl).

Y bueno, en el terreno de sistemas hay dos cosas: Perl para llegar a todo sistema que funcione (routers, switches, servidores, clientes, linux, microsoft, mac, solaris, etc) y donde no llega Perl llega PowerShell.

Qué decir de Perl y el mundo Web, si fue Perl junto con Apache y CGI el que construyó la web antes de que PHP llegara. Aún así, Perl persiste en webs serias y tiene muchas de las comunidades más serias que he visto en la red, como PerlMonks, entre otras.

He visto dos cosas que realmente me han impactado de Perl: una es la facilidad de aprenderlo (yo aprendí casi todo con este estupendo manual en castellano de Jose Miguel Prellezo) y la otra es la cantidad de módulos disponibles para hacer cualquier cosa o para llegar a cualquier cosa: CPAN.

Otra cosa que me gusta de Perl es que va al grano: es corto, rápido y conciso. Este ejemplo lo ví en el artículo de los diez mitos y es impresionante:

s/(.*):(.*)/$2:$1/

La línea de código anterior puede hacer lo siguiente: toma una línea de texto que contenga cualquier cosa, luego el símbolo de dos puntos y después cualquier otra cosa. Lo que hace es intercambiar las dos cosas que están a los lados de los dos puntos (puedes leer el artículo ya traducido para ver la explicación).

Sin dudarlo, de todos los lenguajes que he utilizado: Basic, Logo, Pascal, Ensamblador, Cobol, Batch, Bash, Python, Ruby, C, C++, C#, Visual Basic, Java, PowerShell y Perl, me quedo con este último.

KB2490606, nueva vulnerabilidad

2011-01-09T00:08:00.003+01:00

El pasado día 4 de enero, Microsoft anunció una vulnerabilidad importante en el archivo de Windows shimgvw.dll, que permitiría ejecución remota de código malicioso en Windows XP SP3, Windows Server 2003 SP2, Windows Vista y las primeras versiones de Windows Server 2008, entre otras de 64-bit.

Este archivo es el Visor de imágenes y fax de Windows, aplicación que Windows utiliza por defecto para abrir imágenes y también para mostrar las Vistas en miniatura de una carpeta que pueda contener alguna imagen.

Si el Visor de imágenes y fax de Windows abre o muestra la vista en miniatura de una imagen especialmente creada para aprovecharse de esta vulnerabilidad, ésta se produciría permitiendo la ejecución remota de código malicioso.

De momento no hay parche para shimgvw.dll, pero Microsoft aconseja quitarle privilegios para minimizar el riesgo, hasta que publiquen el parche. Para ello Microsoft recomienda utilizar la siguiente línea de comando (versiones de 32-bit de Windows XP y Server 2003):

cacls %WINDIR%\SYSTEM32\shimgvw.dll /E /P Todos:N

Y para deshacer lo anterior:

cacls %WINDIR%\SYSTEM32\shimgvw.dll /E /R Todos

Más líneas de comandos para otras versiones de Windows en la publicación de esta vulnerabilidad.

De momento no ha habido mucha repercusión con esta vulnerabilidad, pero es igual de peligrosa que la de agosto del año pasado relacionada con la visualización de iconos.

Tres reglas en la administración de sistemas

2010-12-30T18:57:00.011+01:00

Fuente original: http://www.thegeekstuff.com/2010/07/three-sysadmin-rules/

El borrador de este artículo trataba de las 7 costumbres de los administradores de sistemas. Tres de ellas destacaban realmente.

Si las costrumbres son buenas, a veces las reglas son incluso mejor, especialmente en el mundo de la administración de sistemas cuando se trata de un entorno de producción.

Regla #1: Haz copia de seguridad de todo ( y compruébala con regularidad )

Los administradores de sistemas experimentados saben que, independientemente de lo proactivo que seas, un sistema en producción fallará algún día. La mejor forma de estar preparado para esta situación es disponer de una copia de seguridad correcta.

Si no dispones de una copia de seguridad de tus sistemas críticos, deberías empezar a pensar en ello inmediatamente. Ten en cuenta lo siguiente:

¿Qué software o script utilizarías para realizar la copia de seguridad?
¿Dispones de suficiente espacio en disco para la copia de seguridad?
¿Con qué frecuencia se actualizarán las copias de seguridad?
¿Necesitarás copias de seguridad incrementales además de la copia de seguridad total?
¿Cómo se ejecutaría la copia de seguridad, por ej. utilizando crontab o algún otro sistema de calendarizaje?

Si no tienes una copia de seguridad de tus sistemas críticos, deja de leer este artículo y ponte a trabajar. Comienza la planificación de tu copia de seguridad inmediatamente.

En una de las investigaciones realizadas por una compañía (no recuerdo cual), recuerdo que sólo el 70% de las aplicaciones en producción tenían copia de seguridad, y de ellas el 30% eran incorrectas o estaban corruptas.

Supongamos que Samuel realiza copia de seguridad regularmente de las aplicaciones críticas, pero no las comprueba. Por otro lado, Javier no realiza ninguna copia de seguridad de sus aplicaciones críticas. Se puede pensar que Samuel lo hace mejor que Javier, pero en mi opinión los dos están en una mala situación: Samuel no puede asegurar la restauración correcta de la copia de seguridad en caso de desastre.

Si eres un administrador de sistemas y no consideras esta regla de oro número 1, debes pensar seriamente en dejar de administrar sistemas y dedicarte al desarrollo de aplicaciones.

Regla #2: Domina la línea de comandos ( y evita las ventanas )

No hay una ni una tarea en un servidor Unix / Linux que no puedas realizar con la línea de comandos. Existen algunas aplicaciones de administración basadas en ventanas para hacerlo más fácil, pero realmente no las necesitas y deberías utilizar siempre la línea de comandos.

Si eres un administrador de sistemas Linux, debes dominar la línea de comandos.

En cualquier sistema, si quieres ser fluido y productivo, debes ser un maestro con la línea de comandos. La diferencia principal entre un administrador de sistemas de Windows y de Linux es: Interface gráfica vs. Línea de comandos. Los administradores de sistemas de Windows no se sienten muy cómodos con la línea de comandos, mientras que los administradores de sistemas de Línux si.

Aparte de utilizar la línea de comandos, también debes entender cómo funciona un servicio en particular. En muchos entornos de servidor en producción, los administradores de sistemas normalmente desinstalan los servicios y herramientas que utilizan la interface gráfica.

Si eres un administrador de sistemas de Unix / Linux y no te gusta esta regla, es posible que realmente te guste más la administración de sistemas de Windows.

Regla #3. Automatiza todo ( y hazte vago )

El mejor administrador es el vago.

No conozco a ningún administrador que rompa esta regla. Esta es la parte más vaga.

Piensa durante unos minutos en la lista de tareas rutinarias que tienes que hacer todos los días, semanas o mensualmente. Cuando tengas esa lista, piensa en cómo automatizarla. El mejor administrador de sistemas normalmente no está ocupado, todo lo contrario: está relajado y deja que el sistema haga el trabajo por él.

Exchange 2010: informe de buzones grandes

2010-12-07T14:45:00.011+01:00

Objetivo: enviar informe por email (por ej. una vez por semana) con los tamaños de los 10 buzones Exchange 2010 más grandes y sus respectivos usuarios.

Requisitos: en un servidor Exchange 2010 lanzar el script una vez por semana mediante una tarea programada.

Observaciones: indicar en el script los campos adecuados del email del remitente, del destino y el servidor smtp de destino correspondiente.

---- comienzo del script --------

# top 10 en tamaño de buzones de Exchange 2010 vía email
# datos envío email

$remitente = "remitente@dominio.com" # origen email
$destino = "destinatario@dominio.com" # más de uno separados por coma
$asunto = "TOP 10 buzones de usuario"
$servidor_smtp_destino = "smtp.dominio.com" # servidor smtp destino

# extracción ordenada de tamaños de buzones

$buzones = Get-Mailbox |
get-mailboxstatistics |
select-object DisplayName, TotalItemSize |
sort TotalItemSize -Descending

# selección de los 10 primeros

$top10buzones = 0..9 | % {$buzones[$_]}

# elaboración del informe

$informe = "`n" # primera línea en blanco del texto del informe

$informe = $informe + " Tamaño Usuario" + "`n"
$informe = $informe + "-------- : ----------------------" + "`n"

foreach ($buzon in $top10buzones) # procesa los 10 buzones
{
$informe = $informe + "{0,5:n0}" -f ($buzon.TotalItemSize.value.ToGB()) + " GB" + " : " + $buzon.DisplayName + "`n"
}

# envía email con informe

$smtp = new-object Net.Mail.SmtpClient($servidor_smtp_destino)
$smtp.Send($remitente, $destino, $asunto, $informe)

---- fin del script --------

Exchange 2010: creación rápida de usuario y buzón

2010-12-01T17:08:00.006+01:00

Con un único formulario, crea un usuario con buzón de correo en Exchange 2010 desde cualquier host conectado al dominio del Directorio Activo. Sólo es necesario tener instalado PowerShell 2 y .NET 3.5 en adelante.

Características:

Un sólo formulario.
Nombre de dirección de correo igual al nombre de inicio de sesión.
Inserción única de la contraseña.
Visualización del tamaño de las bases de datos de Exchange 2010 antes de elegirla.
Distinción entre cuenta personal y de servicio.
Inserción en grupos del Directorio Activo.
Inserción de los atributos más utilizados.
Visualización en la barra de estado del servidor Exchange 2010 conectado.
Gratuito.

Modo de empleo:

Ejecuta la herramienta "alta_usuario_mailbox_2010.exe" con un usuario que tenga privilegios para crear buzones en Exchange 2010.
Elige en el árbol de la izquierda la Unidad Organizativa donde quieres ubicar la nueva cuenta.
Rellena los campos que necesites (algunos son obligatorios).
Clica en "Dar de Alta" y si todo es correcto, el usuario (con todas las opciones indicadas en el formulario) y su buzón de correo aparecerán en su sitio.

Pantallazo:

Directorio Activo: Informes de usuarios

2010-11-27T16:35:00.023+01:00

Toca realizar consultas al Directorio Activo en busca de patrones que guardan los usuarios. Sólo vamos a utilizar PowerShell y .NET (sin más).

Un usuario de un dominio de un Directorio Activo es un objeto y tiene una serie de propiedades (también conocidas como atributos) que le hacen único para unas cosas y común para otras. Entre otras, las propiedades más conocidas de un usuario son: name, displayname, samaccountname, company, department, division, memberof y mail.

Como ejemplo a ilustrar, vamos a obtener un informe de todos los usuarios del grupo G_ADMON y cuya oficina (atributo physicalDeliveryOfficeName) sea Madrid. Primero pongo el código PowerShell y después lo explico:

----comienzo de script.ps1-------------

$rootdse = New-Object DirectoryServices.DirectoryEntry("LDAP://RootDSE")
$dominio = $rootdse.Properties["defaultNamingContext"]
$raiz_dominio = New-Object DirectoryServices.DirectoryEntry("LDAP://$dominio")

$busca = New-Object DirectoryServices.DirectorySearcher $raiz_dominio
$busca.Filter = "(&(objectClass=user)(objectCategory=person))"
$usuarios = $busca.findall()

$c=0

foreach ($usuario in $usuarios)
{
if (($usuario.properties.memberof -like '*G_ADMON*') -and
($usuario.properties.physicaldeliveryofficename -eq 'Madrid'))
{
$usuario.properties.name
$usuario.properties.mail
"-----------------------"
$c++
}
}
"$c usuarios encontrados."

----fin de script.ps1-------------

En las tres primeras líneas se crean tres objetos consecutivamente:

$rootdse: localiza la configuración principal del Directorio Activo.
$dominio: extrae el valor del dominio de la configuración de $rootdse.
$raiz_dominio: partiendo de $dominio, se ubica en su elemento raíz para realizar búsquedas.

Las tres siguientes líneas preparan y ejecutan la búsqueda de usuarios:

$busca: objeto que busca en $raiz_dominio.
$busca.Filter: es un filtro para que sólo busque usuarios y no otro tipo de objetos.
$usuarios = $busca.findall(): busca y encuentra a todos los usuarios que cumplan con el filtro y los deja en $usuarios.

Después se inicializa un contador a 0 y luego hay un bucle foreach que recorre todos los usuarios encontrados. Por cada usuario ($usuario) en $usuarios se busca con if a los usuarios cuyo campo memberof (grupos a los que pertenece el usuario) contenga lo que estamos buscando (el grupo G_ADMON) y cuyo campo physicaldeliveryofficename (oficina) sea Madrid. Si las dos condiciones anteriores se cumplen, mostramos el nombre y el email del usuario en cuestión; además se incrementa el contador. El informe finaliza con el número de usuarios encontrados que cumplen las condiciones.

Este es el armazón básico para realizar consultas a objetos de un Directorio Activo, en este caso han sido consultas a dos atributos de todos los usuarios, pero podemos consultar cualquier atributo de cualquier usuario u otro objeto. Sólo necesitamos saber cómo se llaman los atributos de los objetos para buscarlos. Para averiguar estos nombres de atributos aconsejo utilizar la herramienta AD Explorer de Mark Russinovich para ver el Directorio Activo por dentro, localizar los objetos y ver sus atributos.

Además, escribir código para estos menesteres es mucho más corto y rápido con PowerShell que con cualquier otro lenguaje que utilice .NET como VBasic o C#.

Acceso rápido a herramientas de Windows

2010-11-02T16:11:00.011+01:00

El Panel de control de Windows tiene varias herramientas, pero hay otras importantes como los servicios y el visor de sucesos que no aparecen ahí.

Por otro lado, dependiendo de la versión de Windows, los nombres de algunas herramientas cambian, por ej. en Windows XP, Windows 2000 y Windows 2003 tenemos "Agregar o quitar programas", en Windows Vista, tenemos "Programas y características", y en Windows 7 tenemos "Desinstalar un programa" pero en este caso la barra de direcciones sigue haciendo referencia a "Programas y características", todo esto con la misma función recurrente: desinstalar programas.

Por estos motivos y por muchos otros, y porque un click es más rápido que dos, se me ocurrió hacer un menú (herramientas.exe) con categorías y botones donde cada uno inicializa una herramienta:

Este menú ha funcionado correctamente en:

Windows XP
Windows 2003
Windows 7

Y el ordenador que lo utiliza necesita el Framework 3.5 instalado (Windows 7 ya lo lleva puesto).

Nueva contraseña en tres pasos

2010-10-30T00:52:00.010+02:00

Una de las tareas más recurrentes en la administración de un Directorio Activo es el cambio de contraseña de los usuarios.

Utilizar las típicas consolas de administración implican varios pasos para encontrar el usuario y cambiar su contraseña.

Para dejarlo sólo en tres pasos, he creado cambiapass.exe, y una vez abierto ...

Introduce el nombre de la cuenta del usuario (sAMAccountName) y pulsa ENTER.
Si existe, aparece la información suficiente para identificar al usuario.
Introduce la nueva contraseña y pulsa ENTER.

Un vistazo:

Requisitos: Framework 3.5 en un ordenador miembro del dominio.

Altas rápidas de usuario con Exchange 2007

2010-09-28T23:47:00.014+02:00

Cuando se da de alta un usuario en un Directorio Activo Win2003, normalmente también se necesita:

Buzón de correo
Atributos (organización, departamento, etc.)
Pertenencia a grupos

Y para esto son necesarias la consola de Exchange 2007 (creación del usuario y el buzón en este caso) y la consola de Administración de Usuarios y grupos del Directorio Activo (inserción de atributos y grupos).

Para no perder tanto tiempo utilizando dos consolas, he desarrollado una herramienta llamada alta_usuario.exe que ofrece un único formulario para crear un usuario+buzón, indicar toda la información mencionada y alguna cosa más:

Lo primero que debemos hacer es asegurarnos de que cumplimos los requisitos mínimos, que son tener instalado el siguiente software en el host donde ejecutemos alta_usuarios.exe:

Consola de administración de Exchange 2007 (Windows de 32bit)
Powershell 2.0
Framework 3.5

Lo segundo es ejecutar alta_usuarios.exe con un usuario que tenga permisos suficientes para crear usuarios en el dominio y buzones en Exchange 2007.

Aparece el formulario, indicamos el nombre del dominio (por defecto DOMINIO) y le damos a Conectar. Esperamos un poco y si todo es correcto, aparecerá en la columna izquierda el árbol de OU's del dominio. Elegimos la OU correspondiente para el nuevo usuario, y ésta aparecerá arriba en el apartado Unidad Organizativa.

Después indicamos la información común de alta del usuario donde es obligatorio el nombre, el nombre de inicio de sesión, la contraseña y el grupo de almacenamiento de correo (los atributos son opcionales).

En el apartado Tipo de cuenta podemos elegir entre:

Cuenta personal: el usuario es una persona e indicamos sus apellidos.
Cuenta de servicio: el usuario no es una persona e indicamos el atributo Nombre para mostrar que queramos.

Una cuenta de servicio es aquella que utilizan uno o más usuarios, y la cual carece de apellidos. En el caso del atributo Nombre para mostrar de la cuenta personal será: apellido1 apellido2, nombre.

El penúltimo paso es añadir al nuevo usuario en los grupos que queramos del Directorio Activo, y si nos equivocamos también podemos quitarlos (tampoco es obligatorio).

Por último, le damos al botón Dar de Alta y el resultado lo tendremos más abajo.

Nota: esta herramienta está muy probada en producción, en el entorno indicado y funciona estupendamente, no obstante, si la pruebas y ves algún fallo o sugerencia, agradeceré me lo comuniques.

Directorio Activo: grupos y miembros

2010-09-13T14:04:00.015+02:00

Cuando un Directorio Activo alcanza su madurez, también alcanza un buen número de grupos que se utilizan para que sus miembros (usuarios y otros grupos) dispongan de otros recursos del Directorio Activo como carpetas compartidas, listas de distribución de email, permisos para realizar ciertas operaciones, etc.

En cualquier caso y a medida que pasa el tiempo, la creación de grupos disminuye y aumenta la necesidad de agregar/eliminar miembros de estos grupos.

Para que esta tarea sea más rápida y amena, he creado una herramienta llamada Gestión de miembros en grupos (gestion_grupos.exe) que hace lo siguiente:

Conecta con el dominio deseado previa indicación de su nombre.
Crea una lista desplegable con todos los grupos encontrados en el dominio indicado.
Elegido un grupo de la lista desplegable, aparecen sus miembros.
Para eliminar un miembro, lo seleccionamos de la lista y clicamos en "Eliminar".
Para agregar un miembro, escribimos su nombre de cuenta (samAccount) en el campo a la izquierda del botón "Agregar" y clicamos en él.
Los miembros pueden ser usuarios y/o grupos.
Requiere .NET Framework 3.5

Un pantallazo:

Monitorizando colas de Exchange 2007

2010-07-19T12:41:00.025+02:00

Get-Queue -server nombre_servidor_exchange2007

es el comando PowerShell que muestra una instantánea del número de mensajes de las colas del servidor de correo Exchange 2007.

Una buena mejora en la visualización de resultados de este comando sería que éstos aparecieran en una ventanita de Windows y se actualizara con cierta frecuencia:

Para conseguirlo, escribiremos una aplicación en C# que internamente ejecute nuestro comando en PowerShell y envíe su salida a un Listview con los resultados, todo en una ventanita.

Para que esto funcione, tanto en el desarrollo de la aplicación como en la ejecución posterior del .exe, es necesario utilizar un usuario que tenga permisos para visualizar las colas, por ej. el administrador de dominio.

Requisitos de software en el host de desarrollo:

- SharpDevelop
- Powershell 2
- Consola de administración de Exchange 2007
- .NET Framework 3.5

Instalado todo esto, abrimos SharpDevelop con el usuario que tenga permisos para ver las colas de Exchange 2007 y creamos en un proyecto nuevo una nueva aplicación de Windows que se llame "colas_correo", de esta forma:

Creada la aplicación, tendremos una ventana vacía que es el formulario por defecto "MainForm". A la derecha de la vista de diseño del formulario tenemos la columna de propiedades del elemento que tengamos seleccionado. Seleccionamos la ventana del formulario y en la lista de propiedades buscamos la propiedad "Text", y le ponemos el nombre que queramos para que aparezca como título de la ventana, por ej. "Colas Exchange".

Dentro del formulario creamos una etiqueta cuya propiedad (Name) sea "leyenda_form". La propiedad Text de esta etiqueta la modificaremos dinámicamente para visualizar la fecha/hora de la última consulta a las colas.

Debajo de la etiqueta creamos un ListView con dos columnas, seleccionamos el ListView creado, clicamos en la flechita que está cerca de la esquina superior derecha del ListView, clicamos en "Editar columnas" y agregamos un miembro 0 (columna izquierda) donde su propiedad (Name) debe tener el valor: cola_form, y la propiedad Text debe tener el valor: Cola. Después agregamos otro miembro 1 (columna derecha) donde su propiedad (Name) debe tener el valor: mensajes_form y la propiedad Text debe tener el valor: Mensaje.

Aceptamos ventanas y pasamos a picar código. Clicamos en la pestaña "Fuente" de abajo y podremos editar el código de este formulario que es el que utilizaremos. El archivo que contendrá este código es MainForm.cs y estará ubicado en la carpeta del proyecto.

También tienes disponible el código de MainForm.cs en este enlace.

En el comienzo del archivo MainForm.cs aparece por defecto una lista de directivas using que tenemos que completar dejándolas así:

using System;
using System.Collections.Generic;
using System.Drawing;
using System.Windows.Forms;
using System.Collections.ObjectModel;
using System.Management.Automation;
using System.Management.Automation.Host;
using System.Management.Automation.Runspaces;
using System.Text;

Para evitar errores en la compilación relacionados con la falta de referencias, seguramente sea necesario agregar las referencias correspondientes para alguno de estos using. Lo puedes hacer desde el menú Proyecto, Agregar Referencia, pestaña GAC, buscar la referencia correspondiente, seleccionarla y OK.

Después de la lista de los using, hay un namespace cuyo nombre da igual para nuestro propósito. Dentro de tal, tendremos un public partial class MainForm: Form que es la clase de nuestro formulario y dentro de ella hay métodos (funciones), entre ellos, el punto de entrada es el método public MainForm() que se encarga de iniciar el formulario.

Dentro de public MainForm(), lo primero es el método InitializeComponent() que se encarga de inicializar el formulario con las propiedades por defecto, y justo después crearemos un Timer para que nuestra aplicación saque datos cada minuto:

Timer timer1 = new Timer();
timer1.Interval = 60000; // un minuto
timer1.Enabled = true;
timer1.Tick += new System.EventHandler (OnTimerEvent);

Además, necesitamos un método OnTimerEvent() que tiene que ir al mismo nivel que public MainForm(), así:

public void OnTimerEvent(object source, EventArgs e)
{
saca_datos();
leyenda_form.Text = "Última actualización: " + DateTime.Now.ToLongTimeString();
}

leyenda_form es el nombre de una etiqueta dentro del formulario que indica la última fecha/hora que se hizo la consulta a las colas (no olvides tenerla ubicada visualmente en el formulario con la propiedad (Name) adecuada).

saca_datos() es el método que hará la invocación a PowerShell y sacará los datos de la cola. También debe ir al mismo nivel que public MainForm().

Importante: el método saca_datos() debes editarlo para definir la variable "servidor" con el nombre DNS de tu servidor Exchange 2007.

El código del método saca_datos() es el siguiente:

private void saca_datos()
{
lista_form.Items.Clear();
// edita la siguiente línea con el nombre DNS de tu servidor de correo
string servidor = "el_nombre_de_tu_servidor_exchange";

RunspaceConfiguration rsConfig = RunspaceConfiguration.Create();
PSSnapInException snapInException = null;
PSSnapInInfo info = rsConfig.AddPSSnapIn

("Microsoft.Exchange.Management.PowerShell.Admin", out snapInException);
Runspace myRunSpace = RunspaceFactory.CreateRunspace(rsConfig);
myRunSpace.Open();
Pipeline pipeLine = myRunSpace.CreatePipeline();

// comando powershell
Command myCommand = new Command("Get-Queue");

//parámetros powershell
CommandParameter param_server = new CommandParameter("server", servidor);
myCommand.Parameters.Add(param_server);

//mete en la tubería de ejecución
pipeLine.Commands.Add(myCommand);

//ejecución
Collection commandResults = pipeLine.Invoke();

//resultados
string cola = "";
string mensajes = "";

foreach (PSObject cmdlet in commandResults)
{
cola = cmdlet.Properties["NextHopDomain"].Value.ToString();
mensajes = cmdlet.Properties["MessageCount"].Value.ToString();

//saca datos en lista
ListViewItem i = new ListViewItem();
i.Text = cola;
i.SubItems.Add(mensajes);
lista_form.Items.Add(i);
}
}

Y listo, con esto sólo queda darle a F5 para compilar y ejecutar la solución.

Si todo es correcto, el ejecutable colas_correo.exe lo encontrarás en la carpeta debug o release dentro de la carpeta bin del proyecto, el cual podrás utilizar directamente.

División entre dos

2010-05-23T02:30:00.005+02:00

Si algo se parte en dos,
tendrás dos lugares distintos,
si ambos comprendes,
avanzarás.

Espacio libre

2010-03-27T20:42:00.024+01:00

En un entorno con varios servidores en red, una de las cosas más importantes y que más suele pasar desapercibida es el espacio libre de sus discos duros.

Si una partición de un disco duro de un servidor comienza a quedarse sin espacio libre, las consecuencias suelen ser:

Caída del rendimiento del servidor que contenga la partición.
Caída del rendimiento de los servicios que utilicen tal servidor.
Con el tiempo, la interrupción de los servicios que utilicen tal servidor.
Si el servicio interrumpido se dedica a tareas de seguridad, mal vamos.

Para evitar esto de forma proactiva es conveniente conocer, por lo menos una vez a la semana, el espacio libre de cada partición de cada disco duro de cada servidor de la red, y si este espacio libre es menor que 1GB (por ejemplo), se avisaría al administrador del sistema para que remedie esta situación.

Automatizar lo anterior en un Directorio Activo con muchos servidores es posible utilizando Powershell y las Tareas Programadas en algún servidor.

Para ello, he escrito el script freespace.ps1 que busca en el Directorio Activo los nombres de todos sus servidores. Después, el script realiza las consultas adecuadas a los servidores dados, filtra resultados y si es necesario envía un email con la información pertinente al administrador del sistema para que pase a la acción.

freespace.ps1 debe estar ubicado en una carpeta de trabajo, por ejemplo, en c:\freespace

Ubicado freespace.ps1 en su sitio, es necesario editarlo y personalizar los valores de las siguientes variables que se encuentran al principio:

$limite = 1000000000 # con menos de un giga libre en una partición, se informa
$emailFrom = "pon_email_de@origen.es" # origen email
$emailTo = "pon_email_de@destino.es" # destino email
$smtpServer = "tu_servidor_smtp.tu_dominio.es" # servidor smtp de destino
$subject = "Particiones con menos de 1GB libre" # asunto

Una vez personalizadas las variables, guardamos los cambios del script y en la carpeta de trabajo creamos el archivo freespace.bat que debe contener la siguiente línea:

powershell c:\freespace\freespace.ps1

Por último, creamos una tarea programada que ejecute c:\freespace\freespace.bat una vez por semana. Los permisos de la tarea deben ser de un usuario que tenga acceso a todas las particiones de todos los servidores.

Un email enviado en un caso real es el siguiente:

Descubriendo troyanos 3/3

2010-03-06T12:35:00.034+01:00

Ahora toca registrar las conexiones realizadas en Windows desde Windows.

Para ello, iniciamos Windows desde la máquina virtual e instalamos Wireshark. Abrimos Wireshark, elegimos el adaptador de red y comenzamos una captura de paquetes apuntando exactamente la hora y el minuto de inicio de la captura.

Ahora es el momento de abrir IE6 en Windows, navegar por páginas de dudosa reputación y aceptar todo lo que se ponga por delante. Cuanto más tiempo tenga la captura, más posibilidades tendremos de atrapar a algún troyano.

Cuando detengamos la captura de paquetes con Wireshark, exportamos los paquetes capturados mediante el menú File, Export, File..., y guardamos el archivo como export_w32.txt con formato de texto plano (plain text) en el directorio de trabajo.

El siguiente paso es extraer las IPs de las conexiones que se han realizado desde Windows hacia Internet, eliminar redundancias y mostrar más información de la IP (como ya hicimos con Ubuntu con el script conex_report.pl). Para ello, en el directorio de trabajo, ejecutaremos el script conex_report_w32.pl de la siguiente forma:

perl conex_report_w32.pl > windows.txt

Lo anterior genera el fichero windows.txt cuyo contenido será parecido a esto:

Ya tenemos todos los datos que necesitamos. Ahora tenemos que comparar los resultados de windows.txt y de ubuntu.txt para detectar sus diferencias. Para ello, copiamos el contenido de windows.txt, creamos otro windows.txt en el directorio de trabajo de Ubuntu y pegamos en él el contenido del primero.

La comparación de ambos ficheros la realizaremos con el script compara_conex_report.pl que ejecutaremos en el directorio de trabajo de Ubuntu donde también deben figurar los archivos ubuntu.txt y windows.txt

Conclusión y aclaraciones:

Como el procedimiento explicado en el segundo y tercer post depende de ciertos scripts para permitir la automatización de tal, la presentación en PDF del primer post muestra el concepto general, mientras que el procedimiento detallado paso a paso es el siguiente:

En un ordenador conectado a Internet mediante un router con IP 192.168.1.1 instalamos Ubuntu 9.10 (Karmic Koala).
Ubuntu debe tener la interface de red eth0 con la IP 192.168.1.33, máscara 255.255.255.0 y un par de DNS válidas.
En Ubuntu, instalamos el módulo de Perl Net::Whois::IP con CPAN.
En Ubuntu, instalamos VirtualBox.
Creamos una máquina virtual en VirtualBox para Windows XP, configuramos el adaptador de red en modo bridged. Iniciamos la máquina virtual e instalamos en ella Windows XP.
En Windows XP configuramos la IP fija 192.168.2.35, máscara 255.255.255.0 y las mismas DNS que tiene Ubuntu.
En Windows XP instalamos Strawberry Perl y Wireshark (implica la instalación de Winpcap).
En Windows XP, instalamos el módulo de Perl Net::Whois::IP con CPAN.
Ya tenemos todo montado.
En Ubuntu, creamos NAT para la red 192.168.2.0 permitiendo su tráfico de E/S e iniciamos el logeo para el tráfico de dicha red. Para ello, en Ubuntu podemos crear un directorio de trabajo, bajamos a él este script en bash: captura.sh y lo ejecutamos en un terminal.
En Windows XP, iniciamos Wireshark y empezamos a capturar paquetes apuntando la fecha, la hora y el minuto de comienzo de la captura de paquetes.
Iniciamos IE6 en Windows XP y navegamos por webs maliciosas abriendo todo lo que se ponga por delante.
Después de un tiempo prudencial (cuanto más mejor), detenemos la captura de Wireshark, exportamos los resultados a un archivo de texto plano llamado export_w32.txt y lo guardamos en un directorio de trabajo junto con el script conex_report_w32.pl
Iniciamos una shell en Windows (Inicio, Ejecutar, cmd), vamos al directorio de trabajo y ejecutamos: perl conex_report_w32.pl > windows.txt
Abrimos windows.txt, seleccionamos su contenido, lo copiamos y lo pegamos en otro windows.txt nuevo, pero en el directorio de trabajo de Ubuntu.
En el directorio de trabajo de Ubuntu, bajamos los scripts conex_report.pl y compara_conex_report.pl
En el directorio de trabajo de Ubuntu, ejecutamos en un terminal: perl conex_report.pl, le proporcionamos el mes, el día, la hora, el minuto y el segundo de inicio que tenemos apuntados de la captura con Wireshark y después el mes, el día, la hora, el minuto y el segundo de fin de captura. El tiempo de inicio debe ser lo más exacto posible, mientras que el tiempo final mejor que vaya sobrado.
El resultado del script anterior es el fichero ubuntu.txt que contiene las IPs de conexión únicas con la información de whois en el intervalo de tiempo dado.
Por último, en un terminal de Ubuntu y en el directorio de trabajo, ejecutamos: perl compara_conex_report.pl. Las IPs resultantes con su correspondiente información son las de las conexiones que inició Windows, que han sido capturadas por Ubuntu y no han sido capturadas por Wireshark desde Windows, esto es: conexiones realizadas por rootkits troyanizados. En caso de que el resultado no indique ninguna IP, quiere decir que todas las IPs de windows.txt y ubuntu.txt coinciden y todo es correcto: no hay rootkits en Windows.

Descubriendo troyanos 2/3

2010-02-15T17:39:00.008+01:00

El post anterior trata sobre registrar las conexiones que inicia un Windows hacia Internet. Tal operación se realiza con un Linux y una máquina virtual donde "enjaular" a Windows.

Una vez registradas las conexiones en /var/log/kern.log, hay que extraer las IPs remotas y averiguar más información sobre ellas. Como el número de conexiones a una misma IP puede ser muy elevado, conviene eliminar redundancias, obtener la lista de IPs únicas visitadas en un rango de tiempo que indicaremos y obtener más información mediante el servicio whois.

Para ello, he preparado un script en perl conex_report.pl, que hace todo el trabajo y nos saca esa lista junto con alguna información relevante de whois y lo deja en el archivo ubuntu.txt.

Un ejemplo de la ejecución del script:

Y su correspondiente informe de conexiones únicas del archivo ubuntu.txt

En la tercera entrega, veremos cómo hacer lo mismo pero con las conexiones registradas dentro de Windows.

Descubriendo troyanos 1/3

2010-02-13T15:19:00.009+01:00

La mayoría de las veces, es infructuosa la búsqueda de troyanos en un Windows debido a los siguientes factores:

Se ocultan con Rootkits
Se propagan rápidamente vía web
Existe muchísima variedad y cada vez más
Muchos son 0-day que antes de ser descubiertos puede pasar mucho tiempo

Esto quiere decir que un Windows infectado por un rootkit que oculte a un troyano es garantía de pertenecer, con suerte, a una botnet y en el peor de los casos, tus datos personales incluyendo contraseñas y números de tarjeta de crédito (si has realizado compras por Internet) estarán en una base de datos lista para ser vendida.

La solución que propongo es enjaular un Windows en una máquina virtual, exponer a Windows como cebo para los troyanos (navegando con IE sin cuidado) y monitorizar las conexiones de red dentro de Windows y fuera de él (mediante el S.O. anfitrión) durante días.

Comparando ambos resultados, las conexiones remotas que estén registradas fuera de Windows y que no estén registradas dentro de Windows son, seguramente conexiones realizadas por rootkits troyanizados.

En esta presentación en PDF muestro cómo realizarlo con el siguiente software:

Ubuntu Linux 9.10
Virtual Box 3.0.8 para Linux
Windows, preferiblemente un XP pelado
Internet Explorer 6
WinPcap y WireShark

Recopilación de herramientas

2009-12-10T17:01:00.010+01:00

adsetuserpass: cambia contraseñas de usuarios del Directorio Activo con un script de PowerShell.

control-drivers: identifica a los drivers actuales de Windows y los compara con futuras versiones o drivers nuevos para comprobar cambios sospechosos.

dirsize: informa sobre los tamaños de todas las subcarpetas de una carpeta.

ejecutable.pl: script en perl para detectar archivos ejecutables sospechosos.

error-sys-events: realiza un informe con los sucesos de error de varios servidores Windows.

infosis: realiza un informe html recopilando hardware/software de un host Windows.

limpia-medios-extraibles: detecta y elimina (con confirmación) archivos sospechosos que pudieran estar en algún medio extraible como un pendrive.

regsys-net: realiza informes html del hardware/software de todos los hosts Windows de una red.

regsys: realiza un informe recopilando hardware/software de un host Windows.

userperm-net: informa sobre los permisos que tiene un usuario/grupo en todas las carpetas compartidas de un Directorio Activo.

Informes de Windows masivos

2009-11-18T21:05:00.019+01:00

Disponer de informes hardware/software de los ordenadores de una red administrada ahorra mucho tiempo al solucionar problemas.

Una muestra de los datos que se pueden incluir en estos informes puedes verla en el post de Informe del Sistema.

Para automatizar la elaboración de estos informes, las utilidades regsys e infosis extraen estos datos mediante WMI y el Registro de Windows en el mismo ordenador donde se ejecuta la utilidad y pasa los resultados a HTML.

Estas utilidades son muy prácticas al finalizar la instalación/configuración de un sistema Win32 nuevo, pero en el caso de necesitar los informes de decenas o cientos de ordenadores, por ejemplo, de un Directorio Activo, realizar los informes uno a uno es ineficiente.

Para automatizar esta tarea realicé regsys-net que hace lo siguiente:

Ejecutas regsys-net con permisos de administrador de dominio en un ordenador que pertenezca al dominio (supongamos que este ordenador tiene la ip 192.168.1.56)
regsys-net busca ordenadores para conectar con WMI desde la ip 192.168.1.1 hasta la 192.168.1.254 (busca en toda la subred en la que se encuentra)
Si en su búsqueda, regsys-net encuentra un ordenador con el WMI disponible, conecta con él, le extrae la información mediante WMI y el Registro de Windows, y la pone en un archivo HTML, nombra al archivo HTML con el nombre DNS del ordenador correspondiente y lo guarda en la misma carpeta donde se encuentra regsys-net

Este proceso suele suele tardar entre una y tres horas. En el caso de necesitar informes de más ordenadores ubicados en otras subredes, bastará con repetir el proceso en algún ordenador de la subred correspondiente.

Observación: es necesario que los ordenadores con Windows Vista tengan iniciado el servicio Registro Remoto, así, regsys-net puede extraer la información del software instalado mediante el registro de Windows.

Localiza evidencias de Rootkits

2009-11-12T16:05:00.012+01:00

Los rootkits son procesos que tienen la capacidad de ocultarse al usuario mediante varias técnicas. Una de ellas es mediante la inyección de código malicioso desde un proceso maligno a un proceso víctima.

Una de las funciones que utiliza el malware para realizar esta inyección es CreateRemoteThread, por tanto, conocer qué archivos ejecutables tienes en tu Windows que utilicen esta función puede sacar a la luz archivos sospechosos.

Mediante la herramienta Filealyzer podrás ver dentro de un archivo ejecutable, entre otras cosas interesantes, la tabla de importación donde aparecerá una lista de funciones que utiliza el archivo ejecutable en cuestión. Pero ¿cómo saber si un archivo ejecutable utiliza la función CreateRemoteThread para fines lícitos o no? Una forma rápida es buscar dentro de los archivos ejecutables de un Windows recién instalado e identificar los que utilizan la función CreateRemoteThread.

Hacer esto con Filealyzer es muy tedioso, así que para automatizar este proceso puedes utilizar la herramienta Strings de Sysinternals, ubicarla en una carpeta del Path (por ejemplo en c:\windows\system32), ir a esa misma ubicación en la línea de comandos y poner:

strings * | findstr CreateRemoteThread > report.txt

De esta forma, Strings buscará CreateRemoteThread en todas las cadenas de texto de todos los archivos de c:\windows\system32 y pondrá el resultado en el archivo report.txt.

Observando el report.txt en un Windows XP SP3 recién instalado con las Windows Update al día, los archivos ubicados en c:\windows\system32 que utilizan la función CreateRemoteThread son:

csrsrv.dll
dbgeng.dll
kernel32.dll
safrslv.dll
usrcoina.dll
vdmdbg.dll
winlogon.exe
winsrv.dll

Todos ellos son archivos ejecutables de Windows que se suponen lícitos, pues al sistema, se supone que no le ha dado tiempo de infectarse con malware. Por tanto, si generas un report.txt de la manera mencionada en tu Windows XP SP3 y observas que además de los archivos listados hay alguno más, mosquéate, porque los que no aparezcan en esta lista utilizan la función CreateRemoteThread y no es de Windows.

Errores de sistema en varios servidores Windows

2009-10-22T10:23:00.008+02:00

Comprobar los sucesos de error de sistema que se producen en un servidor Windows forma parte imprescindible en la administración de sistemas en estas plataformas. Para ello tienes el Visor de Sucesos y el procedimiento: eventvwr.msc, Sistema, Filtrar por Tipo y seleccionar sólo el tipo Error. Luego queda ver lo que ha sucedido y comprobar si todo va como tiene que ir.

Esto está bien si lo haces con un servidor, pero si lo tienes que hacer con más de tres, el procedimiento es más ineficiente: desde el Visor de Sucesos tienes que ir conectando con cada uno de los distintos servidores y repetir el procedimiento anterior (menos el primer paso que es la ejecución del visor de sucesos).

Quiero que la extracción de los sucesos de error de sistema de varios servidores se realice en un sólo paso, y después consultarlo tranquilamente, y para ello he realizado la herramienta error-sys-events.exe que funciona así:

Creo una carpeta y pongo en ella la herramienta error-sys-events.exe
Creo en esa misma carpeta un archivo de texto llamado servers.txt y pongo un nombre de servidor por cada línea (también valen ip's)
Ejecuto con los privilegios adecuados (administrador local o de dominio) la herramienta error-sys-events.exe, y a esperar
Al terminar tendré un archivo llamado syslogerror-nombre_servidor.txt en esa misma carpeta con los resultados del servidor correspondiente

Después sólo queda ir mirando los distintos informes y ver qué pasa realmente con los servidores.

Alertas con PowerShell

2009-09-25T15:15:00.025+02:00

Si administras servidores con Windows, existen soluciones como MOM o Vbscript para que, si ocurre un evento que consideres importante, salte una alerta que te informe por email. Un ejemplo muy común es que salte la alerta cuando quede poco espacio libre en alguna unidad de un servidor de archivos.

Vamos a ver como se hace con PowerShell.

El requisito es, que en el servidor en cuestión debemos tener instalado PowerShell (Windows 2008 ya lo incorpora).

Abrimos un editor de texto (recomiendo PowerGUI) y empezamos asignando un par de variables: la letra de unidad en cuestión y el tamaño en bytes de espacio libre que, cuando se alcance, queramos que salte la alerta.

$ud = "C:"

$gb1 = 1048576000

En este caso queremos la alerta sobre la unidad C: y el tamaño de espacio libre de alerta es 1 GB.

Ahora hacemos la consulta utilizando WMI (una línea):

$i = get-wmiobject -query "select DeviceID, FreeSpace from win32_logicaldisk" | where-object { $_.DeviceID -eq $ud }

En $i queda el objeto que contiene la letra de unidad (DeviceID) y el espacio libre (FreeSpace) de la unidad C: ($ud).

Ahora queda comprobar si la unidad C: tiene menos de 1GB y enviar el email de alerta si así es:

if ( $i.FreeSpace -lt $gb1 )
{
  $emailFrom = "admin@dominio.dom"
  $emailTo = "destino@dominio.dom"
  $subject = "Menos de 1GB en C: en el servidor x"
  $body = ""
  $smtpServer = "smtp.dominio.dom"
  $smtp = new-object Net.Mail.SmtpClient($smtpServer)
  $smtp.Send($emailFrom, $emailTo, $subject, $body)
}

En $emailTo podemos indicar más de un destinatario separados por comas. En este caso el cuerpo del mensaje $body no tiene nada y $smtpServer es la dirección del servidor smtp de destino donde está el buzón de correo del destinatario.

Ahora sólo queda guardar el script, por ejemplo, como pocoespacio_c.ps1, en alguna carpeta y ejecutarlo de forma programada con las Tareas Programadas de Windows. Una buena programación en este caso sería que este script se ejecute de lunes a viernes, durante la jornada laboral y a cada hora.

Detalle importante: a la hora de definir el comando a ejecutar en Tareas Programadas es necesario indicar toda la ruta del ejecutable powershell.exe, un espacio en blanco y después entre comillas dobles indicar toda la ruta del script, por ejemplo:

C:\WINDOWS\system32\WindowsPowerShell\v1.0\powershell.exe "C:\scripts\pocoespacio_c.ps1"

Y a esperar a quedarnos con menos de 1GB en C:

Conoce la web y defiéndete con ella

2009-09-06T16:57:00.005+02:00

Para navegar por la web de forma segura hay, entre otros, conceptos básicos como:

Saber en qué URL estamos y como se construyen
Diferenciar webs falsas de las verdaderas
Diferenciar un enlace javascript de otro convencional
Rellenar formularios de forma segura
Identificar y gestionar los complementos web del navegador

Explicados junto con más cosas en esta presentación.

Felíz rumbo.

DirSize

2009-08-30T12:46:00.009+02:00

Con Windows siempre hay una carpeta que ocupa demasiado y no sé donde está. Me pongo a buscarla y llegar a ella es tedioso: clicar en las propiedades de cada carpeta, comprobar el tamaño, y así sucesivamente...

Qué práctico sería ver directamente los tamaños de cada carpeta de la unidad C: (por ejemplo), y más práctico todavía sería ver esos tamaños ordenados para saber primero cual es la carpeta con más tamaño. Así puedo entrar en ella y repetir la operación hasta dar finalmente con la carpeta con más tamaño.

Para ello he implementado una utilidad llamada dirsize que funciona en línea de comandos y que directamente, allá donde se ejecute, te muestra los tamaños de las carpetas.

Por ejemplo, este es un pantallazo de los resultados de ejecutar dirsize en la unidad C:

Con estos resultados, ya sé que la carpeta Windows es la de mayor tamaño en la unidad C: con unos 4,7 Gb.

Ahora sólo me quedaría entrar en la carpeta Windows y volver a ejecutar dirsize para que me diga cual es la carpeta con más tamaño del "lugar".

Y así sucesivamente.

En este caso concreto, os sorprendería saber cual es la más gorda del "lugar", pues Windows oculta el tamaño real de algunas de sus carpetas (si se realiza la consulta mediante las propiedades de la carpeta en cuestión). Con dirsize esta información queda al descubierto y permite saber exactamente el tamaño de cada carpeta y poder tomar medidas si es necesario.

Por último, es recomendable ubicar a dirsize en una carpeta con path (por ejemplo: c:\windows\ o c:\windows\system32\) para que funcione en cualquier sitio.

Buena cacería de carpetas de gran tamaño.

Directorio Activo, Usuarios, Permisos y Carpetas compartidas

2009-08-25T14:19:00.010+02:00

En un Directorio Activo, es fácil saber qué usuario/grupo tiene acceso a un recurso como una carpeta compartida (sólo tienes que mirar las propiedades de la carpeta compartida en cuestión), pero las propiedades de un usuario/grupo no te dicen a qué carpetas compartidas tiene acceso en un momento dado.

Una debilidad muy común es el acceso del grupo Todos, y es imprescindible saber en qué carpetas compartidas tiene el permiso Control Total. Igualmente, saber puntualmente quién tiene acceso a qué, y qué tipo de permiso tiene, ayuda de una forma extraordinaria a mantener segura la política de seguridad de un Directorio Activo.

Como no encontré una herramienta que automatice esto, hice en Perl la herramienta de línea de comandos userperm-net, que hace lo siguiente:

Pide al usuario el nombre de un usuario o un grupo
Mediante net view genera un archivo de texto con la lista de los hosts en red
Toma la lista generada y realiza lo siguiente en cada host:
Intenta una conexión WMI para extraer la lista de carpetas compartidas
De cada carpeta compartida, extrae la lista de usuarios/grupos con sus permisos NTFS
Compara cada nombre de usuario/grupo del paso anterior con el introducido en el paso 1
En caso de coincidencia, muestra el nombre del usuario/grupo, el permiso, el host y la ruta completa de la carpeta en cuestión
Por último, si el usuario quiere, muestra una lista con los hosts donde no ha podido conectar con WMI

Consideraciones para utilizar userperm-net:

Es mejor ejecutarlo con permisos de administrador de dominio, así llegará al máximo de hosts del Directorio Activo
Hay que ser muy cuidadoso introduciendo el nombre de usuario/grupo porque tiene en cuenta mayúsculas/minúsculas, espacios, etc.
Como trabaja a nivel de permisos NTFS de carpetas compartidas y no a nivel de permisos de carpetas compartidas en sí, es posible que algunos resultados sólo tengan sentido para accesos locales y no desde otro host

Pantallazo:

Cloud-Computing

2009-08-11T08:43:00.015+02:00

La nueva plataforma web aplicada a negocios parece inexorable. Microsoft con Azure, Google con App Engine y otros del mismo calibre están apostando por el Cloud-Computing, que entre otras tiene las siguientes novedades y ventajas:

Reducción de costes: normalmente no se pagan licencias, sólo se paga cuota en base al número de usuarios o de uso de la infraestructura. Mantenimiento in-situ prácticamente nulo (sólo necesitas conexión a Internet).
Servicios de todo tipo centralizados y escalables: mensajería, blogging, video, intranet, colaboración, aplicaciones a medida, bases de datos, etc., que pueden crecer sin límite aparente y sin problemas.
Facilidad de desarrollo: sólo hay que ver este tutorial que traduje sobre Google Apps.

Ahora, ¿cuales son las dudas que invaden a los responsables de las empresas?:

Seguridad: las comunicaciones web por Internet no son seguras, ni lo han sido ni lo van a ser.
Disponibilidad de los datos: ¿qué ocurre cuando no hay conexión a Internet?
Privacidad de los datos: los datos físicamente no los tengo yo, están repartidos dinámicamente por servidores en todo el mundo ¿quien me garantiza su privacidad?
Migración: será fiel la migración si migro todo mi sistema al Cloud-Computing, ¿podré después migrar después a otro proveedor de Cloud-Computing?

Más info:

Cálculo de costes de Microsoft Azure
Cálculo de costes de Google Apps en mensajería
Google App Engine Blog

La desinformación de la red social

2009-07-25T10:32:00.017+02:00

¿Sabes quien anda detrás de la otra pantalla?

En seguridad informática hay una cosa evidente: el factor más peligroso es el ser humano. Y aquí es donde entra la ingeniería social como método, donde la información consigue información mediante la desinformación. Actualmente en Internet, a esto lo podríamos llamar irónicamente human data injection o simplemente engaño, método antiguo como la picaresca.

Un nuevo campo en la aplicación del engaño, muy significativo y reciente, son algunas funcionalidades de la red social. Un usuario de Facebook tiene acceso prácticamente a toda la información que quiera publicar otro usuario aunque no sea su amigo, sólo basta ser amigo de un amigo suyo. El pequeño equivalente en el mundo real es el boca a boca: la información que le doy a un amigo, éste puede propagarla a sus amigos y así sucesivamente... nunca sabes a donde llega, y nunca sabrás cuando y cómo te repercutirá (efecto boomerang). En la red social, el "boca a boca" es automático.

Con esto deduzco que el mayor peligro de la red social no es acceder a la información de un usuario. El mayor peligro de la red social es la información que publica una persona, y en ésto hay que avisar a los neófitos/as. Cuando buscas la palabra Twitter en Google, al lado de la entrada correspondiente pone: -What are you doing?- (¿Qué estas haciendo?). El recebo del ego es un asunto muy delicado.

No es lo mismo comentar tu vida privada con tu amigo/a más leal, que escribirla en papelitos y distribuirla por la calle al primero que encuentres de una forma inconsciente. Algunas consecuencias, por desgracia, las vemos en los medios: acoso psicológico, robo de información, secuestros, engaños, desinformación, venganzas, robo de dinero, chantajes, y todo lo que permita la creatividad de un alma tocada por su lado más oscuro.

El problema tampoco está en la red social, está como dije antes, en el usuario. La gran ventaja también radica en este problema: los creadores de redes sociales de éxito tienen información a tiempo real de patrones de conducta de todo tipo de millones de personas, un campo de posibilidades a nivel de marketing nunca jamás visto antes.

Es muy natural entre humanos la curiosidad, algunos quieren saber más de nosotros, posiblemente de la misma forma que cualquier otra persona. La libertad de publicación de información en la red no puede discutirse, pero tiene límites éticos, morales y legales que han de ser distribuidos, fomentados y aprendidos. La red social apuesta por el gran negocio: mis amigos y los amigos de mis amigos son mis amigos.

Creo que las personas que trabajan en redes sociales deberían saber que los beneficios de ellas también supondrán desgracias a los más desprotegidos en el contexto informativo.

¿Crees que la red social aportará algo bueno a los humanos que no estén preparados para ello?

Saludos.

Cuida el registro de Windows

2009-07-12T16:23:00.009+02:00

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.

Elimina virus de pendrives, más mejor

2009-06-21T23:15:00.010+02:00

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:

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.

Elimina virus de pendrives

2009-06-17T18:05:00.012+02:00

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.

PowerShell, Directorio Activo y contraseñas

2009-05-28T19:28:00.011+02:00

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.

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.

La guía del administrador de los Cmdlets para administrar el Directorio Activo.

Informe del Sistema 1.0 disponible

2009-04-20T20:11:00.011+02:00

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.

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:

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

- Fabricante de la placa base

- Modelo

- Arquitectura

- RAM

- Procesador

Discos duros

- Letra de unidad

- Modelo

- Capacidad

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

- 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

- 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

- 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

- Versión

- Fabricante

Si lo pruebas, te agradeceré que me reportes tu parecer para mejorarlo.

Rootkits de firmware

2009-03-22T11:11:00.004+01:00

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.

Contra los rootkits: SpyDLLRemover

2009-03-15T20:16:00.007+01:00

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

Windows XP más seguro

2009-02-11T16:38:00.011+01:00

Si inicias Windows XP con una cuenta que tiene privilegios de administrador local o con la misma cuenta de administrador (cosa corriente), tiene sus ventajas porque puedes hacer lo que quieras sin restricción alguna, y también tiene sus inconvenientes: cualquier cosa maliciosa que venga de fuera puede aprovechar perfectamente estos privilegios y también puede hacer lo que quiera sin restricción alguna.

Estas cosas maliciosas, o las cosas que hacen cosas sin que te enteres, como utilizar los recursos de tu ordenador para el enriquecimiento de otros, o simplemente robarte credenciales bancarias para robar el sudor de tu frente, actualmente han crecido tanto en número como en sofisticación.

No existe software que te protega 100%, y tal y como está la cosa actualmente, cuanto más promíscuo seas en la red, más posibilidades tienes de llevarte un premio.

A la vez, el negocio de la seguridad informática es una carrera de tiempos dentro de un toroide cerrado donde tu ordenador está en medio pagando tributos, primero a uno, luego a otro, luego a otro y así sucesivamente. No estás más seguro por tener más software de seguridad, estás más seguro sabiendo lo que tienes y unas buenas contraseñas.

Para tener un buen nivel de seguridad en Windows XP, sólo necesitas cuatro cosas:

Windows XP actualizado todos los días con Windows Update.
Antivirus actualizado todos los días.
Utilizar normalmente una cuenta de usuario que sólo pertenezca al grupo "Usuarios".
Sentido común.

El punto 1 y 2 es una rutina, el 4 depende de tí y ahora hablemos del punto 3.

En el caso de Windows XP, esto se realiza con la Administración de equipos ubicada en las Herramientas Administrativas del Panel de Control, o utilizando el comando compmgmt.msc. Dentro de Administración de equipos, en el apartado de Usuarios locales y grupos aparecen dos carpetas: Usuarios y Grupos.

Dentro de la carpeta Usuarios haz doble click en tu usuario y aparece la ventana con sus opciones, ve a la pestaña Miembro de, agrega el grupo Usuarios y elimina cualquier otro grupo (incluido el grupo de Administradores).

Aparte de esto, no hace falta recordar que tanto nuestro usuario como el usuario Administrador deben tener contraseñas fuertes. Para asignar una contraseña a un usuario basta con clicar en él con el botón derecho y elegir Establecer contraseña...

De esta forma, hagas lo que hagas con tu usuario, éste no podrá escribir o modificar archivos de zonas importantes de Windows y por tanto tampoco ningún código malicioso que puedas "adquirir", sea por Internet, pendrive o disquete de 5 1/4.

Ahora, si necesitas instalar algún software que requiera privilegios elevados, realizar alguna tarea administrativa o cualquier otra cosa que necesite privilegios de administración puedes utilizar el botón derecho del ratón y elegir Ejecutar como dando las credenciales del administrador local, o también puedes utilizar la versión de línea de comando "runas".

Por ejemplo, si necesitas comprobar e instalar actualizaciones de Windows XP con Windows Update en la versión línea de comandos, puedes crear en escritorio el archivo WindowsUpdate.BAT con estas líneas:

@echo off
cd %systemroot%\system32
runas /env /user:administrador wupdmgr.exe

Lo abres, te pide la contraseña del administrador local, se la das y Windows Update empezará a realizar su trabajo, mientras el usuario actual sigue restringido y protegido.

Detecta y elimina malware en Windows XP

2009-02-01T20:12:00.005+01:00

El malware puede tomar cualquier forma dentro del sistema operativo, y conociendo al detalle al sistema operativo, es más sencillo detectar al malware para aislarlo y eliminarlo con herramientas sencillas.

El año pasado escribí una guía de 26 páginas acerca de cómo identificar malware en un Windows XP.

En esta guía verás como utilizar varias herramientas de administración de Windows y, entre otros métodos, detalla el funcionamiento de varias herramientas de Sysinternals como Process Explorer y Autoruns para sacarle la información a Windows y poder interpretarla correctamente para detectar malware. Actualmente, esta guía se encuentra en formato PDF en este enlace.

Windows XP más rápido = servicios necesarios

2009-01-31T10:43:00.016+01:00

Windows XP, como cualquier otro sistema operativo viene por defecto con una serie de servicios que se inician automaticamente cuando el ordenador arranca. Dependiendo del uso que demos al ordenador utilizaremos algunos y otros no.

En este post, explicaré algunos servicios de Windows XP, comprobaremos si los necesitamos o no, y los que no necesitemos los desactivaremos. El resultado será el ahorro de recursos y el incremento de la rapidez de Windows XP, tanto en arranque como en el uso normal.

Lo primero que haremos es abrir el gestor de servicios y ver lo que hay. Para ello vamos a inicio, ejecutar y ponemos: services.msc, pulsamos ENTER y aparecerán los servicios. Para verlos mejor, maximizamos la ventana y pinchamos abajo en la pestaña "Estándar".

La columna interesante es Tipo de inicio. Si ordenamos los servicios por Tipo de inicio los veremos mejor. Hay tres tipos de inicio:

Automático: siempre inicia el servicio en el arranque de Windows.
Manual: se inicia a demanda. Normalmente lo inicia otro servicio ya iniciado, como por ejemplo alguno que ya se inicie de forma automática.
Deshabilitado: nunca se inicia.

Podemos cambiar el tipo de inicio de un servicio dado, además de iniciarlo o detenerlo haciendo doble click izquierdo en él e indicando lo que queremos.

A continuación voy a explicar algunos de los servicios de Windows XP SP3 Profesional que podemos tocar sin problemas, y así averiguamos si los necesitamos o no:

Acceso a dispositivo de interfaz humana: Si tienes un teclado con botones multimedia tipo volúmen, enviar correo, hacer la colada, etc., déjalo en automático. Si tienes un teclado convencional y no utilizas este tipo de controles multimedia, lo puedes detener y deshabilitar.

Actualizaciones automáticas: es recomendable que esté en automático sino quieres que tu Windows se convierta en un colador.

Administrador de IIS: si tienes un servidor Web, o ftp, o alguna aplicación que utilice IIS (Internet Information Server) déjalo en automático. Si utilizas otro servidor web como Apache o Tomcat, lo puedes desactivar. Si lo anterior te suena a chino, desactívalo.

Administrador de sesión de Ayuda de escritorio remoto: esto sirve para que un amigo tuyo se conecte a tu ordenador y te ayude con algún problema. Desactívalo sino necesitas ayuda on-line.

Adquisición de imágenes de Windows (WIA): si tienes un escáner o cámara conectado al ordenador, déjalo en automático, sino, lo puedes desactivar.

Agente de Protección de acceso a redes: el servicio NAP, una capa nueva extra de seguridad que Microsoft sacó ya con Windows Vista y Windows 2008. Tiene sentido en una red local de ordenadores donde queremos más seguridad. En entornos corporativos donde la seguridad es un factor crítico entre ordenadores y servidores no estaría mal. En el caso doméstico no le veo utilidad y puede desactivarse.

Ayuda y soporte técnico: por la utilidad que he visto en este servicio, es mejor desactivarlo.

Configuración inalámbrica rápida: si tu ordenador tiene WIFI, déjalo activado, sino, desactívalo.

DDE de red: otro servicio para dar seguridad al transporte de datos en determinadas aplicaciones (nunca he visto una aplicación que utilice este servicio). No es necesario para compartir carpetas en una red local, por tanto se puede desactivar.

DSDM de DDE de red: más de lo mismo que el servicio anterior.

Enrutamiento y acceso remoto: desactívalo. Un router es un router, y un Windows es un Windows.

Escritorio remoto compartido de NetMeeting: esto es una cosa parecida a la asistencia remota, pero utilizando NetMeeting. Sino te suena, desactívalo.

Instantáneas de volumen: si utilizas el sistema de copia de seguridad propio de Windows, puede ser útil, sino, desactívalo.

Machine Debug Manager: si te dedicas a analizar volcados de memoria cuando algo revienta, es hasta necesario. Si lo anterior te suena a chino, desactívalo.

Mensajero: esto tiene sentido en la oficina cuando el administrador de sistemas necesita alertar de algo a los usuarios. A nivel doméstico no tiene sentido.

MS Software Shadow Copy Provider: esto es lo mismo que el servicio de Instantáneas de volumen.

Programador de tareas: si necesitas hacer algo de forma automática de vez en cuando, tiene sentido, sino, desactívalo.

Publicación en World Wide Web: igual que el Administrador de IIS.

Servicio de alerta: igual que el servicio Mensajero, pero en vez de que la alerta la realice el administrador de sistemas la realiza alguna aplicación en respuesta a algún evento. En entorno doméstico no tiene sentido.

Servicio de Index Server: dice que mejora la velocidad de las búsquedas de archivos en Windows, pero yo no he visto ninguna mejora significativa. Lo puedes desactivar perfectamente.

Servicio de restauración de sistema: yo lo he probado en varios contextos, y es mejor tener una copia de seguridad de nuestros archivos que no pueden perderse fuera del ordenador, por ejemplo en un disco duro externo. Además, es un nicho de virus. Mejor desactivado.

Servicio de uso compartido de red del Reproductor de Windows Media: si utilizas Windows Media Player junto con aparatos reproductores externos, puede servir para que compartan datos entre si (esto es como el itunes y el ipod pero en plan Windows), sino, desactívalo.

Servicio del número de serie de medio portátil: íntimamente ligado al servicio anterior.

Servicios de Terminal Server: si quieres conectar con el escritorio de otro ordenador en red, bien, sino, desactívalo.

Servicios IPSEC: este servicio de cifrado de red tiene sentido en comunicaciones cifradas entre servidores de archivos confidenciales. En entornos domésticos no tiene sentido.

Sistema de alimentación ininterrumpida: si tienes un SAI conectado al ordenador y quieres mirar su estado con el mismo Windows, bien. Si tu SAI ya dispone de software para esto, o no tienes un SAI, desactívalo.

Tarjeta inteligente: esto se utiliza en caso de que algún programa necesite leer tarjetas de identificación, para temas de seguridad. Sino tienes alguna tarjeta de estas, puedes desactivarlo.

Telnet: si te gusta la línea de comandos con conexión remota y la inseguridad, pues vale, sino desactívalo.

Temas: Windows más bonito. Si lo desactivas, se queda con los gráficos en plan Windows 95, y ten por seguro que Windows irá más rápido.

Como dije, el resto de servicios suelen ser más necesarios y están más vinculados con el funcionamiento de Windows, aunque puedes probar a desactivar alguno a ver que pasa.

Si dejamos activos sólo los servicios que utilizamos y deshabilitamos los que no utilizamos, tendremos una mejora significativa en rapidez, que si por contra dejamos los servicios configurados por defecto.

Ejecutable ¿o no?, esa es la cuestión

2009-01-28T10:11:00.017+01:00

Que un archivo comience con los bytes "4d5a" (hexadecimal), no es casualidad. Se trata de un archivo ejecutable de cualquier sistema operativo de Microsoft.

Concretamente estamos hablando del comienzo de la cabecera PE (Portable Executable), que identifica a los archivos ejecutables de MS-DOS también soportados por compatibilidad en las versiones de los ejecutables posteriores de Windows. Disponemos de más información acerca de la estructura de la cabecera PE aquí y aquí.

Las extensiones de los nombres de los archivos ejecutables de Windows son muchas, las más conocidas son .EXE, (el de toda la vida), .DLL (librerías dinámicas) y los .SYS (Drivers). Menos conocidas son .CPL y DPL. En cualquier caso, todos estos tipos de archivos comienzan con los bytes mencionados y tienen la capacidad de ejecutar código en el sistema, para bien y para mal.

Entrando en el contexto de la seguridad, lo normal es que un archivo ejecutable tenga una extensión como las que hemos visto, como EXE, y lo extraño es encontrar un archivo que por su nombre/extensión no parezca ejecutable y su contenido sí lo sea.

Muchos virus utilizan archivos con extensión .TMP (temporal) para alojarse en ellos y "despistar" al observador. Ahora, su contenido comienza con "4d5a", y digo .TMP como si se trata de cualquier otra extensión que no parezca ser un ejecutable, o simplemente que no tenga extensión. Si no nos percatamos de este detalle, el .TMP de turno puede ser abierto por cualquier otro proceso y ejecutarlo... y en ese caso tenemos papeletas para el premio.

Para saber si existe en nuestro sistema algún archivo que por su extensión no denote "ejecución", he preparado un script en perl. Este script trabaja sobre archivos que NO tengan las extensiones típicas de los ejecutables (exe, dll, sys, drv, ocx, com, cpl, dpl) para comprobar si el contenido comienza con "4d5a". Si el script detecta estos bytes al inicio del archivo, indica la ruta y el nombre del archivo en cuestión. En estos casos, habría que buscar información de la extensión de este archivo y comprobar de qué se trata.

Este script da la opción de realizar esta búsqueda en toda la unidad C: incluyendo todos sus subdirectorios (tarda un buen rato), y también da la opción de realizar esta búsqueda en el directorio actual. En ambos casos, el resultado lo dejará en el archivo resultados.txt del directorio donde se ejecute el script.

He pasado este script en tres ordenadores con Windows XP SP3, y no podeis imaginar la cantidad de archivos que existen, que no parecen ejecutables, y sí lo son. En próximos posts intentaré dar más información acerca de este tipo de extensiones como ax, flt, mui, wpc, etc.

El script está disponible en este enlace.

Protege los drivers de tu Windows, y 2

2009-01-27T21:57:00.004+01:00

El script del post anterior sólo trabaja con MD5: crea MD5 de los drivers actuales a un archivo (drivers.md5) y también puede comprobarlos en un futuro.

Pero le falta una cosa importante: si hay drivers nuevos no los procesa porque toma como referencia el archivo drivers.md5, y en base a su contenido comprueba si existe el driver correspondiente en el sistema, sin realizar un recorrido en éste. Por tanto, sólo procesa los que tiene en drivers.md5 ignorando los nuevos que pudieran existir. Esta funcionalidad es crítica y necesaria puesto que necesitamos saber si algún driver ha sido instalado en el sistema desde la última "foto" que le hicimos.

Para ofrecer esta nueva funcionalidad, he ampliado el script dando una opción más que es: Comprobar drivers nuevos. Además, como ahora he utilizado contadores para contar tanto los drivers en drivers.md5 como en el sistema, los resultados en general se han ampliado.

Como los cambios son significativos respecto al script anterior, a éste lo he llamado control-drivers.pl y su versión es la 1.0.

Y para evitar erratas producidas por blogger, el nuevo script se encuentra en este enlace.

Protege los drivers de tu Windows

2009-01-26T15:50:00.010+01:00

En base al trabajo del post anterior, podemos eliminar los drivers que no utilizamos, y si el resto es de confianza, podemos controlarlos haciéndolos una foto con MD5 para después compararlos con la realidad. De esta forma sabremos si alguno es modificado.

El sentido de esto es saber cuando queramos si estos archivos (de confianza) han sido alterados o no, comparándolos con sus MD5 antes generados. Así, si instalamos una versión nueva de un driver, o si Windows Update lo hace, lo podremos confirmar. Y si ha habido algún cambio sin que nosotros lo sepamos, pues puede ser un virus.

Para ello, realizaremos un script con perl con un menú donde podamos elegir realizar el MD5 de los drivers, que son los archivos que tengan extensión .SYS, o .sys, o, Sys (perl distingue entre mayúsculas y minúsculas), que se encuentren tanto en system32 como en system32\drivers y guardarlo en un archivo de texto.

La segunda opción tendrá sentido a futuro, cuando comparemos los MD5 de los drivers actuales con los guardados (la foto) . Si no hay ningúna discrepancia, el script no dará ningún resultado, y si la hay, indicará cual es el driver afectado.

------------- Comienzo md5-drivers.pl -------------------------------

# Generación y comprobación de los MD5 de los drivers de Windows
# ramiro.encinas@gmail.com - 2009
# Tuya es la responsabilidad del buen o mal uso de este script

use Digest::MD5::File qw(file_md5_hex); # Cargamos el módulo MD5 para archivos

sub menu # El menú con las tres opciones
{
print "\nControl de drivers. Elige opcion:\n";
print "-------------------------------------\n";
print "- [1] Generar MD5 de los drivers en $file_out\n";
print "- [2] Comparar los MD5 de los drivers con el de $file_out existente\n";
print "- [3] Salir\n";
print "->";
}

sub genera # Procesa los MD5 de los drivers actuales en ambas ubicaciones
{
open f_out, ">$file_out"; # Abre para escritura a drivers.md5

$path = $path1; # Procesa la primera ubicación
busca($path); # Y llama a la función correspondiente para generar los MD5

$path = $path2; # Procesa la segunda ubicación
busca($path); # Y llama a la función correspondiente para generar los MD5

close f_out; # Cierra drivers.md5
print "Archivo $file_out generado ok.\n";
}

sub busca # Busca drivers en ubicación, genera MD5 y los guarda en drivers.md5
{
opendir DIRECTORY, $path or die; # Abre la carpeta $path (la ubicación actual)

# Recorre $path y deja en $file cada nombre de archivo

while ($file = readdir(DIRECTORY)) # Leemos todos los archivos de la ubicación
{
if ( -d $path.$file ){# $file es un directorio
}
else # $file es un archivo (porque puede un directorio)
{
if ($file =~/.[sS][yY][sS]$/) # Sólo *.SYS (mayus y minus).
{
$md5 = file_md5_hex($path.$file); # Calcula el MD5 de $file
print f_out "$path$file\:\:$md5\n"; # Escribe en drivers.md5 path+archivo+::+md5
}
}
}
}

sub compara # Compara los MD5 actuales con los guardados en drivers.md5
{
open f_in, $file_out or die "No puedo abrir $file_out"; # Abre drivers.md5

while () # Leemos línea a línea hasta la última
{
chomp $_; # Quitamos el fin de línea
$_ =~ /(.*)::/; # Extrae el nombre del archivo (path incluido) de drivers.md5
$f = $1; # y lo pone en $f

$_ =~ /::(.*)/; # Extrae el MD5 del archivo de drivers.md5
$md5 = $1; # y lo pone en $md5

$md5_actual = file_md5_hex($f); # Generamos el MD5 del driver actual

# Y comparamos. Si hay discrepancia la pone, sino, no la pone

if ($md5 ne $md5_actual){print "\nCuidadito, el MD5 de $f no coincide.\n";}
}
close f_in; # Cerramos drivers.md5
}

sub principal # Empezamos aquí
{
$path1="C:\\WINDOWS\\system32\\"; # Primera ubicación de los drivers
$path2="C:\\WINDOWS\\system32\\drivers\\"; # Segunda ubicación de los drivers
$file_out = "drivers.md5"; # Nombre de archivo donde se guardarán los MD5 actuales

menu(); # Llama al menú
while ($opcion=) # Espera opción desde el teclado para meterla en $opcion
{
chomp $opcion; # Elimina el fin de línea
if ($opcion == 1){genera($path1,$path2);exit;} # Llama a sub genera
elsif ($opcion == 2){compara($file_out);exit;} # Llama a sub compara
elsif ($opcion == 3){exit;} # A la calle
else {$opcion = NULL;menu();} # Sino hay opción válida, volvemos.
}
}

principal(); # Esta es la primera función que se ejecuta

-------------- Final md5-drivers.pl -------------------------------

AVISO: Debido a que blogger elimina los símbolos mayor menor que, a este script le faltan algunas cosas para funcionar. El script completo puedes verlo y descargarlo en este enlace.

Perl, MD5 y los drivers sospechosos de Windows

2009-01-24T19:45:00.013+01:00

En Windows, los drivers que normalmente están alojados en

c:\windows\system32 y

c:\windows\system32\drivers,

pueden ejecutarse en el espacio de memoria del núcleo y por tanto, pueden hacer lo que quieran en el sistema. Estos archivos suelen tener la extensión .sys, y normalmente no se les presta atención.

Hay drivers que ya los pone Windows, otros se alojan ahí cuando instalamos algún dispositivo, y hasta hay programas que también dejan ahí su .sys para hacer cosas. Los virus también los utilizan para sus cometidos, y con más frecuencia que lo que creemos.

Se inicie el driver o no al encender el ordenador dependerá si el driver es llamado desde el registro. Para ver esto, aconsejo autoruns de Sysinternals.

A veces es difícil saber si un .sys es de fiar o no, aunque consultemos en la red. Una forma de averiguarlo es, si sospechamos de alguno, crear una carpeta en la misma carpeta donde se aloja el driver y moverlo ahí. Después reiniciamos y a ver que pasa. Si hemos movido un driver crítico del sistema, seguramente nos toque arrancar con un live-cd y volver a poner el driver en su ubicación original. Sino ocurre nada, podemos esperar a ver que pasa, y si sigue sin pasar nada, pues lo mismo ese driver no se usa.

Si da la casualidad de que hemos movido un driver que es utilizado por algún virus u otro programa malicioso, es posible que, si el virus está en memoria, lo vuelva a crear incluso con otro nombre, y aquí es donde entra el

MD5

El MD5 de un archivo es un resumen del contenido del archivo y además es único para ese archivo. Lo bueno es que ese resumen sólo ocupa 32 dígitos hexadecimales (128 bits), ocupe lo que ocupe el archivo. De esta forma, con estos 32 dígitos podemos verificar la integridad de un archivo.

Si hemos apartado los drivers sospechosos a una carpeta llamada "sospechosos", podemos calcular el MD5 de cada uno y crear un archivo de texto donde cada línea tendrá el nombre del archivo y su MD5. Después, si alguno de estos drivers sospechosos es el resultado de un virus y éste vuelve a crear el driver, aunque sea con otro nombre, para identificarlo podemos comparar los MD5 sospechosos que contiene nuestro archivo de texto con los MD5 de los archivos de las carpetas de sistema de Windows (system32 y system32\drivers) hasta que salte la coincidencia. Si el nuevo driver tiene otro nombre y el mismo MD5, se trata de un virus seguro.

Entrando en harina

Primero vamos a hacer un pequeño script en perl llamado md5.pl para sacar los MD5 de un archivo dado:

------- comienzo md5.pl -----------------------------------------------
# ramiro.encinas@gmail.com - 2009
# Tuya es la responsabilidad del buen o mal uso de este script

use Digest::MD5::File qw(file_md5_hex);

if ($ARGV[0]) {$archivo = $ARGV[0];}
else {print "\n";print "Sintaxis: perl md5.pl nombre_archivo.\n";exit;}

if ( -e $archivo )
{
$md5 = file_md5_hex($archivo);
print "\n";print "El MD5 de $archivo es: $md5\n";
}
else {print "\n";print "Sintaxis: perl md5.pl nombre_archivo.\n";exit;}
------- fin md5.pl ----------------------------------------------------

Con este script podemos sacar los MD5 de los archivos sospechosos. Después, en la carpeta de trabajo, creamos un archivo de texto llamado drivers-sospechosos.txt, donde cada línea contendrá cada nombre de archivo sospechoso y su MD5 correspondiente. Para separar el nombre del archivo y su MD5 utilizaremos "::" como vemos en este ejemplo:

data.sys::ee2f07a2d1f81e2f5a8a454f61d9395a

Cuando tengamos drivers-sospechosos.txt lleno con los archivos (drivers) sospechosos y sus MD5, y además tengamos movidos dichos archivos a la carpeta "sospechosos", podemos esperar unos días y ejecutar el siguiente script que realizará la búsqueda-comprobación:

------- comienzo drivers-sospechosos.pl ----------------------------------------

# Los drivers sospechosos de c:\windows\system32 y c:\windows\system32\drivers
# han sido movidos a la carpeta "sospechosos" que está en la misma carpeta donde
# estaba el driver sospechoso.

# Cada uno de los nombres de estos drivers sospechosos junto con su MD5 están en
# una línea de drivers-sospechosos.txt, y éste archivo está en la carpeta de trabajo.

# Este script busca los MD5 de los archivos de drivers-sospechosos.txt
# en c:\windows\system32 y c:\windows\system32\drivers
# para comprobar si existe alguna coincidencia.

# Este script asume que la carpeta de trabajo es
# C:\WORKSPACE\drivers-sospechosos
# y que dentro está el archivo drivers-sospechosos.txt con los nombres y MD5
# de los archivos sospechosos, uno por línea y este mismo script, claro.

# Este script también asume que por cada línea de drivers-sospechosos.txt hay
# un nombre de driver sospechoso, una separación "::" y su MD5.

# ramiro.encinas@gmail.com - 2009
# Tuya es la responsabilidad del buen o mal uso de este script

use Digest::MD5::File qw(file_md5_hex);

# Ubicación del archivo con los archivos sospechosos

$path_filein = "C:\\WORKSPACE\\drivers-sospechosos\\drivers-sospechosos.txt";

# Función principal

sub todo
{
# Apertura drivers-sospechosos.txt
open f_drivers, $path_filein or die "No puedo abrir $path_filein";
$c = 0; #Número de coincidencias

while( ) # Abro drivers-sospechosos.txt y lee línea a línea
{
chomp $_; # Quita el fin de línea, que si se queda esto no funciona

$_ =~ /(.*)::/; # Extrae el nombre del archivo
$filein = $1; # y lo pone en $filein

$_ =~ /::(.*)/; # Extrae el MD5 del archivo
$fileinmd5 = $1; # y lo pone en $md5

$path = "C:\\WINDOWS\\system32\\";
proceso($path,$filein,$fileinmd5); # Búsqueda en system32

$path = "C:\\WINDOWS\\system32\\drivers\\";
proceso($path,$filein,$fileinmd5); # Búsqueda en drivers
}
close f_drivers; # Cierra drivers-sospechosos.txt
print "\n";
print "Coincidencias: $c\n"; # Muestra número de coincidencias
}

# Función de búsqueda por cada $path

sub proceso($path,$filein,$fileinmd5)
{
opendir DIRECTORY, $path or die; # Abre la carpeta $path

# Recorre $path y deja en $file cada nombre de archivo

while ($file = readdir(DIRECTORY))
{
if ( -d $path.$file ){# $file es un directorio}
else # $file es un archivo
{
$filemd5 = file_md5_hex($path.$file); # Calcula el MD5 de $file

if ($filemd5 eq $fileinmd5) # Si los MD5 coinciden, premio
{
print "\n";
print "Cuidadito, $path$file tiene el mismo MD5 que $filein.\n";
$c++;
}
}
}
}

todo();

------- fin drivers-sospechosos.pl ---------------------------------------------

Este proceso normalmente tarda un buen rato, así que podeis ir a preparar un café y esperar a que a la vuelta no haya premio.

Asegurando a Apache2

2009-01-16T22:52:00.008+01:00

Llevo poco tiempo con Apache2 en Debian etch (la versión estable actual) y lo que me interesa es realizar un sitio web con comunicación cifrada (OpenSSL) y que tenga algún directorio privado protegido con nombre de usuario y contraseña.

La instalación y configuración de Apache2 con soporte de OpenSSL no da problemas en Debian etch, pero el tema de la autenticación del directorio privado me hizo dar más vueltas.

La documentación de Apache2 ofrece un sistema de autenticación simple que requiere un archivo con los nombres de los usuarios para autenticarlos, pero, ¿quien quiere crear un archivo con usuarios cuando ya tenemos usuarios locales? De la misma forma, utilizar el soporte de autenticación con MySQL (auth_MySQL) supone trabajo extra, aunque es más eficiente si tenemos que autenticar a una montaña de usuarios.

Al final llegué al sistema de autenticación PAM. PAM tiene bastantes implementaciones para autenticar incluyendo a Apache2 y permite autenticar a los usuarios locales que queramos, utilizando un grupo para ello. No obstante, una vez instalado el módulo de PAM para Apache2, hay que realizar una serie de ajustes en el sistema para que funcione.

He documentado todo el proceso aquí, para tenerlo como referencia.

La persistencia del adware

2009-01-16T13:28:00.002+01:00

Fragmento extraido de http://philosecurity.org/2009/01/12/interview-with-an-adware-author

¿Puedes contarnos más sobre como hacer que el adware sea complicado de eliminar en un ordenador?

Si. Primero prefiero contarte como funciona el adware. El objetivo fundamental del adware son los usuarios de Internet Explorer porque obviamente es el más utilizado en el mercado. Además, tienden a ser los más ingenuos. Si utilizas IE quiere decir que, o no pones cuidado, o no sabes nada sobre vulnerabilidades en IE.

IE tiene un mecanismo llamado Browser Helper Object (BHO), que básicamente es un trozo de código ejecutable que consigue información de las solicitudes web que se están produciendo. Esto corre en el proceso actual del navegador, quiere decir que puede hacer cualquier cosa que pueda hacer el navegador - y esto básicamente quiere decir: cualquier cosa. Nosotros podemos tener un BHO que actualmente es el servidor de ads, y lo hemos realizado de forma que para eliminarlo tengas que eliminar todas las instancias del navegador. Esto es una pequeña parte en cuanto a la persistencia.

Si además tienes un instalador, un pequeño ejecutable, puedes crear una entrada en el Registro para que en cada reinicio el instalador compruebe que el BHO existe. Si existe, bien. Sino existe lo instala. Esto funciona hasta que alguien elimina el ejecutable.

Lo siguiente es crear un ejecutable que continuamente compruebe cada 10 segundos que el BHO está activo y en su sitio. Si así es, perfecto. Sino, el ejecutable lo instalará. Para asegurarse de que el ejecutable sea dificilmente detectable, desarrollamos un algoritmo para hacer que los nombres de estos ejecutables sean aleatorios, a la vez que estén relacionados con el ordenador anfitrión y que sea complicado descubrirlos. Creo que utilizabamos los primeros 6 u 8 caracteres de la codificación DES de la dirección MAC del ordenador. Codificas la MAC con DES, tienes en cuenta los primeros 6 u 8 caracteres y ya está. Esto está muy bien. La pega es que el archivo en sí podía ser el mismo binario. Si sumas el MD5 del archivo siempre sería el mismo, y siempre estaría en el mismo ordenador (con esa MAC).

Lo siguiente que hicimos fue una función para repartir funciones, que podía ir dentro de un ejecutable, tomando funciones y repartiéndolas aleatoriamente, de forma que las firmas de los archivos estén mezcladas. También mezclábamos un montón de punteros con cada función corriendo. Esto cambia completamente la forma del ejecutable.

Luego creamos un lanzador, que es un minúsculo trozo de código escrito en ensamblador que descifraba el ejecutable en memoria y lo ejecutaba. Al mismo tiempo también creabamos un proceso ejecutable virtual. Nunca he oído que alguien hiciera esto antes. Windows tiene una cosa llamada Create Remote Thread. Semánticamente quiere decir: eres un proceso, yo soy un proceso distinto, puedo llamarte y decirte "¡Oye! tengo este código, y me gustaría que lo ejecutaras". Tu dices "Claro" porque eres un proceso de Windows -tu eres un hippie que crees en el amor libre-. Los procesos de Windows, dicho sea de paso, son peligrosamente promíscuos. Por tanto, podemos pillar unos cuantos procesos de Windows y darles un trozo de código para que lo ejecuten. Cada proceso conoce a los dos anteriores (el anfitrión y el que le hemos dado que es el trozo de código), y de esta forma podemos hacer un anillo para que se ayuden mutuamente, ¿ok?.

Hasta ahora tenemos una entrada en el registro, un ejecutable, nombres aleatorios para ejecutables, un ejecutable que es repartido en cada ordenador, uno de ellos está cifrado -y para más ofuscación- un ejecutable que ni siquiera se ejecuta como tal. Esto se ejecuta simplemente en forma de hilos. Ahora, esos hilos pueden comunicarse entre sí, pueden comprobar que el BHO está activo, y que cualquier otro software que queramos también esté bajo control.

Hay una cosa más avanzada que empezamos a realizar pero no terminamos de probar, y es prescindir de los hilos y utilizar los manejadores de las interrupciones.Resulta que en Windows puedes acceder facilmente al manejador de interrupciones. De hecho, puedes registrar con el OS un trozo de código para manejar una interrupción dada. Todo lo que tienes que hacer es pillar una interrupción, y cuando ésta se inicie, haces tu trabajo y listo. Nunca hemos hecho esto pero es algo que estamos pensando hacer.

Creamos claves de registro y nombres de archivos que no se podían modificar, explotando una "desajuste de impedancia" entre la API de Win32 y la API de NT. Windows XP está basado en el kernel de NT. La mayor parte de NT es un sistema Unicode, y debido a ello, los strings internamente son Unicode de 16-bit. La mayor parte de la API Win32 es ASCII. Existen strings que puedes expresar como Unicode 16-bit pero no puedes expresar en ASCII. Sorprendentemente, puedes ver cosas con un Null en medio de ello.

Esto quiere decir que podemos, por ejemplo, escribir una clave de Registro que contenga un Null. Debido a que la interfaz de usuario está basada en la API Win32, éste podría ver la clave, pero no podría modificarla porque no sabría interpretar el Null. De esta forma podemos hacer que las claves del Registro sean invisibles o inmodificables para cualquiera que utilice la API Win32. Esto es muy interesante, no para la gente común, pero sí para nuestros competidores y para las compañías antivirus.

También escribí un controlador y luego un controlador de impresora. Cuando escribes un controlador puedes hacer las cosas más locas que puedas imaginar, incluso más locas todavía que pudieras hacer normalmente con Windows. Esto ocurría cuando Eliot Spitzer demandó a la compañía y empezó a decaer. Tomaron una mala decisión justo cuando empezaron a dar más visibilidad a la compañía y entonces todo el mundo al mismo tiempo me quería para deshacerse de nuestros competidores y nosotros mientras tanto trabajando en todo lo anterior.

Por supuesto que se trataba de un plan. No nos gustaba escribir un nuevo programa en C cada vez que queríamos echar a alguien fuera de una máquina. Todo el mundo decía, "Lo que necesitamos es algo configurable". Yo decía, "Instalemos un lenguaje basado totalmente en Turing", y para eso utilicé tinyScheme, que es un intérprete muy pequeño y rápido con licencia BSD que puede compilarse en un ejecutable de 20kb, si sabes lo que estas haciendo.

A veces, en vez de escribir ejecutables independientes, utilizamos un gusano, así podemos escribir código, lo ponemos en el servidor, e inmediatamente las cosas deberían oscurecerse, llegando a repartirse el código en una guerra de entre 4 y 10 millones de nodos en red.

Windows XP más rápido, rapidamente

2008-11-22T13:07:00.041+01:00

El factor crítico de la seguridad TI en un entorno de muchos usuarios radica en éstos.

Los usuarios actuales son seres humanos, y si su ordenador no va rápido, se fustran, se despistan y empiezan a ser peligrosos. Esto también se produce en el ordenador de casa, pero no es lo mismo que tu ordenador vaya lento a que te llamen todos los días 3 o 4 usuarios diciendo que su ordenador va lento.

Las causas principales de la lentitud de un ordenador con Windows XP son:

Consumo contínuo de de CPU por encima del 50%.
Consumo contínuo de RAM por encima del 75%.
Excesivo trabajo del disco duro debido a la paginación (consecuencia del punto anterior).
Excesivo trabajo del disco duro debido al poco espacio libre y la fragmentación de archivos.

Los dos primeros puntos se resuelven cambiando la CPU por otra más rápida y ampliando RAM, pero antes de eso hay una alternativa más asequible: eliminar procesos de memoria que no se utilizan. Para identificar qué procesos podemos quitar del medio y así bajar estos consumos, mirar este artículo (está enfocado al malware, y explica muy bien como identificar a los procesos para saber si los necesitamos o no).

El punto 3 se resuelve al resolver el punto 2, y el punto 4 se resuelve centrándonos en los archivos de los discos duros, principalmente donde se aloja el sistema operativo (normalmente en la unidad C:).

Archivos temporales

Windows XP tiende a guardar casi todo lo que hacemos (archivos temporales, descargas de Internet, cachés de todo tipo, etc). En un principio es una buena idea para recuperar de forma rápida un archivo que ya hemos utilizado, pero con el tiempo tiene dos inconvenientes: (1) si hay versiones nuevas del archivo, la versión guardada no sirve y (2) la acumulación de archivos temporales a largo plazo consume disco duro de forma innecesaria provocando lentitud (a la par que nos invita a comprar un disco duro más grande).

Fragmentación de archivos

En el tiempo y con el espacio limitado del disco duro, escribimos muchos archivos y eliminamos pocos (tendencia humana con el agravante de los archivos temporales), lo que provoca huecos libres cada vez más pequeños.

A medida que nos vamos quedando sin espacio, llega un punto donde se reutiliza el espacio libre de los huecos para escribir nuevos archivos. Si éstos archivos son más largos que los huecos (cosa normal), la escritura de un archivo continua en otros huecos que pueden estar en cualquier parte del disco, por tanto el archivo se fragmenta, y lo peor: se tarda más en escribirlo. La consecuencia colateral es que también se tarda más en leer un archivo muy fragmentado.

El objetivo de la desfragmentación es: localizar los fragmentos dispersos de archivos grandes, reagruparlos y escribirlos de forma contigua. Ahora, para esto se necesita el espacio libre adecuado, y es conveniente no llenar el disco duro por encima del 75% de su total.

Herramientas

Hay dos incluidas en Windows XP muy útiles para resolver el punto 4:

cleanmgr.exe, más conocido por Liberador de espacio en disco.
defrag.exe, más conocido como Desfragmentador de disco.

Al automatizar por primera vez cleanmgr.exe mediante sus argumentos (sageset y sagerun), requiere seleccionar en una ventana los grupos de archivos que queremos que sean eliminados. Estos grupos son:

Archivos de programa descargados.
Archivos temporales de Internet.
Archivos temporales de informe de errores.
Papelera de reciclaje (los archivos que contiene).
Archivos temporales.
WebClient/Archivos temporales de Publisher.
Comprimir archivos antiguos (elimina versiones comprimidas de los archivos).
Catalogar archivos para el Indizador de contenidos.

Y obviamente, para hacerlo de forma desatendida en muchos ordenadores no sirve.

Si sabemos lo que queremos eliminar y queremos evitar la ventana preguntándolo, debemos saber cómo funcionan los argumentos sageset y sagerun de cleanmgr.exe, y también debemos saber qué ocurre cuando aceptamos dicha ventana con los grupos que marcamos para eliminar.

Cada uno de estos grupos se corresponde con una carpeta de configuración en el registro de Windows, exactamente dentro de: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\VolumeCaches\:

Cuando se marca un grupo en la ventana mencionada antes y aceptamos, en el registro de Windows se crea la clave StateFlagsxxxxx con el valor 2 de tipo DWORD dentro de la carpeta que se refiere al grupo (las xxxxx las explicaremos después).

Por ejemplo, si escribimos la clave StateFlags0200 con valor 2 de tipo DWORD dentro de la carpeta Internet Cache Files del registro que hemos visto en el gráfico, se marcará el grupo de los Archivos Temporales de Internet para eliminación. Y para eliminar los Archivos Temporales de Internet que hemos marcado utilizamos el comando: cleanmgr.exe /sagerun:200.

Las xxxxx en el ejemplo es el valor 200 (puede ser cualquier otro número entre 0 y 65535) e indica la identificación de la operación entre la clave StateFlags (con el valor 2 que indica la marca) y el argumento sagerun que invoca la eliminación correspondiente.

Eliminados los archivos innecesarios, se producen numerosos huecos en el disco duro y seguramente se requiera una desfragmentación con el comando defrag.exe c:

Juntándolo todo

Todo esto puede ir en un script. Yo he realizado uno para eliminar lo siguiente:

Las carpetas temporales de instalaciones.
Los índices de contenidos del buscador de Windows.
Los archivos de programa descargados.
Los archivos temporales de Internet.
Los archivos de volcado de memoria.
Los archivos temporales de Microsoft_Event_Reporting.
Los archivos de páginas sin conexión.
Los archivos antiguos de las recuperaciones de ChkDsk.
Los archivos de la caché del Escritorio Remoto.
Los archivos logs de instalaciones.
Los archivos temporales.
Los archivos de caché WebClient y WebPublisher.

Como vemos, existen más grupos que los que indica cleanmgr.exe para marcar, lo cual hace más interesante y amplio este método.

La versión 1.0 del script está disponible aquí, y como último paso realiza una desfragmentación si es necesaria.

El caso L-A-C (3/3)

2008-08-28T11:38:00.010+02:00

El caso L-A-C (1/3)
El caso L-A-C (2/3)
El caso L-A-C (3/3)

El dominio principal en cuestión "http://l-a-c.cn" tiene la sorpresa que vimos en el primer post del caso L-A-C.

Ese pedazo de código en javascript es otro sistema de ofuscación parecido al que hemos visto en el post anterior pero más complejo y extenso. No lo voy a explicar en profundidad pero, una vez interpretado vamos a ver directamente la sorpresa que lleva dentro:

Como vemos, define la variable url con el contenido que vemos que es una URL muy peculiar. Si ponemos esa URL en el navegador, éste descarga la sorpresa final: un fichero llamado "file.exe" de 20.480 bytes.

Conclusión:

El peligro de este tipo de ataques es bastante eficiente y silencioso, debido a que si navegamos a cualquier URL que consideramos de confianza y ésta tiene agregado el código de javascript que vimos en el primer post de esta serie, automáticamente IFRAME hace el resto de forma oculta: descargar de la web maliciosa y ejecutar un fichero ejecutable con el premio.

Aunque estas webs sospechosas utilicen ofuscación en javascript, es sencillo comprobar los resultados monitorizando el tráfico entre la web y el host que realiza la monitorización.

La web en concreto todavía sigue activa, y eso quiere decir que la legislación del país donde reside el webserver (Tailandia) todavía no tiene una política madura en cuanto a perseguir el alojamiento de malware.

rAmIx

El caso L-A-C (1/3)
El caso L-A-C (2/3)
El caso L-A-C (3/3)

El caso L-A-C (2/3)

2008-08-24T22:12:00.014+02:00

El caso L-A-C (1/3)
El caso L-A-C (2/3)
El caso L-A-C (3/3)

Vamos a analizar el código javascript que genera el iframe malicioso en la web víctima y que lleva al navegador del usuario hacia la web maliciosa.

Este código primero define la función Decode() y después la invoca al final del script para decodificar la secuencia de valores decimales que contiene la variable str y construir la sentencia completa del iframe. Para seguirlo con más claridad lo he formateado de una forma más estructurada:

La función Decode comienza con la definición de las variables:

temp: para transportar valores, iniciado con un blanco
i: que no se utiliza
c: es un contador iniciado a 0
out: contendrá la cadena resultante con la sentencia del iframe completo. Esta variable se inicia con un blanco
str: contiene los valores codificados
l: contiene la longitud en bytes de str, y tampoco se utiliza

Comienza la decodificación en la línea 7 con un while que dice que mientras c sea menor o igual a la longitud total de str menos 1 (esto es 221 porque la longitud total de str son 222), iremos dando vueltas a lo siguiente.

Lo siguiente es el while de la línea 9 que aisla los números decimales de los símbolos de admiración, los deja en la variable temp, incrementa c en uno por cada posición de str y saldrá del while cuando llegue a la posición del siguiente símbolo de admiración.

La línea 10 incrementa c en uno que es la posición que tiene el símbolo de admiración.

En la línea 11 es donde realmente se produce la decodificación. Actualiza la variable out con su valor existente más el valor ASCII de temp.

Por último, cuando c se incremente hasta 222, saltará del while de la línea 7 y sacará con document.write el resultado decodificado.

En la primera vuelta, la variable str comienza con el decimal 60. El 6 del 60 es c=0 (primera posición) y el 0 del 60 es c=1 (segunda posición). Como c en la primera vuelta es 0 entra en la primera vuelta porque es menor a 221. Después entra en el while de la línea 9, y como 6 es distinto del símbolo de admiración, temp se actualiza con el valor 6 porque el valor original de temp es un blanco (blanco más 6 igual a 6), se incrementa c en uno y pasa a ser c=1. Seguimos en la línea 9 en la segunda vuelta y nos encontramos con el 0 del 60 (segunda posición de la variable str), y como no es un símbolo de admiración volvemos a meter en temp lo que tenia (6) más lo de ahora (0): se agrega el 0 al 6 y tenemos 60 en temp. Se incrementa c en uno (c=2) y nos encontramos con que en esta posición que es la tercera de str (c=2) tenemos una admiración, por tanto sale del while de la línea 9, se incrementa c en uno y mete en out el valor ASCII de 60 que es el símbolo menor que.

Así, sucesivamente, el siguiente valor decimal (105) es i, el 102 es f... hasta llegar al 62 que es un mayor que, que cierra la sentencia siguiente y que ya vimos en el post anterior:

Esta sentencia sencillamente abre la URL indicada en src en el HTML que contiene el código javascript analizado.

En el siguiente post intentaremos analizar el código javascript encontrado en el dominio principal de la URL indicada, que, como adelanté en el post anterior, provocaba un desbordamiento de buffer en el navegador con toda la pinta de un rootkit.

rAmIx

El caso L-A-C (1/3)
El caso L-A-C (2/3)
El caso L-A-C (3/3)

El caso L-A-C (1/3)

2008-08-20T14:15:00.028+02:00

El caso L-A-C (1/3)
El caso L-A-C (2/3)
El caso L-A-C (3/3)

Analizando el origen del código de un website, al final y después de la etiqueta del fin del código HTML, aparecía un trozo de javascript bastante sospechoso:

Lo que más llama la atención aquí es el contenido de la cadena str, que es una serie de números decimales separados por el símbolo de admiración. Estos números decimales deben tener una correspondencia, y lo más seguro es que sea en ASCII.

Para comprobar rápidamente esta correspondencia, utilicé la utilidad on-line JavaScript ASCII Converter de los chicos de HolyCarrot. Introduje la cadena en el campo "Enter decimal ASCII here.", le dí a "Calculate" y en el campo de arriba apareció la equivalencia en ASCII...

toda una revelación.

Como sabemos, iframe incrusta un HTML en el HTML actual.

Con la herramienta Paros Proxy intenté analizar la respuesta de "http://b.l-a-c.cn/" pero no hubo respuesta. Entonces intenté analizar la respuesta del dominio principal "http://l-a-c.cn/" y el resultado fué escalofriante:

Una obra de arte en javascript que, cargada en Internet Explorer provoca un desbordamiento de memoria: KERNEL32.LoadLibraryA. Tiene toda la pinta de un rootkit.

Veamos más información acerca de "http://l-a-c.cn/":

Domain Name: l-a-c.cn
ROID: 20080726s10001s95148405-cn
Domain Status: clientTransferProhibited
Registrant Organization: l-a-c.cn
Registrant Name: Alison Fineman
Administrative Email: ****@CHINOPOSTALPLACE.COM
Sponsoring Registrar: 厦门三五互联科技股份有限公司
Name Server:ns1.mynsnet.biz
Name Server:ns2.mynsnet.biz
Registration Date: 2008-07-26 21:50
Expiration Date: 2009-07-26 21:50

IP Address: 202.151.177.35
IP Location: Thailand
Website Status: active
Server Type: Apache/2
Cache Date: 2008-08-19 12:36:49 MST

Estos datos dicen que el host tiene la versión 2 de Apache, está en Thailandia a nombre de Alison Fineman (a saber de donde han sacado ese nombre) y lo de ****@CHINOPOSTALPLACE.COM es muy gracioso.

El registro del nombre de dominio es bastante reciente: el 26 de julio de este año.

Veamos los puertos abiertos de nuestro amigo el chino:

C:\nmap>nmap -sS 202.151.177.35

Starting Nmap 4.60 ( http://insecure.org ) at 2008-08-20 16:00 Hora estandar romance
Interesting ports on ppp-202.151.177.35.revip.proen.co.th (202.151.177.35):
Not shown: 1703 closed ports
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
25/tcp open smtp
53/tcp open domain
80/tcp open http
110/tcp open pop3
143/tcp open imap
443/tcp open https
587/tcp open submission
993/tcp open imaps
995/tcp open pop3s
3306/tcp open mysql

Nmap done: 1 IP address (1 host up) scanned in 65.218 seconds

C:\nmap>

Vamos, que tiene casi todas las ventanas bien abiertas, para dar servicio.

Viendo todo esto, sólo queda la moraleja:

Firefox y Noscript
siempre antes de salir.

Que la calle está más mala que en los 80's

Salu2.

rAmIx

El caso L-A-C (1/3)
El caso L-A-C (2/3)
El caso L-A-C (3/3)

La Cápsula Verde aterriza

2008-08-20T12:10:00.000+02:00

Estimados navegantes.

Este será un blog donde verteré información relacionada con la seguridad en las TI.

Espero resulte de vuestro agrado.

Ramiro Encinas (rAmIx).