In Defense of David Bianco

I'd like to second the post by David Bianco that Sguil is not a Security Information Management (SIM) or Security Event Management (SEM) product. I think Sguil creator Bamm Visscher summarized the issue nicely when he said the following in the #snort-gui IRC channel:

SIMs take in all this information from points a-w, but the value is less than if you'd just grab data from x, y, and z.

I've advocated elsewhere that the garbage (the a-w) shoved into SIMs/SEMs does not necessarily produce a diamond when "correlated," summarized, or otherwise reported. I have advocated the value of simply collecting all logs in one place (log centralization), because logs should never be exclusively stored on a target system. (Bejtlich: "Every system is a future victim." This is a corollary of "Prevention eventually fails.")

Sguil's x, y, and z is alert data from Snort, session data from SANCP, and full content data from a second instance of Snort, or Tcpdump or Tethereal. In my experience performing network security, these are the three indispensible elements of detecting and responding to intrusions. I couldn't imagine doing my job without them, and prior to starting my own company I refused jobs at MSSPs that were unwilling to collect, analyze, and escalate that data.

Read More

In Defense of HD Moore

Thanks to Tom Ptacek, I learned of a truly lame SANS poll questioning the responsibility of the Metasploit ie_xp_pfv_metafile component. The poll results as of now show the following:

Was the release of the 2nd generation WMF exploit on Dec 31st 2005 irresponsible ?

35 % =>Yes, I 'd like to see the authors brought to justice
21 % =>Yes, they made the world a worse place
32 % =>No, the bad guys had already equal ammunition
11 % =>No, I believe the ends did justify the means
Total Answers: 1379

Regarding the first option -- what law exists against writing Metasploit components? About the last -- what "ends" are in play? I would have liked to have seen the following option:

"No, I now have a means to test the effectiveness of patches, 
anti-virus/malware products, and other defensive measures."

Without a way to test the effectiveness of countermeasures, defenders are as much at the mercy of the intruders as they are the software vendors who fail to provide timely patches.

I found that many of the poll comments do not seem to reflect the majority of "Yes" (meaning "irresponsible") votes, and some reflect the sentiment of this post.

I highly recommend reading Tom's post and his link to criticism of SATAN in 1995. The history major in me speaks up once in a while to say "nothing ever changes."

Read More

Microsoft Says Wait One More Week

I just received notice of the updated Microsoft Security Advisory on the WMF fiasco. It states:

Microsoft has completed development of the security update for the vulnerability. The security update is now being localized and tested to ensure quality and application compatibility. Microsoft’s goal is to release the update on Tuesday, January 10, 2006, as part of its monthly release of security bulletins. This release is predicated on successful completion of quality testing...

What’s Microsoft’s response to the availability of third party patches for the WMF vulnerability?

Microsoft recommends that customers download and deploy the security update for the WMF vulnerability that we are targeting for release on January 10, 2006.

As a general rule, it is a best practice to utilize security updates for software vulnerabilities from the original vendor of the software. With Microsoft software, Microsoft carefully reviews and tests security updates to ensure that they are of high quality and have been evaluated thoroughly for application compatibility. In addition, Microsoft’s security updates are offered in 23 languages for all affected versions of the software simultaneously.

Microsoft cannot provide similar assurance for independent third party security updates.

In other words, get 0wn3d, stay 0wn3d.

I'm going to keep my eye on the Kaspersky Lab Analyst Diary for news on any other WMF worms.

Read More

imple OpenSSH Port Forwarding Tip

Recently I deployed a FreeBSD sensor on a client network. The only way I can access the sensor remotely is to use a Citrix client to connect to a Windows server. Then I use Putty to connect from the Windows server to my sensor. Argh. That is no fun.

Today I realized I should use port forwarding on OpenSSH. Here is what I do.

Connect using Citrix to the Windows server, and then use Putty to connect to the FreeBSD sensor.

