31 enero 2010

Las empresas de energía, telecomunicaciones y transporte público dependen cada vez más de sus sistemas para realizar las operaciones del día a día. ¿Qué ocurriría si estos se vieran comprometidos?

Este jueves McAfee Inc. publicó el informe: "En el punto de mira. Las infraestructuras críticas en la era de la ciberguerra", con los resultados de un cuestionario anónimo que realizaron a 600 responsables de TI y seguridad de infraestructuras críticas de siete sectores en 14 países de todo el mundo.

El cuestionario contenía preguntas sobre sus actitudes y políticas de seguridad; el impacto de las normativas, su relación con la Administración, las medidas de seguridad concretas que emplean en sus redes y los tipos de ataques que sufren.

Más de la mitad afirmaron haber sufrido ataques a gran escala e infiltraciones en sus sistemas. Y mediante auditorías detectaron malware instalado, destinado al robo de información, espionaje de correos, etc.

El informe destaca puntos como la falta de confianza para poder hacer frente a ataques de alta envergadura, reducción de los presupuestos dedicados a la seguridad aumentando el riesgo y supuesta participación de gobiernos en algunos de estos ataques.

Imaginemos hackers subvencionados por bandas del crimen, terroristas o gobiernos, accediendo en remoto a estos sistemas para producir un caos mundial, desastres medioambientales, económicos e incluso de pérdidas humanas.

Parece que estemos en nuestro salón viendo La Jungla 4.0, pero no está tan lejos de la realidad. McAfee anunció, que el ataque que ha sufrido Google y las demás compañías, ha sido uno de los más sofisticados vistos en años. ¿Qué sucedería si el objetivo fueran las infraestructuras, como la energía, las comunicaciones o el transporte público? Quizás tengamos que ir pensando en adquirir un generador auxiliar y un radio transmisor, como tenía el hacker al que interpretaba Kevin Smith y ayudaba a Bruce Willis en la película, porque nunca se sabe lo que puede ocurrir en un futuro.

[+] McAfee: Critical Infrastructure Under Constant Cyberattack Causing Widespread Damage

[+] McAfee: En el punto de mira. Las infraestructuras críticas en la era de la ciberguerra
Leer más...

30 enero 2010

Publicadas guías de securización de Vmware vSphere


VMWare, la compañía por excelencia de software de virtualización de máquinas, así como una de las tecnológicamente punteras e innovadoras lleva tiempo apostando por los sistemas desplegados en la nube. Tanto es así, que han desarrollado el primer sistema operativo basado en Cloud Computing del sector.

Según veo en uno de los blogs de VMWare, se ha puesto a disposición pública las guías oficiales de securización de todos los componentes de la plataforma.

Dicha guía viene distribuida en diferentes documentos, dependiendo de qué parte del sistema queremos securizar: los hosts virtualizados, el Host (donde corren las máquinas virtuales), la consola de gestión, vCenter Server (y su base de datos), y VCenter Network (la infraestructura para conexiones de red de las máquinas virtuales) principalmente.

Se indican procedimientos seguros de implantación desde el momento de la instalación hasta el despliegue de las máquinas virtuales. Hay opciones específicas para el cifrado de las comunicaciones, de los contenedores de las máquinas virtuales, aislamiento de VLANs virtuales, política mínima de cortafuegos para acceder al COS (Console Operating System), etc,...

Evidentemente cada máquina virtual, además debería securizarse convenientemente dependiendo de cada sistema operativo. En varios posts, en SbD hemos indicado herramientas y procedimientos de configuración y securización de diferentes sistemas operativos, que no estaría de más tener en cuenta también para optimizar la seguridad del sistema completo.

Los documentos a los que hacía referencia deberían ser de obligada lectura para administradores de plataformas de máquinas virtuales podéis descargarlos desde aquí
Leer más...

29 enero 2010

Vuelven los Dialers

Supongo que algunos de nuestros lectores mas provectos serán capaces de mirar en perspectiva hacia atrás, en las épocas que los hombres eran hombres, programaban en C y Perl y las lineas ADSL eran solo 'algo' de lo que 'alguien' había leído en foros americanos.

En esas épocas, todo aquel que quisiera tener Internet debía buscarse un ISP (pagarlo) y luego, emplear un módem y pagar una nada despreciable cifra a Telefónica por el tiempo de la llamada. En ese tiempo, una de las amenazas que mas disgustos causaba eran los famosos 'Dialers', programas de tipo Malware que alteraban el 'acceso telefónico a redes' para que en vez de llamar a un inocente número de teléfono, la llamada se hiciera a un número con sobre-tarificación (en España, típicamente un 906).

Mucha gente se hizo de oro con ese tipo de programas (yo conozco casos). Con el advenimiento del ADSL y su popularización, ese mercado negro desapareció porque ya nadie usaba modems.

Ahora, según leo en The Register, el concepto florece de nuevo. Esta vez el target no es el teléfono convencional, es el teléfono móvil y lo que hacen estos Dialers es enviar subrepticiamente mensajes a números con sobrecostes.

Hasta donde yo sé en España se han dado casos de este tipo, tal vez no se les haya dado publicidad, pero ya conozco investigaciones por parte de las operadoras buscando troyanos para móviles.

Ignoro como funcionan Windows mobile, Iphone, BlackBerry y compañía, pero en el caso de Symbian, en sus últimas versiones no puedes instalar ninguna aplicación 'unsigned' (sin firma digital), lo que en teoría debería hacer inútiles este tipo de programas
Leer más...

28 enero 2010

Análisis de procesos en sistemas RedHat (y derivados)

Hace tiempo que no publicamos un post linuxero y para no perder la costumbre hoy vamos a publicar algo relacionado con seguridad, análisis forense y procesos en linux.

El motivo real de este post es la próxima liberación de una nueva versión de Unhide así que, aprovechando el post, presento la nueva versión en sociedad y en rigurosa exclusiva (Ríete del Ipad!!).

Voy a dividir el post en dos tipos de procesos 'los que ves' y 'los que no ves'.

Los que ves: Hace tiempo, una de las cosas con las que mas frecuencia se recurría para atacar a los sistemas Windows desde acérrimos usuarios de Linux era la enorme cantidad de procesos que te podías encontrar en un sistema Windows frente a la simpleza de un sistema Linux. Esta situación ha cambiado drásticamente, véase un ejemplo de una workstation Linux:

$ ps ax | wc -l
228

No está mal, 228 procesos que, como es lógico, resultan poco manejables para averiguar que-es-que y si son legítimos o ilegítimos. Para este menester acude en nuestra ayuda rpm que es el gestor de paquetes en sistemas RedHat, Fedora, CentOS y derivados. Rpm implementa firma digital para verificar la autoría de los paquetes y, adicionalmente, tiene una base de datos con las firmas digitales de los ficheros de cada paquete. Y eso es realmente interesante, porque con un pequeño script en Perl, podemos interrogar a cada proceso en ejecución si pertenece a algún paquete y si ha sido alterado. El script lo podéis bajar de aquí y lo que hace básicamente es lanzar ps, buscar la ruta del ejecutable mirando en /proc/pid/exe (sorprendentemente, ps no lista bien la ruta de los ejecutables en *todos* los procesos) y lo interroga con rpm -Vf.

 $ perl procv.pl

