Unfortunately, Google’s infrastructure has grown so big and fast that there are a few Google properties that aren’t signed by DKIM yet. There are also some Google applications whose email components are outsourced to other companies, like SalesForce, who in turn send mail claiming to come from Google that, of course, isn’t signed. And in some cases, mail that goes between two Google services and is then forwarded to other addresses goes out unsigned.

This means it’s impossible to apply these implicit DKIM rules across the board to keep these scams at bay before they can get started: If we turn them on for everything, some legitimate mail will be bounced, or some mail that deserves preferential treatment won’t get it.

We know about these limitations of DKIM already. And we know it’s a challenge for any large organization to ensure that any new email policy (or any kind of policy, really) is applied across its entire infrastructure when parts of it operate independently. In the end, though, it means the full benefits of DKIM can’t be realized when the roll-out is only partial. Google has told us they’re aware of these issues and they’re working to tighten it all up.

This is important to remember for all sites, whether deploying DKIM as a signer or as a verifier. When we wrote the DKIM RFCs, we included a lot of discussion about these topics, and experience since then has shown that this was time well-spent.

The text in each fraudulent SMS appears as if it is coming from a major bank or credit card company such as the ones seen recently with Wells Fargo and Visa. The cyber criminals, also known as Phishers, are sending texts with messages such as those below.

When an unwitting recipient calls the number, they are asked for their name, bank card number, account number, expiration date, security/pin code and/or address – all the data the criminals need to gain access to their credit card or bank account. The Phishers become the suppliers of financial institution credentials and sell this data to another element of the cyber fraud chain called Cashers. The same methodology used in email fraud scams can now be leveraged in mobile fraud scams.

The Cashers main role is to take the phished credentials and obtain funds directly from the victims’ accounts. Cashers can leverage the acquired data to create an actual replica of a victim’s bank card simply by using a card reader / writer similar to the one below.

There are varying degrees of difficulty in cashing out certain credentials. For banking credentials, the preferred, though more difficult, method, is ATM fraud. In ATM fraud, the Casher actually encodes the banking information (tracking) onto an ATM card and withdraws the maximum daily funds. The main difficulty with tracking is the encoding of the bank data to the ATM card. The preferred hardware used to encode information onto magnetic stripe cards is the MSR–206. Although the MSR–206 hardware most preferred by Cashers can be easily obtained, each bank uses a specific encoding algorithm to translate the credentials into the encoded data written to an ATM card. The tracking algorithm may be as simple as appending the expiration date and cvv2 code along with a fixed numeric value to the end of a check card number, or as complex as encrypting the information with a secret key and then encoding the encrypted block to the card.

See more details on the economy of phishing at http://www.cloudmark.com/en/whitepapers/the-economy-of-phishing.
It is imperative for consumers to take appropriate steps if they believe they have received unsolicited SMS messages. This will help minimize their exposure to risk and fraud.

• a new working group that will produce protocols and advice documents relevant to reputation services (see my previous posts about DKIM and domain reputation);
• creation of a working group seeking advancement of SPF to the standards track; and
• a working group to develop and standardize a more useful replacement to the only-somewhat-useful WHOIS service.

There’s already active interest in all three of these areas.

We’re also championing the work of some best practices documents covering things like greylisting and handling of malformed mail, both with input from the Messaging Anti-Abuse Working Group.

And we’re keeping an eye on developments in the web and IPv6 communities within IETF, with an eye towards how those changes will affect messaging security.

For more information, contact us through your representatives, or find us through the various IETF mailing lists dedicated to those purposes.

The next meeting is at the end of March in Paris. We’ll be there!

It was explained that in the recent past a couple of US senators have had to arrange sudden press conferences to spread the word that, contrary to what’s been said in email, they are not dead. Apparently there had been forged email campaigns making such claims, causing some amount of chaos, and they needed to be dispelled. The FBI, IRS, and the House domains have also been the target of forged email or phishing campaigns.

