¿El hash de un archivo de un sitio web sin firma da una falsa sensación de seguridad?

  

Entonces, si está descargando un archivo de lo que efectivamente es una fuente no autenticada, y lo está validando con un hash de la misma fuente (o incluso otra fuente no autenticada), ¿cuál es el valor real de hashing del archivo?

El hash proporcionado le permite verificar dos veces que el archivo que descargó no se corrompió accidentalmente en tránsito, o que el archivo que descargó de otra fuente (un reflejo más rápido) es el mismo que el archivo disponible para descargar en este sitio web.

Sin embargo, no hay mucha seguridad adicional. Un cracker suficientemente capacitado puede reemplazar el archivo con una versión maliciosamente modificada y el hash con uno que coincida con el archivo modificado; o puede MITM las solicitudes a través de la red y reemplazar tanto el archivo solicitado con el suyo propio como el hash con el suyo.

El beneficio allí es limitado. Como señalaste, si puedes reemplazar una cosa en un sitio, probablemente puedas reemplazar ambas.

Sin embargo, esto tiene algunos beneficios:

• Permite que otros sitios alojen archivos grandes con integridad verificada. Con eso puedo capturar el archivo de una tercera parte aleatoria en la que no tengo motivos para confiar y aún verificar que sea un buen archivo basado en el sitio de origen (que puede tener un ancho de banda limitado).
• Si su sitio es lo suficientemente popular, es probable que haya suficientes copias del hash antiguo para confirmar rápidamente un compromiso para el público, incluso a través de archive.org y varios cachés de motores de búsqueda.

Si bien hay seguridad adicional que se obtiene al firmar archivos con un par de claves pública / privada, el beneficio práctico para la mayoría de las aplicaciones no es mayor con una clave que sin ella. Si publico mi clave en el sitio web y firmo todo en lugar de publicar el hash, un atacante puede lograr el mismo efecto al reemplazar la clave como lo hizo al reemplazar el hash. Los proyectos realmente a gran escala que tienen distribución independiente necesitan esta capa adicional (Debian viene a la mente), pero creo que pocos se beneficiarían de ella.

Para que el hash tenga algún valor relacionado con la seguridad, se deben cumplir las dos condiciones siguientes: ambas :

• el valor de hash debe distribuirse a través de un protocolo que garantice la integridad (por ejemplo, HTTPS);
• el archivo descargado no debe distribuirse a través de un protocolo que garantice la integridad;

porque, si el archivo también se sirve con HTTPS, el hash tiende a ser inútil: SSL ya garantiza la integridad durante la transferencia.

El hash no protegerá contra un atacante que tome el control del servidor, ya que podría modificar el hash del mismo modo que pudo modificar el archivo.

Un ejemplo de la utilidad del hash publicado es cuando descarga el archivo en alguna fecha y luego desea verificar que la copia que tiene es correcta, porque no necesariamente confía la integridad de su almacenamiento local (por ejemplo, estaba en una llave USB que podría haber sido robada temporalmente por una persona con malas intenciones). Otro ejemplo es cuando la descarga en sí provino de una red p2p, porque esas cosas son muy eficientes para distribuir software a gran cantidad de clientes (eso es lo que hace Blizzard Downloader): use el p2p para obtener el archivo, luego obtenga el valor de hash pequeño del sitio HTTPS principal. Un tercer ejemplo (con el que me encuentro profesionalmente) es cuando se construye un sistema confiable bajo condiciones de auditoría rigurosas (por ejemplo, se crea una nueva CA): desea que el auditor pueda verificar que el software utilizado es genuino . Si se distribuye un archivo hash (a través de HTTPS), el auditor solo tiene que compararlo con un archivo local; de lo contrario, el auditor deberá presenciar toda la descarga. Dadas las tarifas por hora de los auditores, el hash es preferible.

Tienes razón en que tener un hash en bruto es un beneficio limitado, ya que también necesitas distribuir el hash de forma segura, y la mayoría de las personas no saben cómo verificarlo correctamente o navegar por los muchos problemas posibles.

La forma correcta de obtener una buena seguridad es usar tecnología de clave pública para firmar los hashes, e integrarla perfectamente en todo el esquema de distribución de software. Todavía es necesario distribuir de manera segura la clave pública, pero esto se puede hacer una vez, por ejemplo. Cuando el sistema operativo está instalado. Supongo que eso es esencialmente lo que se hace con Windows y MacOS para las actualizaciones del sistema operativo y algunos paquetes importantes como Office.

Lo mejor de todo es cuando casi todo el software que necesita está cubierto por las mismas teclas estándar. Eso es esencialmente lo que sucede con la mayoría de las distribuciones de software de código abierto, como Debian, Ubuntu, Red Hat, Suse, etc. Distribuyen de manera segura decenas de miles de paquetes, todos firmados automáticamente con claves que se administran como parte de la distribución, y por lo tanto muy seguro Y sucede principalmente sin que nadie necesite realizar ninguna comprobación manual.

  

