¿En qué momento un orificio de ciberseguridad no es un orificio? Jamás

¿En qué momento un orificio de ciberseguridad no es un orificio?  Jamás
            Uno de los inconvenientes más bastante difíciles en ciberseguridad es decidir en qué momento una brecha de seguridad es un enorme inconveniente, que requiere una solución inmediata o bien una solución opción alternativa, y en qué momento es suficientemente trivial para ser ignorada o bien por lo menos despriorizada.  La parte difícil es que una gran parte de ella implica la temida seguridad de la obscuridad, donde se deja una vulnerabilidad en su sitio y los que lo saben aguardan que absolutamente nadie la halle.  (Ejemplo clásico: dejar una página sensible sin protección, mas con la esperanza de que no se halle accidentariamente su URL larguísima y poco intuitiva).
Y después está el inconveniente real: a cargo de un villano creativo y bien dotado, prácticamente cualquier orificio puede explotarse de formas no tradicionales. Mas, siempre y en todo momento hay un mas en ciberseguridad, los profesionales de TI y seguridad no pueden reparar pragmáticamente todos y cada uno de los orificios del ambiente. Como afirmé, es complicado. Lo que me recuerda de esto es un intrigante orificio en el procesador M1 encontrado por el desarrollador Héctor Martin, quien lo apodó M1racles y publicó pensamientos detallados a este respecto. Martin lo describe como "un defecto en el diseño del chip Apple Silicon M1". Deja que 2 aplicaciones que se ejecutan bajo un sistema operativo intercambien datos en secreto entre sí, sin utilizar memoria, sockets, ficheros o bien cualquier otra funcionalidad normal del sistema operativo. Marcha entre procesos que se ejecutan como usuarios diferentes y bajo niveles diferentes de privilegios, creando un canal secreto para el intercambio subrepticio de datos. La vulnerabilidad está incorporada en los chips Apple Silicon y no se puede arreglar sin una nueva revisión del silicio ". Martin agregó: "La única mitigación libre para los usuarios es ejecutar su sistema operativo como una máquina virtual. Sí, ejecutar su sistema operativo como una máquina virtual tiene un impacto en el desempeño", entonces sugirió a los usuarios que no lo hiciesen debido al impacto en el desempeño. . Acá es donde las cosas se ponen interesantes. Martin mantiene que, desde cierto punto de vista práctico, esto no es un inconveniente. “Realmente, absolutamente nadie hallará un empleo perjudicial para este vacío legal en circunstancias prácticas. Además de esto, ya hay un millón de canales secundarios que puede emplear para la comunicación cooperativa entre procesos (por poner un ejemplo, elementos de caché) en todos y cada sistema. Los canales ocultos no pueden. fuga de datos de aplicaciones o bien sistemas que no colaboran. En verdad, merece la pena repetirlo: los canales secretos son totalmente inútiles salvo que su sistema ya esté comprometido. " Martin en un inicio afirmó que esta falla podría atenuarse de forma fácil, mas cambió de opinión. "Originalmente, creí que el registro era de memoria. Si lo fuera, podría borrarlo en los conmutadores de contexto. Mas como está basado en clústeres, desafortunadamente estamos un tanto jodidos, pues puede hacer comunicación entre núcleos sin entrar en el kernel. Además de ejecutarse en EL1 / 0 con TGE = 0, o sea, en una máquina virtual convidada, no hay forma famosa de bloquearlo ". Antes que alguien se relaje, considere los pensamientos de Martin sobre iOS: “iOS se ve perjudicado, como todos los otros sistemas operativos. Esta vulnerabilidad tiene implicaciones de privacidad únicas en iOS, puesto que podría utilizarse para evitar ciertas de sus protecciones de privacidad más estrictas. Por servirnos de un ejemplo, las aplicaciones de teclado no pueden acceder a Internet por motivos de privacidad. Una aplicación de teclado maliciosa podría utilizar esta vulnerabilidad para mandar texto que el usuario escribe a otra aplicación maliciosa, que entonces podría mandarlo mediante Internet. No obstante, puesto que las aplicaciones iOS distribuidas mediante la aplicación Store no pueden crear código en tiempo de ejecución (JIT), Apple puede escanearlas de manera automática en el instante del envío y advertir de forma fiable cualquier intento de hacerlo. ya emplean. para incorporar estos controles o bien si ya lo han hecho, mas son siendo conscientes del inconveniente potencial y sería razonable aguardar que lo hiciesen. Aun posiblemente el escaneo automático ya esté rechazando cualquier intento de emplear de manera directa los registros del sistema ". Acá es donde me preocupo. El mecanismo de seguridad acá es confiar en las personas en la Aplicación Store de Apple que advierten una aplicación mientras que procuran explotarla. ¿Ah bueno? Ni Apple, ni Android de Google, para el caso, tienen los recursos para contrastar apropiadamente todas y cada una de las aplicaciones mandadas. Si se ve bien de una ojeada, un área donde sobresalen los villanos profesionales, probablemente los 2 gigantes móviles lo aprueben. En un artículo en cuanto al resto genial, Ars Technica dijo: "El canal secreto podría evitar esta protección reenviando las pulsaciones de teclas a otra aplicación maliciosa, que por su parte la mandaría a Internet. Aun entonces, las posibilidades de que 2 aplicaciones aprueben el proceso del examen de Apple, entonces establecerse en el dispositivo de una meta son inverosímiles ". ¿Tarado? ¿Ah bueno? Se supone que el departamento de TI ha de estar persuadido de que este orificio no ocasionará ningún daño, puesto que las probabilidades están contra un atacante que lo explote exitosamente, lo que por su parte se fundamenta en que el equipo de Apple advierta una aplicación problemática. Es una lógica bastante espantosa. Esto nos devuelve a mi punto original. ¿Cuál es la mejor forma de lidiar con los orificios que requieren mucho trabajo y suerte para ser un inconveniente? Puesto que ninguna empresa tiene los recursos para abordar apropiadamente todas y cada una de las fallas en el sistema, ¿qué debería hacer un equipo de CISO con exceso de trabajo y falta de personal? Todavía de esta forma, es refrescante que un desarrollador halle un orificio y después lo minimice tal y como si no fuese un enorme inconveniente. Mas ahora que el orificio se ha hecho público con un detalle pasmante, mi dinero va a un ladrón cibernético o bien extorsionador de ransomware que descubre de qué forma utilizarlo. Les daría menos de un mes para aprovecharlo. Se debe presionar a Apple a fin de que solvente este inconveniente a la mayor brevedad.
<p>Copyright © dos mil veintiuno IDG Communications, Inc.</p>