How to Tell It Was Twitter Asking You to Change Your Password
Posted by admin on 02 Feb 2010 | Tagged as: Twitter, security, useful info
There’s been some meta-discussion around yesterday’s phishing attack on Twitter (of which I, and many others, were victims) regarding the unwisdom of clicking on an unsolicited password reset link in an email, but there are way to assure yourselves that such things are genuine.
Every email package I’ve encountered has a function to allow you to see the full headers of an email message; in Entourage on OS X, it’s the “View Headers” command in the “Message” menu. Taking a look at the message (which is identical, from all appearances, to the one Andrew Girdwood recieved) shows us the following; note the “Received” headers in particular:
Received: from unknown (HELO mail-front4.dca2.superb.net) (66.148.95.125)
by 66.148.95.31 with SMTP; 2 Feb 2010 05:21:20 -0000
Received: (qmail 84707 invoked from network); 2 Feb 2010 05:21:20 -0000
Received: from mx003.twitter.com (128.121.146.152)
by 66.148.95.78 with SMTP; 2 Feb 2010 05:21:20 -0000
Received: from twitter-web043 (web043.twitter.com [10.209.32.253])
by mx003.twitter.com (Postfix) with ESMTP id DF684587210
for
X-DKIM: Sendmail DKIM Filter v2.8.2 mx003.twitter.com DF684587210
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=twitter.com; s=dkim;
t=1265088079; i=@twitter.com; bh=ISzoeDqxeACoknd1YdcwEDZRDOA=;
h=Date:From:Reply-To:To:Message-Id:Subject:Mime-Version:
Content-Type;
b=QPpIZ0gV6a4WZPVALF+WWo3QVbr8HrfEVzCPg4AI9CTmULA9n7iLkNpTAfjxJdsvM
9ldsItg7386k4hf9b4aTiUYQwOf31EJM4jI5dvGG7S/f40lqgqdxIf4EkJ+wdov2Wb
8WTmKeuKm1P8AdZ8aE1WbceMpruk4B5BnGYNsi4M=
X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 mx003.twitter.com DF684587210
DomainKey-Signature: a=rsa-sha1; s=default; d=twitter.com; c=simple; q=dns;
b=3hurpIWY7RHpVLkpad1GNEuzZ8LftciXQP5+G6tQo3Yd5u0jLnFQjLn0TPcluhu9J
E3qz/hUWZWIfCXFgdzRGA==
Received: from twitter.com (localhost [127.0.0.1])
by twitter-web043 (Postfix) with ESMTP id D364EBAD19A
for
Every time an email message passes from one system to the next, a “Received” header is added; you read them from the top down to trace a message back to its origin. So, the first “Received” line, referencing Superb.net, my (excellent) hosting provider, as well as the second, is me picking up the message here are home, in essence. The next line is Superb.net receiving it from mx003.twitter.com, whose IP address is given as 128.121.146.152; we can check that.
Doing a reverse DNS lookup is easy: go to http://remote.12dt.com/, enter the address you’re interested in, and here’s what you get:

So, that address checks out fine. (The 10. address given later for the site web043.twitter.com isn’t useful: any IP address that starts with “10.” is a private one, for internal use, in this case within the twitter.com domain.
Note, if you’re especially paranoid, that the message has been signed with a “Domain Key”. This is a use of public-key-encryption to both sign and validate the contents of the messages, giving assurance as to its origin and that its contents haven’t been altered.
The “Received” headers are well-nigh impossible to forge, given that the path an email message traverses, up to and including my own computer, can’t all be under a “phisher”’s control. The fact that I was able to validate and verify addresses for the origination of the message gives me some level of certainty that it did, in this case, come from Twitter, and not from a phisher.
And yes, I did work in networking for a number of years.