El proceso [ 2936 /usr/bin/gnome-session ] ha sufrido modificaciones en su paquete base:
S.5....T    /usr/share/gnome/default.session                                           

El proceso [ 3227 /usr/bin/python ] ha sufrido modificaciones en su paquete base:
S.5....T    /usr/lib/python2.5/distutils/sysconfig.pyc                          

El proceso [ 9977 /opt/firefox/firefox-bin ] ha sufrido modificaciones en su paquete base:
el archivo /opt/firefox/firefox-bin no es propiedad de ningún paquete

Como se puede ver, en principio nada serio, procesos en cuyos paquetes se han modificado ficheros de configuración y un proceso que no corresponde a ningún rpm. Con esto se puede tener una idea aproximada de que es lo que está corriendo en el sistema.

Lo que no ves: En este punto entran en juego los famosos rootkits, tiempo atrás ya hable de Unhide así que no me voy copy-pastear a mi mismo, solo aprovechar para presentar la versión 20100201 disponible en el repo sbd de herramientas y que espero publicar en Febrero. Esta nueva versión incorpora un buen número de mejoras en fiabilidad y rendimiento además de un nuevo tipo de escaneo empleando hilos (threads). Si alguien encuentra algo-que-no-va-bien correito, por favor

UPDATE: Juan Galiana ha publicado en su blog un port del script para que funcione en sistemas Debian (y derivados) 
Leer más...

27 enero 2010

ncrack ALPHA, fuerza bruta multiprotocolo


Hasta ahora THC-Hydra o medusa eran las herramientas más comunes para hacer ataques de fuerza bruta contra protocolos comunes. Pero con la prematura llegada de  ncrack, de los mismos autores que nmap, parece que nuevas posibilidades se abren.

Su desarrollo ha sido intensivo, ya que nace en el  Google Summer Of Code del año pasado. Pese a que actualmente es versión 0.01ALPHA, no hemos querido dejar escapar la oportunidad para ver qué pinta tiene.

Por el momento solo soporta Telnet, FTP, SSH y HTTP, muy lejos aún otras opciones como las de medusa, aunque el dinamismo del grupo de Fyodor seguramente añada nuevas características pronto.

