jueves, 31 de julio de 2008

Black Hats and Cold War

Invisible threats have a way of eventually sneaking up on you

JULY 31, 2008 | What you can’t see can hurt you -- and most likely, it already has. By now, your credit card number is probably sitting somewhere on a crime server, either already compromised or ripe for the picking. But since we don’t actually see this happen nor can we put a face to the perpetrators, it’s easy to dismiss the threat or ignore it altogether -- until we feel it in our wallets.

The stakes are higher than a compromised credit card account, however. There’s a cyberspace Cold War going on right now between the U.S. and two countries-who-must-not-be-named (two guesses), according to a commissioner on the Commission on Cyber Security for the 44th Presidency, which is working on policy, research, and technology recommendations for the next administration to combat cybercrime and cyber warfare. (See Cyber Security for the 44th Presidency Group to Come Out of the Shadows at Black Hat.) Try bringing that up at a cocktail party, and you can kiss your car keys goodbye. We live in a society in which seeing is believing. If it’s intangible and we can’t view it on YouTube, it must not be real. But the cyber security commission, which is made up of a who’s who of experts and policymakers (some are so top secret they can’t be named), is about to give the U.S. a serious reality check with a major report on recommendations for how to fight cybercrime and cyber warfare. Congress and the Presidential candidates will get first dibs on the report, which is due within the next two months. Several members of the commission will sit on a panel at Black Hat USA next week to give attendees an update of their progress so far, and to unofficially launch a public awareness campaign of just how serious this mostly invisible threat really is.

A couple of tidbits: over 100 countries around the world have dedicated cyber attack groups, and in many developing countries, cybercrime is institutionalized like the drug cartels of the 1970s and 1980s, according to Tom Kellermann, one of the commissioners who will participate in the panel at Black Hat.

If the vision of a raging Cold Cyber War or cybercrime cartels isn’t enough to shake you out of denial, there’s another silent but deadly series of attacks, happening every day on Websites. And no, you can’t stop them with an IDS, block them with a Web application firewall, or patch for them. Famed Web application security researcher Jeremiah Grossman and colleague Trey Ford have unearthed several cases of so-called logic flaw attacks, where bad guys capitalize on weaknesses in the coding of a Website app, or in the handshake between Web applications or business processes. They are making big bucks, too: up to seven figures a month using these methods of attack, some of which are a decade old and can’t be detected. (See Hacking Without Exploits.) Grossman and Ford will demonstrate some real-world attacks using these low-tech hacks that don’t require ninja hacking skills, tools, or exploit code. All you need is a browser. Even if you can see a threat with your own eyes, it’s not always easy to discern. Take video surveillance cameras. There are typically too many of them for one security guard -- who may be watching dozens or hundreds of them at once -- to spot suspicious activity as it occurs. In many cases when there are so many cameras to monitor, it’s more about luck in spotting something going down. But a new company headed up by a former Secret Service agent has created a technology that converts video images into machine-readable language and analyzes any unusual activity caught on camera that would suggest suspicious behavior. (See New Video Surveillance Technology 'Recognizes' Abnormal Activity.) The new software from Behavioral Recognition Systems, or BRS Labs, works a lot like behavioral analysis software that looks for malware or other suspicious activity in networks. We don't always get a visual aid to keep us on the watch for threats, especially the ones online. So sometimes you just have to believe what you can't see.

Las mujeres de Linux


Si es raro ver a un hombre utilizando Linux, ver a una mujer hacerlo es algo prácticamente imposible. No es una cuestión de discriminación, pero parece que el sistema operativo no tiene muchas simpatizantes.

Pero para mostrarnos que SI hubo y hay muchas féminas que contribuyeron increíblemente con el OS y con la comunidad que este posee, la gente de LinuxHaxor decidió hacer una lista detallando qué funciones cumplen (o cumplieron) las mujeres más importantes que tiene Linux:

  • Pia Waugh: Esta australiana está completamente dedicada al software libre. Es actualmente la presidenta de la organización Software Freedom Day y vicepresidente de Linux Australia.

  • Erinn Clark: Una desarrolladora de Debian que también fue co-fundadora y lidera actualmente el proyecto Debian Women.

  • Hanna Wallach: Desarrolladora de GNOME y Debian quien ayudó a la fundación GNOME a desarrollar el Women’s Summer Outreach Program.

  • Amaya Rodrigo Sastre: Desarrolladora de Debian y co-fundadora de Debian Women. Este es su blog.

  • Celeste Lyn Paul: Diseñadora de interacción, investigadora y contribuidora del desarrollo de open source. También lidera el KDE Usability Project, mentor de OpenUsability Season of Usability y está involucrada en el desarrollo de Kubuntu.

  • Eva Brucherseifer: Ingeniera eléctrica de Alemania que está detrás de los proyectos KDE-Women, KDE-Edu y KDE-Solaris.

  • Anne Nicolas: Directora de ingeniería de Mandriva.

  • Kristen Carlson Accardi: Desarrolladora de Kernel quien trabaja para Intel. Es desarrolladora de drivers desde el año ’90 y comenzó a concentrarse en el desarrollo de drivers para Linux desde el año 2005.

  • Valerie Henson: Val (así le dice todo el mundo) es una hacker del Kernel de Linux especializada en el desarrollo de filesystems. En agosto comenzará a trabajar para Red Hat. Este es su website.

  • Stormy Peters: Directora ejecutiva de la fundación GNOME. Está involucrada en la comunidad de GNOME desde el año ’99.

Errores, Fallas y Vulnerabilidades: Reflexiones sobre la inseguridad en las aplicaciones

ecientemente revisando dos artículos sobre el desarrollo de software seguro, es interesante ver cómo los dos coinciden en aspectos fundamentales acerca de la construcción de dicho software, pero igualmente los dos documentos no hacen explícitas las consideraciones sistémicas propias de la realidad de un software confiable, no seguro.

Mientras la Maestra en Ciencias de la Computación Julia Allen, establece que construir software sin consideraciones de seguridad, es como tratar de ir por la cuerda floja sin malla protectora, los autores del artículo “la inevitabilidad de la falla”, sostienen que la seguridad inicia con el aseguramiento de los sistemas operacionales, lugar donde muchas veces establecemos los elementos mínimos para asegurar una ejecución confiable de las aplicaciones.

Para Allen, el problema de la seguridad en el desarrollo de software está asociado por un lado con las amenazas durante el desarrollo, es decir, aplicación formal de las buenas prácticas de seguridad durante el ciclo de desarrollo de aplicaciones y por otro, con las amenazas en la operación del mismo, es decir, la toma de ventaja de las vulnerabilidades que se pueden explotar en el uso de la misma, lo cual puede llevar a corrupción de la memoria, buffer overflows y otras fallas propias de la exigencia del usuario del software en su uso.

Para los autores del artículo “la inevitabilidad de la falla”, la seguridad inicia en una sana y buena propuesta de aseguramiento del sistema operacional. Sin este requisito, sostienen los autores, las implicaciones y complejidades derivadas de las fallas de las aplicaciones, serán mayores y por tanto la identificación de la(s) causa(s) será más demandante y exigente en el tiempo y en el detalle técnico. Evitar una falla, sin bien no es posible todo el tiempo, el documento arguye, que si se toman las acciones requeridas de controles de acceso mandatarios, se valoran las fortalezas y limitaciones de los mecanismos de seguridad instalados, es posible mejorar las condiciones de seguridad de los sistemas operacionales.

Si bien los dos documentos, establecen referentes generales y conceptos específicos que apunta a una mejor ejecución y confiabilidad de las aplicaciones, no se advierte las relaciones emergentes propias de un ambiente computacional y cambiante como lo tenemos hoy. La seguridad del software más allá de la amenazas en el desarrollo y en la operación, y considerando las prácticas propias de aseguramiento de los sistemas operativos, requiere el entendimiento de la inseguridad como propiedad inherente del contexto donde se requieren las medidas de seguridad.

En este contexto, no se puede hablar de seguridad de las aplicaciones, sino confiabilidad de las mismas. Este nivel de confiabilidad, está dado por el nivel de riesgo aceptado que establece la organización para sus desarrollos, medido todo él en función de la administración de riesgos que hace frente a las prácticas de construcción de software, el estudio del perfil psicológico de los usuarios, las vulnerabilidades propias de los productos utilizados y la evolución de los procesos de negocio de la organización.
La confiabilidad es una propiedad emergente del sistema que se percibe como un incremento de la confianza de los usuarios y clientes en el uso de las tecnologías de información, como parte de la estrategia de la generación de valor de la empresa.

Las diferentes propuestas actuales que buscan disminuir las vulnerabilidades propias
del software, basan sus propuestas en consideraciones específicas de uso de las tecnologías y lenguajes de programación, que si bien ayudan a regular el número de vulnerabilidades, frecuentemente conocidas, no avanzan en un estrategia más holística de construcción de software confiable.

Julia Allen sostiene que el software es vulnerado frecuentemente por la explotación de debilidades resultantes de:

1. Complejidades, imprecisiones y cambios en el modelo de procesamiento de software, es decir, en un inadecuado diseño de la arquitectura del software, relacionado con los modelos de procesos y datos lógicos requeridos para los requerimientos del negocio.
2. Supuestos incorrectos aceptados por los desarrolladores, como son entre otros, capacidades del producto, salidas y comportamientos (estados) de las aplicaciones en el ambiente de ejecución o entradas de entes externos.
3. Fallas en la especificación o el diseño que llevan a defectos en la implementación del software o sus componentes.

Considerando este escenario, se puede establecer que tenemos tres tipos de palabras para hablar de problemas que impacten la confiabilidad del desarrollo de las aplicaciones.

Un error, un error es una limitación operacional propia de la utilización del software; un evento causado por un usuario o interconexión con otro proceso. Una falla, es un problema inherente en el diseño mismo de la aplicación y está embebido en la manera como se plantea la solución que se construye y una vulnerabilidad, es la explotación de una falla identificada en el diseño, que bien puede ser producto de la configuración de la aplicación o de las funciones propias del lenguaje utilizado.