Cloudmark was invited to present the perspective of industry to the audience of mainly CIO-level representatives from various branches of the federal government. We highlighted not only the importance of deploying email authentication technologies like SPF and DKIM and why they’re great, but also why they’re not enough. Domain reputation, the obvious next step along the path to securing email, became the focus. Some good questions were asked about the viability and vulnerability of such systems when they’re based on user feedback. Fortunately, we have a lot of good experience in that area from our commercial product and open source history, which supported the discussion.

We’re encouraged to see that the federal government has taken such an interest in these issues. We presented some ideas of how they can help with respect to deploying policy and services from their side of the fence, and we’re looking forward to making progress with them.

This email is NOT from PayPal.  It’s from a spammer, who wants you to go to your browser and open the “AccountValidation.html” page that he or she has attached.

Why should you immediately be suspicious of this email?

• Be suspicious if the “From” address is not paypal.com.
• Also, be suspicious if they don’t use your real name.  If they say “Dear Valued Member” instead of addressing it to your first and last name, it is very likely to be fraud.
  • Unfortunately, the opposite is not true.  Spammers have ways of getting both your real name and your email address.  For instance, sometimes they hack into an unrelated system, that has less security than PayPal, that also stores your name and email address.   So just because they use your real name, does not mean you should automatically trust them.
• Always be suspicious of downloading attachments.  PayPal, your bank and your other accounts are never going to send you an attachment to download and run.

What should you do when you get an email like this?

If you get an email about your Paypal account and you think there might be a real issue with your account then:

• Do not download any attachments.  The attachments may contain a virus or a redirect to a fraudulent site. Or they may contain a fake account verification page, as this email does.
• Avoid clicking on any links in the email, as the links may take you to a fraudulent site.
• Instead, go to your browser and type in the url: www.paypal.com
  • If you do have a legitimate issue, Paypal will inform you when you login.
• Never reply to an email with your username, password or credit card number.  Legitimate sites will never ask you for your password or credit card number via email.

More details about how to avoid PayPal scams can be found on the PayPal site.  Click on “Security and Protection” and hit the “Explore Topics” button. https://cms.paypal.com/us/cgi-bin/?cmd=_render-content&content_ID=security/phishing

What will happen if you open AccountValidation.html in your browser?

You should avoid opening attachments that you suspect are from spammers, as they may contain viruses which can infect your computer.

In this particular case, the AccountValidation.html page is a phishing page.  Phishing is when a spammer pretends to be a legitimate institution such as PayPal, in order to trick you into giving away your personal information.

If you were to open this page in your browser, then in this case you would see the page below.

The page is asking for all your personal information including your credit card number.  Remember, this “AccountValidation.html” page is not from PayPal.  The spammer wants it to look like it is from PayPal, so that you’ll be tricked into giving away your personal information.  It even pulls many of the images on the page from PayPal servers.

However it was sent by a spammer.  If you were to fill in the information and push the “Save Profile”, then the page would send all the data that you entered to an IP address of a computer in the Ukraine.

What do legitimate emails from PayPal look like?

Below is another example of a PayPal email.  This one is legitimate (with the name and email address changed to protect the real recipient).  Sometimes it’s challenging to tell that a legitimate email is actually legitimate.  But when you’re in doubt, you can always type the url www.paypal.com into your browser, and login directly.  When you login to www.paypal.com, PayPal will let you know when there is something you need to deal with.

As I blogged back in April, the industry has been working on an Internet standard called DKIM, or DomainKeys Identified Mail, which is a young but promising email security technology. This past week the IETF approved publication of a revised version of the DKIM specification, with Cloudmark as a co-editor. This is a significant milestone in that DKIM is now recognized as having proven itself and thus has reached a elevated maturity level (“Draft Standard”). We anticipate this will encourage development of new systems that can capitalize on DKIM to improve the email experience as DKIM gains wider acceptance and deployment.

Cloudmark is also spearheading the effort to create a new working group within the IETF to develop new protocols that enable reputation services, not only for reputations about domain names, but anything about which you might want to ask for a rating. The interest in the idea within industry is clearly visible, and the discussion should be lively. We’re already looking at ways to capitalize on the data we collect on an ongoing basis to participate actively in this evolution.

