Baires Norte Lug

Últimamente esta de moda atacar a OpenOffice, por motivos económicos, de infraestructura, diseño, hasta llegar al punto de decir que es inseguro por ser software libre.
Esto viene a colación a lo que se dijo en la ultima conferencia BlackHat 2009 cuyo paper se encuentra para libre descarga y que se encargo de exagerar hasta el artazgo cierto personaje, empleado de Microsoft.
¿Sera que le tienen tanto miedo al software libre? ¿Sera que el modelo de negocio tradicional se esta acotando y ya no se puede vender lo que se vendía antes a Empresas y particulares?
O sera que Microsoft con esto tendrá el argumento para meter su estándar OOXML en Gobiernos e Instituciones con el pretexto de “es mas seguro”.

En el artículo se describen ciertas características del formato ODF (Open Document Format) que lo harían vulnerables a ciertos tipos de ataques:

-El archivo Manifest.xml (que contiene el listado de los archivos que componen el documento), y Documentsignatures.xml (que contiene las firmas)  no están ni firmados ni cifrados.
Esto tiene una razón que al parecer ignoran los autores del documento. ODF es un formato estándar aprobado por la ISO, y lo que se garantiza es que se pueda leer desde cualquier aplicación ya que las especificaciones son abiertas.
Si cerramos estos archivos lo único que estaríamos logrando es que solamente OpenOffice pueda abrirlos. Por lo que el formato no seria ni muy abierto ni muy estándar.
Además parece estúpido y redundante firmar el propio contenedor de las firmas y encima cifrarlo. Como se supone que cualquier aplicación se daría cuenta que el documento esta firmado si ni siquiera lo puede abrir?

-Macros:
En el documento se aseguro que también la firma de macros es insegura por dos razones:
1- Si uno se confunde y vuelve a firmar desde el menú de macro y el documento no contiene una, el documento no queda protegido.
2- La posibilidad de eliminar una macro, reemplazarla por otra y modificar el contenido de manifest.xml para que apunte a la macro maligna.
Reitero algo que ya dije, el autor se olvida que OpenOffice se instala con seguridad de Macros altas, por lo que si abrimos un documento conteniendo una macro y encima de procedencia incierta, automáticamente aparecerá un cartel de advertencia y no lo ejecutara.

-Ataque de virus a documentos no protegidos (página 45):
El autor asegura que es fácil hacerlo y como demostración, descompacta un documento (recordemos que ODF es un contenedor zip con una estructura de directorios y archivos). Procede a editar el archivo content.xml y realiza la siguiente modificación:

<text:p text:style-name=”Standard”>I am a simple
document.</text:p>

Por

<text:p text:style-name=”Standard”>I am a simple simple
(modified) document.</text:p>

Sorpresa! modifico el documento! Eureka!.
Que alguien le aviso que al ser un formato abierto y cuyas especificaciones son públicas, cualquiera puede armar una aplicación que lea, escriba o modifique un documento ODF. De eso se trata un estándar abierto!

-Ataque man in de middle:
Asegura que OpenOffice no verifica las firmas y que fácilmente se puede fabricar una firma falsa para hacerle creer que es verdadera.
Lo que muestra el documento es bastante fantasioso y digno de una película hollywodense. Pueden verificarlo a partir de la página 52.
A partir de los datos obtenidos de Meta.xml, Documentsignatures.xml y macrosignatures.xml y analizando la firma, genera otra aparentemente verdadera.
En el documento claramente se ve que inclusive necesita datos como creation-date, dc:date y editing-duration, que sinceramente no pude comprender, o tal vez se me paso, de en que parte los utiliza.
Nuevamente se olvidan que entre las opciones de OpenOffice existe una característica adicional tan criticada que en este caso ayudaría a evitar el tema de falsificado de firmas. La opción de remover datos personales al salvar el documento.
Al estar activa dicha opción, al menos algunos de los primeros datos que menciona quedan en 0.
Dice que haciendo lo siguiente:

openssl req -newkey rsa:1024 -x509 -keyout CharlieKeys.pem -out CharlieCert.cert

Y luego exportando el certificado  X509 al formato PKCS#12 :

openssl pkcs12 -export -in CharlieCertX509.pem -inkey CharlieKeys.pem -out CharlieCertX509.p12

Va a poder firmar el documento y hacerlo pasar por verdadero.
Ahora hay un pequeño detalle que se le escapo al que redacto el documento.
La segunda linea es errónea. En realidad debería ser así:

openssl pkcs12 -export -in CharlieCert.cert -inkey CharlieKeys.pem -out CharlieCertX509.p12

