¿Por qué los sitios web no proporcionan una suma de comprobación de sus archivos descargables?

Lo hacen! Muchos ejecutables de Windows tienen un certificado incorporado firmado por una CA en la que Microsoft confía. El sistema operativo comprueba este certificado antes de ejecutar el software. Se puede realizar una configuración adicional en evita que el software no firmado se ejecute , en lugar de solo mostrar una advertencia. Además, es posible crear aún más restricciones que solo permitan ejecutar ejecutables firmados por Microsoft, no solo ejecutables firmados por un editor de confianza de Microsoft.

Linux y los sistemas operativos relacionados no lo admiten todavía (ELF, a diferencia de PE32, no es compatible con certificados integrados), pero hay un pequeño impulso para hacerlo porque la mayoría de las instalaciones de software se realizan utilizando su administrador de paquetes nativo, que generalmente verifica El software. En este caso, no hay un certificado de una CA de confianza. Más bien, la firma es proporcionada por los mantenedores del repositorio de software y verificada por el administrador de paquetes durante la instalación.

Para descargas sensibles a la seguridad que necesariamente no son provistas por los administradores de paquetes y no pueden tener firmas integradas, a menudo se proporcionan hashes firmados. Este es el caso de las imágenes ISO de arranque en particular, aunque algunas solo proporcionan hashes no firmados, no firmados. Desafortunadamente, todavía hay numerosos ejemplos de ejecutables proporcionados en conexiones inseguras que no están firmadas simplemente porque los administradores del sitio web no entienden la importancia de la integridad y subestiman el riesgo de compromiso.

Mencionas CCleaner, por lo que es relevante vincular a ¿Una firma digital hubiera evitado el compromiso de CCleaner? La respuesta corta es que no habría evitado este compromiso en particular .

Esto nos da nuestro primer problema con el suministro de hashes: ¿En quién confiamos para firmar la compilación y qué confiamos en que verifiquen? ¿La firma simplemente representa el servidor de compilación oficial, que podría estar comprometido? ¿O representa una auditoría de seguridad real realizada por alguna parte de confianza previa?

Sin embargo, hay otros ataques que tal hash evitaría, por ejemplo, un espejo comprometido o fraudulento que ofrece una compilación alterada. En este caso, sería suficiente para la página principal del proyecto publicar un hash, que podría verificarse contra la descarga ofrecida por cualquier duplicado.

Sin embargo, esto nos lleva al segundo problema, que es uno de los problemas difíciles de la criptografía: distribución de claves (o, en este caso, distribución de firmas).

Para un hash sin firmar, simplemente confía en la página que muestra que el hash no ha sido manipulado. Un hash firmado a primera vista parece mejor, pero aún tiene que descargar la clave pública de algún lugar, por lo que aún confía en la fuente de esa clave. Si un atacante puede dirigir a un usuario a una página de descarga falsa, puede agregar un enlace a una clave pública de su elección, y el usuario obtendrá una falsa sensación de seguridad al verificar el hash de una descarga comprometida.

La alternativa es tener una autoridad central en la que confíe para múltiples aplicaciones diferentes: este es el principio detrás de la firma de controladores de Windows, los administradores de paquetes de Linux y las tiendas de aplicaciones de teléfonos (y también detrás de los certificados utilizados para los sitios web de HTTPS). Ahora tiene un nuevo problema: ¿por qué confía en esas autoridades centrales? ¿Están auditando directamente el código fuente y construyen los procesos de los archivos que está descargando? ¿O están delegando el fideicomiso, a través de un certificado firmado a la inversa, en base a la seguridad de la parte que produce el software? Además, aún necesita adquirir la clave pública raíz de alguna manera, probablemente se incluyó en algunos medios de instalación confiables cuando instaló el sistema operativo / tienda de aplicaciones / administrador de paquetes.

Al final, la publicación de un hash será más útil para proyectos grandes, donde:

• es probable que el mismo usuario descargue y verifique varias versiones, o diferentes aplicaciones, con la misma clave pública;
• y es probable que la fuente de la clave pública sea diferente del servidor que ofrece la descarga (un servidor diferente o algún medio físico)

Pero incluso entonces, no puede arreglar todas las vulnerabilidades, como demostró CCleaner; y existe el peligro de dar a los usuarios una falsa sensación de seguridad.

Porque la mayoría de los usuarios no verifican el hash de todos modos.

Se necesitaría un protocolo de descarga común que automatice y aplique la verificación de firmas para que esto realmente haga mella en la propagación de malware.

Eso aún no sería perfecto: un servidor pirateado también podría publicar un hash diferente. Firmar el software en sí, al igual que con los controladores de Windows, probablemente tenga más posibilidades de causar un impacto. Ambos podrían hacerse también.

Estoy viendo más hash (comúnmente md5) que se muestra en el sitio relacionado con linux . Principalmente, cuando se proporcionan iso .

No quieres instalar un sistema operativo desde una ISO dañada, ¿verdad?

También encontrará el hash de Windows 10 ISO en la página de descarga.

El hash se usa aquí solo para verificar la integridad de los archivos descargados.

Cuando necesite verificar que el archivo no haya sido alterado, en un sitio serio, proporcione una firma de clave GPG que necesite verificar con una clave GPG. Por ejemplo, tails.boum.org hace eso.

Porque es casi inútil formar una perspectiva de seguridad. Los hash al lado de las descargas son una ventanilla única para los compromisos; el atacante actualiza el hash en el mismo lugar en el que está vinculada la descarga. La descarga ni siquiera se debe reemplazar, se puede vincular a un sitio de terceros, ya que el html para usuarios es lo que está bajo ataque.

Es un poco cómodo si un sitio de terceros alberga el hash, pero ha pasado mucho tiempo desde que lo he visto implementado, e incluso entonces, solo significa que se deben comprometer dos sitios en lugar de uno. Si el hash está al lado del archivo en una carpeta FTP, ¿qué tan difícil es reemplazar ambos, considerando que tienen los mismos permisos? A menos que uno sea un objetivo externo reforzado, ¿qué es lo que lo hace más seguro que solo la página / carpeta de oferta de enlaces?

La idea de validar hashes de descarga es buena, simplemente no es fácil enviar el hash al usuario de una manera más confiable que el enlace en sí. Todavía son buenos para la integridad, pero no para la autenticación en una sola autoridad. Una autoridad central estaría bien, pero afaik, todavía no hay una.