We’re directly involved in a working group that talks about standardizing feedback loops (FBLs). These are automated streams of data from users directly to service providers about messages they receive that are abusive, enabling those service providers to respond more quickly. (When you click “Report Spam”, you’re putting data into an FBL.) Cloudmark uses FBLs to collect spam reports and thus keep our system’s accuracy at the top of its class. This work is also branching out into the mobile world, where we’ve been making quite a splash lately.

We’ve started work on a best practices document that’s intended to get all vendors to converge on how they interpret certain malformations in the mail stream. That some components differ in how they handle these various cases can enable certain attacks, and we’re doing this work to try to close those gaps so that this class of attack is harder or impossible to mount in the future. There’s some interest in branching this work in to a similar document that covers the behaviour of web browsers.

Cloudmark has also been approached by people inside ICANN (the Internet Corporation for Assigned Names and Numbers) to work on a revised specification for WHOIS, the perennial tool for looking up registrants of domain names and network blocks. Very early conversations within the IETF about what such a revised system should look like are already taking place. We’re interested in the success of this because a reliable WHOIS system would go a long way to identifying bad actors long before they ever get near your inbox. We’re already involved at the ground level.

We monitor the people that are doing work on internationalizing email addresses. Not only are email systems going to have to cope with the added complexity of supporting these, but we need to think ahead to how bad actors will try to exploit these changes to try to get into your inbox, and plan accordingly.

And we’re keeping a very close eye on developments within the IPv6 working groups. As you’ve undoubtedly heard by now, IPv6 is being slowly deployed at all major service providers. Since a lot of your perimeter security in messaging is based on IP addresses, it’s important that those systems either transition smoothly into the world of IPv6 or are replaced with something that’s as good or better. There’s considerable debate about the efficacy of one of these rollout tools (“6to4”), and we’re watching to see how it plays out.

Those are just the highlights. There are many more working groups doing interesting things in and around messaging. It’s going to be a busy and exciting week as we get some hints from all of this of what the future of messaging might look like. Come back to the blog in early August to find out!

The landing pages themselves all attempt to look like real Canadian government web pages, including versions of the page in both French and English (see below). Many of the links on the landing pages lead to real Canadian government pages, including “Contact Us” and “Help”, but the “English” and “French” buttons, as well as the script that submits the form, lead back to the compromised, phishy servers. The form itself is quite simple, asking for a name, “Social Insurance” number, date of birth, and “Refund Amount”.

Canadian Revenue Agency Phishing Site (French)

Canadian Revenue Agency Phishing Site (English)

You can protect yourself from scams of this type by paying close attention to the emails you receive and the links on which you click. It’s likely, because of the way this email was encoded, that accented characters are appearing as blank squares or black diamonds with question marks – a legitimate email is more likely to have properly encoded characters. Additionally, hovering your mouse over the link in the “call to action” should (in most mail programs and web browsers) show you the target of the link. If the target differs from what you would expect, take great care in clicking on it. If you’re being asked for personal information, it might be time for an ‘out of band’ contact – call a known phone number, or use a trusted search engine to find a contact number to make sure you should give out that information.

As always, do not click on these links and input your account credentials. If you have any concerns whether your account has been compromised, please contact your bank via the telephone number listed on your bank statement or in person.

Emails with the subject “You are in a higher tax bracket”, from “Tax Commisar”, have been making the rounds for the last 20 hours or so. After reminding you that the US uses a progressive income tax, you’re told that you’re making more money than last year, and that you should review your annual tax report. The included link takes you to a double threat – the page itself tells you that you need a new Flash player, and it will attempt to automatically download (and run) a PDF file. The “Flash updater” is an installer for the Zeus bot, and the PDF file takes advantages of some known vulnerabilities in unpatched Adobe Acrobat versions to take control of your machine if the Flash updater doesn’t get it first.

Make sure you’ve grabbed the last Acrobat updates from Adobe, along with all of the other security patches that you should be keeping on top of. Malefactors have been using Acrobat as an abuse vector for a while, and it’s just getting worse.