sábado, 22 de noviembre de 2008

Windows XP más rápido, rapidamente

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:
  1. Consumo contínuo de de CPU por encima del 50%.
  2. Consumo contínuo de RAM por encima del 75%.
  3. Excesivo trabajo del disco duro debido a la paginación (consecuencia del punto anterior).
  4. 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:
  1. cleanmgr.exe, más conocido por Liberador de espacio en disco.
  2. 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:
  1. Archivos de programa descargados.
  2. Archivos temporales de Internet.
  3. Archivos temporales de informe de errores.
  4. Papelera de reciclaje (los archivos que contiene).
  5. Archivos temporales.
  6. WebClient/Archivos temporales de Publisher.
  7. Comprimir archivos antiguos (elimina versiones comprimidas de los archivos).
  8. 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.

jueves, 28 de agosto de 2008

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

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)

domingo, 24 de agosto de 2008

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

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)

miércoles, 20 de agosto de 2008

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

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

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).