Entonces, si está descargando un archivo de lo que efectivamente es una fuente no autenticada, y lo está validando con un hash de la misma fuente (o incluso otra fuente no autenticada), ¿cuál es el valor real de hashing del archivo?

En esta situación, donde un hash se encuentra inmediatamente al lado de un enlace al archivo, el valor es principalmente para garantizar que el archivo no esté dañado o corrompido en tránsito.

Desde un punto de vista de seguridad, tienes razón; esto tiene muy poco valor para demostrar que el archivo no se ha manipulado, porque cualquiera que pueda ingresar y subir un archivo pirateado (o cambiar el enlace para que apunte a una copia pirateada) también podría reemplazar el hash que se encuentra a su lado. Es por eso que casi nunca se hace de esta manera cuando el objetivo es la seguridad.

Normalmente, cuando se ofrece un resumen de hash, viene directamente del productor del software. Ofrecen software para descargar, pero no están dispuestos a alojar directamente el software en sus propios servidores; son una compañía de software, no una empresa de hosting, y no tienen el ancho de banda dentro y fuera de sus propios servidores para permitir miles de descargas simultáneas de banda ancha. Por lo tanto, alquilan espacio y ancho de banda de un proveedor de la nube para proporcionar el mismo servicio.

Ahora, ellos no controlan esta nube; Es un sistema diferente mantenido por una compañía diferente, "mi casa, mis reglas". El proveedor de software está preocupado por la piratería y su buen nombre se ve empañado por un compromiso de la empresa de alojamiento y por una buena razón; este es un método común de ataque, y es el nombre de la compañía de software en el software que permitió a un atacante ingresar a la red de un usuario corporativo y causar estragos.

La solución es que el productor de software haga un hash de los archivos que se ofrecen para descargar en el sitio de alojamiento y presente ese hash desde sus propios sistemas bajo su control. Ahora, usted, el usuario final, puede descargar el software desde el gran sitio de alojamiento y verificar que lo que obtuvo fue lo que la compañía de software puso allí yendo al sitio de la compañía de software y comparando el hash de archivo enumerado con el que usted calcula. El archivo descargado. Esto requiere mucho menos ancho de banda para la compañía de software que alojar el archivo real para descargar. Ahora, ya no hay un solo punto de vulnerabilidad; un atacante debe piratear tanto la nube como el sitio del productor de software para colocar un archivo que pase la comprobación de hash. Pueden arruinar a las personas que no se molestan en revisar los hashes (que son muchas personas) simplemente pirateando el sitio de alojamiento y reemplazando el archivo, o pueden arruinar a las personas que hacen revisan los hashes hackeando el sitio del proveedor de software y cambiando los hash para que el hash del archivo real ya no coincida, pero solo pueden enmascarar realmente un archivo pirateado como propio de la compañía de software haciendo ambas cosas, lo cual es mucho más difícil.

En términos generales, sí, un hash de un sitio http ofrece poca o ninguna garantía de que los datos provienen de una fuente confiable.

Pero depende de su definición de seguridad, es decir, su modelo de amenaza. Un aspecto de la seguridad es la integridad de los datos, y la verificación de un hash a menudo lo ayudará a evitar perder tiempo en un CDROM defectuoso o una descarga dañada.

Es mucho mejor obtener software de un sistema de paquetes que ofrezca una buena autenticación desde el programador, a través del control de versiones, hasta el empaquetado y la distribución.

Para su usuario doméstico, por lo general es "suficiente" que el archivo sea correcto (y con eso quiero decir, la descarga funcionó y no hay daños), aunque desde un punto de vista de seguridad, un atacante podría reemplazar el archivo con la misma facilidad. hashes como los archivos si quisieran si están almacenados en la misma ubicación.

para una persona de seguridad corporativa o para algo un poco más sensible, querría realmente validar el hash, probablemente por un mecanismo fuera de banda.

En la situación que describiste, el único uso de una firma es realmente para asegurarte de que el archivo no esté dañado.

Hay algunos casos en los que comprobar el hash de un archivo podría ser un beneficio de seguridad, incluso si el hash no se descargó a través de una conexión segura:

• Si solo se está manipulando su conexión, puede visitar la página web que contiene el hash utilizando otra conexión (por ejemplo, una VPN segura). Si la página, cuando se ve a través de esa otra conexión, muestra el mismo hash, es mucho menos probable que haya sido manipulado.
  Por supuesto, puede obtener el mismo resultado descargando el mismo archivo dos veces a través de diferentes conexiones, pero esto es mucho más rápido.
