¿Se desvela una "guerra sucia" en el mundo de los antivirus? (y II)

miércoles, 26 de agosto de 2015

Parece que dos antiguos trabajadores de Kaspersky han acudido a Reuters para denunciar (de forma anónima) que cuando trabajaban en el laboratorio, Kaspersky mantenía un plan mucho más sutil para que los competidores cayeran en el falso positivo una y otra vez, detectando ficheros importantes como malware. ¿Cómo lo hacían?

Existía la guerra sucia, pero... ¿venía de Kaspersky?

Microsoft, AVG y Avast confirman que, efectivamente, han observado estas tácticas de inducir a detectar falsos positivos. Las han comprobado, entre otras razones, gracias a la posibilidad de que cualquiera envíe a VirusTotal cualquier muestra. Se reparten entre todos los laboratorios y aquellos con menos recursos, menos cuidadosos, en una primera clasificación rápida para controlar la avalancha o simplemente porque su fórmula de detección, han cazado erróneamente como malware lo que "alguien" ha adulterado para hacerles caer en el error.

Aunque cualquiera puede hacerlo (atacantes, investigadores, la industria del malware...), si quien lo perpetra es la competencia esto se convierte en un claro sabotaje contra el motor de un competidor. Resulta relativamente sencillo desvelar los puntos débiles y fuertes de los motores a la hora de detectar y crear firmas. Y sobre todo en qué se suelen fijar para calificar un malware como tal. La idea es "manipular" ciertos ficheros para que el motor se equivoque y acabe detectando como malware el goodware. ¿Cómo?

Las firmas estáticas están muy limitadas. Al final, no se trata más que de un trozo de código, una cadena, o una combinación de ellas, características y singularidades en un código (un binario, que no son más que instrucciones) limitado. Y luego intentan extrapolar por similitud para que la firma abarque el máximo... pero nunca demasiado. Existen herramientas que trocean un fichero ejecutable por ejemplo, hasta que se dé exactamente con la parte concreta que hace "saltar" a un antivirus. Es muy sencillo y los atacantes y aficionados están muy acostumbrados a eludir así la detección por firmas. Una vez detectada esa pequeña porción de código o característica, se elimina, se tuerce, se cambia de sitio en el fichero... cualquier truco de programación o compilación es válido hasta que se evite la detección manteniendo el comportamiento. Y vuelta a empezar.

Aunque no se han dado detalles técnicos (y por tanto estamos deduciendo aquí cómo podría realizarse esta técnica), parece que según estos supuestos antiguos empleados de Kaspersky, desde el laboratorio se "inyectaba" o añadía código malicioso en ficheros populares y se enviaban a VirusTotal. Así, los antivirus saltarían. No importaría siquiera que el fichero funcione o sea válido. Lo importante es difundirlo y crear el "efecto dominó". Un motor lo comienza a detectar, crea una firma y el resto se plagia.

Pero, si se inyecta esa cadena, código, característica o singularidad de forma muy especial, por la forma que tienen los motores y los laboratorios de funcionar, puede que incluso el fichero original (goodware), que se ha enviado con la ligera modificación sea detectado finalmente si no se ha sido suficientemente riguroso con la creación de la firma... y así ocurría. Imaginemos la presión en las casas antivirus por actuar rápido y minimizando recursos.
  • Llega un fichero supuestamente dañino desde VirusTotal y lógicamente se quiere detectar/bloquear para sus clientes cuanto antes.
  • No hay tiempo para un análisis concienzudo (nunca lo hay excepto para casos muy particulares) porque parece que está claro, muchos lo detectan (recordemos que incluye código muy reconocido dentro de un archivo legítimo). Se deja en manos de automatismos.
  • El efecto dominó de creación de firma hace que se confíe en el resto de motores porque ya todos lo detectan y parece que "está claro que es malware".
  • Se crea una firma rápida para salir del paso o automatizada pero quizás de forma demasiado genérica y... al incluir esa nueva firma para detectar el fichero bueno "ligeramente adulterado", se escogen las características inadecuadas (que también definen al archivo legítimo) y se acabar por detectar ambos: tanto el "fichero inocuo con la ligera modificación" como ese mismo "fichero inocuo sin ella".
Esta es solo una posibilidad. Otra es saber dónde o cómo (qué características) mira exactamente un motor en un fichero para saber si es malware y modificar o inyectar código malicioso en ese espacio. En la siguiente versión de ese fichero que será legítima, también será marcado como malware aunque ya no contenga esas características porque para el antivirus, uno y otro "se parecen mucho", dejando actuar los "automatismos de extrapolación". Depende del archivo, de cómo funcione el motor y cómo se creen las firmas.