Las opciones son amplias y parecen algo complejas, aunque después de leer tranquilamente no tiene mayor dificultad:
Ncrack 0.01ALPHA ( http://ncrack.org )
Usage: ncrack [Options] {target specification}
TARGET SPECIFICATION:
Can pass hostnames, IP addresses, networks, etc.
Ex: scanme.nmap.org, microsoft.com/24, 192.168.0.1; 10.0.0-255.1-254
-iL <inputfilename>: Input from list of hosts/networks
--exclude <host1[,host2][,host3],...>: Exclude hosts/networks
--excludefile <exclude_file>: Exclude list from file
SERVICE SPECIFICATION:
Can pass target specific services in <service>://target (standard) notation or
using -p which will be applied to all hosts in non-standard notation.
Service arguments can be specified to be host-specific, type of service-specific
(-m) or global (-g). Ex: ssh://10.0.0.10,at=10,cl=30 -m ssh:at=50 -g cd=3000
Ex2: ncrack -p ssh,ftp:3500,25 10.0.0.10 scanme.nmap.org google.com:80,ssl
-p <service-list>: services will be applied to all non-standard notation hosts
-m <service>:<options>: options will be applied to all services of this type
-g <options>: options will be applied to every service globally
Misc options:
ssl: enable SSL over this service
path <name>: used in modules like HTTP ('=' needs escaping if used)
TIMING AND PERFORMANCE:
Options which take <time> are in milliseconds, unless you append 's'
(seconds), 'm' (minutes), or 'h' (hours) to the value (e.g. 30m).
Service-specific options:
cl (min connection limit): minimum number of concurrent parallel connections
CL (max connection limit): maximum number of concurrent parallel connections
at (authentication tries): authentication attempts per connection
cd (connection delay): delay <time> between each connection initiation
cr (connection retries): caps number of service connection attempts
to (time-out): maximum cracking <time> for service, regardless of success so far
-T<0-5>: Set timing template (higher is faster)
--connection-limit <number>: threshold for total concurrent connections
AUTHENTICATION:
-U <filename>: username file
-P <filename>: password file
--passwords-first: Iterate password list for each username. Default is opposite.
OUTPUT:
-oN/-oX <file>: Output scan in normal and XML format, respectively, to the given filename.
-oA <basename>: Output in the two major formats at once
-v: Increase verbosity level (use twice or more for greater effect)
-d[level]: Set or increase debugging level (Up to 10 is meaningful)
--nsock-trace <level>: Set nsock trace level (Valid range: 0 - 10)
--log-errors: Log errors/warnings to the normal-format output file
--append-output: Append to rather than clobber specified output files
MISC:
-6: Enable IPv6 cracking
-sL or --list: only list hosts and services
--datadir <dirname>: Specify custom Ncrack data file location
-V: Print version number
-h: Print this help summary page.
Llama la atención que dentro del directorio de diccionarios (denominado lists) se encuentran los usuarios y contraseñas  más típicas de webs de las que se han filtrado, como el de myspace o phpbb.

Las opciones de tiempos aseguran que se pueda especificar la mejor configuración para cada caso particular.


También se observa que el parámetro para definir el alcance está orientado a host o rangos de IPs, como ocurre con Nmap. Esto facilitará el trabajo en auditorías y ataques masivos en Internet.

El siguiente ejemplo se muestra la salida (con un resultado positivo) de la aplicación contra un servidor SSH en el puerto 444 de la dirección 192.168.0.3:
[aramosf@sbd ncrack]$ ./ncrack  ssh://192.168.0.3:444 -U usuarios -P pass
Warning: File ./usuarios exists, but Ncrack is using usuarios for security and consistency reasons. Set NCRACKDIR=. to give priority to files in your local directory (may affect the other data files too).

Starting Ncrack 0.01ALPHA ( http://ncrack.org ) at 2010-01-26 02:50 CET
Discovered credentials for ssh on 192.168.0.3 444/tcp:
192.168.0.3 444/tcp ssh: root Gold3nC4too

Ncrack done: 1 service scanned in 30.05 seconds.

Ncrack finished.
Leer más...

26 enero 2010

Campus Party EU 2010


Imagino que casi todo el mundo conoce la mítica Campus Party que año tras año se realiza en Valencia y en la que el año pasado tuvimos el placer de colaborar en el área de Seguridad.

Este año, con motivo de la presidencia Española de la Unión Europea, se va a realizar un evento especial con carácter internacional enfocado a la innovación en el que habrá un destacado papel para la seguridad. Campus Party EU

La organización de Campus Party EU nos ofreció la posibilidad de llevar el área de seguridad y no dudamos en aceptar el reto.

Tenemos ya 'atadas' dos charlas a cargo de Stefano Di PaolaJoanna Rutkowska (esta última nos ha prometido una charla sobre un nuevo proyecto aún por liberar).

Y aquí viene la parte donde tú puedes colaborar con nosotros. Como parte de nuestra misión, tenemos que reclutar a dos personas por pais de la Unión Europea representando a su nación en el área de seguridad. Esas personas serán invitadas por parte de la organización a gastos pagados (léase alojamiento, BILLETES DE AVIÓN y manutención) y además, la idea es que esas personas participen en un reto de tipo CTF (reto hacking) donde habrá premios en metálico (2.000 euros para el ganador).

¿Como podéis colaborar con nosotros? A día de hoy nos faltan candidatos para hacer la selección en algunos países así que, si conocéis gente que sea habitante de cualquier país de la UE, le interese la seguridad y le apetezca venir a Madrid los días 14-15-16-17-18 de Abril, por favor hacerles llegar la convocatoria y que nos remitan un correo (en inglés) contando su bio a campuseu@securitybydefault.com (podéis darles este link)

¿Y que ofrecemos? Nosotros disponemos de varias invitaciones a la campus destinadas a colaboradores, de forma que si vosotros conseguís hacernos llegar candidatos, podemos integraros como colaboradores de forma que también tengáis derecho a alojamiento, manutención y en caso que no viváis en Madrid, billetes de avión / tren.

Si os animáis, correo a: campuseu@securitybydefault.com (y si, haremos miles de coñas sobre Mr Bean)
Leer más...

25 enero 2010

Identidades digitales inmanejables


Es impresionante la cantidad de sitios web que visitamos, y de empresas/organizaciones que ofrecen vía web los servicios que demandamos, ya sea como forma de vida, por trabajo, ocio, hobbies, interés particular, etc,...


Cada día nos suscribimos a nuevos foros, compramos billetes de avión, tren, reservamos hoteles, accedemos a nuestra banca online, facturas de telefonía, luz, gas,... participamos en redes sociales (como facebook, twitter, linkedin,...), gestionamos diferentes cuentas de correo (hotmail, gmail, yahoo,...), compramos y vendemos (ebay, paypal) foros varios dependiendo de si nos gustan los coches, los libros, el cine, la música,... entre otros.

Para cada sitio web, es necesario introducir unas credenciales: En algunos casos podremos elegir el nombre de usuario (siempre y cuando no exista, o tendremos que derivar uno diferente al que generalmente usamos) y una contraseña (que en algunos casos deberá seguir un formato dado por la organización para satisfacer ciertos requisitos de complejidad). A no ser que seamos felices viviendo en el campo, ajenos a una conexión a Internet, estamos obligados a tener un montón de identidades digitales o una única con un nombre de usuario lo suficientemente raro y una misma contraseña.

¿Problemas? Pues ambas posibilidades tienen sus ventajas e inconvenientes. Tener diferentes identidades (pares usuario/contraseña) permite ser uno diferente en cada sitio, de manera que no se pueda concluir mediante herramientas online o mediante análisis las costumbres (a veces contradictorias) de un mismo individuo. Así, si un sitio de los que somos usuarios se ve comprometido (o picamos ante un ataque de phising) y nuestras credenciales son expuestas, las que usamos para el resto de los servicios seguirán seguras. Mucha gente, incluso importante en el mundo de la seguridad, utilizan mecanismos de generación de credenciales basados en el nombre del sitio web o servicio que visitan. Una vez comprometido el algoritmo pensado, todas las credenciales de ese individuo, quedan expuestas.

Por lo mismo y dada la cantidad de servicios online que consumimos, lo más normal es que olvidemos aquellos que no utilizamos tan a menudo y haya que usar las opciones "Lost Password?".

En el caso de usar el mismo usuario/contraseña (siempre que se pueda) para todos los servicios, si alguien averigua nuestras credenciales (por sniffing, shoulder surfing, compromiso de uno de los websites, ingeniería social, phising, etc...) podrá probar en otros sitios que exista el mismo usuario o de otros en los que conozca nuestros hábitos.

Para evitar este tipo de disyuntivas, las empresas se gastan un dineral anualmente en lo que se llaman proyectos de gestión de identidades, single sign-on y provisioning. Para el usuario "de a pie", hay en el mercado variedad de productos, comerciales y libres (como por ejemplo KeepassX), que permiten mantener en un contenedor cifrado las diferentes identidades. Para aplicaciones web, incluso los navegadores proveen de servicios propios de auto-rellenado de usuario y contraseña.

En general, estos programas de protección de contraseñas, así como los de gestión de identidades, requieren una autenticación basada en una contraseña maestra. Lo cuál nos lleva a otro problema más, si esa contraseña maestra cae, todas las demás quedan expuestas.

Este problema se solucionaría utilizando algún tipo de autenticación fuerte como contraseña maestra, basada en al menos dos factores de estos tres: "algo que se tiene, algo que se sabe, algo que se es".

Si no es posible la autenticación fuerte, al menos:

  • Aseguraos de que cuando insertéis la contraseña maestra de vuestro gestor de credenciales no haya nadie nadie mirando. Si tapáis el PIN cuando metéis la tarjeta en el cajero automático, ¿por qué no tener ciertas precauciones en el teclado del PC?
  • Como extensión al punto anterior, que no nos miren ni desde fuera ni desde dentro del PC: mantenedlo libre de troyanos y keyloggers. Política de parches y antivirus actualizados, firewalls personales, instalar sólo aquello que estéis seguros que no contiene spyware/malware y cuidado con los rogue antivirus
  • Cerrad la sesión cuando terminéis la actividad para la que os hayáis tenido que autenticar (sobre todo para entornos de banca online, los datos son datos, pero la pasta/guita es la pasta/guita)
  • Cuidado con los enlaces sobre los que pincháis (los que veáis en foros, los que os lleguen por correo), puede llevaros a no dar vuestra contraseña, pero sí a ceder vuestra sesión por robo de cookies
  • Seguid las recomendaciones y buenas prácticas recomendadas por Laura respecto a la gestión y vida de las contraseñas
  • Cuidado con las "Preguntas secretas" para recuperar contraseñas. Extremad precauciones con respuestas demasiado triviales que puedan comprometer vuestra información de una forma trivial por quien os conoce
  • Y sobre todo y más importante, cuidado con los ataques basados en ingeniería social. Cuando hay que dar una contraseña a alguien, no fiarse siempre es la opción correcta!
Leer más...

24 enero 2010

Origen y evolución del eFraude

El término phishing aparece por primera vez en el año 96 en las newsgroups de hackers y en la edición del Magazine 2600. Este término tiene dos orígenes: 1) "Fishing" o pesca, refiriéndose a la pesca de credenciales o a la pesca de ingenuos para intentos de fraude, 2) Phishing - "Password Harvesting" que viene a significar cosecha de contraseñas.

