Tuesday, July 24, 2012

New OSX/Crisis malware found for OS X 10.6 and 10.7

While the mode of infection is currently unknown, this new threat has uniquenesses over past malware for OS X.

A new script-based malware threat for OS X has been uncovered by security company Intego. The malware, called OSX/Crisis, has so far not been found "in the wild," but it has the potential to do harm.

Apparently the threat only runs on OS X 10.6 and 10.7 machines, and while it does not require a password to install, if a password is provided then the mode of infection changes. Most of the installed files are randomly named, though in all cases the malware appears to install a file called "appleHID" in the /Library/ScriptingAdditions/ directory. If a password is supplied and the installer gets root permissions, then the malware will additionally locate the system's Foundation framework and install a malware package called "com.apple.mdworker_server.xpc" within it.

The parent directories where these files are installed are the following:

Macintosh HD/Library/ScriptingAdditions/
Macintosh HD/System/Library/Frameworks/Foundation.framework/XPCServices/

Intego provides no information about what the malware looks like when it is first encountered -- whether it is a fake installer posing as a legitimate program, or a drive-by-download similar to later variants of the Flashback malware. However, once installed, the malware will continuously run even when the system is rebooted, and contact a remote server every 5 minutes, which presumably could be used to send instructions to the infected machine.

Unlike prior OS X malware, this new threat is created in ways to make reverse engineering and identification more difficult, and uses low-level system calls to help disguise its activity.

Overall while this is a new threat for OS X with some unique features, unlike others it has not been found on any OS X machines. Its distribution is therefore very low if nonexistant at the moment, and malware definitions for it should soon be available to malware scanning tools so be sure to keep them updated if you have one installed.

Source: http://bit.ly/PFdo81

Wednesday, July 18, 2012

Experts take down Grum spam botnet, world's third largest

Botnet was responsible for 18 billion spam messages a day -- about 18 percent of the world's spam -- experts tell The New York Times.

Computer-security experts took down the world's third-largest botnet, which they say was responsible for 18 percent of the world's spam.

Command-and-control servers in Panama and the Netherlands pumping out up to 18 billion spam messages a day for the Grum botnet were taken down Tuesday, but the botnet's architects set up new servers in Russia later in the day, according to a New York Times report. California-based security firm FireEye and U.K.-based spam-tracking service SpamHaus traced the spam back to servers in Russia and worked with local ISPs to shut down the servers, which ran networks of infected machines called botnets.

The tech community has stepped up its efforts of late to take these botnets offline. Microsoft in particular has been quite active, using court orders to seize command-and-control servers and cripple the operations of the Waledac, Rustock, and Kelihos botnets.

The takedown of the Rustock botnet cut the volume of spam across the world by one-third, Symantec reported in March 2011. At its peak, the notorious botnet was responsible for sending out 44 billion spam messages per day, or more than 47 percent of the world's total output, making it the leading purveyor of spam.

Security experts are confident they have stopped the Grum botnet in its tracks.

"It's not about creating a new server. They'd have to start an entirely new campaign and infect hundreds of thousands of new machines to get something like Grum started again," Atif Mushtaq, a computer security specialist at FireEye, told the Times. "They'd have to build from scratch. Because of how the malware was written for Grum, when the master server is dead, the infected machines can no longer send spam or communicate with a new server."


Sunday, July 15, 2012

Symantec Antivirus Software Update Crashes some PCs

Bug in software used by businesses caused some Windows XP-based machines to crash repeatedly with a "blue screen of death."

A recent update to Symantec's antivirus software rendered some Windows-based PCs inoperable, the security software maker disclosed Friday.