En consecuencia de lo anterior, las confiabilidad del software exige la exposición de la aplicación a los errores propios del uso, a la valoración y evaluación de los riesgos propios del diseño y a la explotación de las vulnerabilidades que se expuestas en el diseño. Es importante aclarar que siempre es posible un efecto de borde u operación inesperada que puede no estar documentada ni en la operación, ni en el diseño, por tanto, esta posibilidad es el riesgo residual aceptado por la organización cuando recibe una solución de software para su uso.

La confiabilidad del software requiere un alto grado de experiencia en el uso de buenas prácticas, un claro conocimiento de las posibilidades y oportunidades de los lenguajes de programación y el ojo crítico y analítico de aquel que busca esos lugares en el diseño (visibles y no visibles) donde podemos ir “más allá de lo especificado en la funcionalidad”.

El software seguro, si bien no es posible, por la sencilla razón que no existe riesgo cero, es una oportunidad tanto para los desarrolladores como para las empresas, para aprender de los efectos de borde, pues como decía Albert Einstein, “la imaginación es más poderosa que el conocimiento”. En este sentido, nuestras limitaciones humanas sobre lo que ocurre en los detalles de la implementación, así como nuestras percepciones y operaciones sobre el software, son alimento suficiente para que la inseguridad de la información busque nuevos caminos para sorprendernos y mantenernos “fuera de la zona de confort”.

Referencias
ALLEN, J. (2007) Why is security a software issue?. EDPACS 36:1, 1-13.
LOSCOCCO, SMALLEY et al.(1999) The inevitability of failure: The flawed assumption of security in modern computing environments. National Agent Security.

Fuente: http://www.eltiempo.com/participacion/blogs/default/un_articulo.php?id_blog=3516456&id_recurso=450011111

Consejos útiles contra el malware 2.0 en Windows

Los consejos obsoletos ofrecen una falsa sensación de seguridad de la
que se están aprovechando los atacantes. Muchas de las informaciones
publicadas sobre seguridad en general y sobre malware en particular no
han sabido renovarse, y se perpetúan coletillas y axiomas que (aunque
útiles y necesarios) no se han matizado ni completado correctamente con
el tiempo. Son consejos de hace años, que no se han adaptado a una
industria (la del malware) que avanza mucho más rápido de lo que podamos
imaginar. Vamos a ofrecer algunos consejos útiles contra el malware...
de hoy.

Administrador no, gracias

El principal consejo para los usuarios de sistemas operativos en general
y los de Windows en particular es no usar la cuenta de administrador. Se
debe utilizar la cuenta de un usuario sin privilegios, sin excusas. Esto
es lo que puede llevar a una mayor protección no solo contra el malware,
sino contra posibles despistes del propio usuario. Un "administrador"
está precisamente para "administrar", y son muy pocas veces las que un
usuario utiliza su sistema para realizar modificaciones importantes. La
mayor parte del tiempo lee correo o navega, actividad esta última que
conlleva un importante riesgo, sea con el navegador que sea. Esta
irresponsable actitud de usuario administrador perpetuo está heredada de
los tiempos de Windows 9x. No tenía sistema de usuarios local real, ni
soportaba NTFS, con lo que no se podían establecer permisos por
usuarios. Cuando apareció XP, tras su instalación Microsoft permitía por
fin la creación de un usuario distinto al administrador para el uso del
sistema. Un gesto que hubiera servido de algo si este mismo usuario no
perteneciese por defecto al grupo administradores, y por tanto fuese tan
poderoso como él.

A nadie que utilice un sistema operativo que no sea Windows se le ocurre
realizar sus actividades cotidianas como "root" o súperusuario. En
Windows, lo extraño es precisamente lo contrario, trabajar con cuentas
limitadas. Este es el verdadero origen de la mayor parte de los males, y
de que el malware pueda campar a sus anchas en un ordenador donde puede
escribir, leer, modificar... puesto que es ejecutado con los mismos
permisos del usuario que está usando la máquina.

En Windows Vista, Microsoft ha establecido un importante sistema de
seguridad para mitigar este problema heredado, rompiendo así una
tendencia muy arraigada y limitando el poder del usuario habitual. Se
ha relegando por fin el uso del administrador a un segundo plano. Sin
embargo esto ha sido visto por muchos usuarios como un estorbo, en vez
de como una importantísima mejora en su seguridad.

Aunque se presente aquí como panacea, no lo es. Todavía una parte del
malware actual podría seguir actuando. Además, trabajar como usuario
raso en XP o 2000 puede llegar a ser incómodo, incluso para usuarios
experimentados. Es necesario tener conocimientos sobre permisos,
privilegios, NTFS, derechos, herencias, grupos... Por si fuera poco, con
ánimo de no complicar al usuario, Windows XP Home Edition escondía
deliberadamente la pestaña de seguridad para poder cambiar los permisos,
a no ser que se trabajara en modo a prueba de fallos.

Actualizar el sistema

No sólo Windows, sino todos los programas que tengamos instalados deben
estar actualizados a la última versión de su rama. Esto es muy
importante, pues una gran parte del malware hoy en día se aprovecha de
vulnerabilidades conocidas que ya tienen parche. Muchos usuarios piensan
que un Windows parcheado tendrá problemas "legales" o que sufrirá fallos
de compatibilidad. Un Windows sin actualizar es un Windows contaminado.
Pero no sólo el sistema operativo. Todo programa es susceptible de
sufrir problemas de seguridad y de que sean aprovechados. Desde el
reproductor de MP3 hasta el lector de PDF, se han detectado ataques
dirigidos a versiones vulnerables de los programas más utilizados para
tareas comunes. La única solución es no abrir archivos no solicitados
tengan el formato que tengan y sobre todo, mantener actualizados los
programas que los interpretan.

Mantenerse informado

Mantenerse informado sobre tendencias de seguridad, malware y estado
en general de la seguridad en la red. No se puede luchar contra lo que
no se conoce. Son muchos los usuarios que desconocen que pueden ser
infectados por archivos que no son ejecutables, que es posible ejecutar
código arbitrario en el sistema de forma transparente con sólo visitar
una web, o que el SSL del banco visitado no tiene por qué significar que
un sistema no esté troyanizado o que no se trate de un phishing. Otros
piensan que el hecho de que la página del banco aparezca modificada y
requiera más casillas de la tarjeta de coordenadas de lo habitual,
significa que la seguridad ha aumentado...estar informado es primordial.
No sólo por lo cambiante de algunas técnicas, sino también porque es
necesario seguir de cerca ciertas campañas que emprenden los atacantes
y que suscitan modas y comportamientos sobre los que resulta
imprescindible estar especialmente atento. Existen momentos en los que
se perpetran ataques concretos para los que puede que la única solución
sea conocerlos y evitarlos hasta que exista parche.

Otros consejos

Estos tres consejos anteriores son los más importantes. Por desgracia no
son los que se dan habitualmente en los medios no especializados. Ni la
tecnología, ni Internet ni los atacantes son los mismos que hace cinco
años, por tanto las precauciones no deben ser iguales para siempre.
Obviamente es necesario usar herramientas o suites de seguridad
actualizadas (cortafuegos, antispyware...) pero sobre todo, saber cómo
se usan. Si no se saben manejar, se vuelven inútiles.

¿Y el antivirus? Por supuesto. También es imprescindible tener un
antivirus actualizado a diario.

domingo, 27 de julio de 2008

CheckaPic, otro sitio sospechoso

Se trata de un sitio llamado checkapic . com (ingrese bajo su responsabilidad) cuya forma de trabajar cambia un poco a las habituales. En este caso se envía un mensaje a los contactos de MSN con una URL manipulada para hacerla más creíble a quien la reciba.

Por ejemplo si el usuario que recibirá el mensaje se llama "pepelepo", verá URL del estilo http://ppepelepo.checkapic . com:



Por supuesto se trata de un engaño y cualquier URL conduce al mismo sitio en donde se solicita el usuario y la contraseña de MSN para ver una supuesta imagen:




Luego del ingreso de los datos, el sitio informa que los mismos son incorrectos y vuelve a solicitarlos, sin poder hacer nada más. Es obvio que se trata de un engaño con el único fin de obtener datos de usuarios que no toman precauciones.


NO ingrese sus datos de autenticación en sitios no oficiales.

Engaños sobre "quién te admite en MSN" (o cualquier otro mensajero) ya me tienen arto mis contactos con esto jeje!

A continuación se detalla una lista de servicios que NO sirven para saber quien te bloquea en los mensajeros electrónicos. Además, se deja explicación de cada uno de ellos, a través de sitios que han investigado cada caso en particular.

Si bien muchos de estos sitios dicen no almacenar direcciones de correo y datos personales esto no puede probarse y siempre es recomendable no utilizar estos servicios debido al caracter poco confiable de los mismos.

Se debe recordar que estos sitios generalmente son un engaño para obtener direcciones de correo y datos personales (como mínimo) utilizando la Ingeniería Social.

¿Puedo saber quién me bloquea?. NO.
¿Puedo saber quién me eliminó?. SI.

NOTA: los sitios que figuran a continuación a sido obtenidos a través de informes de usuarios y no significa que se haya probado que almacenan información sensible del usuario pero se insiste en no utilizarlos debido al caracter intrusivo de las metodologías utilizadas.

Los sitios web que aparecen en este listado no necesariamente guardan los datos privados de los usuarios pero podrían hacerlo.


Sitios fraudulentos en español:

adictosalmsn
admitimequerida
admitemeya
admitemimsn
admitidomsn
admitomsn
alguiennoteadmite, también contiene malware
atevip
blockeo, avisa en su Disclamer que sólo informa sobre contactos eliminados y recomienda cambiar la contraseña
blockyell
blockoo, bloquo o blocuo
bloqueados
borradito
borrado
caleta y caletanomas, sitio peruano que abre ventanas con publicidad
checkapic
checkmessenger y checkmessenger2, aquí y aquí
cristianos/quien-teadmite
cuentasborradas
deletefinder
detectmsn
desadmite / amor.desadmite
descubremsn
detectando
e-inicio / quienesmalo
eliminado (de España)
eliminalos
eramsn
espiacorreos, actualmente dado de baja pero en 2005 fue el origen de otros sitios citados aquí (aún disponible en la Cache de Google y en Archive).
estasnoadmitido
falsos
gabons
genialmsn
granpecado
listamsn
lohizo
medesadmite quien ya es considerado peligroso por SiteAdvisor
messenger-tips, avisa en su Disclamer que sólo informa sobre contactos eliminados y recomienda cambiar la contraseña
messentools / msn-check-list
msndetect.estupideces
msnsinadmision
muymsn
noadmitido, fue uno de los primeros en 2006. Ha sido dado de baja pero su aún puede encontrarse Archive
noadmitidomsn
perujovenes
queblock , que se está volviendo muy popular
queescandalo
quienesmalo / e-inicio
quienignora
quienmeadmite
quiennoadmitido
quienteadmite, actualmente es el más famoso y por eso puede encontrarse mucha información aquí o aquí o aquí o aquí o aquí y por supuesto ellos se defienden con insultos infundados. Es considerado peligroso por SiteAdvisor y existe un video en donde no muestra los contactos bloqueados. quien-te-ama
quienteama
quientebloquea
radiusim
revisatumsn, avisa que sólo informa sobre contactos eliminados
scanmessenger
secretosdelmsn, actualmente dado de baja pero que aún puede verse en Archive
tebloqueo, que abre ventanas con publicidad
teborraron
undisplay / quientebloqueo
vercontactos
youareblocked Broma de BolsaNegra para educarnos sobre estos sitios
Sitios fraudulentos en inglés
blockdelete
blockstatus
msnblockchecker
msnblockerlist
msnblocklist
msnliststatus
msnstatus
you-areblocked


¿Cómo funcionan estos sitios?

Estos "sistemas de información" utilizan una clase PHP gratuita (disponible en muchos sitios), que se basa en el API del MSN de Microsoft, que es pública y no se basa en ningún bug conocido ni desconocido.

Esta clase comprueba que contactos te han eliminado de su lista (que no es lo mismo que los que te tienen sin admisión o bloqueado) y los muestra en pantalla. Esta clase pública no almacena ningún dato privado, lo que no significa que quienes la utilicen no almacenen los mismos a través de otros medios.

Gracias a todos los colaboradores que contribuyen a que esta lista sea cada vez mayor.Si conoce otros sitios semejantes por favor póngase en contacto con nosotros para denunciarlos

jueves, 24 de julio de 2008

Dan Kaminsky on the DNS Bug of 2008

Filmed at O'Reilly FOO Camp 2008, security researcher Dan Kaminsky explains his discovery of a major protocol-level flaw in DNS and how he got major vendors to do something about it.

Yes, Linus, There Is a Difference

The security community and the open source development community have been clashing mightily over the past week, and the results are anything but pretty. It's always ugly when two groups that should be working side by side are found to be miles apart.

Linus Torvalds, the inventor of the popular open-source Linux operating system, fired the first salvo when he said in an online forum that "security people are often the black-and-white kind of people that I can't stand."

In an email, Torvalds criticized the creators of the OpenBSD environment, an open-source version of Unix that is designed to be secure.

"I think the OpenBSD crowd is a bunch of masturbating monkeys, in that they make such a big deal about concentrating on security to the point where they pretty much admit that nothing else matters to them," Torvalds said. "To me, security is important. But it's no less important than everything else that is also important!"

While Torvalds was flaming the entire security community in a public forum, Fortify Software published the results of a study that made similarly blanketing comments about open source developers, using data on 11 different open source projects to demonstrate that the open source development process is rife with security flaws. (See Report: Vulnerabilities Abound in Open-Source Environments.)

It's these sorts of blanket statements that cause enmity and outright dislike between two groups. Any statement that starts with "those people" is headed in the wrong direction. Security experts and open source developers should be digging trenches together, not firing shots at each other.

Torvald's comments, in particular, are chauvinistic and disingenuous. If he were Mel Gibson or Al Sharpton, he'd have been run out of town on a rail for making such stereotypical comments in an open forum. But since he's a quirky computer genius and the people he was talking about don't have a political action committee, everybody seems to be letting it slide.

More importantly, Torvalds is just flat wrong. In his comments, he suggests that finding a security flaw in source code is no different than finding any other code flaw. But there is a huge difference. An everyday development flaw can jeopardize the usability of an application, or even a hard drive. But a security flaw can lead to the loss of a company's data, or its customers'. If I build a house that is unsafe, it threatens the inhabitants. If I build a bank that is insecure, it threatens not only the welfare of the business, but the lives of thousands of customers.

Fortify's study was more informed, and certainly less bigoted. But its conclusions -- that all open source projects contain security flaws and that open source projects may become an Achilles heel for business -- stirred a pot that was too broad, and led to plenty of ire in the open source community.

It's true that open source development projects are rife with security vulnerabilities. But aren't all software development projects rife with security vulnerabilities? Commercial and in-house development teams make many of the same mistakes as open source developers, and the results are just as dangerous. In fact, if you look at the whole body of news here at Dark Reading, you'll see many more vulnerability stories about commercial programs than about open source applications.

The truth, as usual, lies somewhere between two extremes. Security people aren't unreasonable to consider their vulnerabilities more serious than, say, a user interface flaw. Many open source developers need to work on building security more directly into the development process, as all programmers do. But it's not fair to call open source the weak link in the enterprise security chain.

Maybe what both sides need to do is quit generalizing and start finding ways to work together. We should welcome the notion that open source developers are sitting up and paying attention to the security community, even if it's initially in a negative way. It's past time to get this discussion going.

Researchers Raise Alarm Over New Iteration of Coreflood Botnet

Password-stealing Trojan is spreading like a worm – and targeted directly at the enterprise

The seven-year-old Coreflood botnet is quietly stealing thousands of passwords from corporate users and other large organizations, thanks to recent enhancements that allow it to spread like a worm, researchers say.

The enhancements were revealed June 30 by botnet expert Joe Stewart, director of malware research at SecureWorks. Stewart traced the botnet to a single command and control server that held more than 400,000 user IDs, passwords, and other information. (See SecureWorks Finds Massive Cache of Stolen Data.)

Since then, other researchers have had an opportunity to evaluate Stewart's findings, and they don't like what they see. In a nutshell, Coreflood has combined its old ability to deliver a password-stealing Trojan with a new ability to infect whole Windows domains in a matter of hours.

"This is potentially way more malicious than Storm, because it is collecting passwords -- rather than just sending out spam or denying service -- and because the user doesn't have to click on a link or do anything at all in order to be infected," says David Jevans, CEO of security vendor IronKey and chairman of the Anti-Phishing Working Group.

Coreflood, which started out as a simple Trojan in late 2001, has been reiterated more than 100 times during its long lifespan. But with the enhancements, the Trojan now has the ability to infect Windows administrators' machines and then use their privileges to infect all of the other machines in the administrator's domain.

"We've literally seen situations where there was only one machine infected, and within a few hours, 30,000 other machines on the same network were also infected," Jevans says. "And these aren't random infections -- if it gets through to one administrator's machine, then all of the devices in his domain will be infected."

Coreflood can be shut off with an antivirus signature that prevents it from spreading. "The problem is that it's a password stealer," Jevans observes. "Most of the damage is done as soon as you're infected. It doesn't do much good to use a signature-based defense to shut it down hours or days later, after it's already got all your passwords."

Jevans is concerned that Coreflood will quickly become an attractive attack vector for cybercriminals, who want identity data from a highly qualified base of victims. "This is targeting corporate environments, which means there aren't any kids logging on to play Webkinz," he notes. "But a lot of adults access their bank accounts from the office."

The Coreflood vulnerability takes advantage of lax security practices in the Windows environment, where systems administrators often have broad rights to distribute software and other code, but whose authentication methods are simple, and even shared, Jevans observes. "And often, the domain administrator uses the same computer for surfing the Web that he does for sending out software," he notes. "It's relatively easy to find that one administrator who can infect a whole domain."

To defend themselves against Coreflood, enterprises should take a closer look at the way their Windows administrators operate, and which machines they use. Companies should also consider using anti-malware tools that are behavior-based, rather than signature-based, Nevans says.

Enterprises should also consider using anti-malware strategies that employ virtual machines, protecting the original operating system from attack, Nevans suggests. Azure, the hardware-based tool scheduled to be released next month by researchers at Damballa, is a good example of the way next-generation malware defenses might work, he says. (See Researcher Offers Malware Analysis Tool.)

Vulnerability disclosure gone awry: Understanding the DNS debacle

On July 7, the day before the release of the patch for the now infamous DNS design flaw, hacker Dan Kaminsky (with the help of Black Hat conference organizers) invited reporters to a press conference to “discuss the massive multivendor patch being released this Tuesday.”

“A synchronized release of this magnitude has not happened before,” read the invitation sent to the Black Hat conference press list.

By the time the patch was released, Kaminsky had briefed influential bloggers, recorded podcasts, scored a Wall Street Journal hit, celebrated an appearance on the front page of the BBC and won respect from his peers for coordinating such a massive cross-vendor patching effort.

It was a patching initiative that required six months of secrecy when countless security folks had to be kept in the loop. Potential patching hiccups had to be sorted out, important advisories/mitigations had to be prepared, DNS forwarding instructions had to be ready. A near impossible task, executed to perfection.

But, as Kaminsky admitted up front — and would soon find out — he made a major mistake of ignoring his peers in the hacker community, an intensely curious group prone to jealousies and stealing each other’s thunder.

In the days following the release of the patch, Kaminsky declined to provide technical details, insisting that affected vendors and end users needed at least 30 days to properly test and deploy the fix. Funny enough, the self-imposed 30-day deadline would end at the Black Hat conference where, at 11:15 a.m., Kaminsky would take to the stage and bask in the glory of his discovery.

