Asegurando un actualizador automático

Tienes que considerar lo que un atacante podría hacer. Puede agarrar su archivo de actualización, inyectarlo con malware, calcular un hash SHA, entregarlo a uno de sus clientes e infectarlo. Su computadora no lo rechazaría si solo estuviera viendo hashes.

Si su aplicación solo acepta archivos firmados, él no puede infectarlos.

Pero la verificación de archivos individuales puede o no ser suficiente, dependiendo de su código. Si solo prueba su código como una versión completa, el atacante podría posiblemente encontrar un error de interacción al mezclar una versión anterior de uno de sus módulos con su código más reciente. Debe considerar firmar una colección de módulos en la misma agrupación en la que está dispuesto a probar e implementar. De esa manera, usted implementa solo el cambio probado como un todo, nunca fragmentado.

Este tipo de ataque fue perpetrado en contra de Microsoft Update. Alguien podría descargar la lista de módulos pero luego interferir con la descarga de los módulos reales.

Este enfoque no solo podría reducir su huella de ataque, sino que podría servir para mejorar su experiencia de usuario final al garantizar que estén instalando paquetes completos que son exactamente lo que probó. Incluso podría ayudar a mantenerlos fuera del "infierno DLL".

Probablemente firmaría los archivos con una clave a la que no se puede acceder por Internet o el servidor de actualizaciones y solo instalaría los archivos que están firmados por esa clave. Esto evita que un compromiso de su servidor pueda comprometer a sus clientes.

SSL debe ayudar a asegurar que sus clientes no se conecten a un servidor de atacantes, pero no protegerá a sus clientes si su servidor está comprometido. La única forma de protegerse es asegurarse de que el servidor no pueda publicar un archivo que el actualizador acepte.

Este enfoque me parece bien.

Debido a que la comunicación está protegida con SSL, no es posible para un atacante insertar un archivo malicioso. Claro, SSL tiene algunos problemas, pero si un atacante puede romper SSL, puede hacer todo tipo de cosas malas.

Por supuesto, está confiando en el proveedor de software. Podrían deslizar código malicioso en una actualización. Pero entonces, tienes que confiar en ellos de todos modos, podrían haber introducido código malicioso en la versión inicial que ya estás ejecutando. Además, si no mantienen seguros sus sistemas, un tercero podría interrumpir y distribuir actualizaciones maliciosas.

Las actualizaciones definitivamente deben estar firmadas. Simplemente envíe la clave pública con la aplicación y firme las actualizaciones con la clave privada correspondiente. Si la firma no coincide, entonces la actualización no es de usted y no se instala.

Puedes hacer que GPG haga el trabajo pesado. Esta técnica es extremadamente común.