On the FreeBSD sensor, use OpenSSH to connect to a system I control running an OpenSSH server. Call this box janney.taosecurity.com.

sensor$ ssh -R 2222:localhost:22 user@janney.taosecurity.com

On janney, connect to port 2222 on localhost. I am now on the remote sensor.

janney$ ssh -p 2222 user@localhost

That's it. Now I can enjoy an OpenSSH session, instead of an OpenSSH session inside a Citrix window.

Chapter 18 of Debian GNU/Linux 3.1 Bible clued me in to a more interesting scenario. Imagine three hosts, Alpha, Bravo, and Charlie. Alpha can talk to Bravo but not Charlie, and Charlie can talk to Bravo but not Alpha. Is there a way for Alpha and Charlie to talk directly to each other, through Bravo? With OpenSSH port forwarding, the answer is yes.

On host Alpha, run this command. It takes any input to port 2223 on Alpha and sends it to port 2222 on Bravo.

Alpha$ ssh -L 2223:localhost:2222 Bravo

On host Charlie, run this command. It takes any input from port 2222 on Bravo and sends it to port 22 on Charlie.

Charlie$ ssh -R 2222:localhost:22 Bravo

Finally, again on host Alpha (in a new terminal), to access Charlie from Alpha, run this command. By connecting to port 2223 on Alpha, the traffic is sent to port 2222 on Bravo, and from there to 22 on Charlie.

ssh -p 2223 localhost

This sort of access could be helpful when evading network access controls.

Read More

Simple Backups with rdiff-backup

I admit I am not vigilant enough when it comes to backing up personal files. For the new year I decided to at least keep a copy of important directories on a backup server, and keep those copies fairly fresh. rsync initially seemed attractive, thanks to its ability to transfer only incremental changes to files. Upon further reflection it didn't meet my needs. For example, if I delete a file from a directory and then rsync it, the file will be deleted from the backup server.

Today I learned of rdiff-backup, in the ports tree as sysutils/rdiff-backup. This program makes incremental backups of files, but it also supports restoring old versions of files and even deleted files.

In the following example, I want to back up selected directories in my /data partition on laptop orr. Here are the contents of /data:

orr:/data$ ls
Recycled        iso             misc            vmware          zip
code            lpc             tgz             work
documents       media           tmp             writing

I invoke rdiff-backup by telling it to exclude certain directories, include everything else in /data, and send backups to server janney in the /home/richard/rdiff-backup_orr directory:

orr:/data$ rdiff-backup --exclude /data/Recycled/ --exclude /data/iso/ --exclude /data/media/audio/
 --exclude /data/media/video/ --exclude /data/misc --exclude /data/tgz --exclude /data/tmp/
 --exclude /data/vmware --exclude /data/zip /data janney::/home/richard/rdiff-backup_orr

I get a password prompt, which is an indication that rdiff-backup is using SSH to copy files from orr to janney.

When this is done, I have the following on janney:

janney:/home/richard/rdiff-backup_orr$ ls
code                    media                   writing
documents               rdiff-backup-data
lpc                     work

Those are the directories I wanted backed up. A look into the rdiff-backup-data directory gives some insight into rddiff-backup's workings.

janney:/home/richard/rdiff-backup_orr$ ls -al rdiff-backup-data/
total 94
drwx------  3 richard  richard    512 Jan  2 13:36 .
drwxrwxrwx  9 richard  richard    512 Jan  1  1980 ..
-rw-------  1 richard  richard      0 Jan  2 11:34 backup.log
-rw-------  1 richard  richard      0 Jan  2 11:34 chars_to_quote
-rw-------  1 richard  richard     10 Jan  2 13:36 current_mirror.2006-01-02T11:34:22-05:00.data
-rw-------  1 richard  richard    110 Jan  2 13:36 error_log.2006-01-02T11:34:22-05:00.data.gz
-rw-------  1 richard  richard  34536 Jan  2 13:36 file_statistics.2006-01-02T11:34:22-05:00.data.gz
drwx------  2 richard  richard    512 Jan  2 11:34 increments
-rw-------  1 richard  richard  48537 Jan  2 13:36 mirror_metadata.2006-01-02T11:34:22-05:00.snapshot.gz
-rw-------  1 richard  richard    516 Jan  2 13:36 session_statistics.2006-01-02T11:34:22-05:00.data

