FTP Server (modo Pasivo) detras de IPTables

Digamos que tienen un su red un servidor FTP el cual utilizaran para colocar unos archivos que otros descargaran. No pondrán este servidor FTP diréctamente de cara a Internet, sino que en el Firewall redireccionaran los puertos de FTP hacia ese servidor servidor Internet utilizando reglas NAT o PAT. Como seguro saben, FTP utiliza 2 puertos IP: el puerto 21 y el puerto 20. El puerto 21 es el puerto de control, en el que se inicia la conexión al servidor, y el puerto 20 se utiliza para la transferencia de datos. Por lo que lo primero que haríamos seria configurar nuestro IPTables para que redirija estos 2 puertos a nuestro servidor FTP interno, utilizando reglas como estas:

-A PREROUTING -p tcp -i eth0 --dport 20 -j DNAT --to-destination ftp-server-interno.23:20

-A PREROUTING -p tcp -i eth0 --dport 21 -j DNAT --to-destination ftp-server-interno:21

Y luego:

-A FORWARD -p tcp -s 0/0 -d ftp-server-interno -m multiport --dports 20,21 -j ACCEPT

Debería funcionar cierto? bueno, funcionara siempre y cuando indiquen en su cliente FTP que utilizaran FTP  en modo "activo", que es este modo que acabamos de describir. En este modo el cliente hace la solicitud de conexión al servidor al puerto 21, aquí se le indica al servidor el puerto local que el cliente utilizara para esta conexión y entonces el servidor inicia una nueva conexión hacia el cliente al puerto que este le indico. O sea que el servidor inicia una conexión hacia el cliente luego de la negociacion inicial, lo que significa que si el cliente esta detras de un Firewall la conexión no se podra lograr, y como la mayoría de Routers ADSL y Firewalls bloquean todo el trafico entrante no se permitiría esta conexion hacia el cliente. Por esto es muy probable que las reglas de mas arriba no funcionen. Aquí un pequeño gráfico del funcionamiento de este modo:

Ahora bien, para evitar que el servidor inicie una nueva conexión hacia el cliente, se creo el modo "FTP Pasivo", en este modo el servidor luego de la negociación inicial le envía el cliente un puerto aleatorio para la transferencia de datos y el cliente entonces hace la conexion a este nuevo puerto. Así se evita el problema de filtrado del lado del cliente. Este puerto aleatorio se escoge dentro del rango de puertos TCP 1024 al 65535. En el siguiente gráfico se muestra el funcionamiento de este modo:

Esto quiere decir que tenemos que crear una regla que redirija este rango de puertos a nuestro FTP interno? Por suerte no, para esto utilizamos los módulos "ip_nat_ftp"  y "ip_conntrack_ftp" junto a las reglas que definimos mas arriba. Con esto, IPTables sabra el puerto aleatorio que se negocio para la transferencia de datos y lo direccionará a nuestro FTP Server. Para habilitar este modo ejecutamos:

# modprobe ip_conntrack_ftp

# modprobe ip_nat_ftp

Para hacer esto permanente y no tener que ejecutarlo en cada reinicio o incluirlo en algun script, solo tenemos que modificar el archivo /etc/modules y agregar:

ip_conntrack_ftp

ip_nat_ftp

Con estos módulos y utilizando las reglas de IPTables que les mostre mas arriba (las 2 que crean el DNAT y la de FORWARD que permite el  trafico de estos puertos hacia nuestro FTP server) tendremos nuestro servidor FTP funcionando detrás de IPTables. Como siempre, espero que esto les haya servido de ayuda y les haya econimizado unos minutos de busqueda en Google.

Instalando/Actualizando Java RunTime via GPO

Como bien escribió Sergio de los Santos en uno de los artículos de "Una al Día" de Hispasec, "si no actualizas Java, estas infectado". Por lo que en nuestra red debemos primeramente mantener Java actualizado, y segundo minimizar su instalación, o sea, instalarlo únicamente en los equipos que estrictamente lo necesiten. En muchos casos no sera necesario tener esta aplicacion instalada, pero seguro habrán algunos casos que lo necesiten. Para seas computadoras en las que es necesario tenerlo instalado podemos crear una Política de Grupo o "GPO" que se encargue de realizar la instalación y que solo se aplique a estos equipos. Cuando salga una actualizacion de Java, solo tenemos que actualizar nuestra GPO con el nuevo paquete de instalación. Y esa es la idea de este Post, aquí veremos como crear la política y como aplicarla a un grupo especifico de computadoras.

Como seguro saben, para instalar un programa mediante una GPO necesitamos tener la instalación de este en un paquete ".MSI". Pero cuando vamos a la pagina de Java (en este link) para descargar la ultima versión, vemos que lo que nos ofrecen es un archivo ".EXE" de instalación. Por ejemplo, a la fecha de este post la versión mas reciente (de la rama 6) es la 6 Update 33, el archivo que se descarga se llama "jre.6u33-windows.exe". Lo bueno es que este archivo trae empaquetado la instalación del programa y un instalador en formato de Windows Installer (.MSI), y al hacer doble clic encima de este descomprime estos archivos en una carpeta temporal y luego ejecuta desde ahi el instalador. Para crear nuestra política de grupo  solo tenemos que copiar estos archivos una vez han sido descomprimidos a una carpeta compartida a la cual las computadoras a las que se les aplicara la GPO tengan acceso. En Windows 7 estos archivos se descomprimen en la ruta "C:\Users\nombre-de-usuario\AppData\LocalLow\Sun\Java\". Al hacer doble clic encima el ejecutable que descargamos se abrirá la ventana de bienvenida siguiente, en ese momento podemos ir a la carpeta que les mencione y encontraremos la carpeta con los archivos necesarios:

Al entrar a esta carpeta verán que se encuentran 2 archivos: un archivo de instalación "jre1.6.0_33.msi" y un archivo conteniendo los demás archivos necesarios llamado "Data1.cab". Copiaremos entonces la carpeta llamada "jre1.6.0_33", para el caso de la versión que estamos trabajando en este ejemplo, y la compartiremos en la red. Ya teniendo los archivos de instalación necesarios pasamos entonces a crear la GPO.