An update earlier this week to Symantec Endpoint Protection 12.1 antivirus software for businesses caused some Windows XP-based computers to crash repeatedly with a "blue screen of death," the company revealed on its Web site.
"On July 11th, 2012 Symantec Security Response started receiving reports of customers experiencing blue screens after applying the July 11th revision 18 definitions," Orla Cox, of Symantec Security Response, wrote in the post. "Machines may continue to blue screen after they reboot. This problem only appears to occur on Windows XP machines."
In an update, the company said the crashes were limited to XP machines running Endpoint Protection 12.1 and certain software from Norton. Once the cause was identified, Symantec issued a rollback of signatures on Thursday, the company said.
The company said it learned of the issue Wednesday night from customers, who said they were forced to manually remove the software from disabled machines, a process they described as time consuming.
One frustrated Symantec customer called the called the bug "a farce" in the accompanying community discussion board.
"This whole episode is a joke, had the issue been a conflict with a random device driver then I could maybe slightly more sympathetic," the customer said. "But for it to conflict with its own Symantec related drivers and cause this issue is a total farce. Who tested it before release? Was it even tested?"
Others on the board said Symantec was working on a compensation package after they demanded to know how they were going to be compensated for their "for the hours of lost worker production and the time and effort taken by IT staffs to rectify this huge error by Symantec."

How to install Apache on Linux