En 1996 un phisher se hizo pasar por técnico de AOL y envió mensajes haciendo uso de la ingeniería social en los que solicitaba que el usuario verificase su cuenta o confirmase una factura y así poder solicitar las credenciales personales de la víctima. Con estos datos ya podía realizar acciones como el envío de spam. Para intentar solucionarlo, AOL incluyó como texto by default en el intercambio de mensajes: "AOL nunca le solicitará contraseñas o información de facturación".

En 2001 aparecen los primeros scam en Hotmail con el texto "Usted es uno de los 100 ganadores de Hotmail" junto con un formulario que solicitaba el usuario y la contraseña de la cuenta de la víctima. Aunque este mensaje aparecía firmado por el Staff de Hotmail, en realidad provenía de una dirección IP de Ucrania. También AOL informó de un caso similar en donde el usuario recibía un mensaje que le avisaba de un error en su registro y no podían facturarle, para evitar que se le diera de baja debería rellenar un formulario lo antes posible. Además incluía un enlace a una página para realizar la facturación de AOL. Ese mismo año se recibieron mensajes informando que un grupo de hackers había accedido a la base de datos de MSN en donde solicitaban el envío de un correo con los datos personales y la cuenta (usuario y contraseña) porque de lo contrario serían borrados de la base de datos.

En 2002 fueron los usuarios de ICQ quienes recibieron mensajes simulando la imagen de ICQ, en los que les solicitaban sus datos personales en un formulario, y mediante un script redireccionaban sus datos a una dirección de Hotmail. A finales de año Yahoo informaba que varios de sus clientes habían recibido correos donde les solicitaban los datos de sus tarjetas de crédito.

En 2003 le tocó el turno a los usuarios de EBAY quienes recibieron correos que simulaban alertas de Paypal solicitando sus datos bancarios y los números de sus tarjetas de crédito. Después aparecieron los primeros phishing a entidades de banca online como Barclays Bank, BBVA, en donde los phishers usaron técnicas para la ofuscación de URLs. También comenzaron a registrarse nombres de dominio similares a los de las entidades bancarias. A finales de año se detectaron los primeros correos dirigidos a banca online que incluían troyanos con técnicas de ocultación. Un caso fue un ataque que introducía un troyano embedido en código HTML e incluía un script en la máquina de la víctima. Ese troyano era una variante del Spy-Tofger.

Las técnicas que se usaron a partir de entonces se enfocan hacia intentos de fraude como:
  • Correos electrónicos: masivos de spam, selectivos, acompañados por ingeniería social para captar la atención de la víctima, también podían hacer uso de webspoofing o falsas páginas web, algunas venían acompañadas de malware que redirige el nombre de dominio a otra máquina (pharming). Aparece por primer vez un troyano con capacidad para capturar las pulsaciones de teclado (Keylogger)
  • Sitio web: malware que explotaba las vulnerabilidades sin parchear de los navegadores, en el sistema operativo, y una vez infectado redireccionaba a los usuarios a servidores web en donde estaban las páginas que suplantaban a las originales. También se insertaba código malicioso en HTML, frames, scripts PHP, en donde se ocultaban keyloggers, capturadores de pantalla, backdoors. Banners publicitarios para redireccionar al usuario a sitios con confiables.
  • IRC y Mensajería Instantánea: donde se enviaban imágenes, URLs, a los usuarios con contenidos maliciosos. Se enviaba SPAM y se conectaban bots para propagar los contenidos.
  • VoIP: simulación telefónica, uso de Bots-IVR que solicitaban las credenciales personales. Redirección a webspoofing, otros canales.
  • Buscadores: que proporcionaban sitios maliciosos en respuesta a las búsquedas de comercio electrónico o banca online.
  • Mensajes en foros, en redes sociales, tablones de anuncios, con mensajes con ingeniería social para captar a la víctima
  • Redes P2P, descarga de software desde páginas de descarga masiva.
  • Plataformas de juegos online, recordamos los casos de phishing que han sufrido los jugadores del World of Warcraft.
  • Falsos antivirus y antispyware, utilizando llamativos anuncios o pop-ups que avisos alarmantes que advierten al usuario que su sistema está infectado y debe comprar la solución que se le propone. Al usar su tarjeta para obtener este producto sus datos son capturados para su posterior uso fraudulento.
  • Vía teléfono móvil (SMiShing), enviando un SMS al usuario en donde se le invita a enviar su información privada o visitar un sitio web con contenidos maliciosos.
  • Botnets: que tratan de controlar un número masivo de máquinas para la captura de datos bancarios, cuentas de correo.
El objetivo de estas mafias es la búsqueda de usuarios y los datos de sus cuentas bancarias. Haciendo uso de la ingeniería social, el spam y el malware. Entrando en las redes sociales como Facebook o Twitter. Aprovechándose de mensajes con carga emocional, como por ejemplo la catástrofe en Haití, en donde ya se han detectado casos de phishing para lucrar a estas organizaciones.

Los usuarios y las entidades deben tener una actitud responsable y utilizar medidas de protección. Se debe concienciar y educar al ciudadano para estar alerta y evitar que sus datos personales y bancarios sean robados.

[+] INTECO
Leer más...

23 enero 2010

Magirus OpenHouse 2010: Open Mind, Open Cloud

Y ya que estamos de eventos, me he enterado que ya es posible inscribirse en lo que siempre se había llamado Magirus Day. El conocido mayorista, propone una exposición conjunta de los productos de los diferentes fabricantes que comercializa.

Ya desde el año pasado, cambiaron el nombre por el de Magirus OpenHouse. Sin embargo, el objetivo es el mismo, exponer lo último en cuanto a las tecnologías dedicadas a redes seguras, almacenamiento, virtualización y open source de los diferentes fabricantes que distribuye. Con "Open Mind, Open Cloud" nos da a entender que las tendencias para este año van a seguir por los mismos derroteros: la nube, la nube y la nube,.... por lo que se hará hincapié en los enfoques de todos los fabricantes invitados para este modo de ofrecer servicios.

Parece ser que el año pasado, pese a haber crisis, el balance de la experiencia fue positiva y este año repite en lugar (Hotel Puerta de América en Madrid) y en filosofía de evento. La fecha elegida es el 4 de Febrero de 9:00 a 18:00. Sí, ya sé, coincide con el 2nd Security Blogger Summit del que hablamos ayer. Sin embargo, los horarios de ambos eventos no se solapan, por lo que la asistencia a ambos eventos es completamente viable utilizando la misma camisa y corbata.

La agenda del día incluye, aparte de poder conocer de mano de los fabricantes, el modo de funcionamiento de las diferentes soluciones, un calendario de ponencias por parte de los mismos enfocadas por supuesto al Cloud Computing.

En general, el público que asiste a este tipo de eventos de fabricantes/mayoristas suele ser todo aquel relacionado con el canal de ventas: Fabricantes - Mayoristas - Integradores e incluso responsables de seguridad de clientes finales, suelen ser buenos sitios para el intercambio de tarjetas entre personas a la caza de buenas oportunidades tecnológicas. Magirus define aquí el tipo de perfil que espera que asista.

