it-swarm-es.com

¿El hashing de un archivo de un sitio web no firmado da una falsa sensación de seguridad?

Considera esto. Muchos sitios web con descargas de software también ponen a disposición hashes MD5 o SHA1 para que los usuarios verifiquen la integridad de los archivos descargados. Sin embargo, pocos de estos sitios en realidad usan cifrado HTTPS o firmas digitales en el sitio web.

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 del hash del archivo? ¿No establece esto una falsa sensación de seguridad, ya que (en ausencia de una firma digital) tanto la descarga como el hash podrían haber sido alterados, sin el conocimiento del usuario?

46
Iszi

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 del hash del archivo?

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

Sin embargo, en realidad no hay mucha seguridad adicional. Un cracker suficientemente capacitado puede reemplazar el archivo con una versión modificada maliciosamente 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 como el hash con el suyo.

57
yfeldblum

El beneficio allí es de hecho limitado. Como señaló, si puede reemplazar una cosa en un sitio, probablemente pueda reemplazar ambas.

Sin embargo, esto tiene algunos beneficios:

  • Permite que otros sitios alojen archivos grandes con integridad verificada. Con eso puedo tomar el archivo de un tercero aleatorio en el que no tengo razones para confiar y aún así verificar que es 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 antiguo hash 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 se puede obtener mayor seguridad 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 reemplazando la clave como lo hizo al reemplazar el hash. Los proyectos verdaderamente a gran escala que tienen una distribución independiente necesitan esta capa adicional (se me ocurre Debian), pero creo que pocos se beneficiarían de ella.

18
Jeff Ferland

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

  • el valor hash debe distribuirse a través de un protocolo que garantice la integridad (por ejemplo, HTTPS);
  • el archivo descargado no debe no 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, porque luego podría modificar el hash tal como podría modificar el archivo.

n ejemplo de la utilidad del hash publicado es cuando descargas el archivo en alguna fecha, y luego quieres verificar que la copia que tienes es correcta, porque no confías necesariamente en la integridad de su almacenamiento local (por ejemplo, estaba en una memoria USB que podría haber sido robada temporalmente por una persona con malas intenciones). Otro ejemplo es cuando la descarga en sí proviene de una red p2p, porque tales cosas son muy eficientes para distribuir software masivo a un muchos clientes (eso es lo que hace Blizzard Downloader): use el p2p para obtener el archivo, luego obtenga el valor hash pequeño del sitio HTTPS principal. n tercer ejemplo (con el que me encuentro profesionalmente) es cuando construyo un sistema confiable bajo condiciones de auditoría severas (por ejemplo, creando una nueva CA raíz): desea que el auditor pueda verificar que el software utilizado es genuino . Si se distribuye un archivo hash (a través de HTTPS), entonces el auditor solo tiene que verificarlo en un archivo local; de lo contrario, el auditor debe presenciar la descarga completa. Dadas las tarifas por hora de los auditores, el hash es preferible.

8
Thomas Pornin

Tiene razón en que solo tener un hash sin procesar es de beneficio limitado, ya que también necesita distribuir el hash de manera segura, y la mayoría de las personas no saben cómo verificarlo adecuadamente o navegar por los muchos problemas posibles.

La forma correcta de obtener una buena seguridad es utilizar tecnología de clave pública para firmar los hashes y tenerla integrada a la perfección en todo el esquema de distribución de software. Todavía es necesario distribuir de forma segura la clave pública, pero esto se puede hacer una vez, p. 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 forma segura literalmente 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 hacer ninguna verificación manual.

7
nealmcb

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 del hash 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 dañado en tránsito.

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

Por lo general, cuando se ofrece un resumen de hash, proviene 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 empresa de software, no una empresa de alojamiento, y no tienen el ancho de banda dentro y fuera de sus propios servidores para permitir miles de descargas simultáneas de banda ancha. Entonces, 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 piratear y que su buen nombre se vea 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 lo que permitió que un atacante ingrese a la red de un usuario corporativo y cause estragos.

La solución es que el productor de software mezcle 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 del gran sitio de alojamiento y verificar que lo que obtuvo fue lo que la compañía de software presentó allí yendo al sitio de la compañía de software y comparando el hash de archivo de la lista con uno desde el que 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 hackear tanto la nube como el sitio del productor de software para colocar un archivo en el lugar que pasará la comprobación de hash. Pueden fastidiar a las personas que no se molestan en verificar los hashes (que es mucha gente) simplemente pirateando el sitio de alojamiento y reemplazando el archivo, o pueden fastidiar a las personas que hacer verificar los hash pirateando 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 el de la compañía de software al hacer ambas cosas, lo cual es mucho más difícil.

6
KeithS

