Llegamos a ustedes gracias a:



Reportajes y análisis

Errores tontos de cifrado que cometen los criminales

[25/11/2016] Escribir código seguro puede ser un desafío, y la implementación correcta de la criptografía en el software es simplemente difícil. Incluso los desarrolladores experimentados pueden tropezar en esto. Y si su objetivo es estafar a la gente rápidamente -no para sorprenderlos con la calidad de su software-, seguro que habrá serios errores de criptografía en su código.

Los autores de malware pueden proporcionar lecciones importantes sobre cómo no implementar la criptografía. Tal fue el resultado de la investigación realizada por Yaniv Balmas y Ben Herzog de Check Point en la reciente conferencia del Virus Bulletin en Denver. Los autores de malware pueden ser más propensos a insertar criptografías en su código que los desarrolladores que trabajan en software legítimo, ya que no les importa tanto la calidad del código o el diseño, señalaron Balmas y Herzog. Estos criminales se centran en obtener un producto que hace lo suficiente para satisfacer sus necesidades inmediatas -y no más.

He aquí un vistazo a los errores de criptografía de los recientes titulares de malware -y cómo identificar errores similares en los futuros scripts de malware con la esperanza de romper su código malicioso.

Pensamiento borroso sobre el cifrado

Los errores son inevitables cuando solamente tiene una "comprensión difusa de los detalles" y un marco de tiempo muy apretado. Analizando el trabajo de los autores de malware, Balmas y Herzog identificaron cuatro "anti-patrones", cuando trataron de implementar el cifrado, incluyendo la programación voodoo, la técnica del culto de carga, reinventar la rueda cuadrada y el farol. Los defensores que descubren indicios de estas categorías de errores pueden romper el cifrado y obstaculizar la ejecución del malware, o pueden descubrir sus secretos a través de la ingeniería inversa.

"Estos son malentendidos básicos de cómo usar correctamente las herramientas criptográficas, que en el mejor de los casos se difunden como 'no tengo ni idea de lo que estoy haciendo', y en el peor, paralizan catastróficamente el malware de tal manera que no hace lo que se propuso hacer, escribieron Balmas y Herzog.

Profesionales o aficionados, estos autores de malware reconocen que la criptografía es cada vez más esencial para el desarrollo del malware -en ransomware, para extorsionar dinero de las víctimas; en ocultar comunicaciones desde el dispositivo infectado al servidor de comando y control; evitando sigilosamente la detección mediante herramientas de seguridad; y registrando el malware como una aplicación de confianza. Pero el análisis muestra que muchos parecen tener problemas para usar el cifrado eficazmente, en detrimento de ellos. Los analistas de seguridad y los administradores de redes que reconocen las principales clases de errores criptográficos tienen una gran ventaja al frustrar demandas de rescate y frustrar las infecciones.

"Los autores de malware desarrollan basados en sentimientos y supersticiones; saltan con avidez en pobres oportunidades de reinventar la rueda; con igual entusiasmo, en las oportunidades de usar un código ya hecho que resuelva perfectamente el problema equivocado", escribieron Balmas y Herzog en el whitepaper de la conferencia.

No tengo idea de lo que hace esto, pero se ve bien

Los autores detrás del troyano bancario de Zeus y del ransomware basado en Linux Linux.Encoder, cayeron en la trampa de "programación voodoo". Su implementación criptográfica "traiciona una profunda confusión acerca de la funcionalidad que se está invocando -lo que es, lo que hace y por qué podría fallar", dijeron los investigadores.

En el caso de Zeus, los autores eligieron la popular cifra de flujo RC4 para cifrar todo el tráfico C&C de Zeus, pero añadió otro ajuste. Tomaron la corriente ya encriptada y modificaron cada byte por XORing con el siguiente byte. Mientras que RC4 tiene sus propias debilidades de seguridad, el cifrado es lo suficientemente seguro para hacer lo que necesitaba Zeus, y la variante ajustada era "exactamente tan segura como la esencia de RC4a", observaron los investigadores.

Con Linux.Encoder, los autores sembraron la función rand() con la marca de hora actual para generar su clave de cifrado. Cuando los investigadores de seguridad señalaron que era realmente fácil romper las claves de ransomware, los autores trataron de generar una clave AES mediante el hashing de la marca de tiempo ocho veces.

"Utilizar una función hash ocho veces consecutivas en una entrada muestra un malentendido profundo de lo que son las funciones hash", escribieron los investigadores, señalando que la repetición de la función no produce un mejor hash. De hecho, podría resultar en "una creación extraña que tiene propiedades de seguridad más débiles".

Copia y pega este código que encontré

La segunda clase, "programación de carga de culto", se refiere a copiar lo que parece una solución de trabajo para el problema, y pegar ese bloque de código en el programa sin entender por qué o cómo funciona el código. Copiar código no es una gran cosa -si lo fuera, el desbordamiento de pila no existiría- pero si el programador no sabe lo que está sucediendo realmente en ese bloque, entonces el programador no sabe si el código es realmente La solución correcta.

"Ellos podrían terminar usando código que cumple casi lo que tenían en mente, pero no del todo", escribieron los investigadores, señalando que los autores detrás de CryptoDefense ransomware cayeron en esta trampa.

Mientras que la mayoría de las funciones de CryptoDefense -encriptación RSA-2048, pagada vía bitcoin, en comunicación con servidores C&C vía Tor- se copiaron del ransomware original de CryptoLocker, la implementación real de RSA se basó en una API criptográfica de bajo nivel de Windows. El código real se puede encontrar en la documentación de Microsoft Developer Network junto con la explicación de que cuando un indicador no se establece correctamente, la aplicación guarda la clave privada en el almacenamiento de claves local. Los autores de CryptoDefense no establecieron esa bandera, por lo que los investigadores de seguridad trabajaron con las víctimas para encontrar la clave privada en sus equipos con el fin de descifrar los archivos.

