Improve company productivity with a Business Account.Sign Up

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1787
  • Last Modified:

Mac OS X server Hacked by spykids

We are a small firm in Mexico with our own webserver, we got hacked last week by spykids and they replaced the index files, we restored them and now got hacked again this week. We currently use Awstats 6.4 as a CGI. PLEASE HELP US STOP THESE GUYS!
  • 5
  • 4
  • 2
  • +3
3 Solutions
I thought Apple products where spy/virus/hack proof...  Must be your imagination.

Seriously, however, you need to find out HOW they are getting in and plug that leak.

1) Examine the changed file time/date stamps and see when this happened.
2) Examine the system logs in the time period above and see what they did and hopefully how they did it.
3) Shutdown or protect whatever weakness they are using to get in.
AlvaroRattingerAuthor Commented:
Thank you very much for answering, we bought the mas os x g5 server because it was supposed to be more secure, I suppose i was wrong!

Let me answer your questions.

1. I revised all the files and removed the ones i found suspicious among them the spy.txt file, a .pl script and a traio.html file. I restored all the index.* files also
2. "GET / HTTP/1.1" 200 165 "" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)" it does not seem to have entered through awstats but I also updated the file to the 6.5 version, I did not modify the config files.
3. I still have no idea how they got in, I suspect they used the PHPnewads but cannnot put my finger on it.

Thank you again for any help on this issue.


What web server are you running, Apache? version? modules?  AWstats is a log analyzer.  Are you sure you did not install/enable software/services other then the webserver?  Through which you were hacked?

Do you have a firewall in front of the server which might help you narrow down the attack vector?
The Lifecycle Approach to Managing Security Policy

Managing application connectivity and security policies can be achieved more effectively when following a framework that automates repeatable processes and ensures that the right activities are performed in the right order.


First off, I would reinstall the o/s if possible, or, at a minimum, return to last-known good backup.

Then, harden:see Securing Mac OS X -

Next, run an IDS: Intrusion Detection with Snort/ACID on Mac OS X ( is good.

Or, for ease-of-use, see HenWen ( "A network security package for Mac OS X that makes it easy to configure and run Snort, a free Network Intrusion Detection System (NIDS). HenWen’s goal is to simplify setting up and maintaining software that will scan network traffic for undesirable traffic that a firewall may not block. Everything you need to have is bundled in — no compiling or command line use necessary."

Turn off FTP access.

FTP is only required if you need that means of modifying files on the web server, but, if you have physical access to the server, or use a means of remote administration, you do not need FTP.  Without FTP, people will find it extremely difficult to hack your site.
AlvaroRattingerAuthor Commented:
Thank you tnapolitano

I installed the HenWen software and it seems that it has not detected any attacks, I set it up with almost all the defaults. I also stopped the FTP service as EECDML recommended. I hope this prevents a future attack. Is there anyway I can be sure? Or should I only cross my fingers.

We discovered th following files which permited the hacker to delete files in the server: c99shell.php these where uploaded yesterday after we deleted all the index.* files, I am supposing they found a way in but could not hack the site completely.



AlvaroRattingerAuthor Commented:
Today we received a call regarding a service from ScanAlert offering to help us with our problem, is this a good service? do you recommend it?

Okay, you turned off  FTP. So you've confirmed FTP was the vector of attack?

As for a 100% guarantee against future compromise? No such thing. All information security can provide are levels of assurance based on your controls.

So, on to the controls. As Arnold asked, do you have a firewall placed between your webserver and the Internet (better yet, set up a DMZ. This link - - is geared towards MS ISA Server, but will give you the idea).

Again, harden your system by narrowing the attack surface of available service to only what is necessary.

You said you downloaded and setup HenWen. That's good. But again, it is only an IDS. Intrusion Detection is a passive security device. It will only alert you to what you have configured it to detect. So when you say you configured it with almost all defaults I don't how much good that will do you. Read the HenWen Manual included in the package.

Lessons learned: just because a system is touted as being "more secure than Brand X" doesn't mean that security state is achieved by an out-of-the-box configuration.  Read best practices howtos next time before deploying to production.

As for the scanning service,  you can get the same results by using an offsite system and using freeware vulnerability scanners to test your site. Search for NMap, Nessus, Nikto and Metasploit. Also - and I can not stress this enough - get executive permission prior to any security testing.

Don't know about Scanalert, but they called you out of the blue?  How did they know you were having a problem???

Here's some opinions:

Google it and you will find a lot more.  Seems pricey for what they do.

AlvaroRattingerAuthor Commented:
Well the HenWen has produced some log information. I have no idea what to do about it.

[**] [111:1:1] (spp_stream4) STEALTH ACTIVITY (unknown) detection [**]
TCP TTL:53 TOS:0x0 ID:1480 IpLen:20 DgmLen:40 DF
1**A*R** Seq: 0x0  Ack: 0x2651E2CF  Win: 0x0  TcpLen: 20

Also something interesting is the following log entry:

[**] [1:2050:7] MS-SQL version overflow attempt [**]
[Classification: Misc activity] [Priority: 3]
06/15-17:35:05.185701 ->
UDP TTL:107 TOS:0x0 ID:36042 IpLen:20 DgmLen:404
Len: 376
[Xref =>][Xref =>][Xref =>]

The server continues to run normally and havent found any more hacking or changed files, can I assume I reagained control over the server and that these alerts where unsuccessfull attacks?

Again thank you very much for all your help!

Have you done any updates on the OS?  The apple site shows a handful of security updates:

There are vulnerabilities out there for AWStats, PHP and CGI.  That file - c99shell.php - is related to a backdoor trojan:

AWStats 6.4:

When AWStats version is 6.4 or 6.5 is used as a CGI:
If the update of the stats via web front-end is allowed, a remote attacker can execute arbitrary code on the server using a specially crafted request involving the migrate parameter. Input starting with a pipe character ("|") leads to an insecure call to Perl's open function and the rest of the input being executed in a shell. The code is run in the context of the process running the AWStats CGI.

AlvaroRattingerAuthor Commented:
Should I disable the update feature in awstats? How do I run awstats other than CGI?
I haven't used AWStats, so am not familiar with the update process.  I don't think you can run it other than as CGI.  But it looks like there is a new version available that closes these vulnerabilities (but maybe creates another).

If there is an update function in the software to install the newer version - that would be the route to take.  I don't know if installing the new version over the old will change or harm any configuration settings you may have there.  Again, I've never used it, so you might read their documentation a bit before doing anything.  

BACKUP any configuration files, or even the whole folder to be on the safe side.

Installing AWStats:

However, this may not be what was exploited.  It's just one vulnerability out there.

From AWStats website:
Version 6.6 or higher (safe from any known exploits)

There is no exploit nor hole known by AWStats team on this version, so AWStats 6.6 and higher are safe.

You may however find announces aboutt parameters provided into URLs that are not sanitized. In fact, AWStats sanitizing code can be found in the line
$QueryString = CleanFromCSSA(&DecodeEncodedString($QueryString));
This line sanitizes all URLs parameters provided to AWStats (from CSS code and from | command).
Note: Some annouces say that some AWstats versions has more serious holes because of the use of the "eval" Perl function. It's true that using "eval" function can be a hole when its parameters are not sanitized, but they are in 6.5 (for the 'configdir' parameter) and are in 6.6 (for all parameters, even 'migrate' parameter forgotten in 6.5).
Oops - correction!  AWStats can be run from the command line instead of CGI, so it's not limited to CGI only.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Improve Your Query Performance Tuning

In this FREE six-day email course, you'll learn from Janis Griffin, Database Performance Evangelist. She'll teach 12 steps that you can use to optimize your queries as much as possible and see measurable results in your work. Get started today!

  • 5
  • 4
  • 2
  • +3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now