The session.statistics file has information on the last backup.

janney:/home/richard/rdiff-backup_orr/rdiff-backup-data$ cat session_statistics.2006-01-02T11:34:22-05:00.data
StartTime 1136219662.00 (Mon Jan  2 11:34:22 2006)
EndTime 1136226986.54 (Mon Jan  2 13:36:26 2006)
ElapsedTime 7324.54 (2 hours 2 minutes 4.54 seconds)
SourceFiles 3023
SourceFileSize 3312777703 (3.09 GB)
MirrorFiles 1
MirrorFileSize 0 (0 bytes)
NewFiles 3022
NewFileSize 3312777703 (3.09 GB)
DeletedFiles 0
DeletedFileSize 0 (0 bytes)
ChangedFiles 1
ChangedSourceSize 0 (0 bytes)
ChangedMirrorSize 0 (0 bytes)
IncrementFiles 0
IncrementFileSize 0 (0 bytes)
TotalDestinationSizeChange 3312777703 (3.09 GB)
Errors 0

Let's say I now return to laptop orr. These are the contents of the lpc directory.

orr:/data/lpc$ ls
aggtap-hub.lpc          httprint.lpc
bgp-dos.taosecurity.lpc ldp-dos.taosecurity.lpc

For purposes of demonstration, I delete the httprint.lpc file.

orr:/data/lpc$ rm httprint.lpc 
orr:/data/lpc$ ls
aggtap-hub.lpc          bgp-dos.taosecurity.lpc ldp-dos.taosecurity.lpc

I then invoke the same command line to run rdiff-backup (shown previously). It only takes rdiff-backup about 30 seconds to realize only one change has been made to orr -- the delete of /data/lpc/httprint.lpc. A look in the backup directory on janney shows httprint.lpc has disappeared.

janney:/home/richard/rdiff-backup_orr$ ls lpc/
aggtap-hub.lpc          bgp-dos.taosecurity.lpc ldp-dos.taosecurity.lpc

A look at the new rdiff-backup statistics show how fast the update happened.

janney:/home/richard/rdiff-backup_orr/rdiff-backup-data$ cat session_statistics.2006-01-02T13:41:37-05:00.data
StartTime 1136227297.00 (Mon Jan  2 13:41:37 2006)
EndTime 1136227314.64 (Mon Jan  2 13:41:54 2006)
ElapsedTime 17.64 (17.64 seconds)
SourceFiles 3022
SourceFileSize 3312723832 (3.09 GB)
MirrorFiles 3023
MirrorFileSize 3312777703 (3.09 GB)
NewFiles 0
NewFileSize 0 (0 bytes)
DeletedFiles 1
DeletedFileSize 53871 (52.6 KB)
ChangedFiles 2
ChangedSourceSize 0 (0 bytes)
ChangedMirrorSize 0 (0 bytes)
IncrementFiles 3
IncrementFileSize 8978 (8.77 KB)
TotalDestinationSizeChange -44893 (-43.8 KB)
Errors 0

Can I recover httprint.lpc? Yes, the file remains in the increments directory kept by rdiff-backup.

janney:/home/richard/rdiff-backup_orr/rdiff-backup-data/increments/lpc$ ls -al
total 14
drwx------  2 richard  richard   512 Jan  2 13:41 .
drwx------  3 richard  richard   512 Jan  2 13:41 ..
-rwxrwxrwx  1 richard  richard  8978 Dec 29 16:22 httprint.lpc.2006-01-02T11:34:22-05:00.snapshot.gz