Así que ya tenemos un falso positivo, y para solucionarlo será necesario actualizar la base de datos, retirar esa firma, y volverla a crear.

Y esta era una práctica "habitual" durante 2012 y 2013, es un hecho. Si ha sido Kaspersky de forma orquestada o no... probablemente no. Obviamente lo niegan, y sinceramente, pensamos que no le hacen falta este tipo de técnicas contra la competencia. Aunque fuese discutible lo de su experimento de 2010, su capacidad para detectar APTs desde entonces, sus análisis, su rendimiento como motor... dejan ya clara sus capacidades técnicas. Gozan de buena reputación a nivel mediático y parecen económicamente sanos. ¿Por qué habrían de recurrir a estos trucos? Quizás, podría ser que esas sean precisamente las razones por las que fuentes "anónimas" difunden esta acusación.

¿Pero esto ocurre hoy en día?

Cada vez menos. Han tomado medidas. Los motores y laboratorios de calidad ya no suelen recurrir tanto a las firmas para detectar. Técnicas de detección en la nube o Machine Learning están sustituyendo a los métodos de detección tradicionales. Y sobre todo, los laboratorios se encuentran en medio de un viraje hacia la lista blanca, más que la inabarcable e inconmensurable lista negra de malware. O al menos utilizan la combinación de ambos factores, de forma que se intenta seguir combatiendo el malware con la detección (lista negra), pero también con el mantenimiento de una lista blanca que reduce esa bestia negra de los falsos positivos.

Conclusiones

Interesante historia no por la acusación hacia Kaspersky (que podrá o no ser cierta), sino por recordar y poner sobre la mesa las catacumbas y problemas de la industria que, aunque cualquiera que trabaje día a día con malware puede comprobar e intuir, no son tan conocidas para el público en general que venera todavía (erróneamente) el antivirus como santo grial de la seguridad y única arma necesaria para remediar todo mal.

¿Se desvela una "guerra sucia" en el mundo de los antivirus? (I)
Sergio de los Santos
ssantos@11paths.com

¿Se desvela una "guerra sucia" en el mundo de los antivirus? (I)

En el mundo de los antivirus (y en otros muchos) probablemente existen las "tácticas de guerrilla", bien sea a través de una publicidad poco honesta, comparativas "compradas", pequeñas "mentiras" o exageraciones en los análisis, plagios descarados... pero, ¿una estrategia especialmente dirigida contra los competidores? ¿Inducirles a la desconfianza forzándoles a detectar importantes falsos positivos? Acusan a Kaspersky de haber realizado esta práctica. Veamos si es cierto.

El maravilloso mundo de los falsos positivos

Cuando se cree que las firmas y las detecciones lo son todo para un motor, cuando VirusTotal se convierte en un injusto escaparate de lo que una tecnología es capaz de hacer... un falso positivo es una de las peores situaciones que le pueden ocurrir a un antivirus. Generan desconfianza, mala imagen, críticas... Pero si el falso positivo se produce en un fichero de sistema, el problema es descomunal. Si el fichero de sistema es vital para Windows y deja de arrancar... el ridículo y las pérdidas (ya económicas), muy considerables. Y... esto les ha pasado a la inmensa mayoría de los grandes jugadores de la industria. Cada cierto tiempo, grandes meteduras de pata, y constantemente (cada día, en cada versión de miles de programas legítimos), se detectan pequeños y grandes falsos positivos. Y esto sin contar con las líneas grises propias del adware, un problema completamente aparte.

Por poner un ejemplo, cuando VirusTotal decidió trabajar con Microsoft para que le confirmara qué software legítimo de Microsoft estaba siendo marcado como malicioso por algún motor, en una semana de trabajo detectaron 6000 casos de falsos positivos, sin demasiado esfuerzo y sobre un conjunto relativamente pequeño de ficheros.

Por poner otro ejemplo, en Tacyt, si buscamos los apks más populares que han sido detectados (como falso positivo, se entiende) en algún momento por algún motor... aparecen casi todas las apps más conocidas. Pero aunque los falsos positivos siempre son menores que los "falsos negativos" (que no son más que el resultado de las carencias propias en la detección), estos son más difíciles de ver para el usuario, así que no preocupan tanto a la industria, casi que se da por hecho y hemos aprendido a vivir con el problema. Se celebra exageradamente la caza de una muestra fresca, se critica o excusa (dependiendo de su complejidad) que pase desapercibida, pero... no se perdona tanto la detección equivocada (continuada).

