I’ve been working with the security incident response tools on the Helix CD, and been intrigued by Harvey Carlan’s Forensic Server Project

However, the Sourceforge files for the FSP server don’t run on MacOSX or other Unix-style machines because it uses the Win32::GetCwd and Win32::SetCwd modules. The simple patch, below, can be saved as, say, “fspc.patch” in the same directory as the unzipped FSP files. To patch, run:

patch -p0 < fscp.patch

Here’s the patch:

--- fspc.pl.orig    2007-10-24 15:40:22.000000000 -0400
+++ fspc.pl    2007-10-24 16:18:09.000000000 -0400
@@ -18,6 +18,7 @@
 use Digest::MD5;
 use Digest::SHA1;
 use Getopt::Long;
+use Cwd;

 #--------------------------------------------------------------------------
 # Globals
@@ -39,7 +40,7 @@
     exit 1;
 }

-$setup{basedir} = Win32::GetCwd();
+$setup{basedir} = getcwd();
 $setup{casedir} = $config{casedir} || "cases";
 $setup{casename} = $config{casename};
 $setup{port} = $config{port} || 7070;
@@ -296,14 +297,14 @@
 #------------------------------------------
 sub _setup {
 # clean up the directory names
-    $setup{basedir} = $setup{basedir}."\\" unless ($setup{basedir} =~ m/\\$/); 
-    $setup{casedir} = $setup{casedir}."\\" unless ($setup{casedir} =~ m/\\$/);
-    $setup{casename} = $setup{casename}."\\" unless ($setup{casename} =~ m/\\$/);
+    $setup{basedir} = $setup{basedir}."/" unless ($setup{basedir} =~ m/\/$/); 
+    $setup{casedir} = $setup{casedir}."/" unless ($setup{casedir} =~ m/\/$/);
+    $setup{casename} = $setup{casename}."/" unless ($setup{casename} =~ m/\/$/);
     my $casedir = $setup{basedir}.$setup{casedir};
     mkdir $casedir if (! -e $casedir && ! -d $casedir);
     my $curr_case = $casedir.$setup{casename};
-    mkdir $curr_case if (! -e $curr_case && ! -d $curr_case);
-    Win32::SetCwd($curr_case);
+     mkdir $curr_case if (! -e $curr_case && ! -d $curr_case);
+    chdir($curr_case);
     print "Setup complete.\n" if ($config{verbose});
 }

@@ -312,5 +313,5 @@
 # clears setup data so it can be renewed
 #------------------------------------------
 sub _reset {
-    Win32::SetCwd($setup{basedir});
+    chdir($setup{basedir});
 }

Two recent news items in “SANS NewsBites:http://www.sans.org/newsletters/newsbites/ had me thinking about the fun (and profit) from working to ethically “inoculate” one’s staff against phishing and social engineering attacks.

To quote:

—NY “Inoculates” Employees Against eMail-Borne Malware (22 January 2007) Will Pelgrin, New York State’s chief information security officer (CISO), worked with AT&T and the SANS Institute to develop an “inoculation” program to protect state agency computer systems from malware infections. First, approximately 10,000 state agency employees received email messages alerting them to ongoing phishing activity and encouraging them to be aware of the risks of opening email from unknown users and clicking on links in unsolicited email. The next month, the employees were told that in keeping with a tightened security posture, all employees were required to have passwords. That was followed by an email that came from outside the network containing a link that if clicked on, would prompt users for their user IDs and passwords. The email contained some clues that it was not legitimate. If the users provided the requested information, they got a pop-up telling them they had failed the test and then were shown a video and given a 10-question exam. Eighty-three percent of the recipients did not fall for the scam. When a similar test was run two months later, that number rose to 92 percent. http://www.gcn.com/print/26_2/42983-1.html?topic=security&CMP=OTC-RSS [Editor’s Note (Kreitner): This is an excellent example of good security management supported by a security metric that quantitatively measures actual progress toward a specific security goal, in this case a particular change in human behavior. (Pescatore): A good effort as long as it is continuous. If they measure a month later, the number will likely drop quite a bit. If the process continues, they will likely find that the 11% improvement drops off quite a bit.]

And

—Half of Finance Managers Put Unsolicited USB Drive in Computers (25 January 2007) As a research project, a consulting firm sent USB sticks to finance directors at 500 firms in the UK. The memory devices purported to be invitations to “the Party of a Lifetime” with an anonymous sender but were actually part of an experiment. Nearly half of the finance directors inserted the stick into company computers. Media companies fared the worst in the experiment, with 65 percent putting the memory stick into computers. At technology, retail and transportation companies, the figure was between 38 and 39 percent. The devices could be used to plant malware on computer systems. http://www.vnunet.com/computing/news/2173365/uk-firms-naive-usb-stick [Editor’s Note (Liston): While this test seems somewhat contrived, you really can’t argue with the results. Human curiosity is an incredibly strong motivator that will, more often than not, overwhelm common sense. If you found a USB key laying in the parking lot outside your workplace, what would YOU do? What would the majority of your co-workers do? (Schultz): The results of this research study further underscore the great need to reach management in security training and awareness efforts, something that is much too often completely overlooked. (Honan): This story illustrates how depending on your perimeter defences alone are no longer sufficient. Comprehensive security awareness programmes coupled with technical controls such as locked down desktops and USB port management are needed in the battle against ever increasingly sophisticated attackers. Using resources such as those provided by the Centre for Internet Security, http://www.cisecurity.org/, will help. For example, a simple registry entry on Windows machines will disable autoplay from any disk type, regardless of application HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\NoDriveTypeAutoRun.]

