¿Qué sucede con mi descarga de la reciente actualización de seguridad de Apple?

12

La actualización en cuestión es la actualización combinada de los Mavericks que, entre otras cosas, pretende reparar la reciente vulnerabilidad de SSL / agujero enorme.

Este problema realmente me molestó, así que decidí obtener la clave PGP de Apple y verificarla lo mejor que pudiera. Y curiosé mi tráfico con Wireshark durante las descargas. Aquí están mis conclusiones:

  • Obtener y verificar la clave PGP de Apple fue una pérdida de tiempo, porque, por lo que puedo decir, no emiten firmas para las actualizaciones de software
  • El descargador de actualizaciones se conecta a través de HTTPS a su dominio localizador de descargas de software, que redirige a la actualización real en un CDN (en mi caso apple.vo.llnwd.net)
  • Cada bit del paquete de actualización viene a través de HTTP antiguo y simple desde el CDN
  • Cada paquete individual de la actualización va seguido de un ACK duplicado (esto solo ocurre con la actualización, todas mis otras descargas están bien, así que no creo que sea mi infraestructura)
  • La descarga manual del archivo dmg desde aquí es HTTP por defecto. La aplicación de HTTPS provoca una redirección al URI real del archivo (HTTP), el HTTPS no está habilitado para este URI.

Apple (probablemente respondiendo a las críticas de antaño) dice específicamente que las actualizaciones se entregan a través de HTTPS, excepto cuando las "complicadas configuraciones de proxy" hacen esto imposible. He intentado descargar a través de mi conexión de vainilla y 2 VPNs offshore, y por amor y dinero no puedo obtener un enlace HTTPS para ese archivo (actualización de software o sitio web).

Mis preguntas son:

  1. En su opinión, ¿están ellos, o alguien entre ellos, jugando a buggers divertidos?
  2. ¿Hay alguna sospecha que se pueda extraer de todos esos ACK duplicados? (No sé lo suficiente sobre esto para siquiera especular)

Sospecho porque si era NSA / GCHQ y tenía una advertencia de semanas para interceptar y reemplazar blobs en puntos finales HTTP predecibles que se ejecutarán automáticamente porque la firma del código en millones de Las máquinas objetivo están completamente rotas, probablemente pensaría que la Navidad había llegado dos veces. No veo ninguna circunstancia en la que puedan dejar pasar esa oportunidad si fueran capaces de hacerlo, y de todo lo que he leído son más que capaces tal cosa.

    
pregunta CHT 27.02.2014 - 05:01
fuente

1 respuesta

1

(Lo que sigue es toda especulación, no sé cómo funciona el actualizador de Apple internamente).

Definitivamente hay arquitecturas que pueden realizar una actualización segura a través de HTTP. Casi todas las distribuciones de Linux distribuyen paquetes en texto plano y los verifican verificando los hashes (SHA-1, SHA-256, etc.) de los metadatos del repositorio. Los metadatos del repositorio, a su vez, están firmados con una clave GPG que su host verifica y se instaló con su medio de instalación original. (Si su medio de instalación original fue backdoored, todas las apuestas están desactivadas para siempre.)

Entonces, ¿qué tiene esto que ver con tu actualización de Apple? Apple podría estar usando un esquema similar: envíe un hash a través de HTTPS, descargue a través de HTTP y luego verifique el hash. Las actualizaciones de software como esta son un caso en el que todo lo que realmente necesita es integridad (sé que a algunas personas les gustaría la confidencialidad, pero seamos honestos, si un atacante ve que descarga X bytes a través de HTTPS desde apple.com, y la última actualización de Apple es X bytes, ya ha perdido la confidencialidad) y se puede lograr la integridad sin enviar el archivo a través de HTTPS.

De hecho, esta técnica podría ser preferible: Apple podría tener una pequeña cantidad de servidores que sirven metadatos de actualización bajo su control directo (es decir, URL y hash de la actualización) y luego usar un CDN de terceros para distribuir la actualización, reduciendo costos de ancho de banda, latencia, etc. Si la actualización fue atendida por la CDN directamente sobre HTTPS sin el paso de verificación (es decir, toda la integridad es de HTTPS), entonces la CDN (o alguien que comprometa la CDN) podría reemplazar la actualización con una modificación versión.

Si los ACK duplicados son o no algo de qué preocuparse es en gran parte una pregunta aparte. Mi nivel de preocupación dependería de varias cosas: ¿son ACK salientes o entrantes? ¿Qué son los TTLs? ¿Cuáles son los números de secuencia? Es realmente difícil de decir, pero sospecho que es mucho más probable que los ACK duplicados se deban a una mala configuración de la red en algún lugar (incluso si no es tu red) que por un atacante.

    
respondido por el David 22.03.2016 - 23:26
fuente

Lea otras preguntas en las etiquetas