Para la creación de la GPO, en Windows 2008 abrimos la consola "Group Policy Management" y hacemos clic derecho encima del OU donde se encuentren las computadoras a las cuales aplicara la política. Se podría también crear la GPO a nivel del Dominio y luego configurar un filtro para que solo se aplique a un grupo especifico de Computadoras, de esta manera se podría aplicar la política a computadoras de diferentes OU. Para este ejemplo, crearemos un grupo llamado "Java_Computers" y haremos miembro de este grupo las computadoras a las que aplicaremos la política. La carpeta compartida que contiene el archivo "MSI" debe permitir el acceso a este grupo,  claro esta también los archivos dentro de esta. En este ejemplo crearemos la política a nivel de todo el dominio y mas adelante filtraremos en base al grupo "Java_Computers". Al hacer clic derecho encima del dominio, seleccionamos la opción "Create a GPO in this domain, and Link it here..." como se muestra a continuación:

Llamaremos a esta política "JavaInstall", haremos entonces clic derecho encima de nuestra nueva política y seleccionamos "Edit". En la ventana de edicion de la politica nos movemos a "Computer Configuration --> Policies --> Software Settings" y en "Software Installation" hacemos clic derecho, nos ponemos encima de "New" y hacemos clic en "Package":

Se abrirá entonces una ventana donde tenemos que indicar donde se encuentra el paquete de instalación a utilizar en esta Política, asi que escribiremos en la sección "File Name" la ruta completa al archivo que compartimos en la red. En el caso de este este ejemplo, los archivos de instalación se encuentran en "\\VBOXSRV\APPS\jre1.6.0_33\jre1.6.0_33.msi". Una vez hemos escrito la ruta hacemos clic en "Open"

Luego seleccionamos "Assigned" en la ventana de dialogo que aparecerá a continuación y hacemos clic en "OK", al concluir esta parte se vera entonces la política de instalación de software de esta manera:

Aquí podemos cerrar esta ventana y con esto hemos creado la GPO, ahora como la aplicamos al dominio, filtraremos ahora la Política para que solo se aplique a las computadoras que pertenezcan al grupo "Java_Computers". Para esto, en la consola "Group Policy Management", haremos clic encima de la política que acabamos de crear (JavaInstall), en haremos clic en el tab "Delegation", aquí entonces haremos clic en "Advanced", como se muestra a continuación:

En esta ventana se nos mostrara los permisos de la Política que hemos creado, eliminaremos el grupo "Authenticated Users" y agregaremos el grupo "Java_Computers" haciendo clic en "Add". Luego, estando encima de "Java_Computers" seleccionaremos "Allow" en la seccion "Apply group policy". De esta manera, solo las computadoras que pertenezcan a este grupo aplicaran esta política.

Hacemos clic en "OK" y cerramos la consola "Group Policy Management". Con esto ya hemos creado nuestra política y se aplicara a las computadoras que especificamos. Deben tener en cuenta que una vez hayan agregado la cuenta del dominio de las computadoras al grupo "Java_Computers" deben reiniciarlas para que se aplique su membresia al grupo. Otra cosa a tener en cuenta son los permisos de acceso a la carpeta donde se encuentre la instalación de Java, ya que la computadora debe poder acceder a estos archivos para iniciar la instalación, recuerden que no es el permiso del usuario, ya que la instalación iniciara antes de que se inserten las credenciales del usuario en el sistema, sino la cuenta de la computadora la que debe tener acceso al Share. En caso de que la instalación no se ejecute, pueden dirigirse al "Security Log" en Windows Events y revisar los errores, generalmente los errores son de acceso a los archivos de instalación.

Leer Conversaciones Guardadas de Skype con SQLiteBrowser

En estos días se ha estado hablando de Skype en la red debido a la publicación de su código fuente y también a un problema que causaba que mensajes llegaran a personas que nisiquiera estaban en la lista de contactos. Así que quise aprovechar para hablarles de algo que encontré hace un tiempo mientras revisaba los archivos de datos de Skype, por simple curiosidad. Y es que el historial de conversaciónes o chat y otras informaciónes (como la lista de contactos) del usuario son almacenadas en un archivo de base de datos, y lo mejor, no esta encriptado ni nada parecido. Y todavía mejor, por default Skype almacena un historial de todas las conversaciónes, a menos claro que le digamos lo contrario, cosa que por lo que he visto muy poca gente hace.

En Windows 7, los archivos de datos de Skype se almacenan en la dirección "C:\Users\nombre-de-usuario-de-windows\AppData\Roaming\Skype\", dentro de esta carpeta encontraremos una o varias carpetas con los nombres de usuarios de Skype que se hayan logeado en esa computadora, en la que encontraremos estos archivos:

Como pueden ver en el gráfico anterior esta señalado el archivo "main.db", este es el archivo que contiene el historial de chat, los contactos, etc. Aquí es entonces donde utilizaremos el programa "SQLite Database Browser" que pueden descargar desde este link. Verán que es bastante sencillo de utilizar, solo hacen doble clic encima del ejecutable, luego hacen clic en "File--> Open Database" y buscamos el archivo "main.db" en la ruta mencionada anteriormente o donde lo hayamos copiado. Al abrir nuestro archivo lo primero que veremos sera la estructura de la base de datos, como se ve a continuación:

En esta ventana seleccionamos el tab "Browse Data", y luego en la sección "Table" seleccionamos la tabla "Messages". Esta tabla es la que contiene el historia de Chat del usuario. Como verán, aquí aparecen las demás tablas que también pueden contener información interesante. En este caso seleccionaremos "Messages":

Esta tabla contiene muchas columnas, para ver el mensaje transmitido tendremos que movernos hacia la derecha en la ventana hasta la columna "body_xml". Lo bueno es que esta herramienta nos permite también ejecutar Queries SQL en esta base de datos, lo que nos facilitaría la lectura de los mensajes, para esto nos movemos al tab "Execute SQL", y en la sección "SQL String:" podemos escribir nuestro query y filtrar los mensajes. Las columnas mas importantes son author, from_dispname, dialog_partner y body_xml, así que podríamos ejecutar el siguiente query:

Como ven, ahora nos resultara mas cómodo leer todas las conversiones. Ahora bien, que hacer para evitar que alguien pueda leer nuestras conversaciones de esta manera? Lo primero primero seria decirle a Skype que no conserve nuestras conversaciones, esto se hace en "Tools --> Options --> Privacy" en la sección "Keep history for" seleccionamos "no history":

Otra opcion seria borrar periódicamente este log, como ven en el gráfico anterior hay un botón "clear hostory" que se encargaría de esto. En la mayoría de los casos creo que la mejor opción seria la primera, no guardar historial de conversaciónes. Así que ya saben, la próxima vez que tengan la computadora de un amigo o compañero en sus manos y este usa Skype... no sean malos y adviertanle sobre el setting para eliminar las conversaciónes :) . Bueno, espero como siempre que esta información les haya sido de utilidad (tanto como a mi :P ).

Un Poco de IPTables Parte 3: Redireccionando Logs

Siguiendo con lo que ahora se ha convertido en una serie de post de IPTables, voy a hablarles de como manejar los logs de IPTables, configurar cuales eventos que queremos escribir, agregar algún prefijo y redireccionarlos a un archivo especifico en el equipo, ya que por default los logs de IPTables se almacenan en el archivo "/var/log/kern.log". Para esto aplicaremos algunas reglas en IPTables y luego configuraremos nuestro syslog server (utilizaremos Syslog-NG) para indicar que queremos tener un archivo aparte únicamente con los log de IPTables. 

Lo primero que debemos hacer es determinar que tanto queremos que IPTables nos registre, si queremos que registre cada paquete que entre o salga a nuestra red, o si solo queremos que registre los paquetes que hayan sido "Dropeados" o descartados. La opción mas recomendable es logear todo lo que pase por nuestro Firewall, ya sea permitido o bloqueado, ya que esto nos permitirá identificar mas fácil algún problema de conexión, como auditoría en caso de que necesitemos localizar conexiones salientes o entrantes hacia algún sitio especifico o también para generar reportes de uso o ancho de banda. Hay que tener en cuenta que con esta opción nuestro archivo de log crecerá mucho mas rápido, dependiendo de la actividad de nuestra red. Para esto haremos lo siguiente: Supongamos en este ejemplo que nuestro firewall tiene 2 interfaces, la eth0 que esta conectada a Internet y la eth1esta conectada a nuestra red LAN, queremos entonces registrar todo lo que entre o salga hacia Internet, agregamos las siguientes reglas (antes de las demás reglas que hayamos definido para que se registre cada paquete antes de tomar alguna decisión sobre el mismo)

-A FORWARD -o eth0 -j LOG --log-level 7 --log-prefix IPTABLES-BANDWIDTH_OUT: 

-A FORWARD -i eth0 -j LOG --log-level 7 --log-prefix IPTABLES-BANDWIDTH_IN: 

En la primera linea le decimos a IPTables que todos los paquetes que salga desde nuestra red LAN a través de la interfase eth0 (-o eth0) le aplique la acción LOG (-j LOG), esta entrada en el log sera nivel 7 (--log-level 7) y le decimos que agregue el prefijo "IPTABLES-BANDWIDTH_OUT:" (--log-prefix), este prefijo lo utilizaremos mas adelante como filtro para enviar este tipo de eventos hacia un archivo especifico. En este prefijo pueden poner cualquier otra cosa que les haga sentido, de modo que cuando vean un evento en el log con este prefijo sepan de donde viene y como se produjo. En la segunda linea hacemos lo mismo, lo único que decimos que registro todo paquete entrante (-i) por la interface eth0, en este caso serian paquetes provenientes de Internet, y en la parte final del prefijo sustituimos OUT por IN para diferenciar los que son paquetes salientes con los entrantes.

Podemos también registrar los paquetes que han sido descartados, o que no encontraron ninguna regla que coincida permitiendo o denegando el paquete. Como les había mencionado en la entrada anterior sobre IPTables, podemos tener una acción por defecto que se aplicara a los paquetes que no coincidan con ninguna regla, por esto agregamos las siguientes reglas al final de las reglas de cada cadena, por ejemplo, al final de las reglas de INPUT, de modo que luego de que el paquete haya sido evaluado por cada y regla y no coincida, se registre este paquete antes de aplicar la regla default. Por ejemplo, supongamos que tenemos definidas varias reglas en nuestro firewall, una permitirá el trafico HTTP/S y POP3 hacia Internet desde la LAN hacia Internet, luego de estas agregaremos la siguientes reglas para logear todo lo que no se corresponda a lo que hemos definido:

-A FORWARD -p tcp -s LAN -d 0/0 --dport 80 -j ACCEPT

-A FORWARD -p tcp -s LAN -d 0/0 --dport 443 -j ACCEPT

-A FORWARD -p tcp -s LAN -d 0/0 --dport 110 -j ACCEPT

-A FORWARD -j LOG --log-level 7 --log-prefix IPTABLES-FORWARD-DROP:

-A FORWARD -j DROP

Como ven, tenemos aquí las reglas de ejemplo definidas que permiten ciertos paquetes, luego en la cuarta linea indicamos que todo lo que haya llegado a este punto sea logeado y le agregemos el prefijo "IPTABLES-FORWARD-DROP:", así reconoceremos los paquetes con este prefijo y sabremos que fueron descartados en la cadena FORWARD. Esto mismo lo podemos aplicar tambien en INPUT, OUTPUT o cualquier otra que hayamos definido. En el caso de que utilicemos las primeras reglas que registran todo el trafico entrante y saliente, es buena idea también utilizar estas ultimas, así podemos diferenciar cuales eventos corresponden a paquetes bloqueados.