This means I can restore it. I tell rdiff-backup to look for httprint.lpc from the following day, which for my purposes will find the file I need.

orr:/data/lpc$ rdiff-backup -r 1D janney::/home/richard/rdiff-backup_orr/lpc/httprint.lpc /tmp/httprint.lpc

That's it. When finished, the file is restored.

orr:/data/lpc$ ls -al /tmp/httprint.lpc 
-rwxrwxrwx  1 richard  wheel  53871 Dec 29 16:22 /tmp/httprint.lpc
orr:/data/lpc$ file /tmp/httprint.lpc 
/tmp/httprint.lpc: tcpdump capture file (little-endian) - version 2.4 (Ethernet, capture length 1515)

I would note that I had trouble restoring the file to the original location. Therefore, I put it in /tmp in this demonstration.

rdiff-backup can be run where the backup server polls the laptop, as well.

This is only scratching the surface of the backup issue, but I now have a simple yet thorough backup solution to run at the end of every day.

Read More

The Power of Open Source

One of the criticisms of open source software is that there is no one to blame when a customer needs a problem solved. For example, if an open source OS or application is found to suffer a vulnerability, no one is seen to be responsible for patching it. Following this line of thinking, commercial software is considered a superior choice for consumers (whether corporations or individuals). When a problem happens, users can rely on the vendor.

The recent SANS ISC post about the WMF vulnerability has completely annihilated this argument. I have criticized SANS in the past, but I cannot fault their handling of the ongoing fiasco. I've never seen anything like this plea by Tom Liston before:

Looking forward to the week ahead, I find myself in the very peculiar position of having to say something that I don't believe has ever been said here in the Handler's diary before: "Please, trust us."

I've written more than a few diaries, and I've often been silly or said funny things, but now, I'm being as straightforward and honest as I can possibly be: the Microsoft WMF vulnerability is bad. It is very, very bad.

We've received many emails from people saying that no one in a corporate environment will find using an unofficial patch acceptable.

Acceptable or not, folks, you have to trust someone in this situation.

To the best of my knowledge, over the past 5 years, this rag-tag group of volunteers hasn't asked for your trust: we've earned it. Now we're going to expend some of that hard-earned trust:

This is a bad situation that will only get worse. The very best response that our collective wisdom can create is contained in this advice - unregister shimgvw.dll and use the unofficial patch. You need to trust us.

The unofficial patch Tom references was written by Ilfak Guilfanov and described here. What is this? It's a patch created by a non-Microsoft developer, acting more rapidly than Microsoft itself. Sure, you can argue that Microsoft is working now to develop a patch that will hopefully address deeper problems, perhaps serious problems. Nevertheless, SANS has reverse engineered the unoffical patch to ensure its validity, wrote a FAQ about the vulnerability, and is now hosting a .msi to ease patch installation. This is unprecedented.

Where is Microsoft on this issue? They published their initial advisory on 28 Dec and updated it 30 Dec. Nothing they've done has helped resolve the issue. Meanwhile, the Metasploit project has released a module to generate malicious WMF files. This puts exploit creation in the hands of the lowest common denomintaor.

F-Secure reports the WMF issue is truly "a feature, not a bug," due to Microsoft's design of the WMF format. In fact, F-secure says

"'The WMF vulnerability' probably affects more computers than any other security vulnerability, ever."

Everyone who paid good money to Microsoft to fulfill its duty as a commercial vendor selling closed, proprietary software is still waiting for an official patch. Meanwhile, users are owned by exploit spam and targeted WMF email attacks. Remember this example the next time your management refuses to allow running open source software because "no one is responsible for problems."

When private third parties like SANS and Ilfak Guilfanov have to step up to the plate to save the world, the argument for exclusively running closed, proprietary software with a poor security record is weak indeed.

Note: I do not mean to unduly criticize Microsoft employees. I know several of them who are really sharp. At the end of the day, however, Microsoft as a corporation is AWOL on the WMF issue.

