In this month's Windows IT Pro, I wrote a buyer's guide article on Exchange recovery tools. This just in from an admin who works for the city government of a large city in Virginia:
Thanks for putting this article together. I just wanted to let you know we are just about to implement a NetApp solution for Exchange 2003 and without NetApp's Single Mailbox Recovery product, not mentioned as needed in this article, it is impossible to Backup and Recover Individual Mailboxes, Recover Individual Items or Search and Query for Items to be Recovered. I wanted to let you know because their software is expensive and this product is an extra cost.
Yikes! My apologies for that. When I do a buyers' guide, I write the article itself that accompanies the guide, and I work with the magazine's editors to come up with a list of criteria, plus a list of products that meet those criteria. In this case, the selection criteria included the ability to do brick-level backups, the ability to search and query, and the ability to recover individual items. We don't usually ask vendors to list out all the products, submodules, agents, or other components that have to be installed to meet the criteria. For example, for backup solutions we don't ask whether there's a separate Exchange agent or not. Mail like this makes me think that maybe we should, though, because it's frustrating to buy what you think is a complete solution, only to find out that you have to lay out even more money to get the whole package.
Is this the start of a new trend? Vioxx Recall Leads to Worldwide Spam Reduction.
Well, OK, it's just a joke-- but it neatly reinforces the fact that spammers send messages out because it makes them money. If everyone quit buying their products, that would remove the incentive for them to operate.
Thanks to alert cow-orker Tom Meunier, we see that my earlier prediction about Plaxo has indeed come true, sort of.
What I was really talking about at the time was the risk that Plaxo would decide that their business model made it attractive to share your contact data with third parties, possibly without your permission or knowledge. That's why a number of large companies have banned their users from using services like LinkedIn and Plaxo. This PR looks like the first step down that road: it appears that they're opening their data store to the fine folks who brought us Skweezer. That means that now your Plaxo data is only as secure as Plaxo or GreenLightWireless or your wireless device vendor can make it... not exactly a reassuring prospect.
The newest version of XWall supports SURBL.
I haven't used or tested XWall, but it's certainly reasonably priced and it seems to be well-liked by the folks who do use it. (It also has a ton of non-spam-related features, including the ability to strip TNEF attachments and use POPbeamer).
Following up on yesterday's post on Councilman, I found this interesting article at GigaLaw: "Do ISPs' Policies Allow Them to Monitor E-mail?" At issue: whether ISPs can/should/do have the same kind of "we can monitor you" language in their user agreements as many corporations do in their acceptable use policies.
The bottom line is really simple: AOL, MSN, and Earthlink all say that they can monitor your email. AOL is unique in saying that they won't do so unless legally required to; MSN and Earthlink both reserve the right to monitor anything at any time.
Last week's column concerned the Councilman decision, in which a US Federal district court seems to say that intercepting email is OK if you're an Internet service provider. I got a couple of reader emails asking what that meant for private organizations who may or may not want to read employee email. The bottom line, according to my non-lawyerly understanding: the Councilman decision means nothing in that context. Why? Councilman concerned an ISP, not a private company. If your employees have to agree to an acceptable use policy that says you can monitor their email, or if you otherwise put them on notice (e.g. by a statement on your OWA front page), the prevailing legal consensus seems to be that you're in good legal shape if you do need to monitor email. However, you still need to tread very carefully. If you really want more details, a) ask your legal department or b) buy my book and read Chapter 20, which was written by an actual lawyer with real legal expertise in the field.
Via my inbox, I found a very interesting blog post that outlines the timeline for fixing the recent shell: vulnerability in Mozilla. I tip my hat to the Mozilla team for their speedy response.. except that they forgot a couple of important things.
First of all, where was the testing? In the timeline, I don't see any mention of any kind of testing to see whether their fix had any impact on legitimate uses of shell:. That implies that either a) they didn't test it, b) they did test it but forgot to mention it in the timeline (unlikely, given how complete it is otherwise), or c) there aren't any legitimate usages of shell: (in which case one might wonder why they implemented it.)
Next, what about code review? I notice that there was a (wait for it) three minute review listed in the timeline. I guess for a trivial change this might suffice. Then again it might not. Many eyes might make all bugs shallow, but in this case only one set of eyes spent 180 seconds reviewing the fix before approving it.
Third, if you have a look at this bug, you'll notice in comment #11 that this was flagged as security critical in October 2002. However, it wasn't fixed until July 2004. Oops.
Fourth, the original bug was tagged as "won't fix". Why? The dev team thought it was a Windows-only problem. Maybe it was, but oddly IE didn't suffer from it-- that sure makes it seem more like a Mozilla bug to me.
Fifth, I would point out that just because the team released a patch quickly, there's no guarantee (heck, there's no data) on whether users actually got that patch or not. Complain all you want about IE, but at least Microsoft has a robust system for notifying people of updates and, optionally, pushing them to affected machines.
Information disclosure vulnerabilities can be quite serious, and they often generate lots of press interest. Sometimes this interest is fanned by organizations that make their living selling security advisories. mi2g has definitely been a major force in publicizing some past vulnerabilities, and now they've found a new one that has worldwide impact.
Wendy's Drive-up Order System Information Disclosure
Reporter: mi2g (#/)
Date: July 07, 2004
Severity: Medium to High
Attack Class: Physical, Remote, Race Condition
Vendor: Wendy's (#)
I. BACKGROUND
Wendy's International, Inc. is one of the world's largest restaurant operating and franchising companies with more than
9,300 total restaurants and quality brands - Wendy's Old Fashioned Hamburgers®, Tim Hortons® and Baja Fresh® Mexican
Grill. The Company invested in two additional quality brands during 2002 - Cafe Express˙ and Pasta Pomodoro®.
II. DESCRIPTION
Remote exploitation of the Wendy's Drive-up ordering system allows an attacker to gain sensitive information about the
order of arbitrary customers.
During customer/vendor "handshake", the customer vehicle must come to a stop beside the vendor menu ordering system
which contains a large screen to display the current order. During this process, adequate protection is not given to the
space between the vehicle and the menu allowing for a number of remote attackers to obtain sensitive order information.
Once the victim has finished ordering, the information stays available on the screen for up to several minutes or until
another customer has pulled forward. This creates a great window for exploitation and increases the chance of winning
the "race condition".
III. ANALYSIS
Successful exploitation allows unauthenticated remote malicious arbitrary attackers to retrieve the contents of the previous
customer's food order which is a serious breach of confidentiality.
As proof of concept, this attack was carried out against mi2g CEO DK Matai. It was disclosed that he ordered a grilled chicken
sandwich, large fries and a large Coca-Cola.
IV. DETECTION
mi2g has confirmed that all Wendy's with a Drive-up menu display are affected. Other vendors may be affected but were not tested.
V. WORKAROUND
Use a hard object such as a rock or baseball bat to disable the order display screen after the late night drive-thru has closed.
VI. CVE INFORMATION
The Common Vulnerabilities and Exposures (CVE) project has assigned the name CAN-2004-2934 to this issue. This is a candidate for inclusion in the CVE list (http://cve.mitre.org), which standardizes names for security problems.
VII. DISCLOSURE TIMELINE
07/07/02 Exploit discovered by mi2g
07/08/02 mi2g clients (the "Inner Sanctum") notified
01/08/03 The Queen notified
03/22/03 bespoke security architecture updated
09/01/03 mi2g clients notified again
07/07/04 Public Disclosure
07/08/04 Vendor notified
VIII. CREDIT
Rear Admiral John Hilton and Geoffrey Hancock are credited with
discovering this vulnerability.
IX. SPECIAL THANKS
Donny Werner for verifying Wendy's drive up systems are not vulnerable to XSS issues!
X. LEGAL NOTICES
Copyright (c) 2004 mi2g Limited.
Permission is granted for the redistribution of this alert electronically provided a small royalty is paid. It may not be
edited in any way without the express written consent of mi2g. If you wish to reprint the whole or any part of this alert in any
other medium other than electronically, please email mi2g-research@hushmail.com for permission.
Disclaimer: The information in the advisory is believed to be accurate at the time of publishing based on currently available
information. Use of the information constitutes acceptance for use in an AS IS condition. There are no warranties with regard
to this information. Neither the author nor the publisher accepts any liability for any direct, indirect, or consequential loss
or damage arising from use of, or reliance on, this information.
I saw an interesting post by Meng Weng Wong, inventor of the SPF anti-spam mechanism: apparently Microsoft and Wong are working together to converge Caller-ID for Email and SPF. This can only help, as both standards have technical merit but neither provides a complete solution. There's a good overview of what this convergence means in this slideshow.
I used to have some old scripts on the website for my Exchange 5.5 book. I took the pages for the book down some time ago, but I still occasionally get queries for the scripts. Without further ado, then, here they are (note that I don't guarantee that they work with any particular configuration; use them at your own risk):
In the comments to a previous post, Clement Kent asks a set of good questions about how to combine compliance requirements with encryption. The bottom line: if you have DCAR (discovery, compliance, archive and recovery) requirements, you have to be very careful with message encryption. You have two basic alternatives:
The US Defense Department chose option 2. Consider the situation where Alice and Bob, both CIA analysts, need to communicate securely. Alice is in Langley, and Bob is in Baghdad. If the CIA mail system allows direct encrypted mail between them, there's no way for the CIA itself to inspect the message contents. They work around this by using option 2, and also by allowing the mail to travel around Langley and Baghdad unencrypted, but using a server-to-server superencryption like that described in the Open Group's S/MIME Gateway Profile.
It's less clear how you'd preserve DCAR capability with messages protected by Outlook's IRM features. For messages sent to large groups (like, say, "all employees"), it's a simple matter to add the archiver to the group; then you just have to ensure that you keep the IRM system up and running for the required length of time. For messages sent to individuals, you're back to the requirement of writing code to either add the archiving account or to reject the message, but the code has to be smarter because IRM messages lack the easily-recognized S/MIME headers (not to mention that an ordinary message might have an IRM-protected attachment.. but we won't go there for now).
Reader Remek Kocz says:
First of all, thanks for writing Secure Messaging. I've been doing a lot of research on Exchange 2K security recently, and your book pretty much filled in all the gaps. The reason I'm writing you is that I have not been able to find an answer to what I thought was a simple question (Usenet wasn't much help, surprisingly). I've been tasked to secure our OWA servers w/SSL, and the issue of certificates came up. Is it possible to obtain a cert from a trusted authority like Verisign and then issue self-issued certificates with a path back to the Verisign one? Being a school district, albeit a large one, we need to look out for every dollar, so I wondered if it would be possible to combine the self-issuing CA &a commercial one. A pure self-issuing CA is not feasible for us, since many people travel without laptops, and there is no way of knowing how they'll access the OWA servers.
This is a classic case for use of a subordinate CA: you want to create a CA that issues certs to end entities (in this case, your OWA servers; it might equally be used to issue certs to users), and you want that CA's cert to be issued by a well-known commercial CA. You might think that Verisign, Thawte, and other commercial certificate vendors would provide this as a service, but as far as I can tell, they don't. Why? Their preference is for you to use them as an issuer, offloading all CA work to them (and, incidentally, paying a per-certificate, per-year fee!) For the specific case you have in mind, Verisign offers their managed PKI service: they issue the certs, and you manage the issuance and revocation process via a web-based admin tool…but you don't run your own CA. Section 3.1.1 of Verisign's certification practices statement talks about the process of registering as a non-Verisign sub CA, but I can't find where you actually do that on their web site. I'll post more details if I can find a better answer.
Update: BeTrusted's OmniRoot service does exactly what you want. Thanks to David Cross for the tip.
Infosecdaily.net bills itself as a site that aggregates security news for technologies. There's a lot of neat stuff there, including a great blogroll (sample: "A Day in the Life of an Information Security Investigator"). Check it out.
My friend (and fellow E&O editor) Sue Mosher is changing jobs:
Effective at midnight tonight, Diane becomes the new proprietor of # and its Exchange Messaging Outlook newsletter.
We'll be moving the developer content to my other site at #, which I'll continue to maintain and grow as a destination for Outlook developers. (And yes, all moved pages will have redirects to the new site.)
This will let me concentrate on developer issues and maybe get a little long-needed breathing room. I also plan to write a book on deploying Outlook 2003, so send those configuration conundrums my way.
I'm really excited that Diane will be bringing her enthusiasm and a different range of interests to the site, so that it stays fresh and relevant.
I'm not normally one to post the same thing on both blogs, but this deserves double posting: Michael Howard (author of Writing Secure Code) has a blog, in which he discusses all sorts of tasty security stuff. (Too bad gotdotnet doesn't support trackbacks.)
You probably already know about the Windows Rights Management Server. It allows users to apply controls to their documents and messages; for example, you can tag an email as "do not forward", and Outlook won't allow it to be forwarded or copied. This capability is being called Information Rights Management, or IRM. IRM isn't ironclad-- after all, someone who wants to leak information can always find a way-- but being able to specify that documents expire, or that they can only be accessed by certain people, is a powerful tool for the documents' owners. (For more on IRM in Office 2003, see this.) One of the coolest IRM features is that by writing your own XrML templates, you can cusotmize which rights users can grant and how they apply. Sling a little XrML, and next thing you know your users can tag messages with things like "do not forward for 7 days" or "only full time employees can read this".
The problem is that getting people to use this technology may be difficult. IRM can offer a good way to ensure that sensitive material isn't accidentally forwarded, disclosed, or kept beyond its lifetime, but only if people use it. Enter Omniva, which makes a nifty server-side product that takes Exchange messages (including those sent with OWA and OMA) and adds XrML to them on the store side to make them IRM-protected. You define a policy once (e.g. "members of the Legal OU should have all mail encrypted, and it should expire after 180 days") and Omniva does the rest.
For more details on Omniva's product, see this. They have two white papers (one on the product and one on general retention issues). Check it out.
Microsoft is moving toward issuing sets of patches once a month instead of in a steady, Chinese-water-torture stream. Accordingly, now there's a big ol' set of patches up on Windows Update. For all you Exchange 2000 and Exchange 5.5 folks, there are two of particular interest: MS03-046 covers a vulnerability that can lead to arbitrary code execution on Exchange 5.5 and Exchange 2000 boxes, while MS03-047 covers a potential cross-site scripting vuln in OWA 5.5. Happy patching!
Turns out that Exchange-related blogs are popping up like housepainters at a beer giveaway. Andy Webb has one (named, of course, "webb log"), and so do the dynamic duo of KC and David Lemson, who just happen to be program managers on the Exchange team. Welcome, y'all!
From this week's Exchange UPDATE:
Attend Exchange Connections, Win a Free Vacation
Learn the latest tech tips and tricks from gurus like Tony Redmond, Sue Mosher, Paul Robichaux, and the Microsoft Exchange Team. Receive free access to concurrently running Windows & .NET Magazine Connections. Plus, you’ll have a chance to win a 5-day Las Vegas vacation with airfare for two. Register now online, or call 800-505-1201 or 203- 268-3204.
It should be a good show, and I look forward to meeting y'all there!
From a reader at a major whiskey maker (really!):
I purchased Secure Messaging with Microsoft Exchange Server 2000 at a Microsoft Windows 2003 conference in Cincinnati. The reason I purchased this book was for Chapter 14 Securing Outlook Web Access. I had been explaining to my boss that the traditional way of implementing Exchange 2000 (OWA) on a DMZ was not as secure as I would like, since you have to open several ports from the DMZ to the internal network. After explaining what I had found in your book and researching information on Microsoft’s website and others I convinced him and our corporate office this was the way to go. In June I implement your solution of Publishing OWA with ISA Server to secure our OWA server. This September we were audited by our internal auditors and they are telling us this is not as secure as the traditional way of placing Exchange 2000 (OWA) server on the DMZ. They could not give us a reason way, so I want to challenge them that this is more secure before I am force to change to the traditional way. I need information stating this method of securing Exchange OWA is more secure.
Tell your auditors to get off the glue. When you put an Exchange server of any stripe in the DMZ, you've created two problems. First, you're putting a domain member in the DMZ, and if someone compromises it they may have a springboard to compromise other machines inside the perimeter. Second, to make Exchange work you've got to open a ton of ports. DMZ configurations can be made secure, but the whole point behind ISA is that it gives you strong security by reverse proxying so you don't have to open anything in the DMZ.
For those interested, NGSS [David Litchfield's outfit -- PR] has just published a paper describing how to defeat the mechanism built into Windows 2003 Server to prevent exploitation of stack based buffer overflow vulnerabilities. Previous work done in this area presented methods that only worked in highly specific scenarios - the new methods presented in this paper are generic. The paper can be downloaded from #.This is an interesting paper that will no doubt generate a lot of wailing, moaning, and gnashing of teeth. However, the fact remains that MS at least implemented a mechanism, and no doubt they will improve it as people (inside and outside of MS) learn how to defeat it. It's just another small corner in the Great Security Arms Race™. I must say, though, that I'm not thrilled about Litchfield's decision to post exploit code in the paper, but maybe I'm just an old fogey.
Tom Shinder has an excellent writeup on how to configure RPC over HTTP. It's a highly useful supplement to the directions in the Exchange 2003 Deployment Guide, and it includes information on how to publish RPC-over-HTTP traffic through ISA Server-- always handy to have.
Microsoft maintains a page of Exchange 2003 documentation here. There are some very cool things here, not least of which is the little "freshness" icon that indicates when each paper or article was revised and how long it's valid. There's not an impressive volume of documentation there (yet... just wait until you see what's planned), but what is there is quite good. My current favorite is the S/MIME quick-start document.
CSO ("the magazine for the chief security officer") has a terrific, and well-balanced, article on the difficulty, and necessity, of patch management. I highly recommend it.
I figure everyone is sick of hearing about Blaster by now. (Quick recap: 1. Apply patches. 2. Install a firewall. 3. Use up-to-date AV software). There's another, lesser-known story out there that I think is pretty interesting: the master FTP server for GNU was compromised, and now they're scrambling to assess the damage and repair it. It's hard to discuss this without sounding like a fear monger, but I'll try to explain why this is so important.
ftp.gnu.org, the machine that was compromised, is the official central repository for all FSF software. All of the other FSF distribution points (and there are many) mirror its contents. - usually automatically. If you've added an FSF package to your system any time in the last 6 months, chances are that it came from ftp.gnu.org or one of its mirrors. Of course, if you've built any Linux distro in the last 6 months, odds are that you used multiple packages from ftp.gnu.org. Heck, the gcc compiler, which all free Linux software is built with, is officially distributed from ftp.gnu.org, so one might argue all software compiled with a compiler in the last 6 months is potentially impacted. (i.e. someone put a trojan in the compiler sources, placed those sources on ftp.gnu.org. Now anyone that builds that compiler has a trojaned compiler, one which outputs only trojaned binaries).
To recap: any FSF package downloaded from any FSF mirror might have been compromised. The FSF hasn't been cryptographically signing their packages (like Windows Update does) so there's no way to directly verify their integrity other than taking MD5 hashes, but that in turn depends on finding an "original" version of each pacakge and recomputing the hashes. They're going to start signing their packages, as explained here, but... well, horse, barn door, shut.
If this same compromise had happened to Microsoft, you can imagine the press firestorm that would have followed. The press reporting on this has been pretty mild; no one seems to think it's exceptional that an important machine, presumably run by competent admins, was compromised and that no one noticed for four months.
Interestingly, the FSF says that they believe that everything on ftp.gnu.org currently is safe, but they haven't said anything about any piece of software any time in the last 6 months. Their action thus far has been to wipe everything off of ftp.gnu.org and replace stuff that they feel confident hasn't been tampered with. This is the right thing to do from a security standpoint, but it doesn't inspire a lot of confidence in the security of the packages on their server and mirrors.
KB article 331834 describes how Windows 2000 SP4 switches the IIS password change mechanism over to ASP files, instead of the older (and less secure) HTR technology. That's all well and good, except that if you have Windows 2000 on your front-end and Windows 2003 on the back-end (or vice versa), when you drop these new bits on you'll find that things break. Fortunately, help is on the way: use the handy script (also shown below for those who won't/can't download .WSF files directly) to fix up the file names. Note that although this came from a pal of mine at Microsoft, it's not an official MS tool and isn't supported by them.
'======================================================================== ' changePasswordFix.wsf ' Fixes the iisadmpwd virtual directory for the OWA "change password" ' feature so that it works for both common cases: Win2003 FE + Win2000 BE ' and Win2000 FE + W2K3 BE. ' Author: a guy at Microsoft who asked not to be named here ' Date: 8/03 ' =======================================================================
' DISCLAIMER: This script is presented without warranty or support. Use it
' completely at your own risk. If it breaks, that's tough. This is not a
' Microsoft product, and it's not supported by Microsoft in any way.Function Make_IISADMPWD_vDirectory(Directory, DirectoryPath)
' Create the Virtual Dir
Dim oVdir, oApp, oDll
Set oVdir = GetObject("IIS://Localhost/W3SVC/1/Root")
Set oApp = oVdir.Create("IIsWebVirtualDir", Directory)
oDll = vInstallDirectory & "\asp.dll"
' add properties to new virtual directory
With oApp
.AppFriendlyName = Directory
.AppCreate2 1 ' 1 = out-of-process(isolated)
.DefaultLogonDomain = "\"
.Path = DirectoryPath
.AccessFlags = "513"
.AccessRead = True
.AccessScript = True
.EnableDirBrowsing = False
.EnableDefaultDoc = False
.AuthFlags = 1
.AuthAnonymous = True
.scriptmaps = ".*," & oDll & ",5,GET,HEAD,POST,TRACE"
.SetInfo
End With
Set oVdir = Nothing
End Function' asp2htr converts the ASP filename to the corresponding .HTR file name; this provides
' interop with Windows 2000 boxes that are still using HTR files.
Sub asp2htr
Dim File_Collection
Dim Source_File
Dim ASP_File
Dim HTR_File
Set File_Collection = Target_folder.Files
For Each Source_File in File_Collection
If UCASE(Right(Source_File,3)) = "ASP" Then
' msgbox Source_File.Name
File_Name = FSO.GetFileName(Source_File)
ASP_File = Split(File_Name,".")
HTR_File = ASP_File(0) & ".htr"
FSO.CopyFile Source_File, vDirectoryPath & "\" & HTR_File
End If
Next
Set FSO = Nothing
Set Target_Folder =Nothing
Set File_Collection = Nothing
MsgBox ("asp files copied to .htr files for Windows 2000 interoperabiltiy")
End Sub' htr2asp swaps the file names to provide W2K3-to-W2k interop
Sub htr2asp
Dim File_Collection
Dim Source_File
Dim ASP_File
Dim HTR_File
Set File_Collection = Target_folder.Files
For Each Source_File in File_Collection
If UCASE(Right(Source_File,3)) = "HTR" Then
' msgbox Source_File.Name
File_Name = FSO.GetFileName(Source_File)
HTR_File = Split(File_Name,".")
ASP_File = HTR_File(0) & ".asp"
FSO.CopyFile Source_File, vDirectoryPath & "\" & ASP_File
End If
Next
Set FSO = Nothing
Set Target_Folder =Nothing
Set File_Collection = Nothing
MsgBox (".htr files copied to .asp files for Windows 2003 interoperabiltiy")
End Sub
Dim vDirectory, vInstallDirectory,vDirectoryPath
vDirectory = "IISADMPWD"Set wshShell = WScript.CreateObject("WScript.Shell")
vInstallDirectory = wshShell.RegRead("HKLM\System\CurrentControlSet\Services\W3SVC\Parameters\InstallPath")
vDirectoryPath = vInstallDirectory & "\" & vDirectory
Make_IISADMPWD_vDirectory vDirectory,vDirectoryPath
Set wshShell = NothingDim FSO, Target_Folder, w2k3_svr
Set FSO = CreateObject("Scripting.FileSystemObject")
Set Target_Folder = FSO.Getfolder(vDirectoryPath)
w2k3_svr = Target_Folder & "\achg.asp"
If (FSO.FileExists(w2k3_svr)) Then
' WScript.Echo(w2k3_svr)
call asp2htr
Else
' WScript.Echo(w2k3_svr)
call htr2asp
End If
MsgBox "Configuration completed successfully !"
Kurt Dillard of Microsoft was kind enough to let me know of the re-release of the Securing Windows 2000 Server solutions guide. This guide is a beefed-up revision of the original, released in February. It's worth your reading time.
We've all heard the canards about how failure to apply critical patches costs billions and billions of dollars. Maybe, maybe not; it's hard to use that argument in any individual setting. Here's a better argument: Verizon failed to keep its service-level agreements because of outages during Slammer. Those outages were the result of poor patch management, so the Maine public service commission made 'em pay up. The outage period? A day.
In Massachusetts, Verizon tried, but withdrew, a similar attempt to claim that the outage wasn't their fault. In Virginia, VZN was facing an $886,619 payback, but I don't know whether they've had to pay it or not.
I've recently been doing a lot of research into enterprise instant messaging systems (three guesses why :). I stumbled across Instant Messaging Planet, which has a huge amount of interesting reading material. I have no idea how accurate their reports are, so I'll have to get back to you on their reportorial quality.
This site has a lot of interesting stuff, provided you know what a covert channel or tunnel is. Happy reading!
Version 1.1.1 of the Microsoft Baseline Security Analyzer has been released. Why do you care? Because this version adds scanning support for Windows 2003 Server, that's why. Go get it.
MSDN now has a new security center. It's billed as "a one-stop source to help developers write secure code". Check it out. (hat tip: Michael Howard.)
Steve Bass sent out an email alerting me to the fact that Amazon is giving away an anti-spam plugin for Outlook. I haven't used it myself, but Steve's endorsement is good enough for me to recommend it, especially since the $19.99 product carries a $20 mail-in rebate. Check it out and let me know what you think.
Update: Sunbelt was described as a spammer by John Levine, among others; it looks like the world-famous rhyolist spam list contains several entries related to Sunbelt or Stu Sjouwerman, the owner. Stu is also a Scientologist.
So, some reader mail:
What struck me about your editorial was that you were spending time with your family and still checking email. Is your family really that unimportant that you have to check email when you are having family time? This is a prime example of work/family balance having gone all wrong.There are too many examples of people not knowing how to relax that they eventually succumb to a stress attack that prevents them from working again - or worse, their family loses them permanently. Perhaps it is worthwhile learning that email is like postal mail. You CAN leave it until you have finished the family time. You can also switch off the mobile phone!
Nothing - especially work - should interrupt family time. No wonder the divorce rate is so high.
Now, of course, there's nothing I like better than reader mail, even when it's nosy and presumptuous. In this case, I reassured the writer that my work/life balance was just fine, and that the divorce rate here in the Robichaux family is holding steady at 0% after 11 years. I also pointed out that checking email while the kids are napping hardly constitutes vacation abuse. I didn't bother to explain that checking email regularly is one of those quaint business practices that allows me to make it so my family can eat regularly, and that an IT support manager for a company specializing in HR communications might not understand that so well.
So, the executive summary: I love hearing from y'all, but let's leave my family out of it, 'kay? Otherwise I shall have to improve my work/life balance by sending my three noisy, energetic young sons to your house.
Just in from NTbugtraq: Erik Birkholz is giving away the SQL Server chapter from his new book, SPECIAL OPS: Host and Network Security for Microsoft, UNIX, and Oracle. I have no idea if the chapter is good or not; I do know that the book's Exchange chapter was written by Jim McBee, who knows how many beans make five. You can get it directly, or check out the book's cool web site (much cooler than this one, I must admit.)
My question is: Is SMTP the only protocol / port required for basic email connectivity through a firewall? Here's the scenario. We have a simple exchange 2000 implementation: one server, one network, and one firewall separating us from the outside. We only have a need to send and receive email with the outside. I have a dispute with a fellow admin (who also happens to be the boss and has final say - hence the need for an authoritative answer) that believes ports 135-139, 445 and 61007 need to be open at the firewall for exchange to send/receive correctly. I insist they need to be closed, as they are unnecessary and for security concerns. Thank you for any help you can provide.
Good news: you're right. Bad news: you have to diplomatically tell your boss that he is, er, misinformed. For basic in-and-out email, all you need is port 25, period. That's the registered IANA port for SMTP. Ports 135, 137, and 139 are used by various Windows RPC services, so you'd only open them if a) you were crazy or b) you wanted to start attracting hack attempts within minutes. Port 445 is only used by SMB filesharing traffic, which you don't have.
So, bottom line: close everything on the firewall except port 25, and you'll be in good shape. (Of course, if you want OWA access, you'll need some additional open ports-- see Chapter 14 of the book for details).
From a friend who shall remain nameless, lest he get flamed to oblivion. I think this speaks for itself. Physician, heal thyself.
Eric Raymond coined the term "Many eyes make all bugs shallow". he has an open source product, Fetchmail. in the last six months there have been at least four serious buffer overruns in the product:
| Oldest affected version | Release date | Vuln date | Days til found | CVE Number | Short comment |
| 5.3 | 2/22/20 | 10/11/02 | 962 | CAN-2002-1174 | long headers |
| 5.3 | 2/22/00 | 10/11/02 | 962 | CAN-2002-1175 | DNS records |
| 5.9 | 8/13/01 | 12/23/02 | 497 | CAN-2002-1365 | "@"s in local addresses |
| 2.5 | 12/23/96 | 6/25/02 | 2010 | CAN-2002-0146 | Message limits |
note, the version release date comes from ESR's news page
File this under "there's never a right way to do a wrong thing". In fairness, Sybari is proactively alerting their customers about this bug, and they still make a darn good AV product. However, if they had resisted the temptation to make their product do something that shouldn't be done, they wouldn't have this problem now!
From: support@sybari.com [mailto:support@sybari.com] Sent: sometime last week To: faithful E2KSecurity reader Subject: Re: Configuring Scanned Folder Locations - Antigen for Exchange 7.0
Hello reader,What build of Antigen are you running? There is a known issue with
corruption of the priv1.stm associated with use of the Disclaimer.
Several clients have seen this, and it is easily resolved by turning the
Disclaimer off. However, this is only a work-around, and, as of now, future
releases of Antigen will not have a resolution to this, since we don't know what
the cause is. We have been unable to reproduce this in house, and we need
someone who is seeing this to run a diagnostic utility that will provide
more information and, hopefully, a solution.[ snipped some other unrelated stuff ]
Regards,
a support person
Sybari Software, Inc.
E-mail: support@sybari.com
http://www.sybari.com
Peter Gutmann's done it again; he's produced a wonderful paper for crypto implementers. It posits questions like "Consider whether your design can be implemented on a system with a total of 1kB of memory, or alternatively whether it can process a 1GB data block in a machine with 128MB of memory" and offers pithy comments like "No matter how cool/interesting/useful/mandated in standards a new design is, it won't be used if it requires redeployment of all existing hardware and
software for little apparent gain."
I just got an IM from John Matteson informing me that my link to the whitepaper on how Windows XP SP1 uses the Internet is broken. The paper is now here. It'll probably move again at some point in the future, as MS is wont to do.
In a recent column (12/10/02), I more-or-less dismissed VNC as a useful remote access tool. Two readers wrote in to correct me. First, VNC now has a new home, with a slightly more up-to-date version. However, they've dropped the Macintosh version; boo hiss. Second, there's an allegedly optimized version called TightVNC, based on, and interoperable with, the original version. TightVNC has a Java version, so I guess that's what Mac users are supposed to use. I haven't tested either of these, but if you're allergic to Terminal Services they might be worth a look.
A reader asks:
Should I do AVAPI virus scanning on connector servers?
It doesn't matter. AVAPI only scans the Exchange information store, so running it on your connector servers won't do any good. Instead, you need an SMTP virus scanner like Trend's VirusWall or Nemx' Power Tools.
A reader asks:
Can you please help with a huge frustration I have with Outlook? After applying one of the "security patches" a while back, Outlook now deletes .txt files and others out of hand without asking me. I work in an environment with many Unix-heads and thus get lots of .txt file attachments, as well as other types I can't think of off the top of my head, that Outlook summarily deletes. Not only is this an asinine excuse for security, it requires I open Netscape and read my mail through its client in order to view the attachment - DUMB! Is there a way for me to go back to sanity without completely reinstalling the Outlook client?
Why, yes, dear reader-- there is.
The Outlook Security Update (included in Outlook 2002 and available for Outlook 2000 and Outlook 98) blocks certain file types. Unfortunately, .txt isn't one of them. Outlook isn't deleting the blocked attachments; it's just preventing you from opening them. You can customize the list of blocked attachment types, though. See Sue Mosher's resource page for more information on how this works, or read Chapter 13.