Amenazas de Seguridad y Privacidad: Los firmwares

Los riesgos de seguridad y perdida de privacidad no tienen un origen común. Desde los cibercriminales a las grandes organizaciones gubernamentales encargadas de la seguridad como la famosa NSA norteamericana, la lista de posibles fuentes de amenazas contra la seguridad y la privacidad es inquietantemente extensa.

Tenemos que tener presente que estas amenazas se dan en cualquier lugar donde se mueven nuestros datos y como usuarios debemos ser recelosos con cualquier empresa, software o dispositivo que gestionen nuestros datos personales. 

Comenzando por el software más cercano a la máquina, en nuestra surtida lista podemos empezar poniendo a los firmwares propietarios como potencial origen de las amenazas. Estos bloques de código cerrado se encuentran en zonas críticas de los dispositivos electrónicos desde donde puede hacer prácticamente cualquier cosa con nuestros datos.

Mark Shuttleworth, el fundador de la popular distribución Ubuntu Linux, alertaba en su blog de como el código propietario y no verificable del firmware representa una seria amenaza para la seguridad de los usuarios y alienta a los fabricantes de hardware a implementar soporte para poder utilizar código libre en los mismos:

Si lees el catálogo de herramientas de espionaje y armamento digital que nos ha proporcionado Edward Snowden, verás que el firmware de tu dispositivo es el mejor amigo de la NSA .... el error más grande podría ser suponer que la NSA es la única institución que abusa de esta posición de confianza; de hecho, es razonable suponer que todo el firmware es un sumidero de inseguridad, cortesía de la incompetencia de peor grado de los fabricantes, y la competencia de más alto grado de una amplia gama de tales agencias

BIOS/UEFI propietarias, controladores de hardware cerrados y otro tipo de software cerrado como el Intel ME, representan, no un riesgo incierto, sino un riesgo cierto, documentado y constatado por las vulnerabilidades de seguridad que se han ido saliendo a la luz y que pueden permitir a un atacante violar la seguridad de los dispositivos y por tanto de los datos de los usuarios.

El caso de Intel-ME es especialmente inquietante. El motor de administración (ME) de Intel es un entorno informático completamente independiente que se ejecuta en los conjuntos de chips de Intel posteriores a 2006. El ME tiene acceso a todo, acceso a la red, acceso al sistema operativo host, memoria, al disco, las pulsaciones del teclado e incluso al motor de criptografía. El ME se puede utilizar de forma remota, incluso si el equipo está apagado. 

La información que aporta Intel sobre ME es muy poca y evita explicar la mayoría de las tareas específicas que realiza Intel ME y cómo funciona exactamente: "es un subsistema de computadora pequeño y de baja potencia ... realiza diversas tareas mientras el sistema está en reposo, durante el proceso de arranque y cuando el sistema está en ejecución" (Intel FAQ).

Sobre el código concreto que se ejecuta dentro del Intel ME se desconoce, aunque se sabe que ejecuta una variante de un pequeño sistema operativo llamada MINIX (carta del profesor Tanenbaum a Intel).

Dentro del Intel Management Engine se ejecuta la denominada Tecnología de Administración Activa de Intel (La ATM o Active Management Technology). La AMT se ofrece como una solución de administración remota para equipos con procesadores Intel, orientada a empresas y cuya finalidad es la de gestionar, configurar, controlar o borrar computadoras de forma remota, independientemente del sistema operativo. 

Por si todo esto no fuera ya suficientemente alarmante, en noviembre de 2017 Intel anunció agujeros de seguridad en estas tecnologías instando a todos los usuarios a instalar parches para reparar este software que tan amablemente nos habían colado en nuestras máquinas.

Volviendo a los firmwares, un importante caso de backdoor en firmwares es de los routers/firewalls Juniper que durante años permitió espiar las comunicaciones cifradas por estos dispositivos. No se trataba de una vulnerabilidad en sus equipos, sino de un código malicioso que tenía que haber sido instalado en el proceso de producción y de forma consciente por alguien (persona, entidad o gobierno). La compañía dijo que descubrió el problema en una auditoria rutinaria y especularon que detrás de la misma se podían encontrar gobiernos extranjeros como el de Rusia o China.

