En ciberseguridad, uno de los problemas más difíciles es decidir cuándo una brecha de seguridad es un gran problema, que requiere una reparación inmediata o una solución temporal, y cuándo es lo suficientemente insignificante como para ignorarla o, al menos, quitarle prioridad. La parte complicada es que gran parte de esto involucra la seguridad temida por la oscuridad, donde se deja una vulnerabilidad en su lugar y aquellos que saben esperan que nadie la encuentre. (Ejemplo clásico: dejar una página web confidencial desprotegida, pero con la esperanza de que su URL muy larga y poco intuitiva no se encuentre accidentalmente).
Y luego está el problema real: en manos de un villano ingenioso y creativo, casi cualquier agujero puede ser explotado de una manera no tradicional. Pero, siempre hay un pero en la ciberseguridad, los profesionales de TI y seguridad no pueden corregir pragmáticamente todos los defectos del entorno.
Como dije, es complicado.
Lo que me recuerda esto es un intrigante agujero en el procesador M1 encontrado por el desarrollador Hector Martin, quien lo denominó M1racles y publicó pensamientos detallados sobre esto.
Martin lo describe como «una falla en el diseño del chip Apple Silicon M1 [that] permite que dos aplicaciones que se ejecutan en un sistema operativo intercambien datos entre sí en secreto, sin usar memoria, sockets, archivos o cualquier otra funcionalidad normal del sistema operativo. Esto funciona entre procesos que se ejecutan como diferentes usuarios y bajo diferentes niveles de privilegios, creando un canal secreto para el intercambio clandestino de datos. La vulnerabilidad está integrada en los chips Apple Silicon y no se puede reparar sin una nueva revisión de silicio».
Martin agregó: «La única mitigación disponible para los usuarios es ejecutar todo su sistema operativo como una máquina virtual. Sí, ejecutar todo su sistema operativo como una máquina virtual tiene un impacto en el rendimiento» y luego sugirió a los usuarios que no lo hicieran debido al impacto en el rendimiento.
Aquí es donde las cosas se ponen interesantes. Martin argumenta que en la práctica esto no es un problema.
«Realmente, nadie encontrará un uso nefasto de esta falla en circunstancias prácticas. Además, ya hay un millón de canales secundarios que puede usar para la comunicación cooperativa entre procesos, por ejemplo, elementos de caché, en cada sistema. Los canales encubiertos no pueden filtrar datos. de aplicaciones o sistemas que no cooperan. De hecho, vale la pena repetirlo: los canales encubiertos son completamente inútiles a menos que su sistema ya esté comprometido».
Martin originalmente dijo que esta falla podría mitigarse fácilmente, pero cambió de tono. «Originalmente pensé que el registro era por memoria. Si es así, podría borrarlo en los cambios de contexto. Pero como es por clúster, desafortunadamente, estamos un poco jodidos, porque puede hacer comunicación entre núcleos sin entrar en el kernel Además de ejecutarse en EL1/0 con TGE=0, es decir, dentro de un invitado de VM, no hay forma conocida de bloquearlo.
Antes de que alguien se relaje, considere los pensamientos de Martin sobre iOS: «iOS se ve afectado, como todos los demás sistemas operativos. Esta vulnerabilidad en iOS tiene implicaciones de privacidad únicas, ya que podría usarse para eludir ciertas protecciones de privacidad más estrictas. Por ejemplo, las aplicaciones de teclado no son acceso a Internet, por razones de privacidad. Una aplicación de teclado maliciosa podría usar esta vulnerabilidad para enviar texto ingresado por el usuario a otra aplicación maliciosa, que luego podría enviarlo a Internet. No se le permite crear código de tiempo de ejecución (JIT), Apple puede escanear automáticamente en el momento del envío y detectar de manera confiable los intentos de aprovechar esta vulnerabilidad mediante el escaneo personal. tick, que ya utilizan. implementar estos controles o ya lo han hecho, pero son conscientes del problema potencial y sería razonable esperar que lo hicieran. El escaneo automático de ting ya rechaza cualquier intento de usar los registros del sistema directamente».
Aquí es donde me preocupo. El mecanismo de seguridad aquí es confiar en que las personas en la App Store de Apple detecten una aplicación que intenta explotarla. ¿En realidad? Ni Apple, ni Android de Google, para el caso, tiene los recursos para examinar adecuadamente cada aplicación enviada. Si se ve bien de un vistazo, un área donde sobresalen los villanos profesionales, es probable que ambos gigantes móviles lo respalden.
En una pieza por lo demás excelente, Ars-Technica ha dicho: «El canal secreto podría eludir esta protección al transmitir pulsaciones de teclas a otra aplicación maliciosa, que a su vez la enviaría a Internet. Incluso entonces, las posibilidades de que dos aplicaciones pasen el proceso de revisión de Apple y luego se instalen en el dispositivo de un objetivo son inverosímil».
¿Chiflado? ¿En realidad? Se supone que TI debe creer que este agujero no causará ningún daño, ya que hay pocas posibilidades de que un atacante lo explote con éxito, lo que a su vez se basa en que el equipo de Apple detecta cualquier aplicación problemática. Esa es una lógica bastante aterradora.
Esto nos lleva de vuelta a mi punto de partida. ¿Cuál es la mejor manera de lidiar con agujeros que requieren mucho trabajo y suerte para convertirse en un problema? Dado que ninguna empresa tiene los recursos para abordar adecuadamente cada falla en el sistema, ¿qué debe hacer un equipo de CISO con exceso de trabajo y con poco personal?
Aún así, es refrescante ver a un desarrollador encontrar un agujero y luego minimizarlo como si no fuera un gran problema. Pero ahora que el agujero se ha hecho público con un detalle impresionante, mi dinero está en un ladrón cibernético o extorsionador de ransomware que descubrirá cómo usarlo. Les daría menos de un mes para aprovecharlo.
Se debe presionar a Apple para que solucione este problema lo antes posible.
