como o malware sem arquivo funciona no linux?

Entendo a definição de malware sem arquivo:

Código malicioso que não é baseado em arquivo, mas existe apenas na memória… Mais particularmente, código malicioso sem arquivo… se anexa a um processo ativo na memória…

Alguém pode explicar como isso se acrescenta a um processo ativo na memória?

Além disso, qual proteção / proteção (kernel) está disponível contra esses ataques?

process linux-kernel malware

— Martin Vegter
fonte

Por exemplo, explorando um estouro de buffer em um aplicativo de rede e baixando o código malicioso que é executado dentro do aplicativo e se espalha pela rede. Nenhum arquivo envolvido. A segunda parte da pergunta é muito ampla, ela basicamente equivale a "que contramedidas contra malware existem"?

— dirkt

Esta pergunta pode ser melhor respondida em /security// .

— rubynorails

@ Rubynorails - Estou interessado apenas em respostas específicas do Linux. SecuritySE é geral. Se eu solicitar uma resposta específica do Linux, eles me enviarão aqui.

— Martin Vegter

Respostas:

O malware sem arquivo ataca o alvo explorando uma vulnerabilidade, por exemplo, no plugin Flash do navegador ou em um protocolo de rede.

Um processo Linux pode ser modificado usando a chamada do sistema ptrace(). Essa chamada do sistema geralmente é usada pelos depuradores para inspecionar e gerenciar o estado interno do processo de destino e é útil no desenvolvimento de software.

Por exemplo, vamos considerar um processo com o PID 1234. Todo o espaço de endereço desse processo pode ser visualizado no pseudo sistema de arquivos /procno local /proc/1234/mem. Você pode abrir esse pseudofile e anexar a esse processo via ptrace(); depois de fazer isso, você pode usar pread()e pwrite()gravar no espaço do processo.

char file[64];
pid = 1234;

sprintf(file, "/proc/%ld/mem", (long)pid);
int fd = open(file, O_RDWR);
ptrace(PTRACE_ATTACH, pid, 0, 0);

waitpid(pid, NULL, 0);
off_t addr = ...; // target process address

pread(fd, &value, sizeof(value), addr);
// or
pwrite(fd, &value, sizeof(value), addr);

ptrace(PTRACE_DETACH, pid, 0, 0);
close(fd);

(Código extraído daqui . Outro artigo sobre uma exploração do ptrace está disponível aqui .)

Com relação à defesa orientada ao kernel contra esses ataques, a única maneira é instalar as correções dos fornecedores do kernel e / ou desativar o vetor de ataque específico. Por exemplo, no caso de ptrace, você pode carregar um módulo de bloqueio de ptrace no kernel, o que desativará a chamada específica do sistema; claramente isso também torna você incapaz de usar o ptrace para depuração.

— dr_
fonte

Assim como a outra resposta , isso também está desatualizado - conforme explicado aqui, você não precisa mais rastrear um processo para ler ou escrever nele /proc/PID/mem. Espero que você seja menos refratário do que o outro indivíduo a atualizar e corrigir sua resposta, em vez de perpetuar mitos e desinformação.

— Pizdelect 24/10/19

... nesse caso, pode ter consequências, pois as pessoas podem assumir erroneamente que, ao rastrear um processo, elas podem impedir que outros processos leiam sua memória.

— Pizdelect

@pizdelect Obrigado pelo link. Seria bom se você adicionar o conteúdo como outra resposta.

— 24319 dr_

Não, não vou adicionar outra resposta. Estou esperando que você conserte o seu.

— Pizdelect

Lembre-se de que você também pode editar as respostas de outras pessoas. Parece que você tem um conhecimento melhor do que eu sobre esse tópico em particular, por isso é bem-vindo.

— 26519 dr-

Quando você consegue travar um processo, pode fazer com que o processo insira dados na memória. Uma maneira muito popular de fazer isso é usar estouros de buffer .

Como é que isso funciona ? Você sabe, por exemplo, que um processo está escutando na porta x e possui um buffer para uma determinada função com, digamos, 15 bytes de tamanho. Você chama essa função com 15 bytes de dados + n bytes (seu código a ser executado). Se o programa não validar os dados corretamente, ele substituirá a memória adjacente pelo seu código e, portanto, o código permanecerá na memória. Se você pode executar esse código, é o proprietário do sistema. Existem limitações, por exemplo, um processo não pode gravar na memória fora do seu espaço alocado .

Há uma longa lista de vulnerabilidades em todos os sistemas operacionais, em que a saturação de buffer permite que os crackers injetem dados na memória do destino.

— thecarpy
fonte