Thomas Ptacek (right), principal of Matasano Security, was the first to call BS on the secrecy. Kaminsky immediately arranged a private conference call to spill the beans. Dino Dai Zovi, another researcher with hacker cred, was included. After the call, both Ptacek and Dai Zovi confirmed this was something super-serious that required immediate attention.

It was not enough. Monitoring the security mailing lists (Daily Dave, Full Disclosure, etc.), you could sense the backlash growing. Kaminsky’s request for a moratorium on public speculation — he even promised a Black Hat co-appearance for those who figured out the bug but maintained secrecy — did not sit will with everyone, including Ptacek.

Brand-name researchers started to grumble about the “cabal” approach to disclosure, openly venting that non-speculation and non-disclosure even after patch release were tantamount to being irresponsible.

Paul Vixie, of BIND fame, joined Kaminsky in pleading for the embargo but it was clear that public speculation would eventually emerge. It was only a matter of time before someone smart figured out how to forge and poison DNS lookups.

Halvar Flake (right), a reverse engineering guru who was among those arguing for public disclosure, published a guess/hypothesis that (almost) nailed the bug.

Ptacek’s Matasano followed up with a de-facto confirmation that filled in the missing pieces (the blog entry has since been pulled but the deed was done), forcing Kaminsky to acknowledge that his Black Hat thunder was stolen. Ptacek has since apologised but there are so many ruffled feathers, it’s hard to imagine things being the same in the land of trust/coordination/disclosure.

There’s a long list of researchers who argue that Kaminsky’s embargo was nothing but hype for the Black Hat conference. Kaminsky admits to being a media hacker and his pre-patch press conference and appearance on subsequent Black Hat marketing webcasts have done little to quell those concerns.

However, throughout this episode, I always got the sense that Kaminsky was genuine about wanting to give people adequate time to test and deploy the patch before things got ugly. Kaminsky has earned the right to be trusted on the severity of DNS-related issues so it’s sad that this debacle occured on his watch.

A lot of it was his own doing but, in the final analysis, maybe he deserved better.

There’s a lesson in here somewhere for those who try to figure out the politics and drama surrounding vulnerability disclosure.

"Las empresas de seguridad no estamos haciendo un gran trabajo"

Combatir los 'botnets' requiere acuerdos entre proveedores de seguridad, Internet y gobiernos", dice la presidente de Trend Micro - "Si no formamos una cadena de alertas en la que todos puedan contribuir, podríamos romper la confianza creada con los modelos sociales y la Web 2.0".

Corren tiempos delicados (¿o exitosos?) para la industria de la seguridad informática. Cinco millones y medio de virus circularon por Internet durante 2007. Las amenazas en la Red aumentaron el 1.564% desde 2005. El cibercrimen es ya una lucrativa actividad que amasa 8.300 millones de dólares al año, superando los 6.000 millones del mercado de antivirus. El miedo es un efectivo vendedor de antídotos. Pero, ¿está ganando el lado oscuro la batalla?

Eva Chen es la presidenta y cofundadora de Trend Micro, la tercera compañía de seguridad informática por ingresos después de Symantec y McAfee. Nacida en Taiwan, exhibe una sinceridad sin reservas al referirse a los problemas del sector. Consumidores y empresas reprochan a los proveedores falta de innovación, aplicaciones poco efectivas y un interés velado por dar rienda suelta al malware. La única salida pasa por mejorar los productos. "Si el agua es casi gratis, ¿por qué se compra embotellada? Porque la calidad es mayor. Ocurre lo mismo en este negocio".

Chen disecciona los cambios vividos en la industria con una sosegada lucidez, tal vez legado de sus estudios de filosofía en la Universidad de Chen Chi (Taipei). Mucho ha cambiado desde 1988, cuando junto a Steve Chang y su mujer, hermana de Eva Chen, fundaron Trend Micro a caballo entre California y Taiwan. Internet apenas había nacido, y ser alta directiva, especialmente en Asia, era tabú. "Iba a reuniones en Japón y al sentarme me preguntaban: '¿Dónde está tu jefe?'. Tenía dos tarjetas, una como directora tecnológica y otra como secretaria de ingeniería".

Pregunta. Las amenazas informáticas han evolucionado muy rápidamente. ¿Cuáles han sido los cambios clave en los últimos años?

Respuesta. Dos principalmente: la banda ancha es más rápida y permite a los virus extenderse a más velocidad; y los hackers, antes eran estudiantes o gente que quería ser diferente. Ahora su objetivo es ganar dinero. Ya no hay ciberpunks, hay cibercrimen.

P. Los hackers parecen aventajar siempre a las compañías de seguridad. ¿Por qué?

R. Deberíamos ir por delante, pero los proveedores no estamos haciendo un gran trabajo, e incluyo a los fabricantes de sistemas operativos, de equipos... Si un router tiene un problema, los hackers tienen una oportunidad. Si los desarrolladores de aplicaciones no publican códigos sólidos, hay un problema. Para estar por delante, se debe proteger desde el principio, no como un parche añadido.

P. ¿Cómo se han sofisticado los códigos maliciosos?

R. Ahora combinan diferentes canales y utilizan la ingeniería social en sus redes de distribución. Antes abrías un documento y se liberaba el malware. Ahora combinan spam, infiltración de páginas web y descargas de código infectado. Es una evolución polimórfica en la manera de llegar hasta el ordenador.

P. En muchos casos el objetivo pasa por robar información financiera y personal. ¿Es la encriptación de datos la solución?

R. Es una forma, pero no la mejor. Si en tu ordenador ya tienes malware instalado, cuando descifres un archivo encriptado será posible robar información. Lo mejor es prevenir que el malware llegue al ordenador y, si llega, tener una forma rápida de identificarlo.

P. En el caso del hacktivismo no es el dinero. ¿Empiezan los gobiernos a preocuparse?

R. Países como Estados Unidos o China comienzan a pensar en la infraestructura tecnológica como parte de la seguridad nacional. La tecnología es un diferencial importante para los gobiernos, y la protección un componente más.

P. Trend Micro acaba de lanzar una arquitectura web para analizar correos, direcciones, archivos... siguiendo la tendencia hacia el cloud computing. Es un cambio de estrategia.

R. Quien quiera ganar a lo grande, debe apostar a lo grande. Fuimos los primeros en desarrollar un servidor de antivirus para archivos y correo, y una pasarela de filtrado online. Ahora estamos seguros de haber hecho otra apuesta segura.

P. Si albergan su estructura de análisis en la Red, ¿no temen ser objeto de fuertes ataques?

R. Hemos barajado todos los escenarios. Las grandes arquitecturas de computación son más resistentes y estables. Tenemos centros de datos en todo el mundo para prevenirlos, sistemas de redundancia y análisis en tiempo real de las amenazas. Estamos tranquilos.

P. Los botnets son un problema creciente. ¿Cuál es la forma más efectiva de combatirlo?

R. Es muy complejo. Combatirlos requiere acuerdos entre proveedores de seguridad, Internet y gobiernos. Nosotros tenemos el conocimiento y la capacidad de identificar qué ordenador está infectado como un bot. El siguiente paso sería informar al proveedor de ADSL para anular la conexión y ponerse en contacto con el internauta. Para ello, son necesarias leyes que se lo permitan o les fuercen a tomar medidas. Eso sólo lo pueden hacer los gobiernos.

P. El spam es el otro gran problema, y ha cumplido 30 años. ¿No hay forma de erradicarlo?

R. Está conectado al problema de los botnets, muchos son utilizados para enviar spam y es difícil aislar las fuentes. Los proveedores de Internet tienen parte de la culpa, deberían responsabilizarse de proveer líneas de comunicación limpias. Es un problema a largo plazo: si más y más gente deja de utilizar la Red en transacciones, no tendrán un buen negocio.

P. ¿Arrebatar el contrato de MSN Hotmail a McAfee ha sido su gran victoria?

R. Fue una de ellas, pero no la más importante. Tomó mucho tiempo. Antes Microsoft no utilizaba Trend Micro porque creía que nuestro reconocimiento de marca en EE UU era insuficiente. Desarrollamos nuestro negocio para consumidores allí y pasamos a ser muy conocidos.

P. Su reciente demanda contra Barracuda Networks, por violar una de sus patentes, se ha interpretado como un ataque a la comunidad de software libre.

R. El objetivo de Barracuda es ganar dinero, ¿cómo pueden llamarse compañía de software libre? Nosotros no hemos demandado a ClamAV [antivirus de software libre utilizado por Barracuda]. Intentan tergiversar el problema.

P. Phishing contra Facebook y Hi5 para robar contraseñas... direcciones web en MySpace que conducen a páginas infectadas. Las comunidades sociales y las aplicaciones colaborativas son el canal idóneo para extender virus. Ya se habla de Malware 2.0. ¿Es tan serio?

R. Sí. Escanear el inmenso contenido generado por el internauta con aplicaciones tradicionales ya no funciona. Lo efectivo es interrelacionar antispam, antimalware, y filtrado de datos y direcciones con los enlaces introducidos en páginas como Facebook y My Space.

P. ¿Acabarán estos problemas con la Web 2.0?

R. Si no formamos una cadena de alertas en la que todos puedan contribuir, podríamos romper la confianza creada con los modelos sociales y la Web 2.0. El 15% de internautas que utilizaban la banca online han dejado de hacerlo, y el 20% está tan preocupado por el robo de identidad que no se atreve con el comercio electrónico. Internet podría corromperse.

Fuente: http://www.elpais.com/

El "rey del spam" condenado a cuatro años de prisión en EE.UU.

Se llama Robert Soloway y tiene 28 años. Su empresa envió, entre 2003 y 2007, decenas de millones de emails basura. En marzo se había declarado culpable de los delitos de fraude y evasión de impuestos ante un tribunal de Seattle, a cambio de una reducción de la pena.

