Uno de los procesos potencialmente más inseguros en cualquier ordenador es el propio arranque del sistema. El desarrollador del kernel y experto en seguridad Matthew Garrett explica por qué.
Hace unos días se celebraron las conferencias anuales del Chaos Computer Club y en una de ellas habló Garrett, un influyente desarrollador de Linux que también trabaja en la seguridad de CoreOS. En referencia a la charla de una hora de duración, ha publicado un extracto en su blog que dice lo siguiente:
Esta semana he dado un presentación en el 32C3. Una de las cosas que dije fue «si alguno de vosotros estáis haciendo trabajo realmente confidencial en portátiles Apple, parad. Por el amor de dios, parad por favor». En realidad no tuve tiempo para entrar en detalles pero ahora estoy sentado en un avión con un buen dolor de cabeza y la pseudoefedrina no ha hecho todavía efecto así que hallá vamos.
La premisa inicial de mi presentación era que es muy difícil determinar si tu sistema está en un estado digno de confianza antes de que empieces a escribir tus secretos (como la clave de descifrado de tu disco duro) en él. Si es fácil para un atacante modificar tu sistema de forma que no sea confiable en ese punto donde escribes una contraseña, es fácil para un atacante conseguir tu contraseña. Así que si de verdad te preocupas por que cifrado de tu disco duro sea resistente a alguien que pueda estar en posesión física de tu portátil, te preocupas sobre que sea difícil para alguien comprometer el proceso de arranque sin que te des cuenta.
Hay dos enfoques para esto. El primero es UEFI Secure Boot. Si verificas criptográficamente cada componente del proceso de arranque, para un usuario no es posible comprometer el proceso de arranque. El segundo es un Measured Boot [arranque medido]. Si mides cada componente del proceso de arranque en el TPM y si usas estas medidas para controlar el acceso a un secreto que permita al portátil probar que es confiable (como el Anti Evil Maid de Joanna Rutkowska o mi variante sobre el tema), un atacante puede comprometer el proceso de arranque pero sabrás que lo han hecho antes de que empieces a escribir.
¿Y cómo están aquí los sistemas operativos actuales?
Windows: soporta UEFI Secure Boot de una forma válida. Soporta Measured Boot pero no proporciona ningún mecanismo para que el sistema atestigüe que no se ha visto comprometido. Bueno, pero no perfecto.
Linux: Soporta UEFI Secure Boot[1], pero no verifica las firmas en initrd[2]. Eso significa que los ataques como el Evil Abigail todavía son posibles. Measured Boot no se encuentra en un buen estado pero es posible incorporarlo con un montón de trabajo manual. Es vulnerable de serie pero se puede configurar para que sea mejor que Windows.
Apple: Ha. Snare habló sobre atacar el proceso de arranque de Apple en 2012 (básicamente todo lo que describió todavía es posible). Recientemente Apple ha contratado a gente detrás de Legbacore, así que hay esperanza (pero de momento todo el hardware vendido por Apple no tiene soporte del firmware para UEFI Segure Boot ni TPM). Eso hace imposible proporcionar garantía alguna para el arranque y no hay ninguna forma real de comprobar que tu sistema no se ha visto comprometido.
Ahora, para ser justos, hay ataques para los que incluso Windows y un Linux configurado adecuadamente todavía son vulnerables. Los defectos del firmware que permiten modificaciones del código de System Mangement Mode todavía se pueden usar para burlar estas protecciones y Management Engine está en una posición tal que puede hacer lo que quiera y jodértelo todo. Pero en realidad eso no es una excusa para ignorar todo lo demás. Mejorar el estado actual de la seguridad en el arranque hace más difícil a los contrincantes comprometer un sistema y si alguna vez llegamos al punto de tener sistemas que no ejecuten código propietario oculto, todavía necesitaremos esta funcionalidad. Merece la pena hacerlo y merece la pena hacerlo ahora.
[1] Bien, excepto el bootloader firmado de Ubuntu ejecutará alegremente kernels sin firmar lo cual es una derrota de todo el ejercicio.
[2] Los initrds se compilan en la máquina local así que no podemos enviar tan solo imágenes firmadas.
TPM (Trusted Platform Module) es una norma internacional que define la forma en que funcionan los criptoprocesadores seguros. Sobre el Anti Evil Maid, se trata de una implementación basada en TPM para evitar los ataques Evil Maid en el arranque. Hay más información en esta entrada. Sobre el ataque de unidades cifradas en el arranque Evil Abigail se puede saber más en este enlace. Y sobre Management Engine, hablamos hace unos meses de esta puerta trasera que afecta a todas las plataformas de Intel que se han vendido en los últimos 10 años.
Para variar, esta vez no está disponible el video subtitulado, pero se puede ver íntegro desde el servidor de la Chaos Computer Club:
Si quieres ver otras charlas subtituladas, puedes visitar nuestra sección dedicada a las mismas.
La entrada original de Garrett se puede consultar en su blog.