Pruebas de producto: simulación, disimulación y exasperación

Como contamos anteriormente, presenté mi 16° paper para Virus Bulletin en la edición 2017 de la conferencia, el 5 de octubre en Madrid. El artículo, titulado The (testing) world turned upside down, está disponible aquí con el amable permiso de Virus Bulletin. [1]

El documento no aborda todo lo que siempre he querido decir sobre las pruebas de producto, pero sí toca algunos de los temas que continúan elevando mi presión arterial, por lo que mi intención es usarlo como un trampolín desde el que hablar algunos de esos problemas en una serie de artículos.

En este primer artículo voy a hablar sobre la simulación de malware. Los simuladores no siempre se utilizan específicamente en las pruebas de productos, y no son (espero) usados ​​deliberadamente para engañar (generalmente), pero la cruda verdad es que las personas tienden a esperar más de una simulación de lo que pueden ofrecer. [2]

Cómo sesgar las pruebas

Aquí hay una cita (seudónima) de un artículo vintage de 1993 en Virus News International [3] sobre cómo sesgar las pruebas. Es sorprendente, dada la edad de ese artículo, cuántas de las técnicas que describe (o su descendencia) todavía se pueden ver (mal)utilizadas en 2017:

“No uses virus en absoluto. Usa virus simulados. Asume que la simulación es perfecta y que, por lo tanto, todos los productos deben detectarlos”.

Posteriormente, una conocida carta abierta [4] del año 2000 se opuso a los virus simulados, con especial referencia a Rosenthal Utilities, un conjunto de programas considerados por la industria de seguridad como de uso no práctico y en algunas circunstancias potencialmente peligroso. Los firmantes de esa carta (y sí, yo fui uno de ellos) señalaron que:

‘… el uso de virus simulados en una evaluación del producto invierte los resultados de la prueba… porque:

• Premia el producto que informa incorrectamente que un no virus está infectado.
• Penaliza al producto que reconoce correctamente al no virus como algo no infectado.

(Extrañamente, uno de los firmantes de esa carta todavía representa a una organización de pruebas que recientemente, según se informa, realizó una prueba patrocinada que utiliza malware “creado” o “simulado”, así como la desactivación de capas de funcionalidad). [5]

Alrededor de la época en que empecé a trabajar de cerca con ESET, vimos más virus simulados, cortesía de la prueba llamada Anti-Virus Fight Club, [6] como representante de muchas otras pruebas y revisiones donde el evaluador usaba:

… virus simulados, fragmentos de virus o incluso programas “similares a virus”, sea lo que sea que eso signifique.

EICAR: pruebas para instalación, no detección

Extrañamente, esa prueba usó varias instancias del archivo de prueba EICAR, que no es exactamente una simulación y ciertamente no es adecuado para las pruebas comparativas [7] a menos que el objetivo de la prueba sea algo como “determinar si este producto detecta el archivo de prueba de EICAR”.

Es cierto que la mayoría del malware ya no es viral, pero no creo que eso importe en este contexto. Tampoco, por supuesto, es el archivo de EICAR un virus, y no se comporta como uno en ningún aspecto. Bueno, el archivo de EICAR no es realmente una simulación sino más bien una verificación de instalación, igual que las utilidades de verificación de características de seguridad de AMTSO (muchas de las cuales usan el archivo EICAR).

El archivo EICAR y la verificación de funciones de AMTSO (Anti-Malware Testing Standards Organization) “funcionan” porque gran parte de la industria acuerda reconocerlos, no como una simulación sino como una indicación de que un producto de seguridad está instalado y “despierto”, aunque no es garantía de que sea completamente funcional.

Tal vez sea un poco desafortunado que AMTSO haya elegido incluir pruebas de instalación en su sitio web, ya que la organización está tan asociada con las pruebas comparativas y de certificación “adecuadas” que la gente podría pensar que la oferta de pruebas de instalación de AMTSO legitima de alguna manera su uso en pruebas comparativas.

Sin embargo, algunas personas y organizaciones ciertamente parecen encontrar útiles las pruebas de instalación, y AMTSO ha dejado sus puntos de vista bastante claros en un documento de directrices sobre el uso y el mal uso de los archivos de prueba.

Simulaciones y falsos positivos

Últimamente ha habido una avalancha de simuladores de malware (especialmente simuladores de ransomware) que no difieren mucho de los controles de instalación y los simuladores de virus de la vieja escuela. Algunos simuladores de virus se basaron en la incorporación de fragmentos no funcionales de código viral, esperando que el software de seguridad se activara mediante el reconocimiento de una simple string de exploración, en lugar de mediante mecanismos de identificación más completos y completos.

Sin embargo, este enfoque se basó en un malentendido básico acerca de cómo funcionó (mucha de) la detección de firmas en la edad de piedra. Nunca hubo una única firma estática “universal” para cada muestra maliciosa, utilizada por todos los escáneres para identificarla.

Hoy en día, la sola dependencia de las firmas estáticas en productos de seguridad convencionales es, en todo caso, historia antigua, o producto de la imaginación de los marketineros de la next-gen.

Aquí hay un extracto de un paper que (junto a Lysa Myers y Eddy Willems) presenté en AVAR hace varios años, describiendo la famosa simulación de virus de Doren Rosenthal (en ese momento muy desacreditada):

“A los investigadores antivirus en general no les gusta, por una serie de razones:

• Se basaron en la premisa falsa de que un producto que detecta un virus real también debería detectar una simulación de ese virus.
• La premisa falsa anterior también se basa en la premisa igualmente falsa de que una firma de virus es una huella única y que todo el software de seguridad utiliza la misma firma. Por supuesto, no hay ninguna razón por la cual los fragmentos de virus aleatorios deban detectarse como si fueran un virus real, y aún menos motivo para que varios proveedores usen la misma firma. “