• Si el atacante, ya sea humano o software, no se preocupó de calcular el hash del archivo malicioso y reemplazar el hash original con él. Sin embargo, tenga cuidado, confiar en que los atacantes sean perezosos no es la mejor defensa.
• Si el archivo se descarga desde un sitio diferente al hash y ese sitio se ha comprometido, pero el sitio que proporciona el hash no fue . Por ejemplo, el archivo se puede distribuir a través de un mirror o CDN .
• Si el hash proporcionado está firmado digitalmente con una clave de confianza. Por ejemplo, los hashes firmados con una firma PGP de confianza.

Aún así, cuando se proporcionan hashes a través de una conexión no segura, la principal ventaja es que puede verificar que el archivo transmitido no esté dañado durante el transporte. Hoy en día esto no sucede muy a menudo, pero ocurre. La grabación de una ISO de Linux dañada puede proporcionarle una instalación dañada que solo notará cuando ya sea demasiado tarde. La actualización de su BIOS con una descarga dañada podría ser aún peor.

Otra cosa a tener en cuenta es que, si bien el hecho de proporcionar hashes puede dar una falsa sensación de seguridad, es muy probable que la persona que descargue el archivo lo haya descargado de todos modos, incluso si no hubiera ningún hashes presente. En ese caso, el pequeño beneficio de seguridad provisto por los hash puede no ser mayor que nada.

@Iszi aquí hay una historia corta ... (ok, tal vez no sea "corta" ... lo siento por eso: P)

digamos que quieres descargar VLC . Para ventanas. Última versión (ver. 1.1.5). Ok?

Su primer lugar para ir sería enlace ( sitio oficial ). Pero puede encontrar y obtener el progreso "igual" de 5.780.000 sitios. ¿Verdad? (google "vlc download 1.1.5").

El sitio oficial dice que el MD5 del archivo es "988bc05f43e0790c6c0fd67118821d42" (ver enlace). Y puede obtener este prog (ver. 1.1.5) desde el sitio oficial servidor WEB de videolan.org ( NO HTTPS ). O haga clic en el enlace, redirija a Sourceforge y consígalo. Y otra vez con NO HTTPS . Pero Sourceforge es un nombre grande . Digno de confianza. ¿Derecha? Y adivina qué. Su tío que tiene VLC, le envía un enlace de rapidshare por correo electrónico, para descargarlo. Y tu amigo del trabajo también.

Por lo tanto, lo descarga de estas " fuentes confiables ".

Amigos, sitios, versiones, tíos. Confías en todos ellos. Correcto ? No lo creo. Al menos no deberías.

Hay una (y solo una) manera de verificar que lo que tienes, es el archivo original . Sin modificaciones, sin modificaciones. Sin tocar Y eso es comparar el hash de ello. ¿Pero con qué? Con el hash de la fuente oficial.

Sin HTTP (S), sin firmas digitales, sin servidor "Seguro" o "Confiable". Nada. No necesitas ninguno de estos. La integridad de los datos es tu amigo.

Es lo mismo con PGP / GnuPG. Puede detectar si un mensaje ha sido modificado desde que se completó.

@Justice dijo eso

  

Un cracker suficientemente capacitado puede reemplazar el archivo con una versión modificada malintencionadamente y el hash con uno que coincida con el archivo modificado

Claro, Colisiones MD5 se ha encontrado que existen. Y colisiones SHA-1 también existen. Pero para citar Wikipedia :

  

Las funciones de hash criptográficas en uso general en la actualidad están diseñadas para ser resistente a colisiones , pero solo muy pocas de ellas lo son absolutamente . MD5 y SHA-1 en particular, ambos han publicado técnicas más eficientes que la fuerza bruta para encontrar colisiones. Sin embargo, algunas funciones de compresión tienen una prueba de que encontrar colisión es al menos tan difícil como un problema matemático difícil (como la factorización de enteros o el logaritmo discreto). Estas funciones se denominan de forma segura .

Y no creo que un "cracker suficientemente capacitado" pueda encontrar una "versión incorrecta" o crear un archivo / binario / cualquiera del original que desee y make tiene el mismo MD5 / SHA-1 como el original. Y hacer que se vea igual (pic). O con el mismo tamaño de archivo, o incluso hacer que se ejecute o tenga sentido (texto). Ni siquiera cerca. Puede hacer que no se detecte para el antivirus (si es malicioso). Esa es una historia diferente. Pero hay algunos casos realmente malos para colisiones informados.

Entonces, descargue desde CUALQUIER (buena) fuente que le guste, pero compare el hash de fuente original . Y siempre hay una fuente original .

Si realmente lo pensaras, tener múltiples sitios para alojar tu contenido descargable, junto con las claves hash, detendría la mayoría de los ataques de reemplazo de la fábrica. Una vez más, el supuesto es el modelo de amenaza en el que el atacante tendría que reemplazar in situ en lugar de en tránsito. Incluso con una sola fuente, las copias evitarían que alguien reemplace tanto el archivo como el hash.

Y, las fuentes de archivos se pueden corromper con la descarga.