Debido a que los autores de malware no leyeron bien la documentación, los defensores fueron capaces de salvar el día.

Empedrar juntos el código

El desarrollador de software típico con mucho gusto se unirá a un proyecto de código abierto que se encarga de una tarea necesaria, y ahorra tiempo y esfuerzo para escribir desde cero. Desafortunadamente para los autores de malware, la compilación con código de terceros vinculados estáticamente no siempre es una opción, ya que el código extra puede ampliar el ejecutable resultante o facilitar las herramientas de seguridad para detectar el malware. En lugar de vincular, los autores tienden a improvisar y juntar algo que funciona. Los grupos detrás del kit de la explosión nuclear y las familias de ransomware Petya y DirCrypt intentaron "reinventar la rueda cuadrada", y para beneficio de todos los demás, lo hicieron demasiado mal.

"Si piensa que cualquier cosa en la criptografía es completamente simple de implementar, o no entiende la criptografía, o ésta no lo entiende", escribieron los investigadores.

El kit de exploit ampliamente distribuido, Nuclear, ofusca la entrega del exploit mediante el uso del Diffie-Hellman Key Exchange para cifrar la información transmitida a las cargas útiles. Las variables necesarias para el intercambio de claves se envían al servidor como un archivo JSON que contiene cadenas de dígitos hexadecimales, y los valores se analizan y se decodifican utilizando Base64. Sin embargo, los investigadores señalaron que la implementación fue "absurda" ya que estableció la clave secreta a 0, haciendo todo el proceso inútil.

Los autores de Petra implementaron Salsa20, una cifra de flujo menos conocida que se considera más resistente a los ataques que RC4, desde cero. Sin embargo, tres defectos importantes en la implementación de Petya hacen que el ransomware genere una clave de 512 bits que contiene 256 bits de valores constantes y predecibles.

"Cuando su implementación de un cifrado reduce su tamaño de clave efectiva a la mitad, y el tiempo requerido para un descanso de 25 órdenes de magnitud, es hora de ir a sentarse en la esquina y pensar en lo que ha hecho", dijeron los investigadores.

A DirCrypt no le fue mucho mejor, ya que los autores cometieron el error común de reutilizar la misma clave al cifrar cada archivo con RC4. La reutilización de claves es un error comprensible, especialmente si la persona no tiene conocimientos elementales de cómo funcionan los cifrados de flujo y cómo pueden fallar. Sin embargo, el grupo cometió un error mayor añadiendo la clave al archivo cifrado. Las víctimas pueden acceder directamente a la clave y utilizarla para recuperar porciones de archivos bloqueados y, en algunos casos, recuperar archivos enteros.

Fínjalo

La última categoría no es en realidad un error de codificación, sino más bien el atajo de ingeniería social intencional del autor de malware. Los autores de Ransomware, por ejemplo, no necesitan crear el "impecable diseño criptográfico e implementación" cuando es mucho más fácil mentir, según Balmas y Herzog de Check Point. Pocas víctimas van a cuestionar las demandas de cifrado del malware cuando se trata de recuperar sus datos.

Este fue el caso de Nemucod, un troyano JavaScript que recientemente se transformó en ransomware, que afirmaba cifrar archivos con cifrado RSA-1024 cuando en realidad estaba utilizando un cifrado XOR rotativo simple. Nemucod también muestra la nota de rescate antes de que los archivos estén realmente cifrados, por lo que, si el antivirus o la herramienta de seguridad de la víctima es lo suficientemente vigilante para evitar que el malware descargue los componentes de cifrado, los archivos permanecen intactos.

Del mismo modo, el ransomware Poshcoder utilizó originalmente AES, en lugar de cifrado RSA-2048 o RSA-4096 listado en la nota de rescate. Poshcoder también afirma utilizar el cifrado asimétrico fuerte, salvo que AES es un cifrado simétrico y es vulnerable a una serie de ataques.

El grupo detrás de Nemucod cree que "los posibles adversarios se convertirán en tontos y débiles en las rodillas en el momento en que escuchen la frase 'RSA-1024'", escribieron los investigadores, señalando que Nemucod "establece el estándar de oro para un esfuerzo mínimo". Si las víctimas están lo suficientemente asustadas, es posible que tengan menos probabilidades de echar un vistazo más de cerca a las capacidades del malware.

Aprovecharse de los errores

La criptografía es difícil, y muchos desarrolladores de software se equivocan al intentar implementar el cifrado. Tenga en cuenta que la lista de las primeras diez vulnerabilidades de la aplicación web de Open Web Application Security Project identifican solo dos errores criptográficos comunes que los desarrolladores pueden realizar. No es de extrañar que los malos también estén luchando.

"La evidencia sugiere que la mayoría de los autores de programas maliciosos ven esas herramientas como maravillosas cajas negras de magia negra, y calculan que deberían estar contentos si pueden obtener el código de cifrado para que se ejecuten", escribieron los investigadores.

Es tentador pagar el rescate o comenzar a restaurar desde el respaldo de inmediato cuando los archivos han sido bloqueados por ransomware, o asumir que no hay forma de romper las comunicaciones entre un punto final infectado y los servidores C&C del malware. Los analistas de seguridad y los administradores de TI dispuestos a tomar el tiempo para buscar estos errores comunes en el malware ofensivo, pueden ser capaces de cambiar el resultado. Algún día, los chicos malos aprenderán a usar el cifrado correctamente; hasta entonces, los defensores tienen la ventaja, ya que pueden ingresar a las implementaciones rotas y errores de codificación.