Archives


Atom Feed

Associated Blogs
 
Edge City
 
Numbering Peano
 
Praxis101
 
Prof. von Clueless in the Blunder Dome

Recent Items
 
Shared Identity Surprises - How Not To Do Single Sign-On
 
Congratulations ODF, OSI Draft International Standard 26300
 
Weight Loss and the Cravings
 
Party on the 10 island! Aftermath
 
Party on the 10 island!
 
Tom Clancy's Jack Ryan Novels
 
Serious Camp Fu 2.0
 
Happy Birthday, Ted
 
We have a great future behind us
 
DRM as Destroyer of Markets

Phish Eggs: "We Can't Do Anything About That ..."

I receive one or two phish e-mail daily.  Lately, they have been taking turns threatening me about lock-down of my eBay and PayPal accounts.  They are usually sent to e-mail addresses that I do not use with those accounts.  They also end up in my junk e-mail folder because anything from an unknown sender goes there (including mail that is faked with one of my e-mail addresses because I really don’t spend much time sending e-mail to myself).  I also have all e-mail received in plaintext, so it is very easy to inspect and detect the phish-hook in these.  There are some, involving images, that make it quite difficult to find the hook, but I have been successful, when curious enough, in capturing the HTML and inspecting that for the URL of a compromised system, without actually visiting any sites or fetching images or anything else from an imposter site.  (The legitimate sites should watch how often their images are fetched for other than their pages to gain a sense for the extent of these impersonations, though.)

With all of these defenses in place, I have also began forwarding the few daily arrivals to the appropriate security authorities at the web sites of the impersonated senders.  Some of these are easier to use than others.  Security contact information tends to be buried in the bowels of the site, often obscured completely as sites are updated for mercantile purposes.  The most peculiar condition of the various security centers is that you often need to be an account holder to submit information about fraudulent e-mail (although both amazon.com and Microsoft have public e-mail addresses for contacting their security organizations). 

The odd thing about limiting contact to account holders is that is it is easier, as a member of the public, to notice a likely fraud when I don’t have an account.  Working as I am to maintain my anti-phishing good-citizen merit badge, I notify those institutions, often in distant places, that are unfortunate enough to not have my business.

Today, I failed miserably.  I received an incredibly lame phish email (one each to e-mail addresses that I haven’t given out in years), one so deficient that I wonder if it has some other purpose.  This email had the following amazing announcement, in both plaintext and HTML:

Dear National City Account Holder, During our regular update and verification of the Internet Banking Accounts, we could not verify your current information. Either your information has been changed or incomplete, as a result your access to use our services has been limited. Please update your information by clicking Reply and providing your account login and password. Sincerely, National City Accounts Department.

Please Click Reply?  How 80’s retro.  The subject of the mail is “National City Account Problem” and by golly there’s a reply address, to Customer Service with an obviously-bogus comcast.net address.  I feel like I’ve walked into the middle of a roadrunner cartoon where the coyote has painted a bulls-eye on his chest and a kick-me sign on his butt.  

Aw go on, report it.  Give it your best shot.  Lacking a National City account, but bemused by the peculiarity of the phish message, I did an Internet search and settled on a likely National City financial institution.  Not being a customer of anyone with that name, I am not that confident that I’ve found a legitimate site nor the intended institution.  I don’t see anything about fraud or security on the home page, and the “Contact Us” link requires JavaScript, which I have disabled by default for unknown Internet sites.  Imagining all sorts of movie-plot scams, I am unwilling to trust this site and I take the “Locations” tab.  There I discover that National City Corporation is in Cleveland, Ohio, and I call the listed local number.  I’m offered two menu choices but choice three, “0”, works and I tell the representative that I want to report a security/fraud-email incident.  I am transferred to the “loss prevention” center and offered two more choices.  Here, choice three is rejected so I claim to be an account holder (not a branch) calling with a problem and press “1”.  The “loss prevention” center is not interested in the e-mail I received.  I’m told they can’t do anything about that and they receive untold numbers of reports like this already.  When I’m advised to contact my local law-enforcement authorities, I know I’m in the wrong place and end the call.