Qué ha pasado

Ante este panorama, una de las peores zancadillas que se pueden poner en el mundo de los antivirus es la de inducirle a detectar goodware como malware y medrar su reputación. Durante los últimos años, "ha sido más fácil que nunca", puesto que desde la llegada de VirusTotal en 2004, se han dado dos circunstancias importantes:
  • Las casas antivirus pueden enviar muestras y saber rápidamente qué opina la competencia con un análisis estático. Esto ha permitido que muchos laboratorios se relajen. "Oye, si las compañías X, Y y Z lo detectan como malware... ¿quién soy yo para contradecirles? Hagamos una clasificación rápida, al menos para cierto tipo de muestras". Y efectivamente, se produce una especie de "efecto dominó" en la detección (equivocada o no) tantas veces demostrado como escasamente admitido.
  • Las muestras se distribuyen entre todas las casas antivirus y por tanto algunos laboratorios, ante tal avalancha, clasifican en primera instancia según los resultados de esas compañías X, Y y Z porque se sabe que suelen realizar un buen trabajo.
¿Quiénes son esas compañías en las que "todo el mundo confía"? Pues las más reputadas (sea lo que sea que eso signifique, aunque solo sea un mayor gasto en marketing). Sin duda Kaspersky suele estar entre ellas. ESET (por su habilidad con firmas estáticas y heurística), Microsoft (no destaca por su volumen de detección pero suele ser muy específico por firmas y poco tendente al falso positivo), Avast (gran detector de muestras frescas, aunque de forma muy genérica), AVG... en definitiva, se valoran las características conocidas de cada una y así cada laboratorio "cocina" su fórmula para "homenajear el trabajo ajeno".

¿Qué opinan estas casas antivirus sobre estas prácticas? A nadie le gusta que se aprovechen de su trabajo, aunque casi seguro que todas, en algún momento, han mirado al pupitre ajeno para mejorar su nota. Kaspersky fue la primera en demostrar esta práctica con un experimento realizado en 2010. Creó unos cuantos ficheros benignos e hizo que su motor los marcara en VirusTotal como malware. Era una mentirijilla, un "falso positivo" controlado para ver cómo reaccionaban el resto de casas. Diez días después, 14 motores más detectaban este "no malware", en un efecto dominó que dejaba claro quién se fijaba en quién a la hora de marcar con una firma un supuesto malware. Hicieron público el experimento y denunciaron la situación, no sin cierta polémica. Este juego, aunque sirviese como muestra, no "demostraba" por sí solo. Además empañaban la imagen de cara a los usuarios y desacreditaba en cierta manera la función de una herramienta de seguridad no infalible pero sí imprescindible para muchos.

Pero... ¿Llegó Kaspersky más allá?

Parece que dos antiguos trabajadores de Kaspersky han acudido a Reuters para denunciar (de forna anónima) que cuando trabajaban en el laboratorio, Kaspersky mantenía un plan mucho más sutil y maquiavélico para que los competidores cayeran en el falso positivo detectando ficheros importantes y/o comunes como malware. Al margen de la acusación (que levanta muchas dudas), ¿cómo se supone que lo hacían? Aunque no desvelan los detalles técnicos, lo intentaremos explicar en la próxima entrega.

¿Se desvela una "guerra sucia" en el mundo de los antivirus? (y II)

Sergio de los Santos
ssantos@11paths.com

A fondo: algunas funcionalidades de la API de Latch

miércoles, 12 de agosto de 2015

Desde que concebimos Latch en Eleven Paths, tuvimos muy presente que queríamos que fuera algo sencillo. Sencillo para los usuarios pero también lo más sencillo posible para los desarrolladores que integrasen Latch en sus sistemas añadiendo una capa extra de seguridad.

A pesar de ello, en Latch existen muchas otras funcionalidades para desarrolladores más avanzados. Hoy queremos hablaros de algunas de las funciones menos conocidas de la API de Latch que permiten configurar ciertos elementos.

Gestión de operaciones

Hasta ahora la manera tradicional para crear, configurar y eliminar operaciones era mediante el panel de edición de una aplicación:


Todas estas acciones ahora pueden ser realizadas y automatizadas a través de nuestra API. La documentación relativa se encuentra en la pestaña ‘API de Aplicacion’ en la sección ‘Gestionar Operaciones’ de la página de documentación de la API.



