Paypal follow-up

Some people wonder whether the situation with PayPal is that bad. Well, at least the phishing part is. Today’s mail included this little gem from points unknown pretending to be PayPal:

Attention! Your PayPal account has been limited!

[…]

[Link to a phishing site]

This is the Last reminder to log in to PayPal as soon as possible. Once you log in, you will be provided with steps to restore your account access.

[…]

How did I know this was a forgery? Let’s take a look at the email headers:

From: "PayPal Services" <paypal@service.com>
To: "lear" <lear@ofcourseimright.com>
Subject: Your PayPal account has been Limited
Date: Fri, 16 Oct 2009 10:18:53 +0000
Organization: PayPal
MIME-Version: 1.0
Content-Type: multipart/alternative;
        boundary="----=_NextPart_000_0000_01C6527E.AE8904D0"
Message-ID: <RI1BvDvIMYk5XYA4IyF00002a42@mail.realinterface.com>

The first thing we note is the From: line. While this line can be easily forged, in this case, the miscreant forged not paypal’s domain but service.com‘s. Well, that’s not PayPal. This one was easy to establish as a fraud. But had we any doubts we would need look no further than the previous two lines (the last Received: header). If we look at the address 196.12.233.14, which is claimed to be dynamic.casa1-15-233-12-196.wanamaroc.com, we note that the name it has begins with “dynamic”. That name, and the numbers that follow in it, indicate that this is probably someone’s house or office PC, and not paypal’s email server. Note I’ve highlighted to “To” line, with the address lear@ofcourseimright.com. But that is not the address I’ve given PayPal.

What’s more, I happen to have an actual paypal.com set of headers to compare against. Here is what it looks like:

Return-Path: <payment@paypal.com>
Received: from mx1.phx.paypal.com (mx1.phx.paypal.com [66.211.168.231])
	by upstairs.ofcourseimright.com (8.14.3/8.14.3/Debian-6) with ESMTP id n9E8KIwI026171
	for <xxx@ofcourseimright.com>; Wed, 14 Oct 2009 10:20:39 +0200
Authentication-Results: upstairs.ofcourseimright.com; dkim=pass
	(1024-bit key; insecure key) header.i=service@paypal.ch;
	dkim-adsp=none (insecure policy)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=paypal.ch; i=service@paypal.ch; q=dns/txt; s=dkim;
  t=1255508439; x=1287044439;
  h=from:sender:reply-to:subject:date:message-id:to:cc:
   mime-version:content-transfer-encoding:content-id:
   content-description:resent-date:resent-from:resent-sender:
   resent-to:resent-cc:resent-message-id:in-reply-to:
   references:list-id:list-help:list-unsubscribe:
   list-subscribe:list-post:list-owner:list-archive;
  z=From:=20"service@paypal.ch"=20<service@paypal.ch>
   |Subject:=20Receipt=20for=20Your=20Payment=20to=XXX
   |Date:=20Wed,=2014=20Oct=202009=2001:20:17=20-0700|
   |Message-Id:=20<1255508417.22290@paypal.co
   m>|To:=20Eliot=20Lear=20<paypal@ofcourseimright.com>
   |MIME-Version:=201.0;
  bh=q82fwVBPBq26WHflKsNcdbCIf3Vcc5wRznZ9tfI8+8k=;
  b=OPyR7evc/VcnTZyDZSlYCh9oLm+vmKt8qsocqMrAr7y/kg3P5+DhO3mB
   UDbhkCvqu+owm45X1te+PxoREXR9aMEuuD20ltP2B5f5JWf/MjICk6zc6
   gYv6pY6ZRFKclXFGvtViJwv0LsW8N7uaoiZCAh5mxrjfuJaF+SmNyX23c
   I=;
Received: (qmail 22290 invoked by uid 99); 14 Oct 2009 08:20:17 -0000
Date: Wed, 14 Oct 2009 01:20:17 -0700
Message-Id: <1255508417.22290@paypal.com>
Subject: Receipt for Your Payment to XXXX
X-MaxCode-Template: email-receipt-xclick-payment
To: Eliot Lear <xxx@ofcourseimright.com>
From: "service@paypal.ch" <service@paypal.ch>
X-Email-Type-Id: PP120
X-XPT-XSL-Name: email_pimp/CH/en_US/xclick/ReceiptXClickPayment.xsl
Content-Type: multipart/alternative;
  boundary=--NextPart_048F8BC8A2197DE2036A
MIME-Version: 1.0

A few things to note: first, there my own mailer adds an Authentication-Results header, and in this case you see dkim=pass. It’s done that by looking at the DKIM-Signature header to determine if Paypal really did send the email. This is a strong authoritative check. Knowing that PayPal does this makes me feel comfortable to discard just about any email from paypal.com that lacks this header. Also, this email was addressed to the correct address (I’m not actually showing the address that I use). Not every site uses dkim and that’s a pity. One has to know in advance when to expect dkim=pass and one has to look at the headers to check.

Just by comparing email headers we can see that this is a poor forgery. And yet it takes time and effort for people to determine just that. And this is the risk that we consumers face. If one decides that any email one wasn’t expecting from PayPal is in fact a forgery, then should someone break into one’s account, one may not notice that there is a problem.

Summarizing, here are the things that I’ve done to limit the chances of something bad happening:

I use a single email address for PayPal that forgers are unlikely to know about.
I look for the Authentication-Results header.
Even if I think this is an authentic email, I will not click on links, but instead go to PayPal.com.

But it’s not all that easy for me. It certainly isn’t easy for those who haven’t been paying attention to all of this stuff as part of their job.

Today, the Internet Engineering Task Force begins its 72nd in person meeting. The IETF as it is known is a standards organization that primarily focuses on, well, the Internet. The work done in this body has included Multimedia Internet Mail Extensions, Internet Calendaring, Voice over IP, and many others. Not all work done by the IETF has worked out. An effort I worked on some time ago weeded out the stuff that either was never used or is no longer used. One of the key areas that any standards organization struggles with is how much potentially useful stuff to let through versus sure bets. Sure bets are those things where a necessary improvement or change is obvious to a casual observer. The people who make those changes are not the ones with imagination.

It’s the people who use their imaginations who make the bucks. Always has been. The problem is that there are a lot of people who may have good imaginations, but are unable to convert a good idea into something that can be broadly adopted. This is a problem for a standards organization because each standard takes time and effort to develop, and each failed standard diminishes confidence in the organization’s overall ability to produce good stuff.

On the whole the IETF has done demonstrably well, as demonstrated by the vast amount of money organizations have poured into personal attendance at the in person conferences, even though no attendance is required to participate.

This summer’s conference is being held in Dublin City West at a golf resort, a bit away from the major attractions. There are two benefit of this: first the cost isn’t absolutely outrageous. Second, if people know they the attractions are a bit far off, then fewer tourists will come. I actually don’t mind the idea of an IETF in Buffalo in the winter, but I may be taking things a bit too far.

Among the many discussions that will take place at this conference include one about what to do about email whose domain cannot be ascertained to have authorized its release. The standard in question that identifies email is called Domain Keys Identified Mail (DKIM), and is relatively new. What to do, however, when DKIM is not employed or if the signature sent is broken in some way? This is the province of a work called Author Domain Sender Policies (ADSP). The specification provides a means for sending domains to communicate their intentions. After a year of arguments we hope to have a standard. Whether it proves useful or not will only be shown by the test of time.

Tag: DKIM

Paypal follow-up

Off to Dublin (well sort of)!