22 julio 2011

Buenas prácticas de seguridad para publicación de proyectos

Ayer os contábamos el caso del malware incrustado en el instalador de CamStudio, probablemente debido a una intrusión en el servidor de descargas y modificación del fichero de instalación.

Éste no es un caso aislado, y es que a proyectos tan importantes como irssi, Wordpress, UnrealIRCd, ProFTPd o recientemente vsftpd también les ha pasado algo parecido.

Si bien no se puede decir que sea inevitable, se pueden tomar algunas medidas de seguridad para que las posibilidades de que ésto suceda se reduzcan al mínimo, o ayudar a detectar el problema lo antes posible para aplicar una solución.

1.- Publicar hashes de los ficheros
Ya sea mediante MD5, SHA1, SHA512, WHIRLPOOL u otro que nos guste más, es básico publicar junto con el paquete la huella del mismo para que los usuarios que lo descarguen puedan comprobar que es el mismo fichero que el autor subió. La elección del algoritmo debería depender del tamaño de los ficheros y la popularidad del mismo, por ejemplo, MD5 sería una buena opción para ficheros grandes por ser rápido y SHA1 para los pequeños.

Por supuesto, las huellas y los ficheros de descarga deben estar en diferentes sitios independientes.

2.- Publicar firmas GPG de los ficheros
La idea es la misma que la anterior, pero utilizando GPG en vez de hashes.

3.- Separar sitio web y sitio de descargas
Por una razón lógica, y es que si consiguen hacer una intrusión en uno habrá discordancias que permitirán detectar el problema rápidamente. Por ejemplo, si tenemos los hashes en el sitio web y vulneran el sitio de descargas para reemplazar un paquete, no podrán cambiar también el hash de dicho paquete, y tanto los usuarios como el administrador podrán ver rápidamente que algo no funciona como debería.

4.- Evitar alojamientos o servicios compartidos
Para que no nos pase lo mismo que a Ettercap deberíamos evitar servicios compartidos de alojamiento como SourceForge o Google Code. Un fallo de seguridad en su sistema puede afectarnos directamente.

Por el mismo motivo también deberíamos evitar alojamientos compartidos, donde se comparte un único espacio con múltiples clientes.

5.- Comprobar la integridad de los ficheros en algún proceso
Si el proyecto consta de instalación no está de más que se compruebe la integridad del paquete durante el proceso teniendo como referencia los hashes almacenados en nuestro servidor. Si el proyecto no consta de instalación, se podría programar un pequeño script que realizara el proceso.

Con estas medidas podemos reducir significativamente el riesgo de que nuestro proyecto sufra alguna modificación malintencionada externa. ¿Se os ocurre alguna medida más? ¿Creéis que son medidas excesivas? ¿Las cumplen los proyectos, especialmente los de productos relacionados con la seguridad?

3 comments :

Ignacio Agulló dijo...

Después del incidente CamStudio y la indolencia con que los autores han reaccionado a algo tan grave como que su sitio web contuviera enlaces apuntados a descargas maliciosas, es muy oportuno este artículo.

Observando la lista de buenas prácticas, a mi me parece que hay que hablar de un tema previo.  Hasta ahora distinguimos entre "seguridad por claridad" y "seguridad por oscuridad"; yo creo que hay que distinguir también entre la "seguridad por calidad" y la "seguridad por cantidad".  La seguridad por cantidad consiste en confiar en la pereza de los malosos.   Confiar en que, aunque logren acceso suficiente, se limitarán a utilizarlo para introducir malware y serán demasiado perezosos para además engañar los mecanismos de autenticación.  Al igual que con la "seguridad por oscuridad", la "seguridad por cantidad" no me parece seguridad de verdad.

Muchos servidores ofrecen la descarga junto con el fichero de hash.  Ésto no es seguridad por calidad, es seguridad por cantidad.  Si consiguen que la descarga esté manipulada, también pueden conseguir que el fichero de hash esté manipulado.  Lo mismo sirve también para un fichero de firmas a no ser que te molestes en comprobar la huella.

Por eso creo que aciertas con el punto tres:
-La descarga, en un servidor de descargas.
-El fichero de hash o de firma, en el servidor web.

Ahora, sólo introduciéndose en ambos servidores lograrán autenticar una descarga falsa.

El punto 4 me parece inalcanzable.  Aunque tengas tu código en un servidor propio en vez de SourceForge, ¿ello te garantiza que tu servidor será inexpugnable?

La autocomprobación en los programas instaladores es otro ejemplo de seguridad por cantidad: si consiguen manipular el programa, también pueden conseguir manipular el mecanismo de autocomprobación.

Donde la autocomprobación sí es seguridad por calidad es a la hora de incorporar actualizaciones a través de la red.  Pero entonces, al igual que en el punto 3, el proceso de actualización debe descargar la actualización desde un servidor de descargas y el fichero de hash o firma desde un servidor web.

Alvaro Guzman Lopez dijo...

Yo no se si os pase a los demas o no, pero veo los hashes a la hora de descargarme algun programa y me da bastante pereza comprobarlo... no se si existirá o no pero estaría bien que por ejemplo, en la ventana de descargas de vuestro navegador preferido tuviesemos un boton o un cadro de texto para pegar el hash de la web y que el navegador calcule el hash del archivo descargado y lo compruebe.

lost-perdidos dijo...

No estoy de acuerdo con el punto 4, evitar servicios como Google Code. Los fallos de seguridad pueden afectar de igual o peor forma a una web desarrollada por ti mismo. Google ofrece una garantía de confiabilidad superior a cualquier otro sitio, principalmente por la elevada seguridad con la que cuentan sus servicios y su programa de recompensas ante fallos importantes.