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:
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"
Best Answer
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: