Google: todo Internet es malicioso.

El sábado si uno ingresaba a Google para buscar alguna página, aparecía bajo cada una de ellas el mensaje de "Visiting this web site may harm your computer". Al principio pensé que se trataba de un ataque generalizado, pero después se me hizo sospechoso que toda página listada por Google fuera maliciosa. Empecé a investigar.

                           

Buscando un poco no encontré noticias de algún ataque generalizado y ya algunos sitios de seguridad comentaban que se trataba probablemente de un error de Google [http://tinyurl.com/cr3tvu]. Y en efecto, se tardaron un rato pero al final salió el anuncio en el blog de Google [http://tinyurl.com/cd76r3] de que se había tratado de un error humano. Cabe mencionar que estos mensajes de que X sitio puede causar daño es un servicio adicional de Google que intenta alertar a los usuarios antes de que visiten un sitio que puede resultar malicioso.

 

Supongo que regañaron a alguien en Google, ya que una compañía que entre otras cosas se basa en la confianza de las personas (por ejemplo, todos tenemos la elección de elegir Yahoo o MSN si ya no confiáramos en Google), debe de tener mucho cuidado en no perder reputación. Supongo que no sucederá de nuevo y todo quedó en una falsa alarma.

 

Al final de cuentas este suceso me hizo reflexionar sobre si llegará el día en que en verdad la gran mayoría de las páginas web estén infectadas o modificadas maliciosamente…llegará ese día?

 

¿Qué hace Conficker?

 

Sí, ya hemos escuchado de este gusano llamado Conficker o Downadup que ha infectado millones de computadoras hasta el momento; muchos andan parchando su Windows o desinfectando los equipos y otros más simplemente revisando que todo siga en orden. Muy bien, pero exactamente qué hace este gusano una vez que infecta a un equipo? ¿Cuáles son sus intenciones? La respuesta rápida es que aún no se sabe.

 

Los creadores (o el creador) de Conficker están armando su botnet [http://tinyurl.com/atlco4], es decir, sus millones de computadoras esclavas que forman una red aguardando órdenes. Todo indica que cuando Conficker infecta (al día de hoy), no roba contraseñas de banca en línea ni manda correos spam. Simplemente se queda en "standby". ¿Qué decidirán los creadores de este gusano? ¿Vender el botnet? ¿Rentar parte del botnet? ¿Robará datos del usuario para ingresar a la banca en línea o se usará el equipo infectado para enviar spam? No sabemos qué se tiene planeado con este botnet de Conficker, pero estoy seguro que pronto lo sabremos y será noticia.

 

Reproductor de MP3 con algo más que música

 

No deseamos comprar un costoso iPod y en su lugar adquirimos algo más barato por $14.50 USD. El reproductor de música no funciona y al inspeccionarlo, encontramos información militar clasificada de EUA referente a sus soldados en Afganistán e Irak (números celulares, salud, misiones). Esto le pasó a un ciudadano de Nueva Zelanda [http://tinyurl.com/batauu].

 

Aunque no he visto una confirmación oficial de la noticia, asumamos que es real. Confirmaría que la información de este tipo es encontrada en los dispositivos más insospechados (reproductores MP3) y no sólo en laptops. También que la información “aparece” en el lugar menos pensado (Nueva Zelanda) y que hay gente que simplemente no aprende. Pensemos en nuestra organización. ¿Cuánta gente pone archivos delicados en reproductores MP3? ¿En los USB? ¿Cuántos los mandan a cuentas de GMail? ¿Cuántos los ponen en sus teléfonos inteligentes o en un CD "para trabajar en casa"?

 

Bueno, la pregunta no es si sucede en nuestras organizaciones, más bien sería si estamos haciendo lo suficiente para mitigar este riesgo.

 

PD: Por cierto, si se encontraran con información de este tipo en un MP3, lo notificarían?

 

Hackers famosos

 

Me encontré con una lista de hackers (no crackers) famosos [http://zed.m6.net/dyne/hackers.php]. Está Dennis Ritchie (creador de C), Andrew Stuart Tanenbaum (creador de Minix y autor de varios libros), Steven Gary Wozniak (no necesito decir quién es), Robert Tappan Morris (recordarán el famoso gusano de Morris), Linus Benedict Torvalds (Linux) y Kevin Mitnick entre muchos más.

 

La lista presenta una breve biografía de cada hacker con su foto. Está interesante y tal vez descubran algo que no sabían (como yo).

 

Desempeño del antivirus perimetral

 

Para las organizaciones que tienen un antivirus perimetral en la red, un parámetro interesante para saber qué tan bien hace su trabajo es fijarse en el antivirus local de los equipos. Saquen un reporte del antivirus local y los códigos maliciosos predominantes deben de ser los basados en USB.

 

La teoría (y creo que en este caso coincide con la práctica) dice que si tengo un buen antivirus perimetral, mi antivirus local en las computadoras debe estar detectando y deteniendo como rubro número uno a los códigos basados en USB. Si este reporte arroja que está detectando otro tipo de código malicioso (gusanos, troyanos), bien puede significar que nuestro antivirus perimetral no está siendo tan eficiente como creíamos ya que está dejando pasar códigos que ahora debe de detener el antivirus local.

 

Recordemos que los códigos maliciosos basados en USB han sustituido a los que se propagaban por floppies, por lo cual un gran problema es la cantidad de dispositivos USB que de plano se están "saltando" las protecciones perimetrales y que llegan directamente a los equipos de los usuarios al ser conectados; ahí el trabajo recae en el antivirus y (díganme que es así) en el firewall personal.

 

Nos dejan menos tiempo para actualizar.

No es un secreto que los creadores de código malicioso sacan cada vez más ventaja del tiempo entre el cual se publica un parche y se empieza a explotar la debilidad. Las ventas de tiempo que los atacantes nos dejan abiertas se cierran cada vez más y hoy más que nunca cobra validez el dicho de "más vale prevenir".

Me gustaría poner algunos ejemplos obtenidos del blog de McAfee [http://tinyurl.com/7gcnnn]:

 

·         Parche MS01-020 (octubre 2000): Nimda explota esta debilidad en septiembre de 2001 (335 días después de la aparición del parche).

·         Parche MS02-061 (julio de 2002): Slammer explota esta debilidad en enero de 2003 (185 días después de la aparición del parche).

·         Parche MS03-026  (julio 2003): Blaster explota esta debilidad en agosto de 2003 (26 días después de la aparición del parche).

·         Parche MS06-040 (agosto 8 de 2006): MocBot explota esta debilidad en agosto 12 de 2006 (4 días después de la aparición del parche).

·         Parche MS08-067 (octubre 23 de 2008): Gimmiv explota esta debilidad el mismo día (0 días después de la aparición del parche).

Significa que si antes gozábamos de X días o meses para probar un parche e irlo distribuyendo pausadamente, ahora es común que el mismo día que sale el parche salga también el correspondiente gusano o troyano que se aprovecha de la debilidad. Probar y distribuir pausadamente es cada vez más un lujo y las instalaciones aceleradas son cada vez más comunes. Y esto sin contar los ataques de día cero (primero sale la debilidad y luego el parche).

Finalmente, individuos y organizaciones deben de moverse a esquemas de protección preventivos y no reactivos, como puede ser un firewall personal o propuestas como las de SandBoxie [www.sandboxie.com]. Los tiempos han cambiado, nosotros también?

 

De 2.4 millones de infecciones a 8.9 en cuatro días

De 2.4 millones de equipos infectados a 8.9 millones en cuatro días (13.01.09 - 16.01.09). Sí, se trata de Downadup (también llamado Conficker) que ha logrado los encabezados gracias a esta infección acelerada [http://tinyurl.com/8rj3xf]. Es lo que sucede cuando dejamos nuestro Windows abandonado (sin parchar) y sin protección de antivirus y firewall personal.

El gusano Conficker (me hubiera gustado más que le llamaran Coflincker, suena mejor) se aprovecha de la debilidad solucionada ya con el parche MS08-067. ¿El creador de Conficker es un genio? No, de hecho es todo lo contrario, ya que su acelerada infección ha logrado la atención de los medios, cuestión que ya no es una buena práctica para los creadores de gusanos (el objetivo de un buen creador de gusanos actual es pasar desapercibido). Y tampoco es un genio porque nosotros, los usuarios, se lo facilitamos enormemente al dejar Windows sin parchar o al tener una copia pirata que no recibe actualizaciones precisamente por ser pirata. Vamos, el MS08-067 salió hace meses, ya era hora de que lo hubiéramos aplicado, cierto?

Si actualizamos, tenemos antivirus y firewall personal entonces estamos del otro lado y no tenemos (casi) nada de qué preocuparnos y el Conficker será sólo una noticia más de un gusano. Y por cierto, este gusano no es nada nuevo, ya en noviembre había comentado de este bicho [http://tinyurl.com/7hutsp].

Regresan los DDoS vía GoDaddy

 

GoDaddy, empresa para registrar dominios y "hostear" sites en EUA fue atacado con un DDoS (negación de servicio distribuido) el miércoles pasado [http://tinyurl.com/9baje9]. A la pregunta explícita de si sospechan de alguien (¿competencia?), al empresa GoDaddy guarda silencio. Sea quien sea, se deben de enterar que los DDoS ya pasaron de moda hace varios años.

 

No me imagino a un competidor con una actitud tan inmadura como para llevar a cabo un ataque de DDoS…el año 2000 quedó atrás, y verdaderamente creen que perderán clientes los de GoDaddy por un ataque infantil de DDoS? Si es así, maduren.

 

Yo me inclino a un cliente insatisfecho con el servicio de GoDaddy que tuvo el conocimiento y motivación para hacer un DDoS. Sí, ya sé, no deberíamos de estar hablando de un tema sin importancia. Simplemente me llamó la atención la noticia porque me recordó a los viejos tiempos donde los DDoS reinaban…será el atacante un romántico empedernido? Hasta raya en lo gracioso.

 

Respecto al MS09-001

Normalmente no posteo sobre parches (todos los días tendría decenas de entradas). Pero ayer Microsoft publicó su parche y aunque no me preocupo demasiado, es de considerar porque  no se requiere participación del usuario y se explota vía red por medio de paquetes al SMB. No hay código de explotación y el protocolo SMB lo usan mucho los controladores de dominio.

En fin, sólo sería agilizar la aplicación del parche más de lo normal sin llegar a la emergencia.
[http://www.microsoft.com/technet/security/Bulletin/MS09-001.mspx]

Los 25 más graves errores.

La NSA, DHS, Verisign, Microosft, Symantec y otras organziaciones se juntaron y acabaron haciendo un documento [http://www.sans.org/top25errors/] muy importante con una compilación de los 25 errores más graves que se cometen a la hora de programar. Pienso que cualquier organziación que codifique debe de darle un vistazo a este documento y hacer que sus programadores la lean (al menos). Mejor aún sería que tomaran acciones para evitar esos errores. Y no, no es una lista más.

 

Sabemos que los errores de programación son la fuente más importante de las debilidades que acaban en explotación que luego se convierten en troyanos, gusanos y todo tipo de código malicioso. En pocas palabras, si un programa estuviera libre de errores de programación, le haríamos la vida imposible a los atacantes y los orillaríamos casi únicamente a hacer ataques de ingeniería social ante la imposibilidad de explotar el código.

 

Esta lista de los 25 errores más comunes no la veo como una lista más que sale ocasionalmente en las noticias de seguridad. Los expertos y organizaciones involucradas son de tal importancia que no podemos implemente ignorarla. Lo mejor que podemos hacer es turnar esta lista al área de programación y exigir que nos digan si entre sus desarrollos están tomando en cuenta estas recomendaciones y de lo contrario pedirles un plan de acción para incorporarlas. La lista tiene también una parte de cómo evitar estos errores y hasta cursos que se pueden tomar.

Virus Bulletin certificará productos antispam.

 

Virus Bulletin es conocida principalmente por sus certificaciones de productos antivirus (también tiene una muy buena revista). Ahora anuncia que tiene planes ya para certificar también productos de antispam. Enhorabuena. Muchas veces necesitamos parámetros para decidir qué producto es mejor (o de los mejores) y andamos buscando desesperadamente un comparativo que nos ayude a decidir.

 

Así es que la próxima vez que vayan a conseguir un antispam, dense una vuelta por Virus Bulletin para ver cuáles son los productos mejor calificados y no comprarlos sólo porque el fabricante o proveedor dice que su producto es el mejor (todos lo dicen, cierto?).

 

Ahora que nueve de cada diez correos es spam, es necesaria una herramienta antispam efectiva que nos devuelva el tiempo invertido en estar borrando spam.

Hackean cuentas de Twitter

 

Un hacker de 18 años "obtuvo" una cuenta de una administrador de Twitter (el famoso sitio de micro-blogging) y con estos permisos se adueñó de varias cuentas de famosos como Britney u Obama y puso mensajes a su nombre, digamos de cierta manera, indebidos. ¿Cómo obtuvo la cuenta de administración? Haciendo un ataque de diccionario y encontrando que la contraseña de un empleado de soporte de Twitter era "happiness".

 

Muchos se quejan de la seguridad de Twitter y de que "cómo es posible que esto suceda". Admito que un administrador que tiene la contraseña "happiness" no es alguien que sepa mucho de cómo construir contraseñas seguras. Pero por otro lado, qué podemos esperar de un servicio que es gratuito? ¿Tenemos derecho a quejarnos y alarmarnos sobre la seguridad que este sitio brinda a sus usuarios? Sobre todo Twitter, que hasta el momento ni siquiera tiene un modelo de negocio bien definido. Desde el momento en que abres una cuenta con uno de estos sitios gratuitos (gmail, hotmail, twitter) debes de saber que no puedes esperar demasiado en cuestiones de seguridad (o del servicio en general) y que no podrás quejarte demasiado si hackean tu cuenta. Tal vez Obama o Britney puedan hacer escuchar su voz, pero si hackean mi cuenta, exactamente qué podría hacer? Nada. Debí saberlo.

 

Muchos dan por hecho el nivel del servicio y seguridad de estos sitios gratuitos y con este ejemplo de Britney y Obama nos podemos dar cuenta de que las cosas son diferentes. Es todo por el momento, debo de ir a mi GMail para ver si me llegó ese correo tan importante que estoy esperando (¿cuándo aprenderé?).

 

Criptología durante la Guerra Fría (cortesía de la NSA)

 

La NSA ha liberado unos documentos de lo que fue la criptología en la era de la Guerra Fría. La documentación está densa aunque para algunos puede resultar interesante, sobre todo por cuestiones bibliográficas o para hacer un trabajo académico de investigación.

Aquí están los documentos:

 

Book I: The Struggle for Centralization

Book II: Centralization Wins, 1960-1972

Book II: Centralization Wins

Book III: Retrenchment and Reform

 

 

Reino Unido a favor del hackeo "legal"

 

En el Reino Unido se está proponiendo que la policía pueda hackear equipos de cómputo cuyos dueños sean sospechosos de haber cometido algún ilícito. Sin orden judicial. Sólo con que se considere que el hackeo es “proporcionado y necesario”. ¿El objetivo? Hackear computadoras de sospechosos de terrorismo, pedofilia y un largo etcétera.

 

Se permite hackear al equipo básicamente usando diversas técnicas como entrar a la casa del sospechoso e instalar un programa espía, intervenir el tráfico inalámbrico del equipo o mandar un correo con un software espía. Bueno, bien para atrapar a los “malosos”, pero por el hecho de que no se necesita orden judicial sino sólo una corazonada, apuesto a que más de un inocente será víctima de esta intrusión legal. Esto suponiendo que los ciber-policías de aquellos lugares están capacitados para fabricar y saber usar estas técnicas de hackeo.

 

Ahora los criminales del Reino Unido se deberán preocupar mucho más por la seguridad de sus equipos. Y los que son inocentes también…por aquellos de las equivocaciones. Hoy en día ya no se puede confiar en nadie. Mi predicción es que cada vez más países van a adoptar medidas similares…el Gran Hermano nos vigila.

 

El primer CVE que verá la luz

 

El MITRE tiene ya una candidata para ser la primera vulnerabilidad el 2009 que saldrá a la luz pública y es la CVE-2009-0022. ¡Bienvenida! Y esperemos que sea la primera de una lista corta...sí claro, como si fuera a suceder.

 

Reto Criptográfico del FBI

 

" Can you crack a code?" Eso es lo que nos dice el FBI en su página donde nos ofrecen un reto criptográfico para ver qué tan buenos somos rompiendo códigos cifrados. El reto está interesante y también podemos encontrar útil el documento de esta página llamado “Analysis of Criminal Codes and Ciphers”, entre otros más.

 

Ok, acepto que no es un reto que seleccionemos en este inicio de año sólo por el placer de tener un poco de diversión (mejor invertir el tiempo en ver Dr. House, cierto?), pero vale la pena al menos visitar la página por mera curiosidad. ¿Algún voluntario?

 

PD: espero que este no sea un método del FBI para “fichar” a los expertos en romper códigos criptográficos :-)

 

 

Sorpresas en la seguridad de las aplicaciones

Expertos en seguridad (entre ellos el famoso Gary McGraw) llegaron a diez sorpresivas conclusiones después de haber hecho unas entrevistas y análisis. La lectura de las diez "sorpresas" que se llevaron es interesante y la pueden leer aquí. Yo les resumo las tres que me parecieron las más relevantes.

 

a).- No hay métricas mágicas para la seguridad del software y las malas métricas de hecho hacen daño.

Es difícil que alguien venga a decirte que estas son la serie de métricas que debes de usar en tus programas de software para ver qué tan "seguros" son. No existen estas métricas "globales" que todo mundo debería usar. De hecho, usar malas métricas puede llevar a que sean mal interpretadas, abusadas o ignoradas. Lo mejor es crear métricas que funcionen para uno. ¿Cómo indicamos que una aplicación es segura por medio de métricas? Puede ser que no sea suficiente decir simplemente “esta aplicación (es/ no es) segura”.

 

b).- El diseño que contempla la seguridad es difícil (tal vez más de lo que pensamos).

Los problemas de seguridad vienen básicamente en dos fases: en la de diseño (arquitectura) y en la de implementación (codificación). ¿Quién realmente introduce la parte de seguridad en la fase de diseño (arquitectura) y también al momento de codificar? Sí, hacer un buen diseño de seguridad de un programa no es nada trivial, y no muchos lo hacen o lo hacen mal y a la ligera.

 

c).- Los programadores son los últimos en preocuparse por la codificación segura.

Los medios, los consultores y los investigadores de seguridad se preocupan más por el tema de codificación segura que los propios programadores (debería de ser exactamente lo contrario). Lo que les importa realmente a los codificadores es que un programa sea FUNCIONAL, y no realmente seguro en su diseño y en su codificación (que te pida una contraseña no significa para nada que tiene un diseño y una codificación adecuadamente segura). Apuesto una quincena a que en cualquier aplicación hecha "en casa" de una organización promedio podremos encontrar más de 50 vulnerabilidades (al menos). Efectivamente, actualmente realmente nos interesa que una aplicación sirva, no que sea segura en su diseño y codificación.

 

Si tienen unos diez minutos, recomiendo la lectura de las "diez sorpresas".

 

Foto peculiar desde dentro del metro

Alguien se divirtió poniendo estos letreros. ¿Habrá sido por órden de alguien? :-)