Hasta ahora ya tenemos a IPTables generando logs, pero los estará creando posiblemente en el archivo "kern.log", donde se encontraran también otros tipos de eventos. Ahora veremos como separa los logs de IPTables y almacenarlos en un archivo individual con Syslog-NG.

• Configuración Syslog-NG

El archivo que crearemos para almacenar el log de IPTables lo llamaremos iptables.log y lo crearemos en /var/log. Con esta informacion, vamos al archivo "/etc/syslog-ng/syslog-ng.conf" y en la sección "#destinations" agregamos la siguiente linea:

destination d_iptables { file("/var/log/iptables.log"); };

Aquí creamos un "destino" que llame "d_iptables" y le indicamos hacia adonde apuntara, que en este caso se nuestro archivo iptables.log (tengan en cuenta que luego del corchete hay un espacio en blanco). Luego nos movemos a la sección "filters" donde crearemos un filtro que nos permitirá separar los eventos de IPTables basándonos en los prefijos que indicamos anteriormente. 

filter f_iptables { match("IPTABLES") ; }'

filter f_not-iptables { not match("IPTABLES") ; };

Aquí agregamos 2 lineas (o filtros), uno que aplicara a los eventos que contengan las palabras IPTABLES (esta palabra la agregamos en cada prefijo) y otro para los eventos que NO contengan estas palabras, el segundo lo utilizamos para evitar que los eventos de IPTables se continúen almacenando en el archivo kern.log. Nos moveremos entonces ya a la sección "log", donde buscaremos el log que define los eventos que se almacenan en el archivo "kern.log" y agregaremos el segundo filtro que creamos, se vera entonces de esta forma:

log {

         source(s_all);

         filter(f_kern);

         filter(f_not_iptables);

         destination(df_kern);

}

Luego agregaremos entonces nuestro nuevo log indicando el destino  filtro que creamos:

log {
         source(s_all);
         filter(f_iptables);
         destination(d_iptables);
}

Al agregar esto salvamos el archivo y reiniciamos el servicio (/etc/init.d/syslog-ng restart). Con esto estaremos recibiendo los eventos de IPTables en el archivo definido. Si queremos ver lo que esta pasando entonces por nuestra red (en caso de que hayan configurado la primera opción de logs) o como va creciendo el archivo de log, podemos ejecutar:

# tail -f /var/log/iptables.log

Para ver solo los que estén siendo descartados por IPTables podemos agregar :

# tail -f /var/log/iptables.log | grep DROP

Bien, hasta aquí mi pequeño tip de IPTables, como siempre, espero que esto les sea de utilidad.

Un Poco de IPTables (Parte 1)
Un Poco de IPtables (Parte 2)

Tratando de Analizar (superficialmente) un Malware

Antes que nada quiero aclarar que no me refiero a un análisis profundo de un malware, a lo que me refiero es a ver las actividades que realiza, adonde intenta conectarse y que modifica en el sistema, a fin de que podamos tomar medidas para evitar la infección y facilitar la desinfección en caso de que uno de nuestros usuarios haya decidido ejecutar el malware antes de llamarnos, como usualmente pasa. Usare algunas herramientas, tanto locales como online, que nos ayudan a conocer un poco las intensiones del malware en cuestión y como intenta hacer la infección del equipo que lo ejecute. Teniendo esto claro, podemos continuar :) . En estos días recibí un correo SPAM que decía venir de un scanner HP, y como es normal en este tipo de mensajes traía consigo un archivo anexo ZIP, la diferencia con los que generalmente llegan es que este en lugar de contener un ejecutable contenía un archivo HTML, a continuación el mensaje:

El archivo anexo se veía así al abrirlo con WinRAR:

Lo primero que hice fue crear una regla en el mail server para bloquear este mensaje especifico (por "subject", por "from", etc.) para tratar de evitar que llegue a otros usuarios. Luego subí mi  maquina virtual con XP que tengo como conejillo de indias. Configure la red de la maquina virtual (que en lo adelante llamare "la víctima") en modo "Bridge", la configure en el mismo rango IP de mi computadora host. La IP de mi maquina virtual sera 192.168.137.2 y la del host es 192.168.137.1, se necesita que tengan conexion entre si para poder utilizar el equipo host como proxy para la maquina virtual (como se vera mas adelante). Luego abrí con "notepad" el archivo  para ver el contenido sin ejecutarlo:

No se mucho de programación o html, pero no hace falta ser un experto para darse cuenta que esta pagina ejecuta un script y que esta aparentemente codificado. Haciendo una breve búsqueda en Google con la primera linea de este script encontre este enlace a Pastebin, de donde aparentemente viene el código. Luego encontré también este site que permite decodificarlo. Bueno, es hora entonces de verlo en acción, hice doble clic en el archivo HTML para que se ejecutara en mi maquina virtual, abrió con Internet Explorer 6 (que es el que tengo en mi maquina para pruebas) y presento el siguiente mensaje:

El navegador me indica que este archivo esta intentando ejecutar cierto tipo de contenido que esta bloqueado, y que si quiero habilitarlo debo hacer clic en OK, hacer clic en la franja amarilla y seleccionar "Allow Bloked Content". Es posible que esta advertencia evite que algunos usuarios ejecuten este script, pero es seguro que la mayoría dará clic sin leer en "OK" y luego ejecutaran el código. Como mi intención es probar el script procedí a permitir que este se ejecutara, lo que hizo que el navegador me diera otra alerta mas sobre el contenido:

Cualquiera pensaría que con tantas alertas los usuarios no ejecutarian este tipo de código, pero como todos sabemos los usuarios aman los botones "YES" y ciegamente hacen clic sobre ellos, así que muchos usuarios volaran esta advertencia y ejecutaran el código, que es lo que hice para esta prueba. Al hacer clic en "Yes" e ignorar la advertencia me devolvió el siguiente error:

Si se fijan en la barra de estado del navegador, vemos que aunque se presenta el mensaje diciendo que se aborto la operación, Internet Explorer esta abriendo una pagina en un dominio de Rusia al puerto 8080 de ese servidor. En ese momento ejecute en una ventana de comandos el comando "netstat -na" para ver las conexiones que estaba haciendo mi maquina "víctima" hacia afuera:

Ahora necesitamos ver la conversación entre ese servidor y nuestra PC víctima, para esto configuraremos Internet Explorer en la maquina virtual para que utilice un proxy que correremos en el equipo Host, asi capturaremos los "Request" hacia el servidor en Internet y tambien las respuestas de este. Podríamos utilizar también un sniffer como Wireshark en nuestro Host y capturar todo el trafico entrante y saliente a nuestra maquina virtual, pero en este caso con el proxy es suficiente (y mas facil).

• Monitoreando las conexiones a Internet con Burp Suite Free

"Burp Suite"es un proxy que permite entre otras cosas el ver las peticiones y respuestas a Web servers, podemos también modificarlas on line. Pueden descargarlo de este link. Esta hecho en Java, por lo cual requeriran tener instalado el RunTime. Una vez lo hayan descargado, lo ejecutan y se mueven al tab "proxy", y aquí al tab "options". En este tab le indicamos en que interface y en que puerto escuchara las peticiones, debe verse de esta manera:

Deben quitar la selección de la opción "Listen on loopback interface only" para que el programa escuche en todas las interfaces, en mi caso elegi el puerto 8080. En esta misma ventana deben también seleccionar la opción "intercept if" debajo de la sección "intercept server responses", para poder capturar también las respuestas de los servidores Web. Ya teniendo el proxy preparado para capturar, configuramos el navegador en nuestra maquina virtual para que lo utilice, en el caso de mi maquina virtual utilizo Internet Explorer 6 (lo se, un poco viejo, pero esa es la idea). Por si no saben como hacerlo, abren el Internet Explorer, luego hacen clic en Tools--> Internet Options --> Connections --> Lan Settings. En el caso de mi configuracion se veria de esta forma:

Ahora, volvemos a ejecutar de nuevo el archivo HTML y esperamos a recibir la solicitud de conexion al proxy en nuestro equipo. Cada conexion (http o https) que intente hacer nuestro equipo virtual a Internet pasara por Burp donde podremos revisar cada solicitud antes de aprobar que salga a su destino, en este caso el dominio ".ru".  Al ejecutar el archivo podemos ver la primera solicitud que hace:

Como vemos hemos capturado la primera solicitud la hace al sitio "http://uzindexation.ru:8080" y esta solicitando la pagina "/forum/showthread.php?page...". Para que esta solicitud pueda llegar al servidor debemos dar clic en esta ventana en el boton "Forward", y esperamos entonces por la respuesta del servidor, que llegara en unos segundos y verán algo como lo siguiente:

El servidor responde con otro script, aparentemente también codifcado. Podemos copiar todo este código, guardarlo en un documento html y subirlo a este site que les mencione al principio, aqui podemos decodificarlo y ver que es lo que esta transfiriéndole ese servidor a nuestro equipo. Pero para seguir observando el Malware, hacemos clic en "Forward" en esta ventana para permitir que este paquete llegue a nuestra maquina virtual. Al hacer esto veremos pronto otra solicitud que hace la maquina al servidor del atacante:

Ahora nuestro equipo víctima hace otra solicitud al servidor "malicioso", solicita la ejecución de un archivo PHP (/forum/data/ap2.php), hacemos clic nuevamente en "Forward" para permitir esta solicitud y esperar la respuesta del servidor. Como se puede ver en los headers, en esta ocasión el servidor le envía a la maquina víctima un archivo PDF, es muy posible que sea un archivo "especialmente manipulado" que explote alguna vulnerabilidad en Acrobat Reader y se use para descargar/ejecutar codigo malicioso en el equipo víctima y continuar la infección del equipo. La ventaja de usar un proxy en el medio de la conexion entre la víctima y el atacante es que podemos facilmente reconstruir el archivo que envía el servidor y salvarlo en nuestro equipo. Para esto solo tenemos que hacer clic derecho en el cuerpo del reply del servidor, como se ve en el gráfico siguiente, y seleccionar "copy to file" e indicarle donde queremos guardar el archivo y con que nombre. En mi caso, lo nombre "pdf-bad.pdf".

• Analizando el Archivo en Virus Total

Teniendo ya grabado nuestro PDF de dudosa reputación, podemos subirlo a Virus Total para analizarlo contra los motores de las principales casas antivirus. Por si no lo conocían, VirusTotal es un servicio gratuito que permite analizar tanto archivos como direcciones Web y como les dije los analiza con las versiones actuales de los principales motores antivirus. Es muy utilizada tanto para comprobar archivos sospechosos como nuestro PDF, como para comprobar que tan detectable seria ante los antivirus un ejecutable que hayamos creado. Como verán el PDF es detectado en 6 de los 42 motores antivirus contra los que VirusTotal lo evaluó, lo cual nos confirma que este PDF se trae algo entre manos, y que aparentemente es una explota alguna vulnerabilidad reciente ya que pocos motores antivirus lo reconocen (a la fecha en que hice la evaluacion), como se ve en el siguiente gráfico:

Hasta ahora sabemos que el archivo HTML que llego por correo contiene un script (codificado) que envía al navegador a un sitio web desde donde se ejecuta un archivo PHP que descarga a la maquina víctima un archivo PDF especialmente modificado que aparentemente explota una vulnerabilidad en Acrobat Reader. La versión que tengo instalada en la maquina virtual es la version 9.3 y esta es evidentemente vulnerable al exploit que contiene este PDF, ya que al permitir que llegue a la maquina victima, Internet Explorer llama a Acrobat Reader para abrir el archivo malicioso y al ejecutarlo (en background) realizara esta otra petición:

Aquí la maquina víctima solicita otra pagina PHP, a lo que el servidor responde con el archivo que se ve en el gráfico siguiente. Nuestro amigo en Rusia envía a nuestra victima un archivo ejecutable (contacts.exe), el nombre de este archivo varía, en otras ocasiones el servidor enviar "calc.exe". Al igual que hicimos con el archivo PDF, podemos copiar todo este contenido, guardarlo en un archivo en nuestra computadora, y subirlo a VirusTotal para ver como lo reconocen los motores antivirus.

