Scribd
Carregar
6 visualizações4 páginas

Injeçãode Comando

O ataque de injeção de comando permite que um intruso execute comandos não autorizados em uma aplicação vulnerável, geralmente devido à falta de validação de dados de entrada. Exemplos incluem a manipulação de comandos em programas que executam com privilégios elevados, permitindo que atacantes executem comandos arbitrários. A diferença entre injeção de comando e injeção de código é que a primeira executa comandos do sistema, enquanto a segunda insere código no existente.

Enviado por

aaaaa12312e
Direitos autorais
© © All Rights Reserved
Levamos muito a sério os direitos de conteúdo. Se você suspeita que este conteúdo é seu, reivindique-o aqui.
Formatos disponíveis
Baixe no formato TXT, PDF, TXT ou leia on-line no Scribd
6 visualizações4 páginas

Injeçãode Comando

O ataque de injeção de comando permite que um intruso execute comandos não autorizados em uma aplicação vulnerável, geralmente devido à falta de validação de dados de entrada. Exemplos incluem a manipulação de comandos em programas que executam com privilégios elevados, permitindo que atacantes executem comandos arbitrários. A diferença entre injeção de comando e injeção de código é que a primeira executa comandos do sistema, enquanto a segunda insere código no existente.

Enviado por

aaaaa12312e
Direitos autorais
© © All Rights Reserved
Levamos muito a sério os direitos de conteúdo. Se você suspeita que este conteúdo é seu, reivindique-o aqui.
Formatos disponíveis
Baixe no formato TXT, PDF, TXT ou leia on-line no Scribd
Você está na página 1/ 4

Injeção de comando

Descrição

O objectivo do ataque de injeção de comando é injectar e executar comandos


especificados pelo intruso na aplicação vulnerável. Em situação como esta, a
aplicação, que executa comandos do sistema não desejadas, é como um shell do
sistema pseudo, e o atacante pode usá-lo como qualquer usuário do sistema
autorizado. No entanto, os comandos são executados com os mesmos privilégios e do
ambiente que o aplicativo tenha. Ataques de injeção de comando é possível na
maioria dos casos devido à falta de validação de dados de entrada correta, o que
pode ser manipulado pelo atacante (formulários, cookies, cabeçalhos HTTP, etc.)
Existe uma variante do ataque Código de injeção. A diferença com a injeção de
código é que o atacante acrescenta o seu próprio código para o código existente.
Deste modo, o intruso se estende a funcionalidade padrão de aplicação, sem a
necessidade de executar os comandos do sistema. Código injetado é executado com os
mesmos privilégios e do ambiente que o aplicativo tenha.
Um ataque de injeção de comando operacional ocorre quando um invasor tenta executar
comandos de sistema através de uma aplicação vulnerável. As candidaturas são
considerados vulneráveis ao ataque de injeção de comando OS se utilizar a entrada
do usuário em um comando de nível de sistema.

Exemplos

Exemplo 1
O código a seguir é um invólucro em torno do comando cat UNIX que imprime o
conteúdo de um arquivo para a saída padrão. Também é injectável:

#include <stdio.h>
#include <unistd.h>

int main(int argc, char **argv) {


char cat[] = "cat ";
char *command;
size_t commandLength;

commandLength = strlen(cat) + strlen(argv[1]) + 1;


command = (char *) malloc(commandLength);
strncpy(command, cat, commandLength);
strncat(command, argv[1], (commandLength - strlen(cat)) );

system(command);
return (0);
}

Usado normalmente, a saída é simplesmente o conteúdo do arquivo solicitado:

$ ./catWrapper Story.txt
When last we left our heroes...

No entanto, se somarmos um ponto e vírgula e outro comando para o final desta


linha, o comando é executado pelo catWrapper com nenhuma queixa:

$ ./catWrapper "Story.txt; ls"


When last we left our heroes...
Story.txt doubFree.c nullpointer.c
unstosig.c www* a.out*
format.c strlen.c useFree*
catWrapper* misnull.c strlength.c useFree.c
commandinjection.c nodefault.c trunc.c
writeWhatWhere.c

Se catWrapper tinha sido programado para ter um nível de privilégio maior do que o
usuário padrão, comandos arbitrários podem ser executados com o maior privilégio.

Exemplo 2
O seguinte programa simples aceita um nome de arquivo como um argumento de linha de
comando, e exibe o conteúdo do arquivo de volta para o usuário. O programa é
instalado setuid root, porque se destina a uso como uma ferramenta de aprendizagem
para permitir que os administradores de sistema in-formação para inspecionar os
arquivos do sistema privilegiadas sem dar-lhes a capacidade de modificá-los ou
danificar o sistema.

int main(char* argc, char** argv) {


char cmd[CMD_MAX] = "/usr/bin/cat ";
strcat(cmd, argv[1]);
system(cmd);
}

Porque o programa é executado com privilégios de root, a chamada system () também


executa com privilégios de root. Se um usuário especifica um nome de arquivo
padrão, a chamada funciona como o esperado. No entanto, se um atacante passa por
uma cadeia de caracteres do formulário "; rm-rf /", então a chamada de system ()
não consegue executar o gato, devido à falta de argumentos e arados para apagar
recursivamente o conteúdo da partição raiz.