Lo que hacen estas lineas es armar un certificado autofirmado. Significa que la parte pública y privada son la misma persona, no hay entidad autorizante de por medio. Y justamente este tipo de certificado NO es recomendable para ambiente seguros ya que justamente es susceptible a este tipo de ataques.
Sí puede ser útil para un usuario final para intercambiar en forma “segura” las recetas de la abuela.
Se ve que esta gente o se pasa de viva o NO SABE ABSOLUTAMENTE NADA de seguridad.
Yo que ellos hubiera intentando hacer lo mismo con un certificado expedido por Verisign, Thwate o Entrust.
Realmente me sorprende que a OpenOffice se le haya escapado semejante error, asi que me dispuse a realizar mis propias pruebas.
Para ello utilice una maquina fisica y 1 virtual simulando ser 2 usuarios diferentes. Inclusive con 2 sistemas operativos diferentes. Maquina real con Linux y una virtual con XP. Genere el certificado real (Alice) en Windows xp y genere con sus datos el certificado falso en Linux. Procedi a generar un documento como indica el paper en Linux firmado con el fake y enviarlo a la virtual con Windows Xp.
Y sorprendentemente ¡no funciono!. OpenOffice indicó que el certificado no había sido posible verificar por mas que haya generado el fake con los mismos datos calcados del real.
Perdi varias horas intentando descubrir porque a ellos les funciona y a mi no.
Hasta que se me ocurrió releer el documento y prestar más atención. ¡Y ahí estaba!, el que escribió el documento, por las capturas de pantallas, utilizo el mismo equipo  y la misma sesión de usuario para simular 3 entidades diferentes: Alice, Bob y Charlie. Por lo que pierde absoluta validez la demostración.
¡Al menos se hubieran molestado en cambiar el wallpaper en cada captura!, asi por lo menos los mas entendidos no nos hubieramos dado cuenta de la farsa tan facilmente.
Si Charlie arma un certificado autofirmado desde el mismo equipo que Alice y encima en la misma sesión obviamente va a obtener una segunda firma que es ¡valida!.
¿Alguien puede explicar donde esta el agujero de seguridad que menciona el documento?
Habla de inyección de malware con esta tecnica, pero en realidad no inyecta absolutamente nada.
Lo que haces es:
-Abre el documento original y copia el contenido.
-Abre un documento nuevo y pega el mismo. Le agrega una macro “maligna” y lo firma con el nuevo certificado.
Luego para terminar la demostración, abre en la misma maquina el nuevo documento, que obviamente es otro documento valido!.
¿Alguien puede explicar que tiene de raro esto?.
Parece que a partir de ahora se redefine el concepto de “inyección” por “armo un nuevo documento y pego”.

Para mayor información sobre los certificados autofirmados les recomiendo la lectura de los siguientes documentos en Ingles:
http://www.sslshopper.com/article-when-are-self-signed-certificates-acceptable.html
http://www.freesoftwaremagazine.com/columns/self_signed_certificates_and_firefox_3_possible_solution

Antecedente de ataques a OpenOffice:
Desde que OpenOffice empezó a tener un crecimiento en cuanto a adopción por parte de los usuarios, empezaron a aparecer voces de alerta de la posibilidad de infecciones masivas de virus, algunos memorables:
Stardust – Junio de 2006
http://blogs.sun.com/malte/entry/some_information_about_stardust
Sb.Starbugs – Junio de 2006
http://blogs.sun.com/malte/entry/some_information_about_sb_starbugs
SB/Badbunny-a – Mayo de 2007
http://blogs.sun.com/malte/entry/sb_badbunny_a_harmless_little

Lo que tienen en común estos virus es que casualmente intentan explotar características mencionadas en el documento presentado en Blackhat pero ninguno lo logra.
Además notaran de la lectura de los enlaces, que tiempo después, las propias empresas de Antivirus se encargaron de desmentir que esos macrovirus hayan logrado franquear la seguridad de OpenOffice.

Como perlita y para finalizar, hurgando un poquito en el tiempo nos encontramos que en el año 2006 uno de los autores del documento Ion-depth analysis of the viral threats with OpenOffice.org documents es precisamente uno de los autores de este mismo documento.
En aquel entonces, cansado de tanto ataque, Malte Timmermann, ingeniero de SUN, decidió salir a contestarle:
http://blogs.sun.com/malte/entry/my_comments_on_on_the

ACTUALIZACION

Como era de esperase, Malte  Timmermann volvio a tomarse el trabajo de contestarle punto por punto demostrando una vez más lo equivocado que esta:

http://blogs.sun.com/malte/entry/comments_on_the_black_hat

Si alguien pago pasaje, estadía y entrada al evento para precenciar esta conferencia, les diría que reclamen su dinero porque al parecer fueron estafados.

ESTE TEXTO SE PUBLICA BAJO LICENCIA CREATIVE COMMONS BY-NC-SA 2.5 AR.

Por lo tanto, usted es libre de: 1) Copiarlo, distribuirlo y exhibirlo. 2) Hacer obras derivadas. Bajo las siguientes condiciones: 1) Debe dar atribución mencionando el nombre del autor y del LUG Zona Norte. En caso de las notas que no llevan firma, mencionar sólo el nombre del LUG.

2) Usted no puede usar esta obra con fines comerciales. 3) Si usted altera, transforma, o crea sobre este texto, sólo podrá distribuir la obra derivada resultante bajo una licencia idéntica a ésta.

Más detalles y texto legal de la licencia en: http://creativecommons.org/licenses/by-nc-sa/2.5/ar