Update: SANS has temporarily pulled their .msi. However, I just installed the original .exe on a Windows XP SP2 system without incident. I also unregistered the shimgvw.dll library. Ilfak Guilfanov's patch creates this directory on the host:

C:\Program Files\WindowsMetafileFix>dir
 Volume in drive C has no label.
 Volume Serial Number is 30EF-BD7B

 Directory of C:\Program Files\WindowsMetafileFix>

01/02/2006  08:52 AM     DIR           .
01/02/2006  08:52 AM     DIR           ..
01/01/2006  12:38 PM               155 compile.bat
01/01/2006  03:54 PM             1,141 Readme.txt
01/02/2006  08:52 AM             3,537 unins000.dat
01/02/2006  08:52 AM           673,546 unins000.exe
01/01/2006  03:41 PM             7,022 wmfhotfix.cpp
               5 File(s)        685,401 bytes
               2 Dir(s)   3,207,041,024 bytes free

C:\Program Files\WindowsMetafileFix>type Readme.txt
MS WINDOWS METAFILE VULNERABILITY HOTFIX v1.3

PLEASE READ THE FOLLOWING CAREFULLY!

This is a temporary fix for the MS Windows
Metafile file vulnerability:

http://www.hexblog.com/2005/12/wmf_vuln.html

It has been tested on Windows 2000, Windows XP,
and Windows XP Professional 64bit.
Please use it at your own risk and switch
to the official patch from Microsoft as soon
as it is be available.

THIS FIX IS PROVIDED 'AS IS' WITHOUT WARRANTY OF
ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING,
BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF FITNESS
FOR A PURPOSE, OR THE WARRANTY OF NON-INFRINGEMENT.

IN NO EVENT SHALL ILFAK GUILFANOV BE LIABLE TO YOU
OR ANY THIRD PARTIES FOR ANY SPECIAL, PUNITIVE,
INCIDENTAL, INDIRECT OR CONSEQUENTIAL DAMAGES
OF ANY KIND, OR ANY DAMAGES WHATSOEVER, INCLUDING,
WITHOUT LIMITATION, THOSE RESULTING FROM LOSS OF USE,
DATA OR PROFITS, WHETHER OR NOT HE HAS BEEN ADVISED
OF THE POSSIBILITY OF SUCH DAMAGES, AND ON ANY THEORY OF
LIABILITY, ARISING OUT OF OR IN CONNECTION WITH THE USE
OF THIS SOFTWARE.

Copyright 2006 by Ilfak Guilfanov, ig@hexblog.com
http://www.hexblog.com

As you can see, you can inspect the .cpp file and compile it yourself if you do not want to run the compiled wmffix_hexblog13.exe.

Read More

Default Services in Debian

This morning I started reading Debian GNU/Linux 3.1 Bible by Benjamin Mako Hill, David B. Harris and Jaldhar Vyas. I installed Debian 3.1r1 in a VM. I did not select any software packages. When done, this is the netstat output I saw:

richard@debian:~$ netstat -na -A inet
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:113             0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:819             0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN     
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN     
udp        0      0 0.0.0.0:813             0.0.0.0:*                          
udp        0      0 0.0.0.0:816             0.0.0.0:*                          
udp        0      0 0.0.0.0:111             0.0.0.0:*                          

Am I seriously seeing portmapper (111 TCP, UDP) listening? Port 113 TCP is ident. I used lsof to discover that rpc.statd was opening other ports I didn't recognize:

debian:~# lsof | grep IPv4 | grep 81 
rpc.statd 2757        root    4u     IPv4      13603               UDP *:813 
rpc.statd 2757        root    5u     IPv4      13612               UDP *:816 
rpc.statd 2757        root    6u     IPv4      13616               TCP *:819 (LISTEN)

I do not see any reason for a system installed in 2006 to have portmapper or rpc.statd enabled by default.

Read More