API de Usuario

Con la publicación de la nueva versión de la API los desarrolladores con planes GOLD o PLATINUM pueden realizar acciones relativas a la gestión de usuarios que abren todo un abanico de posibilidades a una integración Latch aún más dinámica de lo que era hasta el momento.

Estas acciones se pueden consultar en la sección correspondiente de la documentación de la API en la pestaña ‘API Usuario’.

Para permitir esta gestión de usuarios de forma segura y autenticada, (análogamente a como se hace con las aplicaciones) hace falta disponer de un identificador y un secreto que han de generarse a petición expresa de los usuarios. Esta opción se encuentra en la parte inferior de la sección ‘Mis Aplicaciones’.



Pinchando en el botón ‘Generar clave API de usuario’ obtendremos dicho par de claves:



Una vez obtenidas las claves de acceso a la API de usuario ya podríamos hacer uso de estos endpoints, actualmente se permite:
  • Gestión de Aplicaciones 
  • Consulta del tipo de suscripción y límites

Como podemos ver, se abre la puerta a automatizar configuraciones más avanzadas en diversos escenarios multi-aplicación, autoconfiguración de operaciones en la instalación de plugins, etc, que sin duda permiten realizar, a los desarrolladores, mejores y más robustas integraciones de Latch.

Javier Espinosa
javier.espinosa@11paths.com

Hammertoss, APT que usa esteganografía y Twitter para recibir comandos

miércoles, 5 de agosto de 2015

Como en tiempos de la guerra fría los objetivos se repiten, pero los escenarios cambian. Ya no es tan necesario desplazar agentes secretos a otros países, falsificar pasaportes o disfrazarse para no ser reconocido. Ya no hay que jugarse el pellejo colándose en la noche esquivando sistemas de alarma y seguridad en la sede presidencial o alguna empresa tecnológica para robar documentos. No solo la guerra se libra en internet, sino en sus aspectos más "2.0". Twitter y esteganografía son dos puntos básicos de un grupo de atacantes especializados, llamados APT29 por FireEye.

En un informe publicado por FireEye se detalla el funcionamiento de Hammertoss. Se trata de la herramienta de comunicación y robo de información creada por el grupo que han denominado APT29 y con objetivos de espionaje muy concreto. Se cree que el grupo está siendo financiado por el propio gobierno ruso y sorprende su capacidad de transformación y ofuscación, que le permiten innovar sus estrategias sobre la marcha una vez son detectados.

Esquema de funcionamiento de Hammertoss


Twitter como un DGA

Conficker popularizó una técnica que se sigue usando hoy en día. En vez de incrustar en el código del malware los dominios de sus C&C (dónde tenía que conectarse para recibir instrucciones o dejar datos), lo que hacían eran generarlos dinámicamente, con un algoritmo de generación de dominios (DGA). Según el día, la hora u otros parámetros, eran capaces de generar miles de dominios al día. El malware intentaba conectar con solo un subconjunto, y el atacante registraba según el día (porque conocía el algoritmo y los resultados que arrojaría) unos pocos dominios de los posibles generados. Esto tenía el siguiente efecto:

  • Analizar el malware era mucho más complicado.
  • Nunca se sabía dónde se conectaría el malware para recibir o dejar información.
  • Con pocos registros, el atacante conseguía una buena tasa de "acierto" de dominios, y esto actualizaba el malware con nuevos algoritmos de dominio a su vez, lo que convertían a la botnet en algo muy complejo de seguir o detener, puesto que nunca se sabía exactamente dónde estarían los C&C.

En el caso de APT29 han optado por un sistema parecido pero basado en Twitter. De forma que se crean perfiles de twitter basados en fecha y otros parámetros. Por ejemplo, con la base 123Bob456, donde los tres y últimos números están basados en la fecha. El atacante registraría el perfil de twitter y ahí dejaría instrucciones para el malware en forma de Twit con una URL y un hashtag.

La URL del twit contenía imágenes con información codificada (esteganografía) y además cifrada en su interior. El hashtag le servía al malware para conocer en qué punto se encontraba esa información dentro del archivo de imagen.

Extrayendo información de la cuenta de Twitter generada para la ocasión

Una vez descargada la imagen y localizado el código, se descifran las instrucciones y se ejecutan. Entre estas instrucciones se encuntra la de crear un repositorio en la nube con credenciales de acceso y posteriormente ir recopilando los datos almacenados de la víctima e ir depositándolos allí.

Antonio Bordón
antonio.bordon@11paths.com