An easy step-by-step guide to setting up an Apache Web server on Fedora, CentOS, or Ubuntu
SAN FRANCISCO-- The installation, care, and feeding of an Apache Web server is not terribly difficult, but can seem so if you haven't ventured into those particular waters before. This quick-start guide will help you get your feet wet with Apache on a Linux server. You'll find it's relatively simple to get the Web server set up and running on your Linux of choice. We'll also install PHP and MySQL, though we won't be digging into MySQL configurations, as that deserves a quick start all its own.
The method of installing the Apache packages on a Linux server varies from distribution to distribution. We'll cover how to do this on Fedora and CentOS, as well as on Ubuntu. This is a server-centric walkthrough, so we'll use the command line exclusively. Naturally, you'll need root-level privileges. Open the terminal window and type:
su -
Then enter the root password. Now we can get started.
First we'll install the packages themselves. For Fedora and CentOS, this is a simple step involving Yum, the package installer and updater. To install the basic Apache and PHP packages, run the following command:
yum install httpd php mysql mysql-server
Follow the prompts, as this tool will locate and install a base set of Apache and PHP packages.
For Ubuntu 10.04 servers and newer, you can install the whole LAMP (Apache, MySQL, and PHP) stack with two commands:
sudo apt-get install tasksel
sudo tasksel install lamp-server
While this guide does not cover MySQL, the above commands are a quick way to get all the necessary packages required for LAMP applications. Once the installation is complete, we can begin configuring the server.
For all file editing, on Fedora, CentOS, or Ubuntu, you may want to use nano:
nano /etc/httpd/conf/httpd.conf
This command will open the Apache configuration file in a basic editor. You can save the file with Ctrl-O and exit the editor with Ctrl-X.
Apache on Linux: Initial configuration
While the Apache and PHP packages are essentially the same across the different distributions, there are differences in how they are actually installed on the file system. We'll start with Fedora and CentOS.
Fedora and CentOS. After installation, you'll find a new directory: /etc/httpd. Within this directory are all the Apache configuration files. The important subdirectories for our purposes are /etc/httpd/conf and /etc/httpd/conf.d. Within /etc/httpd you'll find the main Apache configuration file, httpd.conf. In /etc/httpd/conf.d you will find includes, or supplemental files that are included in the main configuration file.
Includes are a way to break out complex configurations into separate files for easy organization and management. For instance, if you have an Apache server that has 20 virtual hosts, then each virtual host should have a separate file in /etc/httpd/conf.d/ that contains its specific configuration parameters. In this way, you can easily add or remove virtual hosts without editing the main Apache configuration file.
In order for files to be included in the Apache configuration, they must have a filename that ends with .conf. If we have a virtual host named www.test.com, all the configuration elements for that virtual host would reside in a file named test.conf or test.com.conf.
You can see how these files are included in the main configuration file by looking at /etc/httpd/conf/httpd.conf. Press Ctrl-W to search for "Include conf.d" and you'll find this line:
Include conf.d/*.conf
That tells Apache to include all files matching *.conf in the /etc/httpd/conf.d folder into the main configuration.
There are many configuration elements present in the Apache configuration file, but beginners need to be concerned with only a few. These are the elements that control where our Web root is, how to handle virtual hosting, and a few other minor tweaks. To start with, the default settings present in this file will be fine.
By default, the Web root on Fedora and CentOS is /var/www/html. This means that any files placed under /var/www/html will be served via Apache when a Web browser connects to the server. If a file exists as /var/www/html/test.html, and you open a Web browser and connect to http://<server IP address>/test.html, the server will deliver that file to the browser. If the server will host only a single website, then you can put all of your content under this directory and configure DNS to map a name, such as www.test.com, to the server's IP address, and then http://www.test.com/ will work.
Controlling the Apache server is very simple. To start the server on Fedora or CentOS, run:
service httpd start
Stopping the server is equally simple:
service httpd stop
To restart the server, you can also use:
service httpd restart
For simply reloading the configuration file without restarting the service, use the following command:
service httpd reload
Another very handy control:
service httpd configtest
This tests the Apache configuration file and all included files for errors without starting or restarting the server. This allows you to make sure your configurations are valid before actually causing Apache to run with that configuration, which makes it easier to add and test configurations without disturbing the running server.
To make sure that Apache starts when the server boots, simply run:
chkconfig httpd on
This will add Apache to the list of services to start at boot time.
Ubuntu. Ubuntu follows the same basic procedure as Fedora and CentOS, but places the files in different directories. The global Apache configurations are found at /etc/apache2/apache2.conf. As in Fedora and CentOS, includes break out different Apache configuration elements to separate files, but go further in Ubuntu, breaking out many more sections of the global configuration to other files (such as ports.conf, which controls the ports Apache listens on). For beginners, these files will not need to be modified.
Unlike Fedora and CentOS, Ubuntu has a specific directory for virtual host configurations, /etc/apache2/sites-available, and a companion directory, /etc/apache2/sites-enabled. Configuration elements specific to individual virtual hosts are placed in sites-available, then symlinked from sites-enabled, making it easy to add and remove active virtual hosts from the configuration without deleting or renaming the files. Just add or remove a symlink to bring them to the configuration.
Ubuntu also has a different default Web root, /var/www, so if a file named test.html exists in /var/www, Apache will deliver that file to a Web browser that requests the URL http://<server IP address>/test.html. If the server will host only a single website, then you can put all content under this directory and configure DNS to map a name, such as www.test.com, to the server's IP address, and thenhttp://www.test.com/ will work.
Controlling Apache in Ubuntu is as simple as in Fedora and CentOS, but generally relies on a different command-line method. Although some versions of Ubuntu support the service command, you can always count on the following commands.
To start Apache, run:
sudo /etc/init.d/apache2 start
To stop Apache, run:
sudo /etc/init.d/apache2 stop
To restart the server, run:
sudo /etc/init.d/apache2 restart
As in Fedora and CentOS, you can reload the configuration files without restarting the service, by running:
sudo /etc/init.d/apache2 reload
And you can test the configuration file syntax with:
sudo apachectl configtest
There are several different ways to configure Apache to start at boot with Ubuntu, but a general method is to use update-rc.d:
sudo update-rc.d apache2 defaults
This will cause Apache to start when the server boots. You might also look into using Upstart, which is a newer method of starting system services at boot.
Apache on Linux: General configuration
Regardless of the Linux distribution, Apache's configuration follows standard concepts. A primary element is the use of opening and closing tags, which are patterned after HTML tags. For instance, if you have a <Directory> statement, everything after that statement is within the <Directory> context, which is terminated with a </Directory> tag. If you forget to add a closing tag, the configuration syntax will not be valid and the server will refuse to run.
It's a good idea to read through the default httpd.conf (Fedora and CentOS) or apache2.conf (Ubuntu) file and included files. While you may not understand everything, these files are well commented, providing context and sometimes even examples on proper usage. They will also give you an idea of how the overall configuration file is constructed and clue you in to different aspects of the configuration that might come in handy later on when you're attempting more advanced configuration tasks.
For our purposes here, we can leave the default configuration as-is and work on extending that configuration to suit our needs. The default settings for server operation are generally well suited for small and experimental servers, but production servers that are expected to handle heavy loads may require extensive modifications to the default settings. But let's start simple.
As mentioned above, you can place your content in Apache's document root directory and it will be served to clients, but in general it's better to configure virtual hosts. It makes no difference to the server if there's only one virtual host, and multiple virtual hosts can be easily added later using the same formula.
Configuring a virtual host is distribution-agnostic. Simply create a file in the default virtual host include directory for your distribution as described above.
We'll create the file test.conf. Within this file we will add all the configuration elements necessary to have the server deliver content for www.test.com.
Note: For Fedora and CentOS, you may have to edit the /etc/httpd/conf/httpd.conf file and remove the # character before NameVirtualHost *:80 near the bottom of the file. This will allow name-based virtual hosts to function. To do this, open the file in nano:
nano /etc/httpd/conf/httpd.conf
Then press Ctrl-W and locate NameVirtualHost by typing in that search string. Remove the # (comment character) from the beginning of the line and save the file.
Now we're ready to create our virtual host. Using Fedora, we'd open a new file in /etc/httpd/conf.d/:
nano /etc/httpd/conf.d/test.conf
For Ubuntu, we would run:
sudo nano /etc/apache2/sites-available/test
We now have an empty file that we need to fill up with the configuration for our virtual host. Here's an example file for Fedora or CentOS:
<VirtualHost *:80>
    ServerAdmin webmaster@www.test.com
    DocumentRoot /var/www/test
    ServerName www.test.com
    ServerAlias test.com
    ErrorLog logs/www.test.com-error_log
    CustomLog logs/www.test.com-access_log combined

We need a slightly different file for Ubuntu due to different conventions for log file placement:
<VirtualHost *:80>
    ServerAdmin webmaster@www.test.com
    DocumentRoot /var/www/test
    ServerName www.test.com
    ServerAlias test.com
    ErrorLog ${APACHE_LOG_DIR}/www.test.com-error_log
    CustomLog ${APACHE_LOG_DIR}/www.test.com-access_log combined
This configuration snippet tells Apache that we have a virtual host that will be listening on TCP port 80 (the standard HTTP port). It also tells Apache that the document root for this virtual host is /var/www/test, indicates that the server name is www.test.com, and specifies where the logs should be placed. It then ends the configuration snippet with the </VirtualHost> directive.
In order for this virtual host to work, the directory /var/www/test must exist and have some contents, such as an index.html file, and DNS needs to be configured to point the DNS name www.test.com to the server's IP address. Note the ServerAlias directive in the configuration file. This allows Apache to accept either www.test.com or test.com as a valid name when a browser requests the site. This is important, as many people omit the initial www when manually typing in website URLs. You can also use ServerAlias to allow the server to deliver content for a completely different name, such as www.foo.com, from the same document root.
Once you have modified the virtual host configuration file to your needs, such as changing the server name and the DocumentRoot directory, then press Ctrl-O to save the file and exit the editor.
At this point, you can go on to create other virtual hosts in the same manner. You can create the document root with the mkdir command on Fedora or CentOS:
mkdir /var/www/test
An alternative on Ubuntu:
sudo mkdir /var/www/test
Then place an HTML file in that directory called index.html:
nano /var/www/test/index.html
Next, type this into the file:
This is a test.
To test the configuration on Fedora or CentOS, use:
service httpd configtest
If it responds with "Syntax OK," you're all set.
For Ubuntu, we first need to enable the site, then test the configuration like so:
sudo a2ensite test
This uses the Ubuntu tool a2ensite to enable the site you configured earlier. We also need to disable the default site if we're working without DNS, or if we want our test virtual host to be the only content served:
sudo a2dissite default
If we don't do this, then accessing the server by IP address with a browser will show the default site that was installed with Apache, rather than our test site. If you want to enable the default site at a later time, just run:
sudo a2ensite default
After this, you can run the following to test the configuration in Ubuntu:
sudo apachectl configtest
If all is well, you can now start or restart Apache to load the new configuration. In Fedora and CentOS:
service httpd restart
In Ubuntu:
sudo /etc/init.d/apache2 restart
Once you've restarted the server, you can test the site by opening it with a browser, assuming that you've configured DNS to translate your site's name to the server's IP address. You should see "This is a test" in the browser, as the server delivers the index.html file you created.
Apache on Linux: Beyond the basics
What we've laid out above is an extremely simple example of an Apache configuration. While most installations will require only minimal modifications to the default configurations, there are a few details to know beyond the basics.
You may recall that we also installed PHP in the initial steps. Because of this, PHP has already been configured for use with Apache. You can test this by creating a file in the document root called test.php and typing in the following PHP code:
Save the file, then open your browser and access http://<server ip address>/test.php. You should get a listing of all the PHP environment variables, modules, and versions. This means that PHP is installed and functional.
An important Apache configuration element to know is the <Directory> statement. This allows you to configure specific permissions on directories shared by Apache. For instance, within our VirtualHost directive example, we might add the following:
<Directory /var/www/test>
    AllowOverride All
    Order deny,allow
    Deny from all
    Allow from 192.168.
This directory statement accomplishes a few goals. First and foremost, AllowOverride All permits the use of .htaccess files within the directory /var/www/test to modify the server's behavior. Through .htaccess files, you can control access to the directory or implement any number of other configuration tweaks without modifying the virtual host configuration file itself. This can be very handy, they allow you to make configuration changes for the virtual host without reloading the server. The downside is that configuration errors within an .htaccess file can cause immediate problems.
(Note that the AllowOverride is subject to several different qualifiers that can grant specific override directives to the .htaccess file. The use of All here allows all of them. You can find a list with descriptions at the Apache Software Foundation.)
Secondly, we have Order deny, allow, and a few Deny and Allow statements. As configured above, the Web server would deny access to any client with an IP address outside the range, or through It's a handy way to deny access to specific IP ranges or to ensure that only internal clients can access that particular resource.
Once you're comfortable with the basics, you can move on to other advanced configuration elements. For instance, it's relatively simple to password-protect a site or directory using .htaccess files. To do this, you need to create a file named .htaccess in the document root of the virtual host (or Apache server) and add these lines:
AuthUserFile /etc/httpd/webpasswds
AuthName "My Web Auth"
AuthType basic
<Limit GET POST>
Then create the password file. On Fedora or CentOS:
htpasswd -c /etc/httpd/webpasswds myuser
On Ubuntu:
sudo htpasswd -c /etc/apache2/webpasswds myuser
Make sure you have set AllowOverride All, or at least AllowOverride Limit, in your configuration file as noted above. After you've done this and reloaded the server, users will be presented with a login dialog box before they can access the website. You can add more usernames and passwords using the same htpasswd command, though you don't need to use the -c flag if you're just adding more users.
To infinity and beyond
With any luck, you've just succeeded in getting Apache up and running on a modern Linux server. There's much more to know about the Apache Web server, and the best way to learn is to experiment with different configurations. You'll want to bookmark Apache's documentation for the version you're running.
It's unwise to put sensitive information on any Web server until you're comfortable that the configuration is proper. It's too easy to make configuration errors that expose information inadvertently. If you're just starting out with Apache and Linux, take the time to research and educate yourself first, and perhaps find someone more knowledgeable to verify your configurations before placing your server into production.