Header Ads Widget

Ticker

6/recent/ticker-posts

¿Cuándo un agujero de ciberseguridad no es un agujero? Nunca

 

En ciberseguridad, uno de los problemas más desafiantes es decidir cuándo un agujero de seguridad es un gran problema, requiere una solución inmediata o una solución alternativa, y cuándo es lo suficientemente trivial como para ignorarlo o al menos despriorizarlo. La parte complicada es que gran parte de esto involucra la temida seguridad por oscuridad, donde una vulnerabilidad se deja en su lugar y los que saben esperan que nadie la encuentre. (Ejemplo clásico: dejar una página web sensible sin protección, pero con la esperanza de que su URL muy larga y no intuitiva no se encuentre accidentalmente).

Y luego está el problema real: en manos de un chico malo creativo y con buenos recursos, casi cualquier agujero puede aprovecharse de formas no tradicionales. Pero, siempre hay un pero en ciberseguridad, los profesionales de TI y seguridad no pueden arreglar de manera pragmática todos los agujeros en cualquier parte del entorno.

Como dije, es complicado.

Lo que trae esto a la mente es un intrigante agujero de CPU M1 encontrado por el desarrollador Héctor Martin, quien lo apodó M1racles y publicó pensamientos detallados al respecto .

Martin lo describe como "una falla en el diseño del chip Apple Silicon M1 [que] permite que dos aplicaciones que se ejecutan bajo un sistema operativo intercambien datos de forma encubierta entre ellas, sin usar memoria, sockets, archivos o cualquier otra característica normal del sistema operativo. Esto funciona entre procesos que se ejecutan como usuarios diferentes y bajo diferentes niveles de privilegios, creando un canal encubierto para el intercambio subrepticio de datos. La vulnerabilidad está incorporada en los chips Apple Silicon y no se puede solucionar 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ó que los usuarios no lo hicieran debido al impacto en el rendimiento.

Aquí es donde las cosas se ponen interesantes. Martin sostiene que, en la práctica, esto no es un problema.



"Realmente, nadie va a encontrar un uso nefasto para este defecto en circunstancias prácticas. Además, ya hay un millón de canales laterales que puede usar para la comunicación cooperativa entre procesos (por ejemplo, material de caché) en todos los sistemas. Los canales encubiertos no pueden filtrar datos de aplicaciones o sistemas que no cooperan. En realidad, vale la pena repetirlo: los canales encubiertos son completamente inútiles a menos que su sistema ya esté comprometido ".

Martin había dicho inicialmente que esta falla podría mitigarse fácilmente, pero ha cambiado de opinión. "Originalmente pensé que el registro era por núcleo. Si lo fuera, entonces podría borrarlo en los interruptores de contexto. Pero como es por grupo, lamentablemente, estamos un poco jodidos, ya que puede hacer comunicación entre núcleos sin entrando en el kernel. Aparte de ejecutar en EL1 / 0 con TGE = 0, es decir, dentro de un invitado de VM, no hay forma conocida de bloquearlo ".

No tenemos más información sobre si Apple planea implementar estos controles o si ya lo han hecho, pero están al tanto del problema potencial y sería razonable esperar que lo hagan. Incluso es posible que el análisis automatizado existente ya rechace cualquier intento de utilizar los registros del sistema directamente ".

Aquí es donde me preocupo. El mecanismo de seguridad aquí es confiar en que la gente de la App Store de Apple detecte una aplicación que intenta explotarla. ¿En serio? Ni Apple, ni Android de Google, para el caso, tienen los recursos para verificar adecuadamente cada aplicación enviada. Si se ve bien de un vistazo, un área donde los malos profesionales sobresalen, es probable que ambos gigantes móviles lo aprueben.

En un artículo por lo demás excelente, Ars Technica dijo : "El canal encubierto podría eludir esta protección al pasar las teclas presionadas a otra aplicación maliciosa, que a su vez la enviaría a través de Internet. Incluso entonces, las posibilidades de que dos aplicaciones pasen la revisión de Apple proceso y luego se instalan en el dispositivo de un objetivo son inverosímiles ".


¿Rebajado? ¿En serio? Se supone que TI debe confiar en que este agujero no hará ningún daño porque las probabilidades están en contra de que un atacante lo aproveche 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 devuelve a mi punto original. ¿Cuál es la mejor manera de lidiar con los agujeros que requieren mucho trabajo y suerte para ser un problema? Dado que ninguna empresa tiene los recursos para abordar adecuadamente cada uno de los agujeros del sistema, ¿qué debe hacer un equipo de CISO con exceso de trabajo y falta de personal?

Aún así, es refrescante que un desarrollador encuentre un agujero y luego lo minimice 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 algún ladrón cibernético o extorsionista de ransomware que averigua cómo usarlo. Les daría menos de un mes para aprovecharlo.

Apple necesita ser presionada para arreglar esto lo antes posible.

Publicar un comentario

0 Comentarios