La inscripción es libre (aunque el aforo suele ser limitado así que hay que darse prisa) y la podéis realizar aquí.

Allí nos vemos!!!
Leer más...

22 enero 2010

2nd Security Blogger Summit


El año pasado os comentábamos en un post las impresiones después de acudir a la primera edición del evento Security Blogger Summit, organizado por Panda Security. Después del magnífico buen sabor de boca de la anterior y la excelencia de los ponentes (si no lo recordáis, aquí podréis ver un video resumen con las conclusiones más importantes), hoy se ha anunciado la apertura del registro para la segunda edición, llamada 2nd Security Blogger Summit, y que tendrá lugar el Jueves 4 de Febrero en Madrid, en el Circulo de Bellas Artes.

Aún no habiéndose cerrado el cartel definitivo de los ponentes, se ha publicado una primera lista de invitados, en la que nuestro compañero Yago Jesús compartirá escenario con otro buen conjunto de profesionales y expertos del sector. El tema clave será la necesidad general de concienciación de seguridad para los usuarios, mensaje que esperemos que consiga extenderse al mayor número posible de consumidores de internet.

El registro es gratuito, y para llevarlo a cabo tendréis que escribir un correo electrónico a la dirección comunicacion@pandasecurity.com, cuanto antes mejor, por si acaso. Evento recomendado que no os podéis perder si tenéis la oportunidad

Leer más...

21 enero 2010

Los Twitters de seguridad (el retorno)


Seis meses después retomamos esta entrada con actualizaciones, ya que desde que el verano pasado publicásemos la lista de twitters de seguridad sorprendentemente muchos de "los conocidos de siempre" se han abierto una cuenta en este servicio y lo hace aún más atractivo.

Una vez más insistimos en que el uso puede llegar a saturar si no sabemos seleccionar correctamente que personas seguir, siendo esta lista dinámica y configurable.

Además se añaden listas que pueden ser seguidas en su totalidad: miembros-sbd, conferencias-es, compañías-es, blogs-es, gente48bits, personas-es

Por último volver a recordar que algunos twitters también hablan de asuntos personales.

De SecurityByDefault (spam alert!):
Conferencias de habla hispana:
Compañías de habla hispana:
Blogs de habla hispana:
Gente de 48Bits (para mayores de 18 años):
Personas relacionadas con la seguridad de habla hispana:
Leer más...

20 enero 2010

Un vistazo a NetSparker de Mavituna Security


Mavituna Security es una pequeña empresa que desarrolla un producto de análisis de vulnerabilidades web llamado NetSparker  que hemos tenido la suerte de poder evaluar.

La aplicación es bastante más sencilla que sus competidores más directos, como pueden ser los productos de HP WebInspect, de IBM Appscan o incluso la ya más cercana en cuanto a prestaciones Acunetix (otras aplicaciones en Security Wizardry).

Entre sus principales características se anuncia que está libre de reportar falsos positivos, o lo que es lo mismo, identificar como vulnerabilidades peticiones que realmente no lo son. Aunque esta característica tiene truco, ya que las que no puede garantizar como vulnerables las etiqueta como "posibles", para que posteriormente el auditor haga las comprobaciones oportunas.

Los motores soportan la detección de los riesgos más comunes: Inyección SQL , XSS, inclusión local y  remota de ficheros, inyección de comandos, CRLF, archivos obsoletos, código fuente, recursos ocultos, listado de directorios, vulnerabilidades de configuración de los distintos servidores web, etc etc. Pero sin duda el que más destaca y funciona mejor es el  de inyección SQL, que además permite la ejecución de comandos y de sentencias una vez se detecta un parámetro vulnerable.

La siguiente captura muestra la vista general de la aplicación.



A la hora de lanzar un nuevo análisis se permiten seleccionar algunas opciones básicas como los módulos a utilizar, el método de autenticación o el tipo de navegación, permitiendo procesar javascript/ajax.

 

La aplicación dispone de otras opciones que permiten ajustar parámetros para la optimización del rendimiento y funcionamiento general de la herramienta



La ejecución es rápida y visualiza las apariciones según son detectadas, además de la petición HTTP y la respuesta del servidor para la verificación manual o como evidencia del hallazgo. Otra característica interesante es la posibilidad de registrar todas las llamadas (Request Monitor) que se solicitan y que permitirán un posterior análisis en caso de necesidad.