Las andanzas del "rey del spam" llegaron a su fin. Robert Soloway, un empresario de 28 años, fue condenado a cuatro años de cárcel por un tribunal de Seattle, tras declararse culpable del envío de decenas de millones de emails basura para publicitar productos en la Web.

Soloway era dueño de una empresa de marketing, que entre 2003 y 2007 despachó millones de mensajes por correo electrónico para promover los productos de su compañía.

El empresario se había declarado culpable en marzo de los delitos de fraude y evasión de impuestos, tras alcanzar un acuerdo con la Fiscalía para obtener una rebaja de la pena.

La condena a Soloway coincidió con una espectacular fuga de otro acusado de enviar decenas de millones de correos electrónicos, que se encontraba detenido en una prisión cercana a Denver, en el estado de Colorado.

Se trata de Edward Davidson, de 35 años, quien cumplía una pena de 21 meses de cárcel, luego de haber sido declarado culpable por el envío -entre 2002 y 2006- de cientos de miles de "spam" en beneficio de varias empresas.

Fuente: http://www.clarin.com/diario/2008/07/22/um/m-01721091.htm

Los detalles de la vulnerabilidad en el protocolo DNS, descubiertos

Desde el 8 de julio se está produciendo uno de los episodios más
curiosos vividos nunca en la red. Se publicó ese día una actualización
masiva para la mayoría de los dispositivos en Internet que utilizan DNS.
Se dijo que había sido descubierta una vulnerabilidad que permitía
falsificar las respuestas DNS, y por tanto redireccionar el tráfico.
Casi todos los grandes y pequeños fabricantes y programadores
actualizaron sus sistemas y se intentó mantener los detalles técnicos
de la vulnerabilidad ocultos, por la gravedad y el potencial impacto
que podría suponer. Finalmente, dos semanas después, se conocen los
detalles.

Toda vulnerabilidad es importante y tiene un potencial impacto en la
red. Sin embargo, cuando hablamos de la resolución de nombres y de
problemas en los servidores DNS, la gravedad se multiplica porque se
supone que los servidores DNS sustentan la red. Dan Kaminsky había
descubierto un fallo de base en el protocolo que permitía a cualquiera
falsificar las respuestas de un servidor. No era problema de ningún
fabricante sino de casi todos, un fallo de diseño de un estándar usado
en todo Internet. En un importante esfuerzo de coordinación todos los
grandes fabricantes están publicado sus actualizaciones desde el día
8 de julio.

Pero Dan Kaminsky no daba detalles sobre el asunto. Era demasiado grave
y pensaba que sería irresponsable proporcionar esa información sin dar
suficiente tiempo a todos los administradores para actualizar. Del
parche no se podía deducir el problema puesto que simplemente añadía
aleatoriedad y entropía a ciertos valores que desde hace mucho se sabía
que no eran la mejor solución para asegurar el protocolo. Es por esto
que se apostaba desde un principio por que la vulnerabilidad de Kaminsky
se tratara en realidad de una nueva forma más eficaz de engañar a los
servidores DNS para que den respuestas falsas, gracias a un fallo
inherente del protocolo (y así ha sido).

Kaminsky daría los detalles un mes después, en la conferencia Black Hat
de agosto. Por una parte, el descubridor estaba siendo responsable
(dando tiempo a los administradores) pero tremendamente mediático por
otra (creando una expectación exagerada en torno a la conferencia).
Todo esto, ayudado por la desinformación de los medios generalistas
ha ayudado a que la desconfianza siguiese creciendo. Todos defendían
su teoría: desde el escéptico hasta el que hablaba de la debacle de la
Red. Sólo un grupo de personas concretas conocía los detalles técnicos,
y tenían instrucciones de no revelarlos y de evitar las especulaciones
públicas. Kaminsky pretendía así ingenuamente asegurarse que sólo él
daría los detalles cuando lo tenía planeado, cumpliendo así la segunda
parte de su plan una vez publicadas las actualizaciones. Imposible...
poco después las listas estaban llenas de comentarios y elucubraciones.

Afortunadamente en la seguridad informática siempre hay alguien que
va más allá. Thomas Dullien, el CEO de la compañía Zynamics (también
conocido como Halvar Flake) se aventuró a publicar en su blog su
particular visión de lo que podía ser el problema descubierto por
Kaminsky, sin tener conocimiento previo de los detalles. Y no se
equivocó en su teoría. La insinuación de que estaba en lo cierto vino
desde varios frentes (entre ellos desde un post en Twitter del propio
Kaminsky), pero lo confirmó totalmente una entrada del lunes pasado en
el blog de Thomas Ptacek, director la compañía Matasano que era de los
que conocía los detalles reales. La entrada estaba firmada por un/a tal
"ecopeland" del equipo de Ptacek. Según linkedin.com existe un/a Erin
Ptacek (Copeland), desarrollador/a de software en Matasano (¿familiar
del director?). En el post se daba la razón a Dullien, junto con todo
lujo de detalles sobre el fallo que Dullien había 'redescubierto'. La
explicación fue retirada poco después (actualmente está disponible a
través de la caché de Google). Ptacek se ha disculpado públicamente,
probablemente se dejó llevar por su ánimo de compartir la información.
Demasiado tarde... ya circula libremente por Internet.

Los detalles técnicos pueden ser encontrados en el apartado de más
información. No tardarán en aparecer exploits. Ahora la gravedad del
problema se multiplica. Afortunadamente casi todos los fabricantes han
publicado ya un parche.

Aunque se conocía el problema desde enero, Kaminsky trabajó intensamente
con los grandes fabricantes para mantenerlo en secreto y coordinar la
aparición de parches un día concreto (que tuvo que coincidir con el día
de actualización de Microsoft). Esto resulta extremadamente complicado,
y hay que reconocer que ha debido resultar un trabajo complejo el
coordinar y mantener la discreción sobre un tema tan delicado. Un
esfuerzo elogiable. Sin embargo desde que se anunció la existencia del
problema, sólo se han necesitado dos semanas para que sea desvelado,
frustrando el plan de Kaminsky de aguantar un mes hasta la Black Hat
para revelar los detalles.

Son muchas las moralejas y conclusiones que se pueden extraer de este
incidente. De nuevo el debate sobre la revelación responsable de
vulnerabilidades, la fuerza del ego de muchos investigadores, la
demostración de que un esfuerzo coordinado para una actualización masiva
ante un problema común es posible... pero sobre todo llama la atención
la capacidad de Thomas Dullien de redescubrir un problema que siempre
habría estado ahí, pero que no se había planteado buscar hasta que
alguien apuntó que existía. Dullien contaba con las bases (el protocolo
DNS sufre de problemas inherentes conocidos) sólo había que mover las
piezas para encontrar lo que podía ser el fallo que otro decía ya saber.
Y acertó. Una de las mejores formas de captar el interés de un asunto,
(aunque siempre haya estado ante nuestras narices y creamos conocerlo)
es afirmar que oculta un secreto.

Más información:

Kerfuffle erupts as DNS flaw described
http://www.securityfocus.com/brief/779

Reliable DNS Forgery in 2008
http://amd.co.at/dns.htm

On Dan's request for "no speculation please"
http://addxorrol.blogspot.com/2008/07/on-dans-request-for-no-speculation.html

Regarding The Post On Chargen Earlier Today
http://www.matasano.com/log/1105/regarding-the-post-on-chargen-earlier-today/

martes, 22 de julio de 2008

Los virus más destacables del primer semestre de 2008

El 63,12% de los nuevos códigos maliciosos que aparecieron dura Panda Security publica un anecdotario en el que se recopilan aquellos códigos maliciosos que, sin haber causado grandes epidemias, destacan por algún aspecto en particular:MEl 63,12% de los nuevos códigos maliciosos que aparecieron duraalwareProtector2008 y AdvancedXpFixer, los más bichos: Desde luego, son dos códigos maliciosos que llenan el ordenador de bichos. Más concretamente de cucarachas virtuales que se comen el fondo del escritorio. En realidad, se trata de un reclamo comercial para recordar al usuario que, supuestamente, su ordenador está infectado (aunque sea mentira) y que compre la estupenda solución de seguridad que estos adware ofrecen.Tixcet.A, el más limpio. Desde luego no puede negarse el afán por la limpieza de discos duros que tiene este gusano. Otra cosa es lo que opine el usuario al encontrar que todos sus archivos han sido borrados.PGPCoder.E, el secuestrador: Este nuevo ejemplar de ransomware, o malware secuestrador, toma como rehenes a los datos del ordenador y pide, literalmente, un rescate por ellos. En realidad, lo que hace es cifrar toda la información que se encuentre en el ordenador mediante un algoritmo, y exige dinero a cambio de proporcionar la clave para descifrarlos. Desde luego, es verdadero exponente de cómo el crimen tradicional tiene su espejo en los cibercriminales de la Red.Nuwar.OL, Nuwar.QI y Valentin.E los amorosos. Hay amores que matan, y eso es lo que se han empeñado en demostrar estos miembros de la familia de gusanos Nuwar, (también conocidos como Storm Worm) y Valentin.E. Todos ellos utilizan el amor como gancho para engañar a los usuarios e infectar sus ordenadores.Romeo.C el informador. No se puede negar que a veces los creadores de códigos maliciosos incluyen funcionalidades realmente insospechadas, pero lo de dedicarse a mostrar noticias de actualidad, mientras lleva a cabo sus maldades, tiene su punto divertido. Seguro que incluso algún usuario habrá alabado las virtudes de ese nuevo programa que tan diligentemente le mantiene informado de la actualidad más candente.Manclick.A, Manclick.B y Manclick.C, el suplantador. Estos códigos maliciosos se dedican a hacerse pasar por otros programas con el objetivo de que el usuario crea que lo que está instalando en es realidad alguna aplicación legítima, y no un auténtico código malicioso. No conforme con esto, también se dedica a redirigir a los usuarios hacía páginas web falsas, relacionadas con entidades bancarios, con el objetivo de conseguir datos financieros con los que luego llevar a cabo todo tipo de estafas online. Desde luego, no se trata de la compañía más recomendable a la hora de navegar por Internet.FakeDeath.A, el mentiroso: Este gusano anuncia la muerte de Fidel Castro para engañar a los usuarios e infectar a los ordenadores. Todo un ejemplo de mal periodista que no tiene reparos en contar una mentira para lograr su objetivo.RenameLoi.A, el profeta apocalíptico: Cuando es ejecutado, este gusano hace sonar un sonido muy molesto al tiempo que muestra un llamativo mensaje que trata sobre el anticristo y el día del juicio final.MSNWorm.EI, el cerdito presumido: cuando el usuario ejecuta el archivo que contiene este código malicioso, éste gusano muestra una foto de un cerdo maquillado y ataviado con collares y unas curiosas y llamativas gafas de sol.BeepBeep.A, el ruidoso: A este código malicioso le gusta hacerse notar, para ello, cada vez que el usuario accede al directorio de Windows o al directorio de sistema de Windows, comienza a emitir una serie de molestos pitidos.
Fuente: http://www.laflecha.net/canales/seguridad/noticias/los-virus-mas-destacables-del-primer-semestre-de-2008?_xm=rss

