News

Reflexiones sobre cómo establecer los límites

Para complementar las declaraciones de Eugene, quisiera agregar mi posición sobre lo que está por suceder en Defcon este año. El año pasado di una conferencia en Defcon y tengo la impresión de que es un evento muy especial: ofrece una oportunidad para que personas inteligentes con ideas originales se reúnan y compartan sus conocimientos. Además de ser un lugar de encuentro de personas con ideas originales, Defcon permite a sus participantes empaparse del espíritu de la cibercultura moderna.

Siempre supe que en algún momento aparecería una competición como Race to Zero. Ahora que sucedió, aunque no nos guste, es muy probable que empiecen a surgir otras propuestas similares. No hay duda de que romper la ley es malo. De hecho, creo que la competición sufrirá modificaciones antes de que inicie Defcon para mantenerla dentro de las regulaciones.

Sin embargo, pienso que los organizadores de Race to Zero podrían modificar las reglas de juego para convertir la competición en una actividad que beneficie a todos los participantes. Déjenme explicar a qué me refiero…

Echémosle un vistazo a lo que los participantes van a manipular en la competición: Tendrán el código de aplicaciones existentes y es probable que también se les suministre algunas series preparadas de códigos nop. Los códigos nop (códigos “no operation”) son códigos especiales de programas que no afectan el estado del ordenador ni alteran el sistema. Hay muchos métodos de ofuscación, pero casi todos trabajan usando el mismo principio básico: se reestructura el código afectado y se lo mezcla con códigos nop. El algoritmo que se use para mezclar los dos grupos de códigos va a determinar si el código va a ser más difícil de leer y modificar o si va a evadir la detección de los programas de antivirus basados en firmas.

Por supuesto, un código ofuscado puede causar dolores de cabeza a las empresas de antivirus. Como es más difícil analizar de forma manual los códigos ofuscados, se gastan más recursos tratando de conservar una colección de muestras ofuscadas que tengan el mismo comportamiento. Si una muestra ofuscada se analiza con herramientas automáticas, el análisis toma más tiempo que el de una muestra de otro tipo. Por esta razón, las empresas de antivirus trabajan duro para desarrollar herramientas de descompilación.

Entonces hablamos de dos cosas importantes: Ofuscación y descompilación. La complejidad de ambos métodos los diferencia. Imagine que tiene un balde de azúcar y uno de arena. Puede mezclar el contenido de ambos baldes de muchas formas: cada método que puede usar para hacer la mezcla es como un algoritmo de ofuscación diferente. Descompilación es el proceso invertido: separar la mezcla de azúcar y arena. Se dará cuenta de mezclar el contenido de los baldes es fácil, pero separarlo es un proceso mucho más largo y agotador.

De alguna manera, ocuparse de algoritmos de ofuscación y hacer que los programas de seguridad no detecten una aplicación es un reto fácil, un problema de “caja blanca”. Se tienen los datos de origen y el programa antivirus, así como la oportunidad de analizar el código desensamblad, por lo tanto, se pueden depurar los errores y desarrollar su propia aplicación para alterar los datos. Se puede ver cada paso del proceso y el mecanismo que se crea.

Pero la descompilación es muy diferente. Se tienen unas cuantas piezas de código que la ofuscación ha transformado y se desconoce la aplicación se usó para ofuscarlo. Así que la descompilación ni siquiera encaja en el modelo de la “caja negra”, en que se tiene la oportunidad de utilizar un mecanismo cuantas veces sea necesario, pero no se puede ver en su interior para entender cómo funciona. Para lograr una descompilación sólo se cuenta con los datos que son el resultado de este mecanismo; los datos deben estudiarse para determinar factores comunes y únicos. Luego, se deben sacar conclusiones para determinar cómo es que funciona la “caja negra” hipotética.

En mi opinión, la descompilación requiere de mucha más imaginación y destreza. Creo que los organizadores de Race to Zero deberían regirse por principios éticos y ampliar las reglas de la competición para que incluya la descompilación. Esto haría que, además de ser una actividad divertida, sea una buena experiencia para todos.

Para aclarar mi posición: El hecho de que se trabaje con los métodos de ofuscación y descompilación no significa que sea necesario crear o modificar nuevos programas nocivos. Simplemente no es necesario. La competición no es sólo un reto técnico, también es un reto moral. Esperemos que los participantes decidan mantenerse en el lado bueno para que todos podamos beneficiarnos de sus conocimientos.

Reflexiones sobre cómo establecer los límites

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

 

Informes

MosaicRegressor: acechando en las sombras de UEFI

Encontramos una imagen de firmware de la UEFI infectada con un implante malicioso, es el objeto de esta investigación. Hasta donde sabemos, este es el segundo caso conocido en que se ha detectado un firmware malicioso de la UEFI usado por un actor de amenazas.

Dark Tequila Añejo

Dark Tequila es una compleja campaña maliciosa que tiene por objetivo a los usuarios ubicados en México, con el propósito principal de robar información financiera, así como credenciales de acceso a sitios populares que van desde versionado de código fuente a cuentas de almacenamiento de archivos en línea y de registro de dominios web.

De Shamoon a StoneDrill

A partir de noviembre de 2016, Kaspersky Lab observó una nueva ola de ataques de wipers dirigidos a múltiples objetivos en el Medio Oriente. El programa malicioso utilizado en los nuevos ataques era una variante del conocido Shamoon, un gusano que tenía como objetivo a Saudi Aramco y Rasgas en 2012.

Suscríbete a nuestros correos electrónicos semanales

Las investigaciones más recientes en tu bandeja de entrada