Exemplo 3
O seguinte código de um programa privilegiado usa a variável de ambiente $ APPHOME
para determinar o diretório de instalação do aplicativo, e, em seguida, executa um
script de inicialização nesse diretório.

...
char* home=getenv("APPHOME");
char* cmd=(char*)malloc(strlen(home)+strlen(INITCMD));
if (cmd) {
strcpy(cmd,home);
strcat(cmd,INITCMD);
execl(cmd, NULL);
}
...

Como no Exemplo 2, o código deste exemplo permite que um invasor execute comandos
arbitrários com os privilégios elevados da aplicação. Neste exemplo, o atacante
pode modificar a variável de ambiente $ APPHOME para especificar um caminho
diferente, contendo uma versão maliciosa de INITCMD. Porque o programa não valida o
valor lido a partir do ambiente, controlando a variável de ambiente, o atacante
pode enganar o aplicativo em execução de código malicioso.
O atacante é variável usando o ambiente para controlar o comando que o programa
chama, de modo que o efeito do meio ambiente está expressa neste exemplo. Vamos
agora voltar nossa atenção para o que pode acontecer quando o atacante muda a forma
como o comando é interpretado.

Exemplo 4
O código abaixo é de um utilitário baseado na web CGI que permite que os usuários
alterem suas senhas. O processo de atualização de senha sob NIS inclui executar o
make no diretório / var / yp diretório. Note-se que desde que o programa atualiza
os registros de senhas, que foi instalado com setuid root.
O programa invoca fazer como se segue:

system("cd /var/yp && make &> /dev/null");

Ao contrário dos exemplos anteriores, o comando neste exemplo é codificado, de modo


que um atacante não pode controlar o argumento passado para system (). No entanto,
desde que o programa não especifica um caminho absoluto para fazer, e não esfregar
as variáveis de ambiente antes de chamar o comando, o atacante pode modificar sua
variável $ PATH para apontar para um binário malicioso chamado fazer e executar o
script CGI a partir de um janela de comandos. E desde que o programa foi instalado
com setuid root, a versão do atacante de fazer agora é executado com privilégios de
root.
O meio ambiente desempenha um papel importante na execução de comandos do sistema
dentro dos programas. Funções como system () e exec () usar o ambiente do programa
que os chama, e, portanto, os atacantes têm uma oportunidade potencial para
influenciar o comportamento dessas chamadas.
Existem muitos sites que lhe dirá que Runtime.exec do Java é exatamente o mesmo que
a função do sistema de C. Isto não é verdade. Ambos permitem que você invocar um
novo programa / processo. No entanto, a função do sistema de C passa seus
argumentos para o shell (/ bin / sh) para ser analisado, enquanto Runtime.exec
tenta dividir a string em um array de palavras, em seguida, executa a primeira
palavra na matriz com o resto das palavras como parâmetros. Runtime.exec não tenta
invocar o shell em qualquer ponto. A principal diferença é que grande parte da
funcionalidade fornecida pelo shell que poderia ser usado para o mal (o
encadeamento de comandos usando o "&", "&&", "|", "| |", etc, redirecionamento de
entrada e saída) seria simplesmente acabar como um parâmetro que está sendo passado
para o primeiro comando, e, provavelmente, causando um erro de sintaxe, ou ser
jogado fora como um parâmetro inválido.

Exemplo 5

Os seguintes trechos de código triviais são vulneráveisa OS comando injeção na


plataforma Unix / Linux:
C:

#include <stdlib.h>
#include <stdio.h>
#include <string.h>

int main(int argc, char **argv)


{
char command[256];

if(argc != 2) {
printf("Error: Please enter a program to time!\n");
return -1;
}

memset(&command, 0, sizeof(command));

strcat(command, "time ./");


strcat(command, argv[1]);

system(command);
return 0;
}
* Se este fosse um binário suid, considere o caso quando um atacante entra o
seguinte: 'ls; cat / etc / shadow'. No ambiente Unix, comandos shell são separados
por um ponto e vírgula. Agora podemos executar comandos do sistema à vontade!
* Java:

Existem muitos sites que lhe dirá que Runtime.exec do Java é exatamente o mesmo que
a função do sistema de C. Isto não é verdade. Ambos permitem que você invocar um
novo programa / processo. No entanto, a função do sistema de C passa seus
argumentos para o shell (/ bin / sh) para ser analisado, enquanto Runtime.exec
tenta dividir a string em um array de palavras, em seguida, executa a primeira
palavra na matriz com o resto das palavras como parâmetros. Runtime.exec não tenta
invocar o shell em qualquer ponto. A principal diferença é que grande parte da
funcionalidade fornecida pelo shell que poderia ser usado para o mal (o
encadeamento de comandos usando o "&", "&&", "|", "| |", etc, redirecionamento de
entrada e saída) seria simplesmente acabar como um parâmetro que está sendo passado
para o primeiro comando, e, provavelmente, causando um erro de sintaxe, ou ser
jogado fora como um parâmetro inválido.

Você também pode gostar