Filtrados detalles del ataque de Kaminsky

Aunque Kaminsky trataba de dar un plazo para que los servidores DNS fueran parcheados adecuadamente, vuelve a comprobarse que no es nada fácil guardar un secreto desde que existe Internet.Slashdot cuenta hoy como las especulaciones de un experto en torno a la vulnerabilidad soltaron la lengua de otro experto que sabía algo más, y aunque su post ha sido luego retirado, Internet ya lo ha incorporado a su memoria.Se complican pues las cosas y los exploits pueden correr ahora más rápido que los parches...

Fuente:http://it.slashdot.org/article.plsid=08/07/21/2212227http://blogs.iss.net/archive/dnsout.htmlhttp://www.vsantivirus.com/23-07-08.htm

Miles de espiados por el Bluetooth de su móvil

La Universidad de Bath sigue desde hace tres años el rastro de miles de personas a través del sistema de conexión sin cables Bluetooth, utilizado por casi todos los teléfonos móviles. Aunque la universidad asegura que no conoce la identidad de las personas que están siendo rastreadas, éstas no tienen conocimiento de que una gigantesca base de datos está almacenando información de sus movimientos. El rastreo forma parte de una investigación académica para conocer mejor los hábitos de la gente, pero según el diario The Guardian es un ejemplo de la facilidad con que se puede controlar a las personas gracias a las nuevas tecnologías y, según algunas organizaciones defensoras de la privacidad, el estudio constituye una violación de los derechos de los afectados.La universidad empezó a trabajar en el proyecto hace tres años. Al principio se limitó al área de la ciudad balneario de Bath, pero luego colgó en Internet los programas que permiten escanear la presencia de las señales de Bluetooth y enviarlas a la base de datos del programa Cityware en Bath. El programa ha sido descargado por internautas de todo el mundo y se estima que en estos momentos hay unos 1.000 escáneres siguiendo por el globo las señales de Bluetooth de 250.000 usuarios de teléfonos móviles. El sistema permite saber la localización del teléfono cuando éste se acerca a menos de 10 metros del escáner.Se puede saber, por ejemplo, los hábitos de una persona, a qué hora se fue al pub y cuándo se fue a dormir. O a qué lugares viaja. El programa ha localizado en Caracas y en París un Bluetooth que fue escaneado por primera vez en San Francisco.Aunque muchos usuarios de Bluetooth se identifican con seudónimos, muchos lo hacen con su propio nombre. Y, en todo caso, es posible conocer la identidad, teléfono y dirección del usuario. "El objetivo no es localizar a individuos. Estamos interesados en el comportamiento agregado de los habitantes de la ciudad como conjunto", se justificó el director de Cityware, Eamonn O'Neill, en declaraciones a The Guardian. "La noción de que una agencia consideraría seriamente el escaneo de Bluetooth como una técnica de vigilancia es ridícula", añadió. O'Neill describió el proyecto como "observación del público", más que vigilancia, y según él permitirá investigar problemas como la propagación de epidemias.No es la primera vez que se utiliza el Bluetooth para seguir rastros. En la ciudad holandesa de Apeldoorm, una página de Internet utiliza la misma tecnología para mostrar al público dónde están los usuarios de Bluetooth sin que éstos lo sepan, para que su rastro pueda ser seguido por familiares y amigos.

lunes, 21 de julio de 2008

Fallo crítico en DNS obliga a parchear toda Internet Parte2

Diferentes fabricantes están reaccionando al problema con parches e instrucciones concretas: Debian, Cisco, Infoblox, ISC, Juniper, Microsoft, Red Hat, Sun (Solaris)...

Esta vez, quien esté libre de fallo que tire el primer parche: desde Debian a Microsoft, y desde Cisco a Sun, todos han lanzado -o están a punto de hacerlo- el parche correspondiente para resolver un grave problema de diseño en el sistema de servidores de nombre de dominio (DNS), que permitiría a un atacante desviar todas las peticiones a banamex.com.mx a una imitación del sitio original, o a cualquier otro sitio que no tenga nada que ver con él.

Pese a lo que digan hoy la mayoría de los medios, el fallo es antiguo (probablemente tanto como la propia Internet) y en diversas variantes ya había sido anticipado por varios autores, aunque ahora sea Kaminsky quien parece llevarse toda la "gloria" mediática. Entre esos trabajos anticipatorios merece quizás la pena citar los de D.J. Bernstein o el presentado por Ian Green hace tres años sobre la resolución de nombres de dominio en Windows XP...

En mi modesta opinión, la nota técnica que mejor describe la vulnerabilidad es la del US CERT, pero quien prefiera un resumen técnico más comprensible puede encontrarlo en esta otra nota del SANS Institute.

Aunque los detalles exactos de este "exploit" concreto no se han revelado, se avecinan días (o semanas) de intenso parcheo para los administradores (añado: y también para los usuarios que utilizan bind y similares para cachear sus resoluciones de nombres). Mientras tanto, el propio Kaminsky ha publicado en su blog un comprobador de servidores DNS (botón "Check my DNS") que os permite comprobar si el vuestro (o en la mayoría de casos el de vuestro proveedor) sigue estando afectado y -sobre todo- cuándo deja de estarlo.

Cómo de crítico era el fallo en los servidores DNS parte 1

Ocurría la semana pasada: Fallo crítico en DNS obliga a parchear toda Internet. No es que el fallo sucediera la semana pasada, ya que es un error tan viejo como Internet, pues proviene de la implementación del protocolo DNS. De hecho, mucho antes ya habían sido descubiertos por distintas personas pequeños errores en dicho protocolo. Sin embargo, fue la semana pasada cuando Dan Kaminsky descubrió que la unión de todos estos pequeños errores daba como resultado un enorme agujero de seguridad que afecta a toda Internet. Pero, ¿por qué? ¿Tan grave es? Pues sí, mucho. Y para entenderlo, pasaré a explicar por encima el funcionamiento del protocolo DNS.

Cada computador conectado a Internet tiene asociado a él idealmente una dirección IP única (técnicamente no es así, pero eso ya es otra historia) del tipo A.B.C.D, donde A, B, C y D son un número entre 0 y 255 (ej. 192.168.1.1). Esta IP es, digamos, como la dirección de nuestra casa para Correos. Entonces, cuando queremos acceder a Google en español, por ejemplo, tendremos que llamar a la dirección 66.102.9.99 (pinchad, y comprobad que os lleva a www.google.es). Pero, ¿cómo vamos a recordar las direcciones de todas las páginas que visitamos? Es mucho más fácil acordarse de “www.google.es”, ¿verdad? Pues es ahí donde entra en juego el protocolo DNS de resolución de nombres de dominio.

Nunca introducimos una IP directamente en el navegador: en lugar de eso, introducimos un nombre de dominio como el de “www.google.es”. Ante esta situación, es nuestro ordenador el encargado de buscar la IP correcta (66.102.9.99) para “llamar” a Google. Para eso se inventaron los servidores DNS, que son unas bases de datos repartidas a lo largo y ancho de Internet que albergan la traducción entre nombres de dominio y direcciones IP. Así que nuestro ordenador solicitará a uno de estos servidores de nombres (uno cercano que viene pre-configurado) que nos devuelva la dirección IP de “www.google.es”. Como hay millones y millones de máquinas conectadas a Internet, tener una traducción de todas ellas en un mismo lugar sería muy ineficiente por el volumen de datos a almacenar, por el coste que tendría cada búsqueda y porque cada máquina de Internet realiza miles de solicitudes DNS al día. Por ello, la escalabilidad es el gran triunfo del protocolo DNS.

Jerarquización de los nombres de dominio

Esta inmensa base de datos de la que hablamos está partida en trozos y dividida entre montones de servidores DNS de manera jerárquica. En la cima del árbol, existen más de 1301 servidores DNS raíz (root servers) repartidos por todo el mundo que albergan las direcciones IP de los servidores DNS encargados de los pocos cientos de dominios de primer nivel existentes, como por ejemplo los ‘.es’, ‘.com’, ‘.net’, etc. Éstos, a su vez, tienen recogidas las direcciones de los subdominios, como por ejemplo ‘rediris.es’, ‘google.es’, etc. Los últimos, a su vez, engloban más subdominios, como por ejemplo ‘www.rediris.es’, ‘ftp.rediris.es’, etc. Lo podemos ver mejor en el siguiente gráfico:

Como veo que esto va a quedar un poco largo, mejor lo divido en entregas. En esta primera anotación ya hay suficiente información por hoy. En futuras entregas repasaremos cómo funciona el protocolo DNS para llegar al meollo de la cuestión: la caché de los servidores DNS, en qué consiste el famoso agujero de seguridad y qué han podido hacer para paliarlo.


