Tweet
Como funciona um exploit
Introdução
Nos dias atuais são indiscutíveis os grandes benefícios obtidos por meio da interligação dos
computadores em uma única e grande rede acessível a partir de qualquer ponto do globo. A Internet, essa
grande teia que une milhões de computadores em torno do mundo, é uma conquista irreversível que admite
um único futuro: uma contínua e frequente expansão.
Entretanto, com o advento dessa incrível interconexão de máquinas em escala mundial, muitos ainda
são os problemas que precisam ser resolvidos para que os usuários obtenham uma razoável segurança na
utilização dos serviços disponibilizados na grande rede.
Cada novo serviço ou funcionalidade implementada pelos fabricantes de softwares utilizados nas
redes de computadores encontra, frequentemente, uma imediata resposta de hackers e crackers. Esses
“usuários” utilizam seus conhecimentos avançados de programação de computadores para explorar falhas
existentes nos códigos desenvolvidos para essas novas funcionalidades. Esse é um problema do qual
ninguém está totalmente livre. Conforme (FIREWALLS SECURITY CORPORATION) , até mesmo
programas famosos e considerados seguros já foram lançados no mercado com esse tipo de vulnerabilidade.
Essas investidas contra fraquezas nos sistemas operacionais e aplicativos são apoiadas por
ferramentas conhecidas como exploits. O resultado desses ataques pode ser simplesmente uma momentânea
indisponibilidade do serviço (DOS – Denial Of Service) ou, na pior situação, a abertura de um acesso
privilegiado no computador hospedeiro do serviço que sofreu o ataque. A partir desse acesso obtido,
poderão ser provocados prejuízos imprevisíveis dentro da rede atacada.
Este trabalho procura descrever como funcionam e quais os resultados do ataque desses exploits. O
objetivo do trabalho é dar subsídios aos administradores de rede e desenvolvedores de aplicativos na difícil
tarefa de tentar evitar ou, pelo menos, responder o mais rápido possível a ataques desse tipo.
O que são exploits
O termo exploit, que em português significa, literalmente, explorar, na linguagem da Internet é
usado comumente para se refererir a pequenos códigos de programas desenvolvidos especialmente para
explorar falhas introduzidas em aplicativos por erros involuntários de programação.
Esses exploits, que podem ser preparados para atacar um sistema local ou remotamente, variam
muito quanto à sua forma e poder de ataque. Pelo fato de serem peças de código especialmente preparadas
para explorar falhas muito específicas, geralmente há um diferente exploit para cada tipo de aplicativo, para
cada tipo de falha ou para cada tipo de sistema operacional.
Os exploits podem existir como programas executáveis ou, quando usados remotamente, podem
estar ocultos, por exemplo, dentro de uma mensagem de correio eletrônico ou dentro de determinado
comando de um protocolo de rede.
Como funcionam os exploits
Os exploits quase sempre se aproveitam de uma falha conhecida como buffer overflow (estouro de
buffer).
O buffer overflow acontece quando um programa grava informação em uma certa variável,
passando, porém, uma quantidade maior de dados do que estava previsto pelo programa. Essa situação
possibilita que um código arbitrário seja executado, necessitando apenas que este seja devidamente
posicionado dentro da área de memória do processo.
Na figura 3.1 pode ser visto um simples exemplo de um programa vulnerável a um ataque de buffer
overflow. O problema está na segunda linha da função ProcessaParm, que não critica o tamanho do
parâmetro recebido na variável arg.
O buffer overflow, quando ocorre de forma aleatória, normalmente causa um crash na aplicação. No
Linux, essa situação gera a conhecida segmentation fault com core dump. Porém, quando corretamente
induzido pelo atacante, o buffer overflow pode permitir que se execute um código malicioso que terá os
mesmos privilégios de execução do aplicativo atacado.
Embora o problema do buffer overflow seja conhecido há muito tempo, somente nos últimos anos
ele passou a ser amplamente explorado como ferramenta de ataque.
Para entender completamente como o buffer overflow é explorado para se obter acessos indevidos ao
sistema, é necessário em primeiro lugar compreender como os processos são organizados em memória. Cada
arquitetura de hardware, sistema operacional ou compilador pode organizar de forma diferente um processo
em memória. Na figura 3.2 é possível ver um diagrama que representa essa organização para um programa
escrito na linguagem C em um sistema Linux/i386.
A área de programa armazena o código executável. Na área de variáveis globais são alocadas todas
as variáveis globais e estáticas; enquanto que a área de heap é reservada para alocação local e dinâmica de
memória. Finalmente, a área de pilha é usada para salvar registradores, salvar o endereço de retorno de
subrotinas, criar variáveis locais bem como para passar parâmetros na chamada de funções.
Como pode ser observado na figura 3.2, os ponteiros da pilha e do heap crescem em sentidos
opostos, convergindo para o centro da área livre que é comum às duas estruturas de memória. Esse artifício é
usado para otimizar o uso da memória livre na área de dados do processo. Entretanto, como será visto ainda
nesta seção, essa característica possibilita que os ataques sejam feitos tanto pela pilha quanto pelo heap.
Na figura 3.3 é possível ver os elementos envolvidos no processo de chamada de uma função.
Normalmente, quando uma função é chamada, os seguintes passos são executados:
1) Os parâmetros da função são colocados da pilha em ordem inversa.
2) Quando a instrução call é executa, o endereço de retorno é armazenado para permitir o retorno
da função à instrução imediatamente seguinte àquela que a chamou.
3) Já dentro da função, o conteúdo do registrador EBP, que é usado como apontador do stack
frame, é colocado da pilha para ser recuperado no final da função.
4) Registrador EBP é carregado com o valor atual do ponteiro de pilha (SP).
5) O ponteiro da pilha é decrementado em N bytes, onde N é a quantidade de bytes necessários
para a criação das variáveis locais.
Devido a essa sua característica, a pilha é o “calcanhar de aquiles” de toda essa estrutura. Com muita
paciência, persistência e algum conhecimento de assembly e C, é possível alterar o valor do endereço de
retorno do programa e redirecioná-lo para um código malicioso.
A partir desse momento, o ponteiro de instruções do processo passa a ser inteiramente controlado
pelo atacante, que poderá fazer qualquer chamada a funções disponíveis no sistema.
A alteração do endereço de retorno pode ser feita tanto pelo “estouro” de uma variável local alocada
na pilha quanto pelo “estouro” da área de heap. Da mesma forma, o código malicioso, para onde o programa
será desviado, pode ser colocado tanto no heap quanto na pilha. Nas figuras 3.4 e 3.5 pode ser vista uma
representação da memória durante um ataque de pilha e de heap, respectivamente.
Como pode ser visto na figura 3.5, os exploits baseados no heap são mais difíceis de se construir
devido à dificuldade de se determinar com precisão o tamanho da área entre o heap e a pilha.
Recentemente, os sistemas operacionais têm implementado mecanismos de bloqueio de execução de
códigos na área de pilha e de heap. Essa medida tem por objetivo evitar esses ataques. Porém, para contornar
essa dificuldade, uma outra variante do ataque foi desenvolvida. Essa nova tática, conhecida como “retorno
à libc”, descrita em (MCDONALD,1999), consiste em desviar o programa para uma função da libc
(system(), por exemplo), portanto dentro da área de código, onde não há qualquer restrição de execução
de programas.
A criação de novas técnicas de ataque é apenas uma questão de tempo. Por exemplo, uma técnica
mais recente que o buffer overflow, e muito mais complexa do que esta, é a exploração do Format String
Bug, detalhada com muita precisão em (THUEMMEL,2001).
Na seção 4 será apresentado, passo a passo, um exemplo de um exploit baseado no estouro da pilha.
Essa variante de exploit foi escolhida para ser analisada aqui por ser, dentre as técnicas de explorações de
buffer overflow, a de menor dificuldade de implementação e a que mais tem sido usada ultimamente.
Um exemplo de exploit baseado no buffer overflow de pilha
Em um ataque de estouro da pilha, normalmente o atacante terá que responder as seguintes questões
antes de poder construir o exploit propriamente dito:
Qual o tamanho do buffer?: em softwares livres isso é facilmente conseguido pelo fato dos fontes
do programas serem de domínio público. Aqui não há demérito algum para o software livre uma vez que,
fazendo um paralelo com a criptografia, conforme (UCHOA,2003), a segurança baseada na obscuridade é
restrita e deve ser evitada.
O que vai ser executado dentro do código malicioso?: para responder a essa pergunta o atacante
deve conhecer uma linguagem de baixo nível, preferencialmente C, que será utilizada para construir o
exploit. Além disso, é necessário que se conheça também um pouco de Assembly e do programa de
depuração gdb. A premissa utilizada aqui é fazer um programa tão poderoso que faça todo o trabalho
necessário e tão pequeno que caiba dentro da área de buffer. Normalmente, a seqüência é: criar o programa
em C, compilá-lo, abri-lo com o gdb, “anotar” os códigos binários das instruções referentes ao trecho
necessário. Esses códigos anotados do gdb serão guardados em uma variável do exploit, que os utilizará na
construção da mensagem que será enviada ao servidor.
Como “estourar” o buffer do servidor?: aqui, principalmente, é onde entra a especificidade de
cada exploit. Novamente o atacante se utiliza do conhecimento dos fontes dos programas para conhecer
todos os fatos necessários ao ataque. Não fosse o conhecimento dos fontes, isso ainda seria possível pelo
menos de duas formas diferentes: ou através de engenharia reversa, utilizando-se de uma ferramenta de
depuração (gdb, por exemplo), ou através da tentativa e erro, enviando grandes strings em qualquer parte do
programa em que há entrada de dados por parte do usuário.
A figura 4.1 mostra um trecho do programa que será alvo do ataque. Trata-se aqui de um programa
muito simples que tem por finalidade apenas servir aos propósitos didáticos deste trabalho. O programa
implementa apenas duas funções: a função main(), que é responsável por “ouvir” a porta UDP 1234 e a
função TrataMensagem(), que é chamada a cada mensagem recebida pelo servidor.
O programa cliente será o exploit, que preparará uma mensagem de forma tal que provoque o buffer
overflow no servidor. Esse ataque abrirá, no servidor, um backdoor que será usado em seguida pelo atacante
para continuar seu “trabalho”.
Procurando responder a segunda questão colocada no início desta seção, foi desenvolvido o código
apresentado na figura 4.2. Neste trabalho, a única ação do atacante será criar o arquivo /bin/sx. Outros
comandos poderiam ser acrescentados ao código para efetuar outras ações, como, por exemplo, incluir um
usuário no arquivo /etc/passwd. Para criar o arquivo /bin/sx foi usada a system call sys_creat,
através da instrução int 0x80. Após criar o arquivo, o exploit simplesmente encerra a execução do servidor.
Na figura 4.2 pode ser visto o código Assembly para esse pequeno programa. Para compilar o
programa, foi usado o comando: gcc -g -o prog prog.c -ldb.
O atacante deve conhecer previamente o endereço da área de memória onde está o comando que será
executado. Outro endereço a ser descoberto em tempo de execução é o da string que contém o nome do
arquivo a ser criado. Aqui, foi utilizada a técnica descrita em (ARANHA,2003), que consiste em iniciar o
programa com um salto para uma instrução imediatamente anterior ao endereço que se quer conhecer. Em
seguida o programa deve ser desviado para o restante do código através da execução da intrução call. Dessa
forma, o endereço da string é armazenado na pilha, podendo, assim, ser lido pelo restante do código
malicioso.
Usando o gdb, o código malicioso deve ser exportado em formato hexadecimal. Nesse caso pode
ser usado o comando do gdb: x/<n>bx <endereço>. A saída hexadecimal do código pode ser vista na figura
4.3.
A figura 4.4 mostra a parte do código do exploit responsável por montar o buffer e enviá-lo para o
servidor. Como pode ser visto, o código do exploit em si é muito simples. Na verdade, a grande dificuldade
reside nos passos anteriores, onde devem ser identificados os endereços de dados e de funções que serão
usados pelo código malicioso quando este estiver executando no servidor alvo.
Conclusão
As técnicas aqui mostradas, e muitas outras, estão disponíveis em diversos sites da Internet,
mostrando a dialética aí envolvida, onde a própria Internet traz em si os elementos capazes de destruí-la, mas
que ao mesmo tempo, são a fonte de seu desenvolvimento. Enquanto os atacantes se utilizam de falhas
deixadas ao longo do desenvolvimento da Internet, as equipes de desenvolvimento e segurança se utilizam
das técnicas empregadas pelo atacantes - geralmente técnicas avançadas de programação - para produzir seus
antídotos, bem como novas funcionalidades.
Como ações de proteção contra esses ataques, recomenda-se a atualização constante do sistema,
aplicando-se os patches necessários, ou mesmo promovendo os devidos upgrades de versão.
Para os programadores, a recomendação não poderia ser outra: atenção! Muita atenção! O menor
descuido pode ser a oportunidade que o atacante precisa. Deve-se, sempre que possível, evitar funções que
podem causar buffer overflow, tais como strcpy, que deve ser substituída por sua equivalente strncpy.
Ao usar funções passíveis de exploração pela técnica Format String Bug, tais como printf, evitar aplicar a
essas funções os valores fornecidos diretamente pelo usuário do programa. Se possível, substituir a libc
por versões seguras de biblioteca padrão, tais como a libmib (Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...)
ou libsafe (Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...).
Afinal, ninguém pode dizer que está livre de ser atacado, porém esse fato não deve ser desculpa para
que não se procure, por todos os meios possíveis, impor aos atacantes, senão uma missão impossível, pelo
menos uma tarefa extremamente árdua.
Fonte : Under L.
Introdução
Nos dias atuais são indiscutíveis os grandes benefícios obtidos por meio da interligação dos
computadores em uma única e grande rede acessível a partir de qualquer ponto do globo. A Internet, essa
grande teia que une milhões de computadores em torno do mundo, é uma conquista irreversível que admite
um único futuro: uma contínua e frequente expansão.
Entretanto, com o advento dessa incrível interconexão de máquinas em escala mundial, muitos ainda
são os problemas que precisam ser resolvidos para que os usuários obtenham uma razoável segurança na
utilização dos serviços disponibilizados na grande rede.
Cada novo serviço ou funcionalidade implementada pelos fabricantes de softwares utilizados nas
redes de computadores encontra, frequentemente, uma imediata resposta de hackers e crackers. Esses
“usuários” utilizam seus conhecimentos avançados de programação de computadores para explorar falhas
existentes nos códigos desenvolvidos para essas novas funcionalidades. Esse é um problema do qual
ninguém está totalmente livre. Conforme (FIREWALLS SECURITY CORPORATION) , até mesmo
programas famosos e considerados seguros já foram lançados no mercado com esse tipo de vulnerabilidade.
Essas investidas contra fraquezas nos sistemas operacionais e aplicativos são apoiadas por
ferramentas conhecidas como exploits. O resultado desses ataques pode ser simplesmente uma momentânea
indisponibilidade do serviço (DOS – Denial Of Service) ou, na pior situação, a abertura de um acesso
privilegiado no computador hospedeiro do serviço que sofreu o ataque. A partir desse acesso obtido,
poderão ser provocados prejuízos imprevisíveis dentro da rede atacada.
Este trabalho procura descrever como funcionam e quais os resultados do ataque desses exploits. O
objetivo do trabalho é dar subsídios aos administradores de rede e desenvolvedores de aplicativos na difícil
tarefa de tentar evitar ou, pelo menos, responder o mais rápido possível a ataques desse tipo.
O que são exploits
O termo exploit, que em português significa, literalmente, explorar, na linguagem da Internet é
usado comumente para se refererir a pequenos códigos de programas desenvolvidos especialmente para
explorar falhas introduzidas em aplicativos por erros involuntários de programação.
Esses exploits, que podem ser preparados para atacar um sistema local ou remotamente, variam
muito quanto à sua forma e poder de ataque. Pelo fato de serem peças de código especialmente preparadas
para explorar falhas muito específicas, geralmente há um diferente exploit para cada tipo de aplicativo, para
cada tipo de falha ou para cada tipo de sistema operacional.
Os exploits podem existir como programas executáveis ou, quando usados remotamente, podem
estar ocultos, por exemplo, dentro de uma mensagem de correio eletrônico ou dentro de determinado
comando de um protocolo de rede.
Como funcionam os exploits
Os exploits quase sempre se aproveitam de uma falha conhecida como buffer overflow (estouro de
buffer).
O buffer overflow acontece quando um programa grava informação em uma certa variável,
passando, porém, uma quantidade maior de dados do que estava previsto pelo programa. Essa situação
possibilita que um código arbitrário seja executado, necessitando apenas que este seja devidamente
posicionado dentro da área de memória do processo.
Na figura 3.1 pode ser visto um simples exemplo de um programa vulnerável a um ataque de buffer
overflow. O problema está na segunda linha da função ProcessaParm, que não critica o tamanho do
parâmetro recebido na variável arg.
O buffer overflow, quando ocorre de forma aleatória, normalmente causa um crash na aplicação. No
Linux, essa situação gera a conhecida segmentation fault com core dump. Porém, quando corretamente
induzido pelo atacante, o buffer overflow pode permitir que se execute um código malicioso que terá os
mesmos privilégios de execução do aplicativo atacado.
Embora o problema do buffer overflow seja conhecido há muito tempo, somente nos últimos anos
ele passou a ser amplamente explorado como ferramenta de ataque.
Para entender completamente como o buffer overflow é explorado para se obter acessos indevidos ao
sistema, é necessário em primeiro lugar compreender como os processos são organizados em memória. Cada
arquitetura de hardware, sistema operacional ou compilador pode organizar de forma diferente um processo
em memória. Na figura 3.2 é possível ver um diagrama que representa essa organização para um programa
escrito na linguagem C em um sistema Linux/i386.
A área de programa armazena o código executável. Na área de variáveis globais são alocadas todas
as variáveis globais e estáticas; enquanto que a área de heap é reservada para alocação local e dinâmica de
memória. Finalmente, a área de pilha é usada para salvar registradores, salvar o endereço de retorno de
subrotinas, criar variáveis locais bem como para passar parâmetros na chamada de funções.
Como pode ser observado na figura 3.2, os ponteiros da pilha e do heap crescem em sentidos
opostos, convergindo para o centro da área livre que é comum às duas estruturas de memória. Esse artifício é
usado para otimizar o uso da memória livre na área de dados do processo. Entretanto, como será visto ainda
nesta seção, essa característica possibilita que os ataques sejam feitos tanto pela pilha quanto pelo heap.
Na figura 3.3 é possível ver os elementos envolvidos no processo de chamada de uma função.
Normalmente, quando uma função é chamada, os seguintes passos são executados:
1) Os parâmetros da função são colocados da pilha em ordem inversa.
2) Quando a instrução call é executa, o endereço de retorno é armazenado para permitir o retorno
da função à instrução imediatamente seguinte àquela que a chamou.
3) Já dentro da função, o conteúdo do registrador EBP, que é usado como apontador do stack
frame, é colocado da pilha para ser recuperado no final da função.
4) Registrador EBP é carregado com o valor atual do ponteiro de pilha (SP).
5) O ponteiro da pilha é decrementado em N bytes, onde N é a quantidade de bytes necessários
para a criação das variáveis locais.
Devido a essa sua característica, a pilha é o “calcanhar de aquiles” de toda essa estrutura. Com muita
paciência, persistência e algum conhecimento de assembly e C, é possível alterar o valor do endereço de
retorno do programa e redirecioná-lo para um código malicioso.
A partir desse momento, o ponteiro de instruções do processo passa a ser inteiramente controlado
pelo atacante, que poderá fazer qualquer chamada a funções disponíveis no sistema.
A alteração do endereço de retorno pode ser feita tanto pelo “estouro” de uma variável local alocada
na pilha quanto pelo “estouro” da área de heap. Da mesma forma, o código malicioso, para onde o programa
será desviado, pode ser colocado tanto no heap quanto na pilha. Nas figuras 3.4 e 3.5 pode ser vista uma
representação da memória durante um ataque de pilha e de heap, respectivamente.
Como pode ser visto na figura 3.5, os exploits baseados no heap são mais difíceis de se construir
devido à dificuldade de se determinar com precisão o tamanho da área entre o heap e a pilha.
Recentemente, os sistemas operacionais têm implementado mecanismos de bloqueio de execução de
códigos na área de pilha e de heap. Essa medida tem por objetivo evitar esses ataques. Porém, para contornar
essa dificuldade, uma outra variante do ataque foi desenvolvida. Essa nova tática, conhecida como “retorno
à libc”, descrita em (MCDONALD,1999), consiste em desviar o programa para uma função da libc
(system(), por exemplo), portanto dentro da área de código, onde não há qualquer restrição de execução
de programas.
A criação de novas técnicas de ataque é apenas uma questão de tempo. Por exemplo, uma técnica
mais recente que o buffer overflow, e muito mais complexa do que esta, é a exploração do Format String
Bug, detalhada com muita precisão em (THUEMMEL,2001).
Na seção 4 será apresentado, passo a passo, um exemplo de um exploit baseado no estouro da pilha.
Essa variante de exploit foi escolhida para ser analisada aqui por ser, dentre as técnicas de explorações de
buffer overflow, a de menor dificuldade de implementação e a que mais tem sido usada ultimamente.
Um exemplo de exploit baseado no buffer overflow de pilha
Em um ataque de estouro da pilha, normalmente o atacante terá que responder as seguintes questões
antes de poder construir o exploit propriamente dito:
Qual o tamanho do buffer?: em softwares livres isso é facilmente conseguido pelo fato dos fontes
do programas serem de domínio público. Aqui não há demérito algum para o software livre uma vez que,
fazendo um paralelo com a criptografia, conforme (UCHOA,2003), a segurança baseada na obscuridade é
restrita e deve ser evitada.
O que vai ser executado dentro do código malicioso?: para responder a essa pergunta o atacante
deve conhecer uma linguagem de baixo nível, preferencialmente C, que será utilizada para construir o
exploit. Além disso, é necessário que se conheça também um pouco de Assembly e do programa de
depuração gdb. A premissa utilizada aqui é fazer um programa tão poderoso que faça todo o trabalho
necessário e tão pequeno que caiba dentro da área de buffer. Normalmente, a seqüência é: criar o programa
em C, compilá-lo, abri-lo com o gdb, “anotar” os códigos binários das instruções referentes ao trecho
necessário. Esses códigos anotados do gdb serão guardados em uma variável do exploit, que os utilizará na
construção da mensagem que será enviada ao servidor.
Como “estourar” o buffer do servidor?: aqui, principalmente, é onde entra a especificidade de
cada exploit. Novamente o atacante se utiliza do conhecimento dos fontes dos programas para conhecer
todos os fatos necessários ao ataque. Não fosse o conhecimento dos fontes, isso ainda seria possível pelo
menos de duas formas diferentes: ou através de engenharia reversa, utilizando-se de uma ferramenta de
depuração (gdb, por exemplo), ou através da tentativa e erro, enviando grandes strings em qualquer parte do
programa em que há entrada de dados por parte do usuário.
A figura 4.1 mostra um trecho do programa que será alvo do ataque. Trata-se aqui de um programa
muito simples que tem por finalidade apenas servir aos propósitos didáticos deste trabalho. O programa
implementa apenas duas funções: a função main(), que é responsável por “ouvir” a porta UDP 1234 e a
função TrataMensagem(), que é chamada a cada mensagem recebida pelo servidor.
O programa cliente será o exploit, que preparará uma mensagem de forma tal que provoque o buffer
overflow no servidor. Esse ataque abrirá, no servidor, um backdoor que será usado em seguida pelo atacante
para continuar seu “trabalho”.
Procurando responder a segunda questão colocada no início desta seção, foi desenvolvido o código
apresentado na figura 4.2. Neste trabalho, a única ação do atacante será criar o arquivo /bin/sx. Outros
comandos poderiam ser acrescentados ao código para efetuar outras ações, como, por exemplo, incluir um
usuário no arquivo /etc/passwd. Para criar o arquivo /bin/sx foi usada a system call sys_creat,
através da instrução int 0x80. Após criar o arquivo, o exploit simplesmente encerra a execução do servidor.
Na figura 4.2 pode ser visto o código Assembly para esse pequeno programa. Para compilar o
programa, foi usado o comando: gcc -g -o prog prog.c -ldb.
O atacante deve conhecer previamente o endereço da área de memória onde está o comando que será
executado. Outro endereço a ser descoberto em tempo de execução é o da string que contém o nome do
arquivo a ser criado. Aqui, foi utilizada a técnica descrita em (ARANHA,2003), que consiste em iniciar o
programa com um salto para uma instrução imediatamente anterior ao endereço que se quer conhecer. Em
seguida o programa deve ser desviado para o restante do código através da execução da intrução call. Dessa
forma, o endereço da string é armazenado na pilha, podendo, assim, ser lido pelo restante do código
malicioso.
Usando o gdb, o código malicioso deve ser exportado em formato hexadecimal. Nesse caso pode
ser usado o comando do gdb: x/<n>bx <endereço>. A saída hexadecimal do código pode ser vista na figura
4.3.
A figura 4.4 mostra a parte do código do exploit responsável por montar o buffer e enviá-lo para o
servidor. Como pode ser visto, o código do exploit em si é muito simples. Na verdade, a grande dificuldade
reside nos passos anteriores, onde devem ser identificados os endereços de dados e de funções que serão
usados pelo código malicioso quando este estiver executando no servidor alvo.
Conclusão
As técnicas aqui mostradas, e muitas outras, estão disponíveis em diversos sites da Internet,
mostrando a dialética aí envolvida, onde a própria Internet traz em si os elementos capazes de destruí-la, mas
que ao mesmo tempo, são a fonte de seu desenvolvimento. Enquanto os atacantes se utilizam de falhas
deixadas ao longo do desenvolvimento da Internet, as equipes de desenvolvimento e segurança se utilizam
das técnicas empregadas pelo atacantes - geralmente técnicas avançadas de programação - para produzir seus
antídotos, bem como novas funcionalidades.
Como ações de proteção contra esses ataques, recomenda-se a atualização constante do sistema,
aplicando-se os patches necessários, ou mesmo promovendo os devidos upgrades de versão.
Para os programadores, a recomendação não poderia ser outra: atenção! Muita atenção! O menor
descuido pode ser a oportunidade que o atacante precisa. Deve-se, sempre que possível, evitar funções que
podem causar buffer overflow, tais como strcpy, que deve ser substituída por sua equivalente strncpy.
Ao usar funções passíveis de exploração pela técnica Format String Bug, tais como printf, evitar aplicar a
essas funções os valores fornecidos diretamente pelo usuário do programa. Se possível, substituir a libc
por versões seguras de biblioteca padrão, tais como a libmib (Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...)
ou libsafe (Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...).
Afinal, ninguém pode dizer que está livre de ser atacado, porém esse fato não deve ser desculpa para
que não se procure, por todos os meios possíveis, impor aos atacantes, senão uma missão impossível, pelo
menos uma tarefa extremamente árdua.
Fonte : Under L.
Comment