Lanzado sobre la aplicación vulnerable que proporciona HP (http://zero.webappsecurity.com), se observa en  estas  imágenes su funcionamiento:




 

Los informes de resultados se exportan con los formatos XML, PDF o RTF, su detalle técnico es aceptable, aunque únicamente categoriza las vulnerabilidades según su criticidad y se echa en falta las recomendaciones y un apartado de conclusiones ejecutivas.




El precio de NetSparker es competitivo, 600 libras (unos 687€) por una licencia para tres aplicaciones web, 1200 libras (1.374€) para un número ilimitado de aplicaciones y una versión de 9200 libras (10.538€) instalable en más de un equipo.

Finalmente mencionar que existe una metodología desarrollada por WASC que facilita la tarea de la evaluación de aplicaciones para el análisis de seguridad web  y en la cual se detallan puntos de control todos ellos útiles y ponderables.
Leer más...

19 enero 2010

Geo IPS 1.0

Una de las cosas que mas me han fascinado en los últimos años, han sido las tecnologías de Geolocalización IP que tan de moda se han puesto.

Y al hilo de esas tecnologías siempre me he preguntado como ningún fabricante de Firewalls ha implementado una evolución de las típicas reglas IP origen / IP destino con reglas basadas en procedencia geográfica.

Por ejemplo, mi servicio de acceso SSH sé positivamente que solo va a ser accedido desde Madrid y en alguna ocasión desde Zaragoza, no necesito conceder acceso a IPs chinas o americanas. Por otra parte, alguien que tenga un negocio online que sirva pedidos a España y Europa, no tiene porque exponer su site web a otros puntos geográficos tan exóticos como Camerún o Hong Kong. Además, es por todos conocido que cuando se publican top-de-países con mas incidencia de ataques, suelen ser siempre los mismos.




Al hilo de esto, he implementado un GeoIPS que extiende las capacidades nativas de Linux en cuanto a filtrado de paquetes permitiendo crear reglas por País o Ciudad. Inicialmente pensé en integrarlo en el kernel como extensión a iptables, pero he preferido hacerlo 'en modo snort' totalmente transparente al sistema operativo para facilitar su portabilidad a otros sistemas (*BSD, OpenSolaris ...) y su mantenimiento (cambios en el kernel, miles de kernels diferentes en función de la distribución ...)

El software se puede descargar del repo en Google de SbD y la guía de instalación está en el Wiki. / Warning / --> No es precisamente sencillo de instalar, se requiere algo de ninjutsu-linux para hacerlo funcionar.

En este post voy a explicar como configurarlo y como es la estructura del fichero de configuración.

El fichero de configuración se llama db.xml y con idea de, en un futuro, desarrollar helpers, está en formato XML.

Fichero de ejemplo:

<config interface="lo" ip="127.0.0.1" blockcommand="iptables -I INPUT  -j DROP -p tcp -s" unblockcommand="iptables -D INPUT  -j DROP  -p tcp -s" blocktime="25">

    <tcp name="53" mode= "deny">

      <country>Spain</country>

      <country>Mexico</country>

       <city>Zaragoza</city>

       <city>Mountain View</city>

    </tcp>

    <udp name="53" mode="deny">

      <country>Spain</country>

      <country>EEUU</country>

    </udp>

  </config>

Viendo la estructura del fichero debería ser fácil imaginar que es cada cosa; la parte inicial define la interface de red sobre la que va a escuchar GeoIPS, la IP que 'va a defender', los comandos de bloqueo y desbloqueo y el tiempo que va a durar bloqueada cada IP. De este punto, tendrás que configurar la interface de red y la IP.


Las siguientes partes son dos ejemplos de reglas geográficas para el puerto TCP/UDP 53.


Tomemos el primer ejemplo:

<tcp name="53" mode= "deny">

      <country>Spain</country>

      <country>Mexico</country>

       <city>Mountain View</city>

    </tcp>

La regla, define que vamos a filtrar el protocolo TCP, el puerto y el modo, en este caso deny. ¿Que significa Deny? Básicamente define que la regla va a permitir TODO el tráfico EXCEPTO el que venga desde Spain / Mexico (como países) y específicamente lo que venga de Mountain View como ciudad.

En contraposición a deny existe la directriz allow y es su opuesta; todo el tráfico que venga a ese puerto que NO pertenezca a Spain / Mexico (como países) o Mountain View como ciudad, será bloqueado.


El formato para puertos udp es idéntico a tcp.


Jugando con las reglas puedes definir cosas como:


'A nivel HTTP, permito todo MENOS lo que venga de Rusia y China'


'Para el ssh, únicamente admito Madrid / Barcelona'


Todo es cuestión de hacerse con la estructura XML del fichero.

Si alguien se anima a probarlo y adaptarlo a otros sistemas no Linux, bienvenidos sean !
Leer más...

18 enero 2010

Tienes un e-mail: Notificación de intento de login fallido

Entrando en mi cuenta de LogMeIn para acceder en remoto a otro ordenador, confundí mi contraseña en el primero intento; tener tantas contraseñas distintas hace que algunas veces no sepas cuál es cuál (recuerdo una anécdota o hackeo "memorable" en la Facultad, sobre por qué no es aconsejable tener la misma contraseña para varias cuentas y más cuando se detecta que una de las cuentas no tiene límite de intentos fallidos - sonrisa - pero eso es otra historia).

Cuál fue mi sorpresa al recibir en mi correo un mensaje que indicaba que se había producido un intento fallido a mi cuenta LogMeIn, en donde se indicaba: el evento, el origen, la hora y la IP desde donde se realizó el intento de acceso.


También indicaba que podía configurar otras opciones en Account > Security > Account Audit.

Creo que es bastante interesante tener constancia de los intentos fallidos a nuestras cuentas, ya sea por equivocación nuestra o intento de acceso no autorizado. Mas que nada porque si detectamos que alguien está intentando acceder a nuestra cuenta de Facebook, Twitter, etc. nos pondríamos en alerta y al menos revisaríamos si nuestra clave es lo suficiente robusta.

A día de hoy pocas aplicaciones 2.0 nos informan sobre los accesos fallidos, como mucho te avisan cuando tu cuenta ha sido bloqueada al superar el número máximo de intentos.

Para muchos quizás sea molesto recibir correos cada vez que se produzca un intento fallido, pero a mi si me gustaría estar informada de ello y más cuando muchas de las aplicaciones 2.0 no cuentan con un sistema de captchas seguro.
Leer más...

17 enero 2010

Vulnerabilidad en modem/router 3G wireless - Novatel Mifi 2352


Estoy encantado con mi nuevo Vodafone MiFi 2352, que viene siendo un Novatel MiFi 2352. Actúa como un router wireless 3G ultra portátil que como principales ventajas presenta su compatibilidad con cualquier sistema al ser wireless, su ya mencionado tamaño y que además puede funcionar (mientras carga batería) con un cable MicroUSB. Más guau-guau-chaow-chaow  detallado y con criterio en Microsiervos.

Pensé que sería más sencillo, pero tiene un portal web de administración bastante completo, sobre todo teniendo en cuenta sus dimensiones. En cuanto a su seguridad, lo primero que llama la atención es que las credenciales para autenticarse no iban por un canal seguro y después me extrañó que únicamente solicitase la contraseña, sin necesidad de usuario.

La siguiente captura de pantalla es del formulario de autenticación:



Después de mirar un rato la aplicación se puede observar que para algunas páginas protegidas se requiere que el usuario haya pasado correctamente el proceso de validación, mostrando un pop-up en caso de error con el mensaje "Es necesario iniciar sesión", tal y como muestra la siguiente imagen:



Pero curiosamente se permite acceder al fichero de copia de seguridad sin una sesión válida,  únicamente introduciendo su ruta completa: http://IP/config.xml.sav.

 

En este fichero estan todas las contraseñas en claro, tanto del acceso wireless como del portal de administración... total, ¿qué mas da?

Esto se ha probado en un dispositivo de las siguientes características:

Versión de firmware del punto de acceso
11.47.17
Versión de firmware del enrutador
012
Versión de firmware del módem
5.15.00.0-00 [2009-06-26 10:24:29]

Esta vulnerabilidad en concreto se encontró en otros sistemas similares hace tiempo, como en Belkin y Linksys. No es muy lógico que distintos fabricantes comentan el mismo error una y otra vez.

Revisando referencias encontré que muchas otras vulnerabilidades habían sido reportadas hace un par de días. Así que esta, pese a que no está en las ya reportadas, tampoco debería sorprender.

Adam Baldwin indica que en el último firmware el archivo es config.xml.save.

Leer más...

16 enero 2010

Pagos con tarjeta. Identificación obligatoria ¿es necesaria?

Si digo que el fraude con tarjetas de crédito está a la orden del día, no creo que le cuente a alguien nada nuevo. Sin embargo, muchas veces nos resulta molesto cierto tipo de medidas que se toman para evitar que den lugar a efectos colaterales. Existe la creencia popular de que las únicas personas con autoridad para pedirnos nuestra identificación son los miembros de los Cuerpos y Fuerzas de Seguridad del Estado. Esto es 100% cierto; sin embargo, cuando queremos efectuar un pago con tarjeta físicamente, se nos exige una identificación mediante un documento oficial (en general, sólo es válido el DNI) argumentando que es por nuestra propia seguridad (en realidad si un pago se realiza en un establecimiento y el dueño de la tarjeta denuncia el mismo, quien asume el coste es el establecimiento).

Una de las cosas que realmente sí son por mi seguridad, y que sí que me debería preocupar, es el saber qué hace el camarero con mi tarjeta cuando desaparece y vuelve con un papelito enrrollado para que lo firme. Es decir, el DNI me lo pides para cubrirte tú, pero, ¿quién me cubre a mí que no clonas mi tarjeta cuando la pierdo de vista? Quizá la medida de las tarjetas con chip EMV que obligan al camarero a traer un lector especial que requieran un PIN para poder efectuar el pago solucionen el problema en algunas ocasiones, pero mientras siga siendo híbrida (teniendo banda magnética y chip) de poco valdrá. Esto lo comprobé esta semana en una conocida cadena de restaurantes de comida rápida: el camarero (que apenas entendía español) pidió mi DNI, hizo como que comprobaba que coincidían los nombres de ambos plásticos, se llevó la tarjeta y la pasó por el lector (esta vez se veía más o menos desde mi posición), me trajo el recibo a firmar, yo lo firmé con una firma que era la primera vez que hacía, no comprobó que la firma coincidía ni con la de la tarjeta (que no la tengo firmada) ni con la del DNI y se fue más que contento.

Entonces ¿Cuánto hay de cierto en la obligación de presentar el DNI? He buscado en google un contrato de solicitud de tarjeta de crédito (por ejemplo éste). Buscando en las condiciones que uno mismo firma en el contrato se indica claramente:

5.1 - El usuario deberá firmar la Tarjeta en el espacio destinado a tal fin, tan pronto como la reciba así como acreditar su identidad cuando sea requerido para ello por el tercero ante quien pretenda hacer uso de la Tarjeta mediante exhibición del Documento Nacional de Identidad, cuando así se solicite, o mediante otros sistemas de identificación o claves que previamente le haya notificado Iberia Cards.

Parece claro entonces que cuando queramos realizar un pago con tarjeta, si nos piden que nos identifiquemos, hemos aceptado y firmado en un contrato de solicitud que lo haremos.

Pero, ¿qué sucede con las compras online? Nadie nos exige nada. Se pueden hacer cargos a una tarjeta de crédito robada desde Internet de una forma libre, de manera que nuestro único amparo sea la ley (y los seguros anti-fraude de las entidades de las tarjetas de crédito), siempre y cuando el fraude se cometa desde un país con relativos medios.

Cuando la compra online involucra unos billetes de avión o la reserva de un hotel por ejemplo, se nos exige además que introduzcamos la fecha de caducidad y el código CVV de la tarjeta. Si alguien comprometiera el servidor de transacciones de la tienda online, se contaría con el conjunto de datos completo para llevar a cabo cuantas compras se deseen (o al menos cargos indebidos).

Pongamos un ejemplo práctico de NO autenticación en servicios online y SÍ en compras físicas. Como tantos viernes, se nos ocurre a Yago y a mí quedar para ir al cine. Al llegar a la taquilla, y pagar con tarjeta, se nos exigirá presentar el DNI del titular. ¿Qué potestad tiene la alegre taquillera para exigirme la identificación? En cambio, si Yago o yo fuéramos previsores y las compráramos/reserváramos a través de Internet, llegaríamos con toda tranquilidad al cajero automático de reservas que está a la vuelta de la taquilla y, al insertar la misma, las entradas se imprimirán sin necesidad de identificaciones previas. En ninguno de los dos casos hemos cometido fraude, sino que hemos realizado una compra usando nuestra tarjeta, en un caso siendo requerida una autenticación con un documento oficial, y en el otro caso, simplemente la posesión de la tarjeta (que podía haber sido robada y no denunciada perfectamente).

Supongo que la integración de una identificación electrónica (en España el DNI-E) aún no ha calado lo suficiente en el comercio, y sus capacidades y usos actuales están aún muy verdes de implementar. La utilización de este tipo de autenticación podría llevar asociada un mecanismo de pago a una cuenta bancaria que realmente permita asegurar que la persona que realiza la reserva, compra, o recepción de un pedido es quien dice ser (o al menos de pistas claras y no repudiables de ello). El problema es la internacionalidad de este tipo de pagos; y es que crear una PKI o una identidad digital única y válida en todo el Mundo sería demasiado complicado e inmantenible al menos para esta década. Veremos en la siguiente!

Leer más...

15 enero 2010


Imagino que a estas alturas de la película todo el mundo habrá leído sobre la ruptura Google VS China motivado por unos ciberataques cometidos por el gobierno Chino contra sistemas de Google (y no solo de google, también están involucradas otras corporaciones de EEUU)

Ayer José Antonio contaba como uno de los vectores de ataque ha sido el software de Adobe, hoy, llegan noticias que además de Adobe, todo apunta a un 0day en Internet Explorer como otra causa de esos ciberataques.

De aquí, hay varias cosas interesantes, las mas obvias pasan por saber que tiene que decir de todo esto el gobierno Chino y tampoco queda muy bien parado Google (con navegador propio), si parte de ese 'hackeo' se ha realizado a través de Internet Explorer.

Uno de los datos que realmente llaman la atención es el hecho de que tanto el exploit, como el troyano solo han sido empleados para las 33 compañías que fueron víctimas del ataque.

Parece que esas historias de ciber-crimen organizado, mafias con 0Days que roban importantes activos, etc etc habrá que tomárselas mucho mas en serio

Y, por cierto, +1 Yahoo por solidarizarse con su enemigo
Leer más...

14 enero 2010

Adobe no confía en sus usuarios


El año 2010 no empieza nada bien para Adobe. Si ya el pasado dejaba su software como el más inseguro de todos, últimamente nos encontramos con noticias que apuntan a que gran parte del "holocausto" que está dándose, en forma de ciberterrorismo, a nivel mundial con varias importantes organizaciones podría haberse debido a un PDF "con regalo 0day" repartido a dichas organizaciones, que una vez abierto, abriría la puerta a los malos para robar...por ejemplo..códigos fuente o información sensible de la compañía.

Adobe no aguanta más. No aguanta ver como sus usuarios, cuando les aparece el mensaje de "Actualizaciones disponibles", las descargan y no las aplican, cancelan el proceso, etc. Y como tampoco aguanta ver como es titular, día si y día también, a causa de sus problemas de seguridad, vulnerabilidades explotadas "in-the-wild" y demás, ya ha confirmado que están trabajando en un nuevo modelo de actualizaciones silenciosas, que permitirían parchear su software sin que sea necesaria la interacción por parte de un usuario.

Este modelo lo utilizó por ejemplo Google con su navegador Chrome, y de momento parece ser que nadie se ha quejado. Y yo os pregunto, ¿creéis que es buena idea dejar que alguien "os toque las dll's" en silencio, o no os hace mucha gracia? ¿Y si en vez de ser Google, a la que todos amamos, respetamos, confiamos plenamente, es Adobe? ¿Tenéis ganas de ver su actualizador silencioso? ¿Creéis que podría dar juego para otras personas, y que pronto podríamos ver un post en un blogspot de fondo negro configurado por default explicando en ruso, francés...como aprovecharse de este sistema para hacer otras cosas? Esperemos que no.

[+] Adobe working on new automatic (silent) updater
Leer más...

13 enero 2010

Tunelizando DNS, otra opción con iodine 0.5.x


Otra herramienta para llevar a cabo tuneles DNS, además de OzymanDNS, DNS2TCP (comentada en SbD el año pasado), NSTX o DNScat es iodine, que actualmente se encuentra en su versión 0.5.2 (0.5.1 para windows).

Este tipo de aplicaciones son útiles en las que deseamos ocultar el tráfico o se desea saltar las restricciones de un firewall, como en el caso de los hotspots wireless de hoteles, aeropuertos y otros malos lugares que se enriquecen con precios de a €uro el byte.

Para el primero de los casos hay túneles más eficaces que nos proveerán de mejor rendimiento y mayores prestaciones, pero para el segundo, esta es posiblemente la única opción.

Iodine funciona de forma portable y no requiere ningún módulo adicional. Además de es compatible con Linux, Mac OS X, FreeBSD, NetBSD, OpenBSD, Windows e incluso la plataforma móvil Android. Otra ventaja es que tiene un sistema de autenticación para que nadie pueda conectarse si no conoce la contraseña.

La aplicación se compone de un cliente y un servidor siendo ambos necesarios para poder crear el tunel. El cliente es la utilidad que se instala donde se desea saltar u ocultar la información y la parte servidor se ha de alojar en un sistema que se pueda configurar como servidor DNS.

Lo más "complicado" es configurar la parte servidor, ya que requiere que se disponga de un equipo conectado constantemente, un dominio y una dirección pública para que responda las peticiones DNS del cliente.

Por ejemplo, la siguiente configuración haría a que cualquier servidor DNS tuviera que solicitar a la dirección IP 74.82.14.199, donde escucha el servidor iodine, todas aquellas peticiones que se hagan sobre  los subdominios de tdns.securitybydefault.com:
tunnel          IN A 74.82.14.199
tdns            IN NS tunnel.securitybydefaul.com.

Una vez configurado el servidor, se arranca  con algo tan sencillo como:
iodined -f 10.0.0.1 tunnel.securitybydefault.com
y el cliente:
iodine tunnel.securitybydefault.com
Con lo que se crearía una red con dos direcciones IP (10.0.0.1 y 10.0.0.2) en las que el tráfico será enviado mediante peticiones DNS.

Leer más...

12 enero 2010

¿0Day en MySQL?


Hace tiempo que el negocio de las vulnerabilidades irrumpió en el mundo de la seguridad y a su calor, nacieron múltiples empresas que recompensan a los descubridores con sumas nada despreciables de dinero a cambio de la información.

Según leo en el SANS, una de estas empresas, intevydis que comercializa un 'pack' de exploits para la herramienta Canvas, ha colgado un video en el que muestra un supuesto 0day para MySQL versiones 5.x (la última versión es 5.1)

¿realidad o hoax? El tiempo lo dirá, aun así conviene no perder la pista a los servidores en los que tengamos MySQL en ejecución.
Leer más...

11 enero 2010

am I Spammer? Publicada segunda versión

El año pasado os hablamos en SbD de amISpammer, una herramienta que habíamos desarrollado para analizar diariamente si una dirección IP pasada por línea de comandos aparecía en alguna de entre más de 90 listas negras de las que utilizan las soluciones antispam. De esta manera, y efectuando diariamente este tipo de consultas, podríamos al menos saberlo y tomar acciones correctivas cuanto antes.

La verdad es que la herramienta tuvo bastante aceptación (muchas gracias a todos!!!) y en los comentarios del post algunos de nuestros lectores nos dejaron sugerencias bastante interesantes a tener en cuenta para implementar en futuras versiones.

Así pues, os presentamos una actualización que incluye alguna de las sugerencias que nos hicisteis, y otras nuevas que se fueron ocurriendo mientras se codificaban las modificaciones.
Son las siguientes:
  • Cuando una IP aparece reportada en alguna de las más de 90 listas negras, se hace una búsqueda en los registros DNS de tipo TXT para conocer la razón por la cuál fue denunciada (Esta característica se añadió gracias al análisis del funcionamiento de la herramienta presentada por Jordi Prats en su blog SystemAdmin.es).
  • En la primera versión era obligatorio pasar como parámetro una dirección IP mediante el flag -i. En la nueva se ha añadido un procedimiento de detección automática de la IP actual, si no se especifica por línea de comandos una concreta.
  • Lo más normal en las organizaciones (y esperemos que utilicen esta herramienta) es tener más de un servidor de correo en la misma o diferentes ubicaciones (para dotar de alta disponibilidad al servicio). Eso se suele implementar mediante la creación de diferentes registros DNS de tipo MX (Mail Exchange). Por ello y siendo que amISpammer funcionaba anteriormente comprobando únicamente una IP, se ha implementado un funcionamiento basado en comprobar TODAS las IPs de un mismo dominio. En esta versión, si especificamos el dominio con -d , obtendrá todas las IPs que resuelva registros MX DNS y comprobará una a una si aparecen en las listas negras. Esto es útil también si contamos con una dirección IP y un dominio dinámico (del tipo DynDNS por ejemplo).
  • La primera versión, comprobaba secuencialmente mediante consultas para cada una de las listas negras, si la IP especificada aparecía en cada lista. Más o menos para comprobar una IP, el programa tardaba unos 120 segundos. En la nueva versión, se ha implementado un mecanismo basado en threads/hilos para hacer las 92 consultas de una sola vez. Como se puede imaginar, el tiempo de espera disminuye hasta los 20 segundos (unas 6 veces menos). Por contrapartida, la máquina consume bastantes más recursos que en la versión secuencial (memoria y CPU fundamentalmente). Para ello (y gracias a mi amigo beta-tester Domingo) se ha incorporado para versiones Linux, que nada más se ejecuta el mismo, asigna al proceso la mínima prioridad posible para el proceso. No obstante, y como en sistemas Windows, requería incluir demasiados módulos para decrementar la prioridad del proceso, se ha decidido dejar la posiblidad al usuario de ejecutar la herramienta de forma secuencial o con hilos. Para ello, se utiliza el flag -T (valores 0 ó 1 dependiendo de si queremos secuencial o con hilos). Por defecto, y mientras no se diga lo contrario, se ejecuta con hilos, de manera que se incrementan las necesidades de recursos pero se tarda poco en hacer las comprobaciones.
  • Si tenéis alguna duda de los flags disponibles, añadiendo -h se muestra la ayuda de los parámetros posibles
La última versión (11/01/2009) de la herramienta, se puede descargar desde aquí

Por supuesto, y como dijimos en la ocasión anterior, quedo a vuestra disposición para tener en consideración futuras mejoras/sugerencias que creaís que sean interesantes de implementar.

Update: He subido la herramienta al repositorio de herramientas de SBD, así que la podéis descargar de aquí también.
Leer más...