Unwitting Mules and Computers

Scales of Justice When I first traveled through Switzerland some 16 years ago, I went to France for the day, leaving from Geneva. On entering France, the guards saw a long, curly haired, American in a rental car, and they assumed I would be carrying drugs, so they took apart the car. I didn’t mind it until it occurred to me that perhaps the last guy who rented might have left something behind. Fortunately, none of that happened.

Last year, I attended one of my favorite conferences, the Workshop on the Economics of Information Security (WEIS08). I met there a number of good folk from the law enforcement community, and some talked about some of their successful investigations into crime on the computer. In one case, the investigators found megabytes of illicit material on someone’s hard drive. An astute and bright man from Microsoft by the name of Stuart Schechter pointedly asked the question how the investigators knew that the owner of the PC had stored the illicit material. The implication here would be that bad guys could be using the computer without the knowledge of its owner. The detective answered that such evidence is only one component used to charge and/or convict someone.

Now comes a case reported by AP in neighboring Massachusetts where this scenario has been brought to the fore. Michael Fiola, an employee of the state government, was fired, arrested, and shunned because some criminal broke into his computer.

What are the lessons to be learned? There is this common notion by many that end users aren’t generally the victims of the people who break into their computers. Not so in this case. There is also a belief that faith in government prosecutors alone will get an innocent person out of trouble. Not so in this case. They did eventually drop the charges, but only at the cost of his entire savings, large amounts of stress, etc.

This is not the only such case in which this has happened. So, do you know what’s on your computer? Are you sure?

Does Facebook Getting Money from a Spammer help?

As many will have seen, Facebook won a court judgment today for $711 million from well-known spammer Sanford Wallace. It’s always nice when a spammer gets told “stop that”, but as bad as some people might think Wallace is, he is a walk in the park compared to the real villains out there. They are faceless, nameless, thugs who want to steal your money, your identity, and whatever else they think they can take from you and your family. They have no scruples and cannot be easily traced. The occasional bust makes the news across the world, which is one way of knowing that these miscreants are hard to find. The other way is that your mailbox is still collecting spam, some of it dangerous.

Ole asks a great question

[not unusual for Ole, by the way.]

Why does security have to be so complicated?

Now knowing Ole as I do, this is of course rhetorical, but it does remind me of two conversations I’ve had. One was a long time ago. A friend of mine was part of a cable start-up team. Some of you will know who this was. He showed up at a conference with his big financial backer, and then told me, “Eliot, I’ve created the perfect parental control system.”

My response was simply, “Are you now – are you now or have you ever a child?” Nearly any child who is motivated enough will get around just about any parental block. Kids are smart.

The same is largely true with security. A former boss of mine once put it succinctly, that it’s either sex or money that motivate people, and that bad guys tend to use the former to get the latter. A great example are the miscreants who give away free porn by typing in CAPTCHA text, so they can get around some site’s security. I think it’s a little more than just those two motivations, but the point is that computers didn’t create crime. Crime has existed since Eve gave Adam the apple. The FaceBook scam occurs every day in the physical world without computers when eldery are taken advantage of in person. Computers simply provide a new attack vector for the same types of crimes.

Bad guys are as smart as good guys, but their best is probably no better than our best.

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:

Return-Path: <paypal@service.com>
Received: from mail.realinterface.com (mail.cecreal.com [66.101.212.157])
	by upstairs.ofcourseimright.com with ESMTP id n9GAJ9h3022332
	for <lear@ofcourseimright.com>; Fri, 16 Oct 2009 12:19:31 +0200
Received: from dynamic.casa1-15-233-12-196.wanamaroc.com ([196.12.233.14]) by
         mail.realinterface.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Fri, 16 Oct 2009 06:32:45 -0400
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>
X-OriginalArrivalTime: 16 Oct 2009 10:32:45.0859 (UTC) FILETIME=[00099730:01CA4E4C]

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.

Financial Institutions and Passwords

You would think that financial institutions would want individuals to choose really strong passwords that are difficult to guess. But in at least one very big case, you would be wrong. What makes a strong password? Several things:

A lot of characters. The more the merrier. The only limitation on this is that you have to remember All of That.
A lot of randomness. That is, words in a dictionary are bad, because attackers will often go through dictionaries to attempt to guess passwords.
Characters that are not letters or numbers. This increases the search space, given a certain sized password.

Now let’s review the actual guidance given by a very popular broker:

Your new password must:

Include 6-8 characters AND numbers

Include at least one number BETWEEN the first and last characters

Contain no symbols (!,%,# etc.)

Cannot match or be a subset of your Login ID

Examples of valid passwords: kev6in, 2be111, wil1iam

In other words, they’re violating two very big rules. The 6-8 character rule means that they are limiting the search space, and people cannot put together phrases, which are actually easier to remember than passwords. Removal of symbols from the search space makes it easier for attackers to perform a dictionary attack.

This site is not alone. Many sites have the same problem, and it is likely a problem with what their security professionals think is the industry standard. Well it’s a bad standard. Who takes on the risk? In the brokerage world, the chances are that you are assuming at least some risk.