En términos generales, sí, un hash de un sitio http proporciona 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 verificar un hash a menudo lo ayudará a evitar perder tiempo en un CDROM defectuoso o una descarga corrupta.

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

5
nealmcb

Para su usuario doméstico, generalmente es "suficiente" la comodidad de que el archivo es correcto (y con eso quiero decir, la descarga funcionó y no hay corrupción), aunque desde una perspectiva de seguridad un atacante podría reemplazar tan fácilmente los hashes del archivo como el 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, desearía validar realmente el hash, probablemente mediante un mecanismo fuera de banda.

4
Rory Alsop

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

3
Steve

Hay algunos casos en los que verificar 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á alterando 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 manipulada.
    Por supuesto, podría lograr el mismo resultado descargando el mismo archivo dos veces a través de diferentes conexiones, pero esto es mucho más rápido.
  • Si al atacante, ya sea humano o de software, no le importó calcular el hash del archivo malicioso y reemplazar el hash original con él. Sin embargo, tenga cuidado, confiar en que los atacantes sean flojos no es la mejor defensa.
  • Si el archivo se descarga desde un sitio diferente al hash y ¡eso el sitio se ha visto comprometido pero el sitio que proporciona el hash era no . Por ejemplo, el archivo puede distribuirse a través de un espejo o CDN .
  • Si el hash proporcionado está firmado digitalmente con una clave de confianza. Por ejemplo, hashes firmados con una firma PGP confiable.

Aún así, al proporcionar hashes a través de una conexión no segura, la principal ventaja es que puede verificar que el archivo transmitido no se haya dañado en tránsito. Hoy en día esto no sucede muy a menudo, pero ocurre. Grabar un ISO de Linux corrupto puede proporcionarle una instalación corrupta que solo puede notar cuando ya es demasiado tarde. Parpadear su BIOS con una descarga corrupta podría ser aún peor.

Otra cosa a tener en cuenta es que, si bien proporcionar hashes puede dar una falsa sensación de seguridad, es muy probable que la persona que descarga el archivo lo haya descargado de todos modos, incluso si no hubiera hashes presentes. En ese caso, el pequeño beneficio de seguridad proporcionado por los hashes puede no superar nada en absoluto.

2
user2428118

Si realmente lo pensara, tener varios sitios para alojar su contenido descargable, junto con las teclas hash, detendría la mayoría de los ataques de reemplazo de fábrica. Una vez más, la suposición es el modelo de amenaza donde el atacante tendría que reemplazar in situ en lugar de en tránsito. Incluso con una sola fuente, las copias evitarían que cualquiera reemplace tanto el archivo como el hash.

Y, las fuentes de archivos pueden corromperse mediante la descarga.

0
mincewind

@Iszi aquí hay una historia corta ... (ok, tal vez no "corta" ... perdón por eso: P)

digamos que desea descargar [~ # ~] vlc [~ # ~] . Para ventanas. Última versión (ver. 1.1.5). Ok?

Su primer lugar para ir sería http://www.videolan.org ( sitio oficial ). Pero puede encontrar y obtener el "mismo" programa de 5.780.000 sitios. ¿Correcto? (google "descarga vlc 1.1.5").

El sitio oficial dice que MD5 del archivo es "988bc05f43e0790c6c0fd67118821d42" (ver enlace). Y puede obtener este programa (ver. 1.1.5) desde el servidor oficial videolan.org WEB server ( NO HTTPS ) . O haga clic en el enlace, redirija a Sourceforge y consígalo. Y nuevamente con NO HTTPS . Pero Sourceforge es un nombre grande . Confiable. ¿Correcto? 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.

Así que lo descarga de estas " fuentes confiables ".

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

Hay una (y solo una) forma de verificar que lo que obtuvo, es el archivo original . Sin modificaciones, sin modificaciones. Sin tocar Y eso es comparar el hash de eso. Pero con que? 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 amiga.

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

@Justice dijo que

Un cracker suficientemente capacitado puede reemplazar el archivo con una versión modificada maliciosamente 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 hash criptográficas de uso general hoy en día están diseñadas para ser resistentes 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 algún problema matemático difícil (como la factorización de enteros o el logaritmo discreto). Esas funciones se llaman demostrablemente seguras .

Y no creo que un "cracker suficientemente capacitado" pueda encontrar una "versión incorrecta" o hacer un archivo/binario/cualquiera de los original que querer y hacer tiene el mismo MD5/SHA-1 que el original. Y haz que se vea igual (foto). O con el mismo tamaño de archivo, o incluso hacer que se ejecute o tenga sentido (texto). Ni siquiera cerca. Puede hacerlo sin ser detectado por antivirus (si es malicioso). Esa es una historia diferente. Pero hay algunos casos realmente malos para colisiones reportados.

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

0
labmice