Is It That Bad?  While muttering that Bruce Schneier is absolutely correct about putting the cost of fraud where it will do the most good at obtaining a cure, I fact check the site a little more before I post this blog entry.  The “online banking” link doesn’t require JavaScript and on that page there is a consumer-fraud warning and link.   That’s more like it.  The instructions are clear and I call the first-listed number.   They refuse a call from my cell phone (the announcement says my phone has calling restrictions), so I drag the land-line instrument over to my computer.  The number is a general one for account holders, but I can wait for an operator.  I state the purpose of my call to Anita, and after “just a moment” I encounter the first hold music in my experience so far.  I switch to speaker phone and go back to my typing.  Anita returns a minute later and says that they have an alert about that, I should delete the message, and as long as I’m not a customer there is nothing else for me to do.  I ask if they want to see the e-mail and Anita claims they already have it (their alert was passed around last Friday).

Now What?   I can’t believe that someone was so thick as to use email reply as a means to harvest account-access information, so I figure I’ll have some fun (assuming the e-mail address is still active).  Using my account with the ancient but no-longer-used email address, I send a warning reply:

Dear [redacted]@comcast.net

I thought I should alert you to the fact that someone is
using your e-mail address as a destination for harvesting
account log-on information via a fraudulent e-mail.

When you contact your local law-enforcement authorities
(or they contact you), you might want to know that the 
message is being transmitted with header information 
that might be useful in locating the culprit that is 
passing around your address:

Received: from c-24-8-194-220.hsd1.co.comcast.net 
(c-24-8-194-220.hsd1.co.comcast.net [24.8.194.220])	
   by infonuovo.com (8.8.7/8.8.5) with SMTP id FAA11920
	for <orcmid@infonuovo.com>; 
         Thu, 22 Dec 2005 05:20:07 -0800 (PST)

X-Message-Info: ETOZ28sVCqlrBSBwb20ad335+BTPsk108rsHBF

Received: from mail0391.vhxz.mindspring.com
   (62.40.218.243) by ytd264-gen056.mindspring.com 
   with Microsoft SMTPSVC(5.0.2195.6824);
	 Thu, 22 Dec 2005 15:12:07 +0200Received: from MHE7 
   (nxd25.132.50.151.qqlw377.lwy.mindspring.com 137.61.8.55)
	by mail1.zho.mindspring.com (74.99.627alb982/25.5.91) 
         with SMTP id o302D08PRni89;
	Thu, 22 Dec 2005 11:16:07 -0200

Message-ID: <99htx5ry588lli8iyp$owy8gx35rf49$qb9370vli34@XX61>

From: "Customer Service" <[redacted]@comcast.net>

To: "Orcmid"

References: <mendacious8-I011DFXzELUhcfU9X76194o6@mindspring.com>

Subject: National City Account Problem

Date: Thu, 22 Dec 2005 19:18:07 +0600

MIME-Version: 1.0Content-Type: multipart/alternative;
	boundary="--998074522543757"

X-UIDL: bMT"!*>a!!a?1"!$iK"!

Where’s the gimmick?  My movie-plot mind is still wondering how something this bare-faced might harbor a tricky way to actually harvest account information.  The message is not marked as being in an interesting character set (where “comcast.net” might not be what it seems), but the time-zone indications are suggestive.  I know there is information in the headers of replies that allow message threads to be reconstructed, and that might be enough to divert the reply in a way where good old [redacted]@comcast.net doesn’t ever notice.  Meanwhile, my realistic-assessment mind says I should expect an e-mail bounce message in response.

It bounced all right.  I got the bounce message, but it wasn’t exactly what I was expecting:

A message (from <ORCMID@INFONUOVO.COM>) was 
   received at 22 Dec 2005 19:57:28 +0000.

