Como seguramente sepa, la semana pasada se celebró la RootedCon, uno de los eventos en los que sin duda más disfruto, enfocados a los profesionales de la seguridad, y con un carácter profundamente técnico.
Me volví de esos tres días con la típica libretita de la Rooted cargada de apuntes. Parte de ellos vinieron reflejados en el email de estos días enviado a la Comunidad. Otra parte, saldrá como artículo para mis queridos patrones, y otros acabarán viendo la luz en esta humilde morada, conforme saque tiempo y ganas para preparar las piezas.
Y empiezo hoy, a colación de la charla que nos presentó Matías Katz (@matiaskatz) sobre su investigación en metodologías de generación de puertas traseras mediante hardware.
Un tema que sin lugar a duda da para varios debates, y que intentaré resumir en este artículo.
Un ecosistema tecnológico inseguro
La industria tecnológica no parece estar interesada, como decía en el título, en vigilar qué está haciendo el hardware de nuestros dispositivos. Y no lo hace por dos motivos principales:
- Resulta muy costoso: A nivel de recursos, estar analizando los patrones de comportamiento de cada componente (interno y externo) de un dispositivo (elementos mecánicos), resulta terriblemente caro. Bastante más que monitorizar los procesos (software) abiertos. De ahí que prácticamente todas las defensas implantadas en nuestros dispositivos obvien lo que hace y deje de hacer una batería, una memoria gráfica, un periférico, o como veremos en este caso, un jack de auriculares.
- No hay apenas ataques conocidos: Y por ende, “es una pérdida de tiempo y recursos”. La mayoría de vectores de ataque vienen de la mano del software y no del hardware. Por tanto, ¿para qué vamos a destinar recursos a algo probabilísticamente menos probable?
La fotografía deja entonces vía libre para explotar vulnerabilidades de este tipo, e incluso una puerta abierta para desconfiar de lo que hoy en día podría estar ocurriendo en nuestras máquinas.
Sabedor de esto, Matías se enfocó en encontrar una manera de, utilizando componentes físicos, comprometer la autenticación de un sistema operativo linux, cumpliendo además que el ataque fuera lo más silencioso (ningún sistema de seguridad alertara al usuario del ataque), lo más universal (vulnerabilidad presente en el mayor porcentaje de dispositivos) y lo menos disruptivo (la víctima no fuera consciente ni antes ni después del ataque) posible.
Eso echa por tierra algunas de las salidas más inmediatas. Si atacamos directamente ficheros de configuración del SO, la seguridad del sistema saltaría. Si utilizamos exploitskits y demás rootkits, dejaríamos huella.
¿Qué elemento opera por tanto por debajo de los ficheros de configuración y es invisible a cualquier monitorización habitual? La respuesta la encontró en DBUS (ES), un mecanismo de comunicación entre procesos (IPC), con permisos prioritarios sobre el resto de la máquina, y que puede ser ejecutado desde hardware.
Gracias a él, con una pieza de tan solo 27 líneas en python (minimizable a 1 línea con puntos y coma), Matías fue capaz de saltarse la contraseña y cualquier sistema de cifrado de disco de un dispositivo realizando algunas acciones de hardware, entre las que estarían:
- Autenticarse en el sistema mediante un pendrive: Parece la opción más obvia. Bastaría con que esa pieza de código definiera como elemento de identificación la ID de ese pendrive. Tan pronto un atacante inserta el pendrive en el puerto del dispositivo, éste se desbloquea, saltándose cualquier protección a nivel de sistema que tuviera implementado.
- Autenticarse en el sistema mediante un patrón de conexión/desconexión de auriculares: DBUS gestiona varios parámetros del puerto de auriculares, y entre ellos, estaría el estado del mismo (conectado/desconectado). Esto permite que se pueda atacar al sistema con cualquier auricular, siempre y cuando sepamos el patrón que el script está leyendo (por ejemplo, conectarlo, esperar un segundo, desconectarlo, esperar tres segundos, volverlo a conectar).
- Autenticarse en el sistema mediante el bloqueo/desbloqueo de pantalla: Semejante al caso anterior, pero sin necesitar un auricular. Simplemente sabiendo el patrón de apertura/cierre de la pantalla.
En cualquiera de estos casos (y en las millones de combinaciones posibles, que aquí el límite lo pone la imaginación), DBUS ofrece un sistema universal, invisible y no disruptivo, para comprometer la privacidad y seguridad de cualquier dispositivo, teniendo en cuenta las siguientes limitaciones:
- Necesita tener DBUS (y python, en este caso) instalado: Algo obvio, y por otra parte, bastante habitual en buena parte de los sistemas Linux. Incluso hay versiones compatibles para Windows (Win-DBUS), aunque esto sin duda es menos común. Y sin obviar que la mayoría de dispositivos del internet de las cosas, la mayoría de routers, y hasta dispositivos Android, utilizan algún tipo de versión o parte de Linux más o menos restrictiva.
- Requiere acceso físico al dispositivo: Estamos hablando de hardware, por lo que en su propia definición ya deberíamos haber contemplado este supuesto.
- Necesita haber sido comprometido con anterioridad: Y aquí hay que hacer una matización. En efecto, es necesario que de antemano, hayamos “instalado” ese script en la máquina. Pero lo bueno es que no se trata de un binario (posiblemente monitorizado por alguna herramienta de seguridad), sino de una pieza de código que tranquilamente se puede ejecutar de forma persistente (en rc.local (ES), por ejemplo) como parte de un software legal comprometido distribuido masivamente, y que pasaría desapercibida para la amplia mayoría de herramientas de seguridad, ya que como vimos anteriormente, “no presenta riesgo alguno”.
De hecho, este último punto me anima a comentar algo que para muchos podría ser obvio.
¿Qué impide que ataques de este tipo estén ya en circulación?
Bien sea por parte de agencias de inteligencia, bien sea por parte de empresas que ofrecen ciberinteligencia mercenaria, bien sea por parte de los propios fabricantes, o por la industria del cibercrimen, lo cierto es que hoy en día, y debido a la enorme descentralización de toda la cadena de producción de dispositivos tecnológicos, cualquier pieza de ese engranaje podría estar incluyendo un backdoor de este tipo.
Y tenemos en la historia ejemplos semejantes, como esa puerta trasera que la NSA implementó en el cifrado RdRand de Linux (que llevaba años operando pese a que ese código es auditable por cualquier interesado), ese “supuesto fallo” en OpenSSL, una librería que gestiona las comunicaciones seguras de prácticamente dos tercios de todos los servidores mundiales, o todos aquellos fabricantes (una docena de los mayores fabricantes del mundo) cuyos discos duros venían con un exploit instalado en su firmware por Equation Group.
Ya ni hablemos de Huawei o ZTE y las supuestas puertas traseras que ofrece al gobierno de su país (EN), o del ataque que recientemente comprometió la página oficial de descarga de Mint con una versión de esta distribución comprometida.
La cuestión, como comentaba recientemente al hilo de la guerra por la privacidad de los datos entre el FBI y Apple, es que si hoy en día estos poderes tácitos no están en efecto explotando este tipo de ataques, no será ni por desconocimiento ni por falta de recursos.
La historia de la seguridad digital se escribe, generalmente, años después de que sus efectos hayan impactado en la sociedad. Y no me cabe la menor duda que tener una llave maestra para saltarse cualquier protección de un dispositivo es el sueño húmedo de muchos de estos organismos.
Al menos, así lo han dejado claro públicamente, tanto por declaraciones, como por hechos.
________
Realizar este tipo de artículos me lleva varias horas, y en algunos casos, gastos extra que habitualmente suplo de mi bolsillo, o gracias a esa comunidad de patronos que me apoyan realizando donaciones puntuales o periódicas.
Si le gustaría ver más de estos tutoriales y análisis por aquí. Si el contenido que realizo le sirve en su día a día, piense si merece la pena invitarme a lo que vale un café, aunque sea digitalmente.