Al momento en que subí este ejecutable a Virus Total, solo era reconocido por 4 casas antivirus, lo que quiere decir que es muy probable que si uno de los usuarios lo hubiese ejecutado, el antivirus no lo hubiese detectado. A esta altura ya tenemos el archivo ejecutable que se descarga del servidor del atacante, ahora queremos saber que como se comportaria este ejecutable, una forma seria usando la misma descripción que dan las casa antivirus que lo detectan, pero en el caso de este ejecutable las pocas que lo detectan lo describen de forma genérica. A continuacion veremos una forma sencilla de saber las actividades que realizaria este ejecutable en nuestro equipo sin tener que ejecutarlo nosotros.

• Utilizando un Sandbox para analizar el Ejecutable

En esta parte utilizaremos el site GFI Threat Track, este sitio nos permite subir una muestra de un archivo para su análisis, luego nos envían un elegante reporte con todas las actividades que realiza el archivo que subimos, los archivos que crea, las conexiones que intenta hacer y hacia adonde, las claves del registro que modifica, etc., lo que nos economiza tener que seguirle nosotros mismo el rastro a este malware en el equipo virtual de prueba que tenemos, y lo mejor, el servicio es gratuito! Luego de unos minutos de haber subido el archivo, recibiremos un correo con el reporte anexo de todas las actividades que detectaron realiza nuestro archivo, el reporte es bien detallado y tiene varias paginas, nos servirá de ayuda para detectar este malware en otros equipos posiblemente infectados y evitar la infección de otros. En el siguiente gráfico se muestran algunas partes del reporte, porque como les dije tiene varias paginas. En esta gráfica se muestra en resumen algunas de las actividades que realiza este ejecutable:

Como pueden ver, nuestro amigo crea archivo ocultos, crea mutaciones de el mismo y borra el archivo original que descarga, hace conexiones de red, etc. Mas adelante en el reporte veremos los archivos que crea o modifica este ejecutable, las claves del registro modificadas y hacia adonde intenta conectarse, lo cual nos servirá para bloquear esta IP en nuestro Firewall:

Resumiendo, podemos decir que el atacante envía masivamente correos con un archivo HTML comprimido en un ZIP haciendo creer que el mismo es enviado por un Scanner en la red. El archivo HTML posee un script camuflajeado que solicita la descarga de un archivo PDF manipulado que explota cierta vulnerabilidad en Acrobat Reader (aparentemente en la versión 9.3), el codigo que se ejecuta tras explotar la vulnerabilidad descarga y ejecuta un archivo "EXE". Una vez este archivo se ejecuta, periódicamente nuestro equipo infectado envia informacion hacia varios servidores (intenta varios servidores en caso de que no pueda conectarse al primero de donde descargo el malware). La información que transmite el equipo infectado es aparentemente encriptada. Bueno, los mas avanzados dirán que esto no es nada nuevo, que es la forma tradicional en la que trabajan los malwares hoy en día, eso es cierto, pero creo que es interesante que nosotros mismos podamos ver por lo menos por arriba como se realizan estas actividades. 

A continuación algunas recomendaciones que entiendo nos pueden ayudar a evitar que este tipo de malware infecte a nuestros usuarios:

1. Educar a los usuarios para que reconozcan este tipo de amenazas y entiendan el riesgo que estos traen consigo, enseñarlos a no abrir o ejecutar ningún archivo anexo que venga en un correo no solicitado o que no reconozcan la dirección o el remitente, y claro, a contenerse las ganas de hacer clic en todos los "OK" que se les presenten.
2. Mantener los sistemas operativos y aplicaciones actualizadas, el PDF que descarga el archivo HTML no ejecuta el código que descarga el ejecutable si se abre con versiones recientes de Acrobat Reader.
3. Filtrar el trafico de salida lo mas que se pueda, en el caso de este malware, intenta hacer conexiones a un puerto no standar (8080), muy pocas aplicaciones que utilicemos utilizaran este puerto, para las que lo usen podemos permitirlo, pero para la mayoría del trafico solo se debería permitir la conexion a traves de proxy y a los puertos standar (80 para HTTP y 443 para HTTPS).
4. Restringir en lo posible el acceso a Internet de los usuarios, en el caso de que un usuario reciba y ejecute un archivo como este, si solo tiene permiso a navegar en ciertos sitios, este malware no se ejecutaria ya que no podría descargar ni el PDF ni el Ejecutable.
5. Por ultimo tener un antivirus y mantenerlo actualizado, tanto en los clientes como en nuestro servidor de correo. Lo dejo de ultimo porque como pudimos ver en este ejemplo muy pocos antivirus (solo 4 de 42) pudieron detectar el archivo malicioso, por lo que no podemos apostar toda la seguridad de nuestro sistema a los antivirus.

Bueno, espero como siempre que esto les haya parecido interesante y sobre todo que les haya servido de ayuda.

Hasta el Próximo!

Convertir una Presentacion de PowerPoint en ScreenSaver

Recientemente he estado trabajando en unos tips de seguridad para los usuarios en la compañía donde trabajo, como parte de un pequeño programa de "Security Awareness". La presentación es corta y básicamente incluye unos consejos sobre como manejar el correo de una forma segura y tener precaución a la hora de recibir correos, especialmente correos que contengan archivos anexos. El caso es que aparte de la presentación, pensé también en crearles un Screen Saver con los mismos tips para que cada 5 o 10 minutos de inactividad la computadora empiece a mostrárselos, y ver si así (aunque sea de manera subconsciente) asimilen y apliquen algunos de estos tips, por lo que empecé a buscar la forma de convertir mi presentación (con unas cuantas modificaciones para que se vea un poco animada) en Screen Saver, o ".scr". La primera opción que se me ocurrio fue utilizar el Screen Saver que trae Windows por defecto (My Pictures Slideshow) que te permite utilizar fotos que tengas en una carpeta. Para esto es necesario primero guardar todos los Slides de tu presentación como archivos JPG, esto se hace de la siguiente manera:

1. En PowerPoint, hacemos clic en "Save as"
2. Elegimos la opción "Other Formats"
3. Seleccionamos entonces "JPGE File Interchange Format (*.jpg)
4. Luego seleccionamos "Every Slide" y seleccionamos la carpeta donde guardaremos los slides

Luego, tomamos esos esos JPG's y los copiamos a una carpeta compartida en la red a la cual los usuarios que queremos que tengan este screen saver deben tener acceso (solo de lectura). Si la computadora tiene Windows XP, nos vamos a la sección de Screen Savers y seleccionamos el screen saver llamado "My Pictures Slideshow" y hacemos clic en "Settings", aquí nos saldrán las opciones como el tiempo en que las fotos cambiaran, el tamaño entre otras, haremos clic en el botón "Browse" y nos moveremos al icono "My Network Places" y buscamos el equipo que contiene la carpeta compartida con los JPG que grabamos de nuestro PPT y  hacemos clic en OK. Con esto ya tenemos un Screen Saver con los datos de la presentación.

Pero este método, aunque es sencillo, tiene un par de inconvenientes. Lo primero es que se pierde cualquier animación que hayamos incluido en la presentación, como efectos en las letras o algún sonido que contenga la presentación, lo que puede tornar nuestro screen saver un poco aburrido (que de hecho seguro que lo sera para la mayoría de los usuarios) Tambien tiene el inconveniente de que hay que configurarlo usuario por usuario, porque este screen saver no tiene una forma de configurarlo via una GPO por ejemplo (al menos, yo no encontré la forma, quizás a se pueda a traves del registro). La mejor forma para mi es usar un programa que haga la conversión de PPT a SCR porque asi traerá las animaciones y sera mas fácil copiarle el archivo a las computadoras e indicar por GPO que usen ese screen saver. Luego de una larga búsqueda en Google, donde encontré muchisimos programas que lo hacen, la gran mayoría requería licencia y los que me daban el Demo entonces incluían una marca al Screen Saver, encontré uno sencillo y lo mejor, no me incluía ninguna marca o limitaba la presentación, llamado "Presentation to Screen Saver Converter for PowerPoint 1.0" que pueden descargarlo (o comprarlo) desde este link. 

El programa es bastante sencillo, solo hay le decimos donde esta nuestra presentación, agregamos algún archivos de audio si queremos, y le indicamos donde queremos guardar nuestro nuevo screen saver y listo. A continuación un "print screen" de la ventana del programa:

Una vez hemos incluido estos datos hacemos clic en "Convert" y ya tendremos nuestro Screen Saver con los efectos y animaciones que hayamos incluido en nuestra presentación y podemos distribuirlo.

Estudiando para el Examen 70-648: Un poco de IPv6

Como el titulo de este post dice, me encuentro estudiando para el examen de Microsoft 70-648, este examen es para migrar la certificación MCSA de Windows Server 2003 a Windows Server 2008, ahora llamados "Microsoft Certified Techology Specialist", ya que cambiaron el nombre de las certificaciones. Como ya soy MCSA en Server 2003 el tomar este examen me economiza 2 exámenes para certificarme como  "MCITP: Server Administrator", el 70-640 y el 70-642, y solo me faltaría tomar el 70-646. Si quieren mas información sobre esta certificación pueden visitar este sitio. Bueno, el caso es que compre el libro de preparación para este examen y ya empece a leerlo. Hay muchas cosas que permanecen igual que en Windows Server 2003, pero también hay cosas nuevas y mejoradas, como se ira viendo mas adelante. Decidí entonces ir haciendo un resumen de cada lección del libro, esto me ayuda a mi a retener mejor cada lección (ya que encuentro que escribirlas me ayuda a aprender mas fácil mas que solo leer), y también les sirve a cualquiera de ustedes que también este pensando en tomar este examen, o que simplemente quieran refrescar cosas que ya saben.

La primera lección es sobre configuración de IPv4 e IPv6, pero no se habla mucho sobre IPv4, ya que se da por sentado es que algo que un MCSA debe manejar, cosas como las clases de IPv4, Subneting, VLSM y direcciones APIPA. Hace mas hincapié en la configuración de IPv6 y eso es lo que haré en este post. Esto no sera una explicacion completa del protocolo IPv6, solo sera un resumen de lo que es necesario saber para configurar IPv6 en Windows Server 2008.

• Porque  necesitamos IPv6?

Los bloques de direcciones IPv4 publicas se están acabando, gracias a NAT se ha podido extender la vida del protocolo IP versión 4 que todos conocemos pero ya se están agotando las direcciones IPv4 publicas y la migración a IPv6 cada dia se hace mas necesaria. Como saben IPv4 ofrece aproximadamente 4.3 billones de direcciones, ese era un numero grande hace unos años atrás, pero hoy día no son suficientes ya que una sola persona puede tener varios dispositivos conectados a Internet y cada dispositivo necesitara una IP para salir a Internet. Este es el principal problema (diria yo) que viene a corregir IPv6, la cantidad de direcciones IP. Dado que una dirección IPv4 es un numero de 32 bits y que cada uno de estos 32 bit solo puede tener 2 valores (1 o 0), IPv4 nos ofrece un espacio de direcciones disponibles de 2^32,  que serian unos 4,294,967,296 direcciones.  Del lado de IPv6 las direcciones están compuestas por 128 bits en lugar de 32. Siguiendo la misma lógica anterior tendríamos 2^128, lo que seria igual a 340,282,366,920,938,463,463,374,607,431,768,211,456 o mejor expresado 3.4 x 10^38 direcciones IP disponibles, lo cual parece ser  una cantidad suficiente de direcciones no creen?.

• Sintaxis de una dirección IPv6

Las direcciones IPv6 no se expresan de la manera en que expresamos las direcciones IPv4 tradicionales; los 32 bits de la dirección eran separados en 4 grupos de 8 bits (binarios) convertidos a números decimales separados por puntos, como "192.168.1.2". Ahora con IPv6 los 128 bits se dividen en 8 grupos de 16bits pero en lugar de ser expresados en forma decimal son expresados en notación Hexadecimal, de la siguiente manera:

21dc:0053:0000:0000:03ad:003f:af37:8d62

Pero esta representación puede ser simplificada eliminando los ceros (0) que encabezan cada bloque, utilizando esto la dirección anterior pudiera expresarse de la siguiente manera:

21dc:53:0:0:3ad:3f:af37:8d62

Otra forma de simplificar las direcciones IPv6 es sustituir los bloques continuos que están compuestos solo de ceros por 2 puntos seguidos, o sea. "::". Por ejemplo, en la dirección del ejemplo, el 3er y 4to bloque (de izquierda a derecha) esta compuesto solo de ceros, por lo que podemos sustituir estos 2 bloques por "::",  quedaría entonces de esta forma:

21dc:53::3ad:3f:af37:8d62 

Hay que tomar en cuenta tambien que en IPv6 la mascara de red ya no se expresa de la forma tradicional de IPv4, en forma decimal separados por puntos (255.255.255.0). Ahora se expresan siempre como se expresan con CIDR (Classless Inter-domain  Routing), con la notacion usando "Slash" ("/"), por ejemplo "/64". La antigua notación de la mascara no se utiliza en IPv6.

• Tipos de Direcciones IPv6

En IPv6 tenemos 3 tipos de direcciones, Unicast, Multicast y Anycast:

- Direcciones Unicast: Al igual que en IPv4, las direcciones Unicast son direcciones que identifican un host, solo que ahora en IPv6 no identifican un host sino una "interface". En IPv4 un equipo era identificado por una IP y en algunos casos un equipo podría tener varias direcciones IP (multihome). En IPv6 la IP identifica únicamente una interface en especifico en el Host, y esto es lo que identifican las direcciones Unicast. Estas son las direcciones IP que utilizamos mas frecuentemente en una red o en Internet. Un paquete dirigido a una dirección Unicast sera recibido solo por una interface en la red.

- Direcciones Multicast: Este tipo de direcciones también se utilizan en IPv4, identifican múltiples interfaces. Un paquete dirigido a una dirección Multicast sera recibido por varios equipos (o interfaces).

- Direcciones Anycast: Este tipo de direcciones no se encuentra en IPv4, es intrucido por IPv6. Al igual que las direcciones Multicast las direcciones Anycast indentifican varias interfaces, con la direferencia de que el paquete enviado a una de estas direcciones no sera recibida por todas las interfaces que posean esta direccion sino únicamente por la mas cercana (en terminos de routing) al origen del paquete. Es algo entre una direccion multicast y una direccion unicast ya que el paquete es recibido por una sola interface. Este tipo de coomunicacion se le llama "uno-a-uno-de-muchos" (one-to-one-of-many).

• Direcciones Unicast

Dentro de las direcciones Unicast, que como dijimos son las que se utilizan para comunicaciones uno-a-uno, tenemos 3 tipos principales de direcciones, Global, Link-Local, Site-Local y direcciones Especiales.

- Global Unicast: Las direcciones Global son las direcciones equivalentes a las direcciones publicas de IPv4, o sea que estas direcciones son ruteadas en Internet. Estas direcciones se reconocen porque el prefijo siempre es "001". Estas direcciones están formadas de la siguiente manera: Como dijimos, los 3 primeros bits de la dirección o "Format Prefix" o "FP", que siempre es "001". Los siguientes 13 bits son asignados por IANA, esto es conocido como "Top Level Aggregator" o "TLA", estos son asignados a los registers de Internet y estos a su vez los asignan a grandes proveedores de Internet o ISP. Luego siguen 8 bit que se encuentran reservados. Le siguen 24 bits contienen el "Next Level Aggregator" o "NLA", estos identifican a clientes o sitios específicos, estos permiten a los ISP crear múltiples niveles de jerarquía dentro de su red para organizar el direccionamiento y el enrutamiento. Luego siguen los 16 bit del "Site Level Aggregator" o "SLA" que se utilizan para identificar subredes dentro de una organización, también son utilizados por ISP's menores. Los últimos 64 bits identifican la interface, a estos se les llama "Extended Unique Identifier" o "EUI-64".

- Link-Local: Estas direcciones son equivalentes a las direcciones APIPA en IPv4, el limite o alcance de estas direcciones es el link local, o sea, la red interna, por lo que NO son ruteadas. Se pueden identificar por su prefijo "fe8". Esta dirección es configurada automáticamente.

- Site-Local: Estas direcciones son equivalentes a las direcciones privadas de IPv4, o sea, las direcciones que usamos a diario en redes internas como "192.168.1.0" o "10.0.0.0". El prefijo de estas direcciones es "fec0".

- Especiales: Hay 2 direcciones especiales, iguales a 2 direcciones especiales usadas tambien en IPv4, la dirección "loop-back" y la llamada dirección "no especificada" o "unspecified". La dirección de "loop-back" en IPv4 es "127.0.0.1", ahora en IPv6 es "0:0:0:0:0:0:0:1" o expresada de manera simplificada "::0". La dirección "no especificada" en IPv4 se expresa como "0/0", en IPv6 ahora se expresa "0:0:0:0:0:0:0:0" o de forma simplificada seria "::".

• Direcciones Multicast

Como decíamos al inicio, las direcciones Multicast pueden ser usadas por varias interfaces, lo que permite que un paquete sea dirigido a varios equipos o Interfaces, a diferencia de las direcciones Unicast en las que el paquete es destinado a una sola interface. Las direcciones Multicast se reconocen porque siempre empiezan con 11111111 o "ff".

Bueno, hasta aquí lo que considero mas importante del contenido de IPv6, y creo que es lo mas importante a tener en cuenta para ir adaptandonos a IPv6. Espero que les sea de utilidad, sobre todo si piensan como yo tomar el examen 70-648. Mas adelante seguiré subiendo resúmenes de los demas capitulos a medida que vaya avanzando.