The following addresses had delivery problems:

<[redacted]@COMCAST.NET>	Permanent Failure: 522_mailbox_full;_
         sz=77003127/262144000_ct=25000/25000

	Delivery last attempted at 
         Thu, 22 Dec 2005 19:57:32 -0000

Well, that isn’t quite what I was expecting.  I may have been shilled into DOS-ing some poor soul’s in box, and I wonder what all those other messages are about.  Because Comcast returned my e-mail, I get to see some things about the headers that might be useful to someone:

Received: from mail9.atl.registeredsite.com ([64.224.219.83])
          by sccrmxc16.comcast.net (sccrmxc16) with ESMTP[…]
Received: from Scampo (70-56-72-209.tukw.qwest.net [70.56.72.209])
	[…] Thu, 22 Dec 2005 11:57:25 -0800 (PST)

[…]
thread-index: AcYG+m0ukTUuJZDLTqW9EYbPNWdXFAAMaS+A

In-Reply-To: <99htx5ry588lli8iyp$owy8gx35rf49$qb9370vli34@XX61>

There's the IP address that has been assigned to my DSL modem for now, but that doesn't really increase the vulnerability of my residential firewall and Scampo, the machine I sent the message from. There is the automatically-generated "In-Reply-To" that might be useful in diverting arriving e-mail to a zombie (welcome-back, movie plot). And there's just the mystery of it all (maybe my computer password is encoded in the thread-index?).

ODMA: The Little Middleware That Could

When I first learned about the formation of an Open Document Management API coalition in early 1994, I didn’t expect to be its principal technical coordinator/evangelist/support contact ten years after the first specification was stabilized and the ODMA Connection Manager (the ODMA “middleware”) shipped in 1995. 

On attending the second 1994 meeting on ODMA, in Orem, Utah, I was easily satisfied that ODMA was a good idea and there was no reason to do anything but to encourage and support it.  I arranged to host the third meeting at Xerox PARC.  At a Massachusetts meeting I lent my voice to Arnie Epstein’s lobbying for use of the Microsoft Component Object Model (COM) at the ODMA integration layer. COM was felt to be too unknown and too new and too Microsoft to adopt for the application-facing API.   At that time, Windows 3.11 was the in-use target platform, with some concern for use on NT.

What Is It We Like About Standards Wars?

While my attention through 1998 was on Document Enabled Networking (an effort of Xerox XSoft with Novell) and its merger with Shamrock (an effort led by IBM with Saros) to form the Document Management Alliance, I always regarded ODMA as complementary to, and separate from, the DMA model and interfaces.  ODMA provided a smooth integration of desktop applications with document-management; DMA provided a federation of document-management systems facing out to the server islands. 

It was always surprising to see the hostility that adherents of one approach had for the offerings of the other, and the degree to which each group feared the other would steal its thunder.  I found it inexplicable.    There was no conflict of scope, but apparently one of ambitions.

Keeping It As Simple As Possible

What only time would reveal was that ODMA was also targeted at an important sweet spot, was timely, and worked well enough.  Meanwhile DMA took too long and was seen as too complex as well as unresponsive to new technologies (like Java).  ODMA’s developer audience, on the other hand, would eventually be more concerned about the inability to integrate using Visual Basic.  We never go to show, in delivered systems, how DMA and ODMA could work together to integrate from the desktop out to the repositories.

Some of the focus (and a certain edginess) by which ODMA succeeded is explained by this manifesto at the beginning of the first ODMA specification:

1. If the standard does not solve a problem it will not be used.
2. If the creation of the standard takes a long period of time, it does not solve the problem.
3. If the standard is difficult to implement, it does not solve the problem.
4. The standard must be vendor independent.
5. The standard must not try to solve all vendors problems, or it will be big, complex and take a long time to implement. This violates rules 1, 2 and 3 above.
6. It is the customers that lose if there is not a straightforward way to integrate applications that create documents, and applications that manage documents. Easy integration between applications and document management systems will grow the industry and increase sales for the entire marketplace.