Para ser justos, la versión registrada de los servicios públicos de Rosenthal incluía, de hecho, “un virus real y relativamente inocuo”.

Por lo tanto, esto podría describirse como un raro ejemplo de una simulación que muestra algo cercano al comportamiento viral. Sin embargo, el uso inapropiado de los programas de Rosenthal por parte de algunos evaluadores en las pruebas comparativas “obligó a la industria AV a agregar la detección de otro no virus a la impresionante selección de archivos basura y otros objetos inapropiados que necesita para detectar si un producto no debe ser penalizado por no detectar lo que no debería necesitar detectar”.

Los simuladores de ransomware actuales tienden a adoptar un enfoque más genérico: en lugar de suplantar malware específico, pueden intentar simular un comportamiento malicioso. Sin embargo, realmente no se comportan como ransomware real.

En los buenos tiempos, al menos era discutible que el comportamiento “viral” (por ejemplo, la autorreplicación) es un indicador generalmente confiable de comportamiento malicioso, lo que tiende a hacer la detección heurística de virus “reales” comparativamente fácil.

Sin embargo, los simuladores de ransomware generalmente se enfocan (comprensiblemente) en el cifrado de archivos, que puede o no ser malicioso. Después de todo, ¡también es una función primaria de algunos software de seguridad! Ransim ilustra exactamente esta dificultad: para poder comportarse de manera ética, el simulador está diseñado para introducir sus propios archivos y luego cifrarlos.

Pero evitar cifrar “archivos existentes en el disco” es bastante opuesto a lo que hace el ransomware real. No hay ninguna razón por la que un proceso que solo cifra los archivos que acaba de crearse debería ser diagnosticado como malicioso, y mucho menos como ransomware. El cifrado es una función legítima: es solo el contexto lo que lo hace malicioso.

De lo contrario, las operaciones de Microsoft Word cuando un usuario opta por proteger con contraseña un documento existente también deben detectarse como ransomware, lo que estotalmente ridículo. Sin embargo, el cifrado realizado de manera encubierta por ransomware en archivos a los que se accede y modifica sin la autorización de su propietario es claramente malicioso.

Entonces, ¿cómo hace un simulador lo que hace el ransomware real sin ser un malware real? No estoy convencido de que sea realmente posible hacerlo de manera ética y con seguridad absoluta, pero no se puede hacer de manera útil bloqueando las “operaciones” sin tener en cuenta lo que realmente está haciendo el sospechado malware.

En general, el software de seguridad moderno no se ocupa del escaneo simplista de firmas, sino de técnicas que analizan cómo se comporta el software para establecer si tiene alguna intención maliciosa posible o probable.

Es la capacidad de distinguir entre la ejecución legítima y maliciosa de una operación lo que hace efectivo un programa de seguridad competente. Si bien es demasiado esperar que el software de seguridad siempre lo haga bien, me parece que solo hay dos formas en que siempre puede detectar malware simulado.

1. Señalando como sospechosa cada operación que podría ser maliciosa, independientemente de los inevitables falsos positivos. Y, lo que es peor, permitiendo que el usuario decida si bloquear o aceptar la ejecución.
2. Detectando el simulador en lugar del proceso malicioso que pretende emular. En general, aquellos que generan simuladores protestan cuando se hace esto, y, por supuesto, esto invalida el propósito de la simulación. Pero ese es un problema que surge de la dudosa naturaleza del enfoque de simulación, y no de la incompetencia o malversación de los vendedores de seguridad.

No es solo que los simuladores de malware generalmente no puedan emular el malware real con éxito. La industria de seguridad no ha acordado reconocerles algún tipo de funcionalidad similar a EICAR, tampoco. Si fueran a ser detectados por los anti-malware más conocidos, probablemente debería ser como algo análogo a una PUA (aplicación potencialmente no deseada). Algo así como ‘Quasi-Simulator Non-Malware’. Lo cual es una forma educada de decir “falso positivo intencional con muerte cerebral”.

Astucia felina

Este podría ser un buen momento para presentarte a mi gato.

Lo llamamos Ike. Diminutivo de EICAR.COM. Es un tigre simulado, pero eso no lo hace adecuado para las pruebas de detección de tigres. También tenemos un perro llamado Little Bobby Tables.

Simuladores y pecadores

La simulación de un ataque no es, por definición, un ataque real, incluso si se trata de una simulación “buena” (lo cual sería una novedad). Es la concepción de alguien de cómo debería ser un ataque,pero no es verdaderamente malicioso.

En general, la industria de seguridad evita detectar ataques simulados, ya que no solo son técnicamente falsos positivos, sino que también se basan en suposiciones dudosas acerca de cómo funcionan los programas maliciosos y los antimalware.

Las simulaciones generalmente se basan en una instantánea de algún malware y no tienen en cuenta las diferencias entre el malware y las tecnologías antimalware. Casi invariablemente engañan a las personas que esperan que sean precisas. De hecho, demuestran poco o nada sobre lo que un producto detecta, excepto que detecta una simulación específica.

Las empresas que eligen detectar simuladores son como aquellas compañías que solían detectar archivos basura, simulaciones, etc., que se sabe están presentes en las colecciones de muestra comúnmente utilizadas, para evitar ser penalizadas en pruebas pobres pero influyentes.

En otras palabras, evitan la desventaja competitiva, pero legitiman las pruebas deficientes. En general, los productos que detectan una simulación pueden detectar la presencia de un simulador, incluso si también detectan el tipo genérico de brecha que el simulador pretende representar o suplantar.

Fuente:https://www.welivesecurity.com/la-es/2017/10/16/pruebas-de-producto-simulacion/