1 Habitualmente se dice que hay 13 root servers identificados de la A a la M, y esto da lugar a confusiones. En realidad, hay más de 130 localizaciones de estos root servers, más de 130 máquinas físicas que albergan root servers. Esto sería como decir que Google sólo tiene un servidor web. Evidentemente, para el volumen de tráfico que tiene que soportar, tiene réplicas de la misma web en máquinas diferentes por todo el mundo. Para comprobarlo, haremos lo siguiente: (desde Windows) vamos a Inicio, y le damos a Ejecutar… Tecleamos “nslookup” (sin las comillas) y presionamos Enter. En la nueva ventana, tecleamos “www.google.es” y volvemos a presionar Enter. Lo que hace este programa es solicitar al servidor DNS la IP de “www.google.es” y mostrarla por pantalla. En el campo “Addresses:” nos muestra las IP de la página solicitada. Como comprobaréis, hay más de una:
> www.google.es
Servidor: -------------------
Address: -------------------

Respuesta no autoritativa:
Nombre: www.l.google.com
Addresses: 216.239.59.147, 216.239.59.99, 216.239.59.104, 216.239.59.103
Aliases: www.google.es, www.google.com

El FBI infecta con un troyano a un sospechoso

La eterna polémica entre lo legal y lo ilegal en la lucha contra el crimen, tiene como protagonista de esta semana la noticia de que el FBI utilizó recientemente un nuevo tipo de software espía para investigar amenazas de bombas a una escuela secundaria.

De acuerdo a las leyes vigentes en Estados Unidos, los agentes federales obtuvieron una orden judicial, para enviar el pasado 12 de junio, un spyware a una cuenta de MySpace sospechosa de ser utilizada para el envío de falsas amenazas de bombas. Una vez implantado, el software envió información de la computadora del sospechoso al FBI, incluyendo un registro de las conexiones salientes.

El propio FBI llama a este software, CIPAV, siglas de Computer and Internet Protocol Address Verifier, o verificador de la dirección IP.

Con las pruebas obtenidas, el sospechoso, un joven de 15 años llamado Josh Glazebrook, antiguo estudiante de la secundaria amenazada, fue finalmente condenado a 90 días de detención en la prisión para menores, después de haber firmado una declaración de culpabilidad por enviar las amenazas de bombas y otros cargos.

Si bien existen aún muchas especulaciones sobre la manera en que el FBI habría enviado el software espía, este caso parece ser el primero en revelar que en la práctica, esta técnica es realmente utilizada.

En 2001, el FBI ni negaba ni confirmaba la existencia de su propio caballo de Troya, creado con la excusa de combatir al terrorismo. El troyano, conocido en ese entonces como Magic Lantern (Linterna Mágica), sería enviado a cualquier sospechoso, como un adjunto a un mensaje aparentemente inocente.

Ante la prensa, el organismo declaró que no era nada nuevo que la organización estuviera trabajando con especialistas de la industria de la seguridad, para crear una herramienta que fuera eficaz en combatir tanto al terrorismo, como a otros actos delictivos. Y aunque no debería ser una sorpresa, "tampoco era apropiado que se revelaran las tecnologías que específicamente serían usadas," explicó un vocero.

Desde entonces, el FBI nada ha dicho sobre Linterna Mágica. En otros dos casos en que se sabe que los investigadores utilizaron un software espía para obtener pruebas, en realidad se trató de keylogers (registradores de lo que se escribe en el teclado), implantados por agentes directamente en los equipos, no mediante su envío electrónico.

El caso actual es diferente, ya que se envío un troyano a una cuenta de MySpace. En la declaración jurada de la orden de allanamiento presentada a un tribunal, el FBI indica que los detalles del uso de este software "son confidenciales."

"La naturaleza exacta de los comandos, procesos, capacidades, y la configuración del software, está clasificada como una técnica de investigación especialmente sensible. [...] Su revelación probablemente pondría en peligro otras investigaciones en curso y/o el uso futuro de dicha técnica", dice la declaración.

Las referencias, parecen apuntar a que se trata de un software específico para Microsoft Windows. Otros datos enviados al FBI, incluyen "el tipo de sistema operativo instalado y su número de serie, el nombre del usuario conectado, y las direcciones de las páginas web a las que la computadora estuvo previamente conectada," afirma la misma declaración.

CIPAV sería instalado "a través de un programa de mensajería electrónica de una cuenta controlada por el FBI", lo que probablemente significa un correo electrónico o de mensajería instantánea. "Luego, durante unos 60 días, se registran las direcciones IP visitadas, pero no el contenido de las comunicaciones."

Lo curioso, y preocupante, es que este tipo de acción involucra alguna clase de infección, y por lo tanto, debería eludir las defensas de un programa antivirus o antispyware para poder ejecutarse. En la declaración jurada del FBI no se hace mención alguna al software antivirus.

Una posibilidad manejada por algunos, es que el FBI haya convencido a todas las empresas de programas de seguridad para pasar por alto a CIPAV, y para no alertar a los usuarios de su presencia. Sin embargo, esto es fácil descartarlo, ya que claramente perjudicaría a las propias compañías y a su confianza con el público, y por lo tanto a sus ventas.

La política general en este sentido para cualquier empresa de seguridad, es que si algo quiere instalarse sin conocimiento del usuario, es un malware, y debe ser detectado. Además, muchas compañías están en países a los que una ley federal no puede afectar.

Otra teoría más plausible, es que el FBI haya descubierto (o pagado a alguien para hacerlo), vulnerabilidades desconocidas en Windows que permitirían a CIPAV instalarse.

De todos modos, la polémica de lo legal y lo ilegal para combatir el crimen informático, ha vuelto a ponerse en juego.


Más información:

FBI's Secret Spyware Tracks Down Teen Who Made Bomb Threats
http://www.wired.com/politics/law/news/2007/07/fbi_spyware

Declaración jurada de orden de allanamiento (PDF)
http://blog.wired.com/27bstroke6/files/timberline_affidavit.pdf

Relacionados:

La mayoría rechaza que no se detecte el "Linterna Mágica"
http://www.vsantivirus.com/03-12-01.htm

Especialistas crean troyano indetectable y lo dan al FBI
http://www.vsantivirus.com/09-12-01b.htm

Cuando un antivirus decide no detectar un troyano
http://www.vsantivirus.com/26-11-01.htm

El FBI y sus troyanos
http://www.vsantivirus.com/22-11-01b.htm

Troj/Malantern (Danschl). Simula ser el Linterna Mágica
http://www.vsantivirus.com/malantern.htm

Aparece troyano que se hace pasar por Linterna Mágica
http://www.vsantivirus.com/12-12-01.htm

El FBI confirma la existencia de "Linterna Mágica"
http://www.vsantivirus.com/13-12-01.htm

BadTrans y su sospechosa relación con Linterna Mágica
http://www.vsantivirus.com/19-12-01.htm

Windows XP, las opiniones enfrentadas del FBI y Microsoft
http://www.vsantivirus.com/23-12-01.htm

Fuente: http://www.vsantivirus.com/21-07-08.htm

Spam coming from free email providers increasingSpam coming from free email providers increasing

After analyzing three weeks of spam data between June 13 to July 3, 2008, Roaring Penguin Software Inc. foundSpam coming from free email providers increasing evidence that spam originating from the top three free email providers (Gmail, Yahoo Mail and Hotmail) is increasing, with spammers in favor of abusing Gmail’s privacy preserving feature of not including the sender’s original IP in outgoing emails :

“Spammers are increasingly using free e-mail providers to avoid IP address-based reputation systems. These systems track mail sent by various IP addresses and assign each IP address a rating. Some anti-spam software operates largely or exclusively on the basis of the IP address rating.

Roaring Penguin’s data shows that over the three weeks from June 13 to July 3, 2008, the percentage of US-originated spam originating from the top 3 free e-mail providers (Yahoo, Google and Hotmail) rose from about 2% to almost 4%. Roaring Penguin believes that spammers are using Google’s service in particular to send spam, relying on the fact that blacklisting Google’s servers is impractical for most organizations. According to their data, the probability that an e-mail originating from a Google server is spam rose from 6.8% on June 13 to a whopping 27% on July 3.”

Spammers and phishers are not just interested in the clean IP reputation of free email providers, they are also interested in taking advantage of the trust they have established among themselves through the use of DomainKeys and Sender ID Frameworks, and by abusing this through the bogus accounts that they’ve automatically registered by breaking the CAPTCHA based authentication, reach the widest possible audience and ensure the successful receipt of their spam/scam.

How are they managing to efficiently abuse these services, and is CAPTCHA breaking for the purpose of automatically registered bogus accounts to blame? The broken CAPTCHAs are only part of the problem. It all starts from the basics, in this case, the companies themselves admitting there’s a problem and how committed they are in not just fighting incoming spam, but also, outgoing spam.

The whole quality and assurance process applied by spammers is nothing new, in fact phishers and malware authors have been putting more efforts into coming up with easier ways to measure the return on investment (ROI) for themselves, and to present clear performance data to those taking advantage of their services. Just because someone has successfully sent several million spam emails, doesn’t mean that the messages didn’t got filtered, and when they did, what number exactly. Coming up with in-depth spam campaign metrics, and processes for verification of delivery, are becoming a top priority for everyone involved in this underground ecosystem.

The problem of spam and phishing coming from free email providers, has had its peaks in the past two years, prompting popular spam blacklists such as SORBS and Spamcop to blacklist entire Gmail servers due to their inability to obtain the real sender’s IP. It’s a signal from the anti spam community, and since Gmail will continue not revealing the real sender’s IP, something they’ve received a lot of criticism from anti spam vendor, but a lot of applause from privacy fighters, the best they can do is balance their incoming VS outgoing spam fighting strategy. Here’s a comment from an anti-spam vendor commenting on the problem back in 2006 :

“Gmail has taken an extreme position on privacy that inhibits the antispam community from doing their job, and it’s ticking people off,” says Tom Gilles, co-founder of IronPort. Some 10% to 15% of the spam IronPort sees comes from free Web-mail accounts, too big a slice to turn a blind eye to. “From time to time, Gmail mail is getting blocked because spam is leaking out of their service,” Gilles says. “Sometimes the babies get thrown out with the bath water, and that is the rub.

