Junio 2008

La razita mexxie... apoyando a Zoé!

Zoé se presenta por primera vez en Argentina el próximo Domingo 29 de Junio, como parte del evento “Ciudad Emergente”. El concierto de Zoé se llevará a cabo en el Centro Cultural Recoleta a las 8 pm. AWEBOOO!!!

Parece broma, pero no: una cafetera que se vende en EE.UU. con conexión a Internet dispone de una vulnerabilidad que puede ser aprovechada por un atacante remoto para modificar los parámetros con los que uno se hace el café. De hecho, este fallo de seguridad puede ser aprovechado para ganar acceso a máquinas Windows XP que estén conectadas a la cafetera. Parece que ya no hay nada que se les resista a los hackers.

Un mensaje en la lista de correo de SecurityFocus ha servido para demostrar que hasta las cafeteras son susceptibles de sufrir ataques de hackers en la actualidad. La Jura Impressa F90 es una cafetera de alta gama (1.800 dólares) que dispone de conexión a Internet y que permite configurarla y personalizarla, y si hay algún problema los ingenieros de soporte de la empresa pueden arreglarla a distancia.

Sin embargo, esas mismas prestaciones también posibilitan el ataque de hackers, y según los datos de ese mensaje de las listas de correo de SF un acceso remoto podría por ejemplo cambiar el tipo de café que uno se hace, cambiar la cantidad de agua que se pone en cada vaso, o incluso romperla estableciendo parámetros de servicio que no son compatibles.

De hecho, el atacante remoto podría incluso acceder a máquinas XP que estén funcionando a nivel de usuario conectadas a la cafetera gracias a la vulnerabilidad, así que el problema es mucho más serio de lo que podría pensarse.

El pasado martes 13 de mayo de 2008, se anunció un grave fallo de seguridad que afectaba a todas las claves criptográficas RSA y DSA generadas en sistemas Linux Debian mediante OpenSSL en los últimos dos años. Esto significa que están afectados todos los certificados y claves públicas de multitud de servicios, como por ejemplo, OpenSSH, OpenSSL, telnetd-SSL, ftpd-SSL, OpenVPN y muchos más. El fallo consiste básicamente en que las claves generadas son predecibles, debido a una falta de aleatoriedad que limita el espacio de las claves al número de proceso (32.768 combinaciones).

En román paladino, lo que quiere decir todo esto, entre otras cosas, es que pueden verse comprometidas (atacadas, vulneradas) muchísimas máquinas en Internet, ya que los atacantes podrían acceder como root (superusuario del sistema) o como cualquier otro usuario a todas aquellas máquinas que permitan acceso remoto al sistema mediante claves o certificados (sin usar contraseñas), siempre que esas claves hayan sido generadas en un sistema Linux Debian mediante openSSL (que, con seguridad, son muchísimas). Asimismo, pueden falsearse firmas electrónicas y pueden descifrarse ficheros encriptados que hayan utilizado este tipo de claves comprometidas.

No es mi intención tratar en este post los detalles técnicos de dicho fallo, pero si el lector desea profundizar en ello, puede hacerlo en los siguientes enlaces: aviso en la página de debian, full-disclosure: seclist.org y anuncio en metasploit. En cualquier caso, después de analizar la información publicada, es indudable que estamos ante uno de los fallos de seguridad más graves de los útimos años. El objetivo de este post es hacer una reflexión sobre las políticas de full-disclosure o divulgación completa y detallada de las vulnerabilidades.

Para los que no lo sepan, una política full-disclosure es aquella en la que, una vez detectado o identificado un problema de seguridad, se deben facilitar y revelar todos los hechos y detalles del problema. De hecho, lo que suelen hacer normalmente quienes detectan el problema, es avisar al responsable del software para que solucione el problema y después facilitar toda la información a "todo el mundo". La razón de esta política es obvia; si no se publica "a bombo y platillo" un fallo de seguridad, los afectados no sabrán que lo padecen y no tomarán las medidas oportunas para solucionarlo. Estarán en manos del desarrollador del software, que podrá tardar más o menos en corrgirlo, si es que lo hace. La contrapartida de esta polítca es que, al publicar todos los detalles, mucha gente podía utilizar dicho conocimiento del problema para aprovecharse de aquellos sistemas vulnerables que aún no han sido corregidos. Difícil dilema pero, sin duda, yo me inclino por defender la política de full-disclosure.

Pensemos en el caso del grave fallo de seguridad de OpenSSL. Si no se hubiese aplicado una politica de full-disclosure, en el mejor de los casos, los desarrolladores del software habrían publicado una actualización, normalmente con escasa o nula información del fallo corregido. Al no ser conscientes los usuarios de la existencia del fallo, no serían conscientes del peligro al que se exponen y por tanto, no podrían calibrar la importancia y el impacto del problema en sus sistemas. Del otro modo, es posible que tarden mucho más de lo debido en corregir el problema, pero aunque lo hagan, no serían conscientes de que todas las claves generadas en los últimos dos años son vulnerables, así que, en general, seguirían padeciendo enormes riesgos de seguridad.

Podría establecerse un paralelismo con lo que ocurre en un accidente químico, biológico o nuclear. Si inmediatamente después del accidente se facilita toda la información posible, mucha gente tomará las decisiones correctas y minimizará los riesgos, otros entrarán en pánico y cometerán errores. Lo importante es que la mayoría se enterará a tiempo del problema y dependerá de si mismo para salvarse, mientras que si no se facilita la información, por mucho que se intente solucionar el problema, mucha gente padecerá las consecuencias ya que desconocen lo que pueden y lo que no pueden hacer.

En definitiva, una política de full-disclosure, aunque tiene puntos negativos (daños colaterales), generalmente es mejor que una política de no-información ya que ésta última deja expuesto a todo el mundo al problema que tarde o temprano será descubierto y explotado por alguien contra una mayoría desconocedora del asunto y no preparada para afrontarlo.

Con mis amigos Mauricio Campiglia, Gustavo Boksar, JP y Mariana en el Fun Fun... en Montevideo, Uruguay. Gracias Mauri & Perro por su buena compañia y amistad, los veo en las Jornadas Regionales acá en Buenos Aires con unos buenos tequilas. JP y Mar, a donde el proximo trip?

"La realidad de mañana se construye a partir de los sueños de hoy, no bajemos la mirada, no seamos mezquinos ni humildes en nuestros ideales. Seamos realistas, soñemos lo imposible. Si lo soñamos seguramente podremos lograrlo, si no lo soñamos es seguro que nunca llegaremos allí."

Wow, tenía un poco olvidado esto... prometo ya no dejar pasar mucho tiempos sin actualizar mi blog. Ya cumplí 3 meses viviendo en Buenos Aires, en donde acá he conocido buenos amigos (tambien extraño a mi banda en México), la familia porteña!! en donde siempre hay un buen motivo para poder reunirnos y tomarnos algo frio Algunos en este año continuan sus proyectos en México, otros nos quedamos por mas tiempo acá en Argentina al menos unos años mas ó a vivir permanente? no lo sé, ya veremos que sucede. Lo que si sé, es que aunque la vida nos guie por caminos diferentes sabemos que cuando haya oportunidad de poder reunirnos nuevamente lo haremos con mucho gusto.

Ya desde 1 mes estoy trabajando en una Consultora de Seguridad, me siento muy contento y agusto... el ambiente laboral es re-excelente y mis compañeros son muy buena onda; soy el único extranjero en la oficina de Buenos Aires... en toda la oficina de Argentina somos aprox unas 15 personas... y en la oficina que esta en Chile son mas de 50, en la de Perú desconosco. Tuve la oportunidad de conocer al CEO de la compañia, grosoo!

Este fin de semana ire a Montevideo, Uruguay... ya que el lunes es feriado acá en Argentina y aprovechare a pasar los 3 dias. Hay veces que me gane la nostalgia de poder estan en México con las personas que quiero, solo son en ratos... en Diciembre regresare a pasar los dias festivos y sé que se pasara rapido, ya para cuando acuerde estare haciendo maleta para ir a visitar a mi familia, solo podre estar unos pocos dias porque tengo que regresar a trabajar. Extraño la comidaaa... los tacos... el pozole... el menudo... chilaquiles... las tortillas... jaja bueno, y podria seguir nombrando... pero bueno, ya pasara.. jaja

JRSL - http://www.jornadasregionales.org
8vas. Jornadas Regionales de Software Libre
Capital Federal - 20, 21 y 22 de Agosto
CaFeLUG

CaFeLUG - Grupo de Usuarios de Software Libre de la Capital Federal Argentina, llama a la participación de la comunidad de software libre a las 8vas. Jornadas Regionales de Software Libre.

La temática del evento es sobre las nuevas tecnologías que se esten desarollando en el Software Libre, también tendrá lugar muchas otras temáticas relacionadas pero estas serán las primordiales.

El autor de cada charla seleccionada podrá participar presencialmente, como orador en el evento. En los casos en que la charla sea realizada por varios autores, se permitirá un máximo de 3 oradores.

Aclaración: Por cuestiones presupuestarias, sólo podrá abonar algunos de los pasajes, total o parcialmente, a los autores seleccionados que residan fuera de Capital Federal o Gran Buenos Aires.

Agradecemos la contribución de todos en la difusión de este llamado y del evento en si mediante los banners diseñados para tal fin y que se encuentran en http://jornadas.cafelug.org.ar/8/es/2008/05/27/ayudanos/

*Dónde enviar las Charlas*

Las charlas tienen que ser enviadas en texto plano y como archivo adjunto (en algún formato libre [1]) a la siguiente dirección de correo electrónico jrsl-cfch[en]cafelug.org.ar Las charlas van a ser recibidas hasta el 27 de Julio inclusive.

*Cómo enviar las Charlas*

El envío de la propuesta de charla debe tener los siguientes datos:

• Título:
• Autor(es): Nombre y apellido, breve descripción de cada uno, foto, lugar de residencia, asociación, LUG, organismo, o empresa a la que pertenece, si corresponde.
• Tipo : Puede ser Charla tradicional o Taller (Con PC)
• Tiempo estimado de duración: Las charlas generalmente son de 45' y los talleres tiene una duración de 1:45. En caso de que sea mayor o menor el tiempo requerido solicitamos su justificación.
• Breve descripción de la charla: Uno o dos párrafo(s) que explique -no tan brevemente- el contenido de la presentación.
• Nivel objetivo de la charla: Clasificar dentro de: newbie (nuevo)/intermedio/avanzado/experto)
• Tipo de publico: Público en general, promotores de SL, alumnos de escuelas medias, alumnos de educación superior, docentes de escuelas medias, docentes en general, capacitadores.
• Conocimientos previos: Especificar que conocimientos previos deberán tener los asistentes.
• Temática: programación, multimedia, comunicaciones, estación de trabajo, servicios de red, interoperabilidad, educación, kernel, etc.
• Teléfono del/los autor/es: Para poder comunicarnos.
• Residencia del/los autor/es.

[1] *Qué formato deben tener las Presentaciones*:

El envío de las diapositivas y/o presentaciones debe tener alguno de los siguientes formatos:

• Openoffice.org presentation
• HTML standard
• Postscript
• PDF
• Texto plano

*Licencia*

Debe especificarse una licencia que permita que CaFeLUG distribuya el material en un CD-Live o de Documentación y que permita ser descargado del sitio web de CaFeLUG. -- Prensa - CaFeLUG http://www.jornadasregionales.org