It is difficult to express the importance the initial members of the consortium placed on wanting to create a useful API that is vendor and platform independent while still simple to implement. They recognized that they could solve 80 percent of the problem easily and were willing to live with having to solve another 10 percent over time and probably never being able to solve the final 10 percent.

It is difficult to comprehend how a motley band of document-management vendors managed to come together long enough to produce something that solved a problem for all of them but that none of them could get enough value from providing on their own.  Integrating between document-management systems and the desktop and getting out of the way of users had been a constant and costly challenge.  The ODMA API, Connection Manager, and underlying integration model (think ODBC or TWAIN for comparable approaches) reduced the cost of entry onto the Microsoft desktop.  It dramatically reduced the cost of retooling and customizing for each new desktop-application release.

I think the generosity and willingness of SoftSolutions, contributor of Brad Clements’ original proposal, was crucial.  It also would not have worked if enough desktop applications were not arranged to be ODMA-aware.  WordPerfect, then joined along with SoftSolutions into Novell, took the first step and Microsoft provided the sustaining presence from Word 97 through 2003.

But No Simpler

AIIM DMware was created in 2001 2000 to provide a safe-landing of public code and support after dissolution of the ODMA and DMA coalitions.  As the technical coordinator for continuation of DMware, I had a big surprise in store for me.  While traveling in Italy and studying the language for six weeks, my arriving e-mail (via MSN in London to cell-phone modem to laptop) was suddenly all about support problems with ODMA.  I was receiving my initiation in ODMA trouble-shooting and the finger-pointing among desktop vendors and DMS vendors that found ODMA a convenient target in the middle.  The developers had moved on and the adopters of ODMA-based integrations were now making their problems known.  The concerned parties had changed.

Fortunately, the last release of the ODMA Connection Manager contained a logging option.  I could talk users and system administrators through the capture of logs that I would then interpret via e-mail.  I could confirm that ODMA was working correctly enough (and I found bugs, thankfully never found to be the causes of difficulties users encountered).  I could see where connecting software (usually the desktop application) went off the rails, but I had no way to troubleshoot the proprietary applications on both sides of the middleware.

That experience completely altered my priorities among DMware activities.  Users with problems always came first, and there had been no support mechanism.  I did what I could, with AIIM sponsorship.  There was always more that could be done.  

Welcome to the Long Niche

Today, problem reports have dwindled.  Announcement of new ODMA-aware applications and compliant document-management systems is rare.  I have no way to know how many PCs are still using ODMA for document-management integration on the desktop in 2005.  I am certain this is a shrinking niche.

I learned some valuable lessons.  First, it is extremely important to look at the lifecycle of integration solutions and plan for sustained troubleshooting and support down the road.  Secondly, I like to think that we now know more about establishing end-to-end scenarios that confirm the proper behavior and failure-modes of this kind of integration.   This wasn’t anticipated in 1995 before the low-hanging fruit began to suffer the blight of bit rust.

Ultimate Student Project

I had always wanted to create something more for ODMA, especially around expanding the forms of integration that were supported.  I had even established a SourceForge project as a haven for any new development.

When I needed to find a software development activity for a project-oriented M.Sc in IT dissertation, it was natural to fix on ODMA as a vehicle for prototyping ideas around open-system trustworthiness.   Although I abandoned the dissertation, I still wanted to carry out the project, and I have announced its formal initiation (after several false starts) at NuovoDoc, my business site.

Although I am completely willing to uncover a hidden pocket of interest, I have no illusions that anything I do will reverse dwindling interest in and use of ODMA.  I am as responsible as anyone for its neglect.  It is more like my safe laboratory for learning how to put the lessons into practice and then adapt them to new settings.  It’s a little as if ODMA has donated its body to science and now researchers will get to know the creature in a new way.