It’s difficult to gauge how widespread the problem of missing Gmail is, since no blocking records are available, though experts worry it’s growing along with the Gmail service. Gmail had 6.7 million visitors in February, up 4.1 million from a year ago, according to measurement firm comScore Networks, a jump that suggests lost email has yet to hurt the service’s growth. Yahoo Mail is still nearly 10 times bigger, hosting 64.6 million visitors last month, and AOL and Hotmail are also orders of magnitude larger. The situation reveals again how the studiously iconoclastic search engine is wrangling with where to draw the line on Internet privacy. As in other recent cases, Google is taking a harder line than its peers.”

Moreover, the abuse of the authentication at these free email providers, by either breaking the CAPTCHA images automatically, or outsourcing the process to human CAPTCHA breakers who earn cents to authenticate the registration process for the spammers to abuse, is clearly making an impact. For instance, underground services offering hundreds of thousands of pre-registered bogus accounts are popping up like mushrooms these days, and their maturity into a customer-tailored proposition offering everyone the possibility to pre-register bogus accounts at services and web sites that they are not currently targeting, speaks for the confidence they’ve built into their ability to deliver the goods. The most recent one which I covered in a previous post is continuing to automatically pre-register accounts with its inventory emptying and filling itself automatically in between the customer’s feedback indicating the quality of the service. Here’s a sample of their inventory as of the last five minutes :

  • Yahoo.com - 270,565 pre-registered accounts
  • Hotmail.com - 167,013 pre-registered accounts
  • Gmail.com - 159,892 pre-registered accounts

These is just the tip of the iceberg, with many other such services offering different inventories and using different tactics in the registration process. And while the companies themselves are keeping track of the latest developments in this ongoing abuse of their services, it’s all a matter of drawing the line at a particular moment of time. For instance, a known to be malware infected IP that has repeatedly attempted to send hundreds of thousands of phishing and spam emails on behalf ot the botnet its participates in, shouldn’t be trusted in any authentication or registration attempts if you’re to take the radical approach, or have the end user warned about what’s going on and why is she not allowed to use the site’s services unless action is taken. The point is that, preventing automatic authentication abuse as a process is very similar to preventing click fraud, and fighting spam in general with the only different in the shift of perimeters from applying the techniques on incoming emails, to the authentication process in general.

Most of the human CAPTCHA breakers, and the automated programs will either abuse malware infected hosts as open proxies, or use open proxy lists in order to change their IP on every several registrations. Considering that the majority of malicious activity comes from well known bad parties are often blocked by default at the email gateway without even bothering to inspect the content in email messages coming from their networks/IPs, the same approach, activity from malware infected hosts should be challenged more aggressively than it is for the time being.

The increasing spam and phishing emails originating from legitimate email service providers is prone to increase, and fighting incoming spam should be balanced with fighting outgoing spam. Moreover, email spam is so Web 1.0, that the possibilities for abusing the joys offered by Web 2.0 services are slowly starting to materialize, with spammers being a step ahead of the filtering solutions.

Dancho Danchev is an independent security consultant and cyber threats analyst, with extensive experience in open source intelligence gathering, malware and E-crime incident response. Dancho is also involved in business development, marketing research and competitive intelligence as an independent contractor. He's been an active security blogger since 2007, and maintains a popular security blog sharing real-time threats intelligence data with the rest of the community on a daily basis.

Do open source applications take security seriously?

Not according to the folks at Fortify, who today are issuing a blistering report claiming open source projects and companies don’t take security seriously at all.

Security best practices are missing in the open source space, Fortify says. (Gary McGraw interviewed Fortify’s technical advisory board in January, 2007. Here are some of those heroes.)

“If there’s an application hack at Microsoft you would know who to go to. But what about open source? The answer isn’t always clear,” director of product marketing Rob Rachwald told ZDNet.

It should be noted before going forward that Fortify specializes in this sort of security life cycle work. One can argue they are arguing from the position of a vendor who stands to benefit if its demands for the industry are met.

But this should not invalidate the point, which is that security is a process that must be followed consistently, and many open source projects do this only haphazardly.

Here is the way way CEO John Jack put it when he got on the call:

There were 215 million data breaches from 2004-2006. Something is going on.

The bad guys have figured out how to exploit software, and one of the key elements is something firewalls can’t deal with and anti-virals don’t deal with – the applications layer.

Most hacks today are at the application layer, anywhere from 75-92%.

Open source projects that leave vulnerabilities open threaten the integrity of entire installations.

computer securityI thought at first this might be a crack at non-professional open source projects, as opposed to the work of professional open source companies.

Fortify’s research indicates both sides are equally at fault here.

“Some commercial companies maintain open source packages and I wish they were doing a better job on this than non-commercial projects,” admitted Jack. “There’s no swing one way or another in terms of security practices.”

Secure development, real-time monitoring, and the hiring of full-time security directors are all steps which need to be taken, Rachwald concluded. Open source needs to take security as seriously as Microsoft does.

“One thing I don’t think developers understand is the difference between security and quality. Security is gray. Quality is black and white. That’s why a security process is essential, because it’s not black and white.”

This should be the chief open source challenge for the next year, because if application security is not addressed, it’s hard to see much more progress coming in the enterprise market.

domingo, 20 de julio de 2008

El hombre que salvó Internet, Dan Kaminsky

Dan Kaminsky descubrió un envenenamiento masivo en el tráfico de direcciones.

El informático que puede haber salvado a Internet del caos cibernético total es un informático de 29 años de Seattle llamado Dan Kaminsky. En febrero, por pura casualidad, se encontró con un error en el sistema de asignación de direcciones de Internet del que todavía no quiere revelar demasiados detalles. "Es pronto", dice. "Primero quiero que el problema se haya solucionado a gran escala y luego descubriré los detalles".

Lo que Kaminsky descubrió es un error de dimensiones titánicas, presente en la Red desde el mismo día de su nacimiento formal en los años ochenta, que permitiría a cualquier hacker, o pirata informático, secuestrar la libreta de direcciones web, conocida como Sistema de Nombres de Dominio, y redireccionar el tráfico de Internet a sitios falsos en los que se podrían hacer con datos valiosísimos, como números de cuentas bancarias, datos privados o contraseñas personales. Cuando lo descubrió, Kaminsky, director de Penetración de Pruebas de Seguridad en la consultora IOActive, decidió colaborar con dos frentes.

"Primero me puse en contacto con los grandes proveedores de Internet y luego con el Departamento de Seguridad Interior", explica. "La respuesta de ambas partes fue magnífica". El 31 de marzo se reunió con representantes de los 16 grandes de Internet de EE UU en el cuartel general de Microsoft en Redmond, en el Estado de Washington. "Les expuse la situación y decidieron que no había más opción que cooperar y trabajar conjuntamente en parches de seguridad idénticos, para evitar una catástrofe".

Este investigador avisó también al Gobierno, a través del Equipo de Emergencia y Respuesta Informática del Departamento de Seguridad Interior. Colaborando con Kaminsky, estos agentes del Gobierno de EE UU revelaron la existencia de este fallo el pasado 8 de julio, advirtiendo que "el tráfico web, el correo electrónico y otros datos importantes de la Red pueden ser redireccionados bajo el control de los atacantes".

En ese momento, Microsoft, Cisco y otras empresas proveedoras de Internet comenzaron a proporcionar sus parches de seguridad, como descargas y actualizaciones automáticas de los sistemas operativos. "Que el Gobierno haya tomado cartas en este asunto y que lo haya hecho de este modo revela la gravedad del asunto", explica Kaminsky. "Además, es la primera vez que las grandes empresas de la Red se coordinan de esta manera y trabajan de forma conjunta y a marchas forzadas".

Por supuesto, ésta no es la primera ocasión en que se descubre un fallo en la Red. "Pero hasta ahora, los hackers eran capaces de atacar los terminales. Podían secuestrar tu ordenador, podían hacerse con el control de una red", añade. "Pero ahora, lo que hemos descubierto no es un fallo local, sino un gran envenenamiento de la Red a través del cual estas personas podrían secuestrar todas las páginas web, aprovechando un agujero en la libreta de direcciones de Internet, su banco de datos primordial".

Muchos son los casos de ciberterrorismo que se viven a diario. A principios de julio los servidores de Icann, organización no lucrativa que administra las correspondencias entre nombres de páginas web y direcciones IP, fueron atacados por un grupo de hackers turcos autodenominados NetDevilz, o Diablos de la Red.

Kaminsky ha prometido revelar más detalles sobre su descubrimiento "cuando la resolución del problema esté más avanzada". Lo hará el próximo día 24 en la conferencia sobre informática Black Hat, la mayor del mundo en materia de seguridad cibernética. Su testimonio se podrá seguir en directo a través de la dirección blackhat.com.

El masivo fallo descubierto, que todavía contamina a millones de ordenadores en todo el mundo, puede ser detectado por los usuarios. Kaminsky ha creado una página web en la que pueden comprobar si su computadora es vulnerable. En doxpara.com se accede a un botón denominado check my DNS. Si el internauta confirma que su nombre de servidor es susceptible de ser atacado dispone de una solución fácil de implementar.

La página web opendns.com ha creado una red entre EE UU y Europa en la que se proporciona un sistema de nombres de dominio blindado. Es, en otras palabras, un listín telefónico alternativo al que no afecta el fallo descubierto por Kaminsky. En esta dirección se ofrecen, de forma gratuita, dos direcciones de servidores de nombres de dominio seguras: 208.67.222.222 y 208.67.220.220. Ambas se pueden introducir en la correspondiente casilla en las Propiedades de Protocolo de Internet de cualquier computadora.

Fuente: http://www.elpais.com/articulo/Pantallas/hombre/salvo/Internet/elpepirtv/20080720elpepirtv_3/Tes