Para ser conscientes de la implicación y difusión de este malware tenemos que tener en cuenta que por aquel entonces la cuota de mercado de estos equipos era cercana al 40% a nivel mundial, muy extendidos por Estados Unidos, Europa, pero también en países como Pakistan o China.La realidad vio la luz con los documentos filtrados por Snowden, en los que se detallaba una operación de dos agencias de seguridad nacionales, la norteamericana NSA y la Británica GCHQ Este proyecto permitía espiar las comunicaciones cifradas por los dispositivos Juniper y era conocido por estas agencias como "Assessment of Intelligence Opportunity - Juniper".

Se sabe que muchas compañías son presionadas por este tipo de agencias gubernamentales para que faciliten puertas traseras de acceso a sus sistemas. En este caso se cree que esta vulnerabilidad fue encontrada y explotada por terceros, motivo por el que la compañía decidió sacarla a la luz.

Teniendo en cuenta el problema de los firmwares, ¿como podemos deshacernos de estos códigos cerrados que Shuttleworth acierta en llamar sumideros de inseguridad?

Pues no es una tarea sencilla, pero creo que es algo a tener muy en cuenta a la hora de intentan mantener nuestra privacidad y seguridad a salvo, algo que debía preocupar a cualquiera que use directa o indirectamente un sistema informático.

Desde luego, según mi criterio, todo pasa por utilizar software libre. Solo si es posible revisar los fuentes se puede tener la certeza de que el código no oculta ninguna sorpresa. El tiempo a dejado más que patente que la confianza ciega en una compañía o entidad es garantía de que nuestros derechos están siendo o serán vulnerados.

En el terreno práctico, para usar una BIOS libre en nuestros equipos tenemos el proyecto Libreboot que funciona muy bien pero muy limitado en cuanto a equipos en los que podemos ejecutarlo, y el proyecto Coreboot del que deriva el anterior y ofrece cobertura para más modelos de equipos y procesadores pero en el que es posible que queden todavía algunos 'binary blobs' en ejecución.

Para librarnos de Intel ME, en versiones anteriores a los procesadores Intel Nehalem (ME versión 6, 2008/2009), el firmware ME podría eliminarse por completo del chip flash cambiando un par de bits dentro del descriptor de flash, lo que lo desactiva de forma efectiva (esto es lo que hace Libreboot, ver La BIOS/UEFI libre: Libreboot).

A partir de Nehalem, el firmware de Intel ME ya no se puede eliminar: sin un firmware válido, el PC se apaga directamente después de 30 minutos, probablemente como un intento de aplicar las políticas de Intel Anti-Theft (el sistema anti-robo).

Aunque Intel ME no se puede apagar por completo, aún es posible modificar su firmware hasta un punto en el que Intel ME esté activo solo durante el proceso de arranque, inhabilitándolo de manera efectiva durante la operación normal, que es lo que intenta realizar una aplicación llamada me_cleaner (podemos ver como hacer este proceso en La BIOS/UEFI libre: Coreboot).

Con las BIOS renovadas y el Intel ME inhabilitado, es turno del sistema operativo.  

Tenemos que tener en cuenta que aunque en algunas distribuciones de GNU/Linux podemos seleccionar no usar software propietario en la instalación de nuestro sistema (algo que nos puede dejar sin la posibilidad de poder usar algunos dispositivos hardware) muchas de estas distribuciones incorporan en su kernel 'binary blobs', necesarios para, por ejemplo, hacer funcionar muchos adaptadores de red. 

Con el fin de utilizar solo software libre en nuestros equipos es necesario por un lado elegir bien el hardware de nuestro equipo y por otro seleccionar o bien distribuciones que solo utilizan código libre (la FSF tiene una lista de distribuciones) o bien personalizar nuestra distro con un kernel libre (ver por ejemplo FSFLA) y no usar, en nuestra distribución, los repositorios que contienen software propietario.

Bien!, tenemos un equipo corriendo solo software libre, buen comienzo!

Modificado por última vez enMiércoles, 29 Abril 2020 09:40
(4 votos)
Etiquetado como :

Más en esta categoría:

« Software Libre - Comunidad Libre

Deja un comentario

Asegúrese de introducir toda la información requerida, indicada por un asterisco (*). No se permite código HTML.