2

There are many topics on the shellshock bash vulnerability, but there isn't any collection of patterns that we could "grep" for in either the webservers access.log files and in the normal logs.

There are already 6 CVE's opened related to shell shock, each with it's own uniqity.

There is a Wiki page for the CVE's related to shell shock: https://en.wikipedia.org/wiki/Shellshock_(software_bug)

Question: Can someone please summarize what to "grep" for in the logfiles, to check if the webserver has been targeted/exploited with the bash vulnerability?

EXAMPLES:

In the access log of the http server (the directory could be elsewhere, listed a few. Also access log filename could differ, 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*
  • it checks for:

    • bash commands (in cgi's, etc.) - example attacks here
    • the general pattern of CVE-2014-6271
    • it's also not very normal to have "wget" or "uname -a" in here

From the example attacks, the 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*

In the normal logs (the directory could be elsewhere):

cd /var/log/

zgrep 'bash' messages*
zgrep 'bash' syslog*
  • it checks for:

    • bash segfaults/crashes - it could occur when using shell shock

If you don't want to grep for all.. the grep for "bash" - this is the most general thing to do..

RELATED links:

Bash Code Injection Vulnerability via Specially Crafted Environment Variables (CVE-2014-6271, CVE-2014-7169)

Mitigating the shellshock vulnerability (CVE-2014-6271 and CVE-2014-7169)

In the future I will update the grep patterns for attacker IP Addresses

UPDATE: You should only grep from the starting of September 24, since the vulnerability only came to public from then. So put an egrep after the zgrep (this syntax is for the 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"
2
  • This might be better suited for ServerFault to make sure you get good coverage on the possibilities. – schroeder Oct 2 '14 at 15:07
  • hmm.. maybe you have a point there, but I cannot migrate it to serverfault.. (maybe a person with more points has permission for it) I hoped I would get more replies if I post a security question to a security forum.. – thequestionthequestion Oct 3 '14 at 6:49
3

detection might be mitigated by attackers through custom headers that are not logged (already seen this), meaning you cannot detect that stuff in logfiles

this is what i check for:

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

furthermore, you'll see some output from the commands in your error-log, if not suppressed, like here:

[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]
1
  • Thanks, updated it. If there will be no other answers, I will accept this as answ. – thequestionthequestion Oct 2 '14 at 15:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.