Coleção de padrões grep do logfile relacionados ao choque shell

Question

Existem muitos tópicos sobre a vulnerabilidade do shellshock bash, mas não há nenhuma coleção de padrões que possamos "grep" nos arquivos webservers access.log e nos logs normais.

Já existem 6 CVE's abertos relacionados ao shell shock, cada um com sua própria uniqity.

Existe uma página do Wiki para o CVE relacionada ao shell shock: link

Pergunta: Alguém pode resumir para que "grep" nos arquivos de log, para verificar se o servidor web foi alvo / explorado com a vulnerabilidade bash?

EXEMPLOS:

No log de acesso do servidor http (o diretório pode estar em outro lugar, listado alguns. Também o nome do arquivo de log de acesso pode ser diferente, ex .: "* access.log"):

cd /var/log/apache2/
cd /var/log/httpd/
cd /var/www/logs/
cd /var/log/nginx/

zgrep 'bash' access*
zgrep "};" access*
zgrep "}\s*;" access*
zgrep "() {" access*
zgrep "wget" access*
zgrep "uname -a" access*

• verifica:

  • comandos bash (em cgi's, etc.) - exemplos de ataques aqui
  • o padrão geral de CVE-2014-6271
  • também não é muito normal ter "wget" ou "uname -a" aqui

Dos ataques de exemplo, os IP's:

zgrep "187.0.222.86" access*
zgrep "209.126.230.72" access*
zgrep "217.14.242.115" access*
zgrep "218.216.190.234" access*
zgrep "54.251.83.67" access*
zgrep "67.227.0.77" access*
zgrep "74.201.85.77" access*
zgrep "78.60.1.101" access*
zgrep "89.207.135.125" access*

Nos registros normais (o diretório pode estar em outro lugar):

cd /var/log/

zgrep 'bash' messages*
zgrep 'bash' syslog*

• verifica:

  • bash segfaults / crashes - pode ocorrer ao usar o shell shock

Se você não quer grep para todos .. o grep para "bash" - esta é a coisa mais geral a fazer ..

Links RELACIONADOS:

Vulnerabilidade de injeção de código Bash por meio de variáveis de ambiente especialmente criadas (CVE-2014-6271, CVE-2014-7169)

Mitigando a vulnerabilidade do shellshock (CVE-2014-6271 e CVE-2014-7169)

No futuro, atualizarei os padrões do grep para

UPDATE : você deve somente grep a partir do dia 24 de setembro, pois a vulnerabilidade só veio a público a partir de então. Então coloque um egrep após o zgrep (esta sintaxe é para o access.logs), ex .:

egrep -i "24/Sep/2014|25/Sep/2014|26/Sep/2014|27/Sep/2014|28/Sep/2014|29/Sep/2014|30/Sep/2014|Oct/2014"

    

Answer 1

A detecção de

pode ser mitigada por invasores através de cabeçalhos personalizados que não estão registrados (já visto isso), o que significa que você não pode detectar esse material em arquivos de log

isto é o que eu verifiquei:

$ grep -e "() {" /var/log/nginx/*access.log

além disso, você verá alguma saída dos comandos em seu log de erros, se não for suprimida, como aqui :

[Thu Sep 25 21:16:55 2014] [error] [client ::1] --2014-09-25 21:16:55--  http://fump.8ack.org/
[Thu Sep 25 21:16:55 2014] [error] [client ::1] Resolving fump.8ack.org (fump.8ack.org)... 
[Thu Sep 25 21:16:55 2014] [error] [client ::1] 46.4.8.254
[Thu Sep 25 21:16:55 2014] [error] [client ::1] 
[Thu Sep 25 21:16:55 2014] [error] [client ::1] Reusing existing connection to fump.8ack.de:80.
[Thu Sep 25 21:16:55 2014] [error] [client ::1] HTTP request sent, awaiting response... 
[Thu Sep 25 21:16:55 2014] [error] [client ::1] 200 OK
[Thu Sep 25 21:16:55 2014] [error] [client ::1] Length: 1631 (1.6K) [text/html]
[Thu Sep 25 21:16:55 2014] [error] [client ::1] Saving to: 'STDOUT'
[Thu Sep 25 21:16:55 2014] [error] [client ::1] 
[Thu Sep 25 21:16:55 2014] [error] [client ::1]      0K .                                                     100% 8.27M=0s
[Thu Sep 25 21:16:55 2014] [error] [client ::1] 
[Thu Sep 25 21:16:55 2014] [error] [client ::1] 2014-09-25 21:16:55 (8.27 MB/s) - written to stdout [1631/1631]