I can’t just bookmark an email in del.icio.us, so I’ll just have to quote this little gem from the SAGE list.

Theodore Tso writes

In another real world example, the security office set some obnoxious password policy that caused passwords to be impossible to remember, and then required changing said obnoxious passwords every 30 days. But this was at a company where the traders were making bazillions of dollars every day, and rule #1 was “thou should not piss off the traders, for they make your company rich and can go find a job with the competition”. So the company hired a set of runners who were given the traders’ passwords, and every morning before the traders came in, the runners would run around to all of the trading workstations and log in the traders so they wouldn’t have to.

Which elicited from Dan Geer, “for the record, I can corroborate the above.”

I’m posting a link to this week 12/12/2006 SANS Newsbites because there are so many tasty tidbits that bear further reading. To wit:

• NASA bans Word attachments.

• Local Colorado woman raided because her system had been taken over by a bot in a credit card scam network. Roland Grefer added a little note with some links worth keeping handy:

[(Grefer): If you are an end-user and your computer suddenly starts to run slow, do NOT turn off your firewall. Rather, run antivirus and antispyware scans. Starting points might be the offerings at -http://free.grisoft.com, -http://www.safer-networking.org, and -http://www.lavasoftusa.com/products/ad-aware_se_personal.php. They all offer their tools free of charge for personal home use and are reputable sources. ]

• After a note about a fellow convicted for stealing credit card data, Ed Skoudis had this to say about VoIP phishing and how banks may be unwittingly contributing. I think VoIP phishing needs much more publicity, and I’ve not heard it mentioned in recent media coverage of spam and phishig.

[Editor’s Note (Skoudis): Credit card theft remains a major issue. Just last Friday, I got an automated call from my bank, one of the biggest in the world, about a fraud warning. The voice mail was comically synthetic, with a tinny machine mispronouncing my name, urging me to call my bank at a phone number that didn’t match the one on my credit card. Given the rise of VoIP phishing, I was instantly suspicious. I called the number printed on my card. As it turns out, the call was legit, and there was a real fraud warning on my card. I was disappointed in my bank for opening themselves to VoIP phishing this way. If you get a fraud warning call, do not dial back to the number in the voice mail. Instead, call only the number printed on the back of your card, or, if the card isn’t available, call the number on your last statement. ]

• Colorado gets a statewide laptop encryption contract. Way to go Colorado (and maybe a bit of Mark Weatherford tooting his own horn as Colo’s CISO).

This week I happened upon a client who was eager to solve a persistent problem with Microsoft’s Internet Explorer bombing when trying to POST content over HTTPS to a custom web application. The client sent me the thread from the trouble tracking system, and it was clear that they were already aware of the magic Apache mod_ssl incantation to address some of MSIE’s non-compliant behavior. Since they were already barking up that tree, I decided that they needed a better test bed to help confirm whether the problem was truly being addressed by whatever remedies they were hauling out. To put it another way, we couldn’t really apply any scientific method unless we could have a control case and an experimental case.

Since the problem was MSIE specific, I first needed a way to drive MSIE through some test cases and evaluate the results.

Getting a flawed version of MSIE

First, I had to get a sufficiently old version of MSIE, since late versions of IE6 and IE7 are all okay. To do this all safely and reproducibly, I’m running Windows under an instance of VmWare Server on a Linux host. To get things set up, I took care of the following:

• Install Windows 2000 Professional from CD (apply no security patches)
• Install Windows 2000 SP2 http://www.microsoft.com/windows2000/downloads/servicepacks/sp2/sp2en.mspx
• Install Microsoft Internet Explorer SP1 http://www.microsoft.com/windows/ie/ie6/downloads/critical/ie6sp1/default.mspx

(if you have WinXP CD, start there, since IE 6 first came out with Win XP)

That will give you MSIE 6.00.2800.1106, which failed miserably when I ran it through it’s paces to POST content over HTTPS.

Automating MSIE with Perl Win32::IEAutomation

Next, I needed to automate testing with MSIE, and to the rescue comes Prashant Shewale’s Perl module Win32::IEAutomation. To run the module, I did the following on my Win2k System

• Download and install ActiveState’s Active Perl 5.8.X: http://www.activestate.com/Products/Download/Download.plex?id=ActivePerl (Providing contact details are optional)

• Download and install Microsoft’s nmake.exe. See their Microsoft Knowledge Base, article 132084, and follow link to nmake15.exe. Then run the downloaded file, and move nmake.exe and nmake.err to c:\perl\bin.

• Run ‘cpan -i Win32::IEAutomation’ from the command line

At this point, I also installed CygWin and some decent editors to so some sane development and testing on the system, but that’s beyond the scope of this article.

Last, I wrote a variant on the following script to drive IE:

    use Win32::IEAutomation;

    # Set up variables
    $server_base="https://www.example.com";
    $wait=$ARGV[0];
    $now=localtime(time);
    $upload="C:\Documents and Settings\Peter Burkholder\My Documents\TextDoc.txt";
    $user="username\@email.com";
    $pass="password";
    $title="PeterB Test for $wait sec at $now";

    # Create new instance of Internet Explorer
    my $ie = Win32::IEAutomation->new( visible => 1, maximize => 1);

    # Goto Login page and Login
    $ie->gotoURL('https://example.com');

    $ie->getTextBox('name:', "username")->SetValue($user);

    $ie->getTextBox('name:', "password")->SetValue($pass);

    $ie->getButton('caption:', "Login")->Click;

    # Navigate to the add content page
    $ie->gotoURL('https://example.com/home/content.php');

    $ie->getButton('caption:', "Create new")->Click;

    ## Fill in Content Page
    $ie->getTextBox('name:', "name")->SetValue($title);
    $ie->getSelectList('name:', "company_id")->SelectItem("ACA");

    # IE fails on 6.00.2800.1106 whether or not a file is uploaded
    # Replace the
    # $ie->getTextBox('name:', "filename")->SetValue($upload);
    $ie->getTextArea('name:', "note")->SetValue("Sample comment on the upload");

    # Now we sleep to see at least 30 seconds to get the Post error, then click the "Save" button
    sleep($wait);
    $ie->getButton('caption:', "Save")->Click;

    # Summarize the output and quit IE so we always start from a known state
    $output=substr($ie->PageText(),0,40);
    print $output;

    $ie->closeIE();

The code starts up IE and walks it through the first few panes of the application until the point where the error has been known to occur. It’s evoked as, say: perl ieautomate.pl 5 where the last argument is the number of seconds to wait before the ultimate submit. When run with a short wait, like 5 seconds, the content is successfully posted. With a wait of 30 or 40 seconds, the submit fails.

Running this is really cool, like some poltergeist has taken over the machine. I can’t wait to use Win32::IEAutomation to check airline ticket prices, etc.

Diagnosing the SSL problems

This breaks down into two steps, a) getting VmWare host-only networking set up to route through the host so we can then b) run sslsniff on the traffic and look inside the packets.

A) Getting VmWare routing set up

Thanks to the folks at Cyberciti.biz for getting me on the right track. Their post on the matter is largely correct except that:

• You need to run: echo 1 > /proc/sys/net/ipv4/ip_forward and add that config to /etc/sysctl.conf

    option routers 192.128.2.1;
    option nameserver (_real ip of nameserver_)

It turns out this step is totally unnecessary. I’d intended to use the routing from the host’s eth0 interface to the guest’s vmnet1 subnet to run Mike Benham’s sslsniff. While SSLSniff works great in such a setup, if sufficently munges up the SSL traffic that it doesn’t aid in addressing the MSIE problem, in fact, it pretty well makes it go away.

B) Analyzing traffic with Ethereal/Wireshark

Ack, I’m getting tired so sorry this last part is so lame. What it comes down to is that three test cases were sufficient to reveal the crux of the problem.

1. Firefox SSL POST—when using Firefox and taking about 30 seconds to fill out the form that gets POSTed, one can see ‘Encrypted Alerts’ coming down from the server about every ten seconds. The alerts are probably change_cipher_spec or more likely a close_notify. When the POST is sent, Firefox starts with an SSL ClientHello and sets up a whole new SSL session

1. Automated MSIE post with no delays—when POSTing the form from the robot with no waits, everything works just great.

1. Automated MSIE post with a 30s delay—while the robot is waiting to POST the form, the same Encrypted Alerts come down from the server, and the client responds with ACKs. But when the form is POSTed the client is trying to re-use the same SSL connection. The server simply replys with ACKS, and MSIE barfs

In case number 3 it’s pretty clear that the Magic Apache mod_SSL Incantation is not working, as close_notify messages are still getting sent from the server.

Over and out.

From SANS:

Colleges Struggle with Cyber Security (2 & 1 August 2006) Cyber security breaches at colleges and universities accounted for one-third to one-half of all reported cyber security incidents in the last 18 months. This could be attributed in part to the fact that schools are likely to be more forthcoming about breaches than are private sector organizations. In addition, computer systems at institutions of higher education are often decentralized, making security more difficult. This series of articles examines “how and why security breaches have occurred” at the schools and looks at the increased privacy and security measures colleges and universities have taken in response to the cyber security incidents.

College Hacking #1

College Hacking #2

College Hacking #3

[Editor’s Note (Kreitner): Establishment and enforcement of security is a widely neglected management responsibility. One of management’s duties is assigning accountability for adherence to established policies and articulating consequences for policy violations. Management’s failure to do this for protecting information is a root cause of most security incidents. Once Boards of Directors begin to routinely require management to report to the Board on every security incident, including its cause and what has been done to prevent a similar incident in the future, management will begin to get serious about protecting the information entrusted to the organization.]