TED Talk: Trolling a Spammer

Back in the early days of spam, I did try replying to a few, but I never got anything like this.

Suspicious emails: unclaimed insurance bonds, diamond-encrusted safe deposit boxes, close friends marooned in a foreign country. They pop up in our inboxes, and standard procedure is to delete on sight. But what happens when you reply? Follow along as writer and comedian James Veitch narrates a hilarious, weeks-long exchange with a spammer who offered to cut him in on a hot deal.

Phishing

Over a month ago, I received a creative phishing attempt. We use a relatively popular service which is mimicked fairly well. I typically receive notification emails from it by an administrative assistant. This came from another name. That was my only real clue that made me look closer. Since, I have received almost a dozen, each pretending to be a different product.

I noticed they all used different domain names for the payload link. But, they all use file.php?d=<value> or f.php?d=<value> to deliver the payload.

Computers are smarter than I am when it comes to patterns like this, so I created an email filter to look for the file names and set it loose. If I see another phishing attempt using another script name, then I will add it to the list. But, so far, I am pleased with how well it protects me from myself.

LastPass feature request

Ghost in the Shell Laughing Man shirt
Ghost in the Shell Laughing Man shirt

There is no enforced standard for passwords for a web site, so they can be all over the place for requirements. Nor do sites typically explain what are the exact standards before a failure. And then most will state the minimum and types of characters. But, too many leave out the maximum number of characters allowed so I end up experimenting to figure out something as strong as I can get. One of my favorite blogs is Password Requirements Shaming.

Web sites almost certainly record the password to a variable. Hopefully they then encrypt it and store the hash instead of recording the password as plain text. I use LastPass’ password generator to create something typically 40 characters [1] long and try it. Almost always that results in an error that my password is too long and the limit is actually something shorter. There are some frustrations with how sites handle these cases:

  1. It would be nice if more sites would look at the passwords with JavaScript and report if it is too long or too short or have bad characters or do not match both locations. Very rarely do they check that it is too long. Most just check that they match. Letting me know before I submit it, keeps me from wasting my time.
  2. In HTML, maxlength defines how many characters the input element will accept. I sometimes look at the HTML to select what password length to generate, but there is no guarantee that the maxlength is reflective of what will work. It fails to help so much I have gotten out of the habit.

Arbitrariness with password policies probably makes people tend to more insecure practices through simplification. This is The Paradox of Choice.

It occurred to me that LastPass developers could solve this problem for me. If LastPass knew the password requirements for a site, then it could preset the generator to the maximum length that will fit. When I go to create a password for a site, then it could work the first time instead of taking 2-5 tries to find something that finally works. Most users are lazy and would not change the preset, so passwords would tend to be the stronger. [2]

Admittedly, it usually works on the second try once I’ve nailed down the maximum number of characters allowed.

[1] Originally I would try 50 characters, but I eventually relaxed that down a bit. Occasionally, I go through brief periods where I just try 30 or 32.

[2] See Nudge: Improving Decisions About Health, Wealth, and Happiness for how organ donation rates work for how t his would work.

Email Changes

Ran across a site where if one changes the email address associated with the account, it sends the confirmation email to the new address.

Say, I am a Blackhat and used a phishing attack to get the password for the account. Having legitimately logged in, I then change the email address associated with it from victim@outlook.com to my blackhatalias@gmail.com. Sending the confirmation to blackhatalias rather than the victim ensures a compromised account will get altered. Strong security would want to prevent the change unless the owner of victim@outlook.com confirms the change.

Though, it does look like an email was sent to victim@outlook.com almost 3 hours after the confirmation saying:

Still scary. The blackhat has probably already made off with the data and done the damage.

I get the temptation to allow users to change their email address to a new one. It will prevent support phone calls because if they no longer have control of the old email account, users can simply change it to another address they do.

Of course, the site in question also does not have Two Factor Authentication. But, then it also is just a support forum. So, the ramifications of losing the account is impersonation at worst. They could ask or answer a question as me or change the profile to say something demeaning.

Verification Codes

One would hope that verification codes would be extremely random. More randomness makes it harder for a malicious entity (person or computer) to guess the code. Less randomness makes it easier. With all the Two-Factor Authentication (2FA) out there, we hope there is enough randomness in these methods to make them unguessable by someone attempting to get into our accounts. But, like all security technology, the hackers get better and protections get easier to break over time.

There is a current temptation to record the codes my generators provide to see if there is a pattern. At least in the back of my head it “feels” like there might be one. My intuitions sometimes turn out true (confirmation bias) and usually do not (reality). If little ole me can see the pattern, then I am sure smarter people than I have seen it as well and maybe even have a way to anticipate the codes.

Scary Password Policy

Doing a training thing for work next week. The training coordinator sent an email to 25 of us about how to access the learning portal. The username is email and password is a single word with an exclamation point. My first instinct was get in ASAP and change the password since so many other people have access to my password.

Only.

There is no link. I click and click and clink. I cannot find it.

Finally, I look at the source code and notice features in it that reveal this portal is running on WordPress. So, I added “wp-admin/profile.php” to the URL and get a 404. I added it to the domain and bingo, I was at my own profile. So, I used the WordPress password feature to generate a strong password and change it.

I wonder how many people have taken training from these people and bothered to change the password?

Phishy Corporate Communications

Received an email that looked phishy:

Greetings,

Please read this important e-mail carefully.

Recently you registered, transferred or modified the contact information for the following domain name:

ezrasf.com

In order to ensure your domain name remain active, you must now click the following link and follow the instructions provided.

http://verify.domain.com/registrant/?verification_id=999999&key=BFrrpxGDbb&rid=999999

Sincerely,

Domain Registrar

The web page listed my name and email address, so the riskiness of clicking it seemed low, but ALL KLAXONS were going off in my head about this being phishing. I also received another email threatening to suspend my domain if I did verify it.

The email headers really confirmed for me this was phishing:

Received: from mx.registrarmail.net (mx.registrarmail.net [216.40.35.248])
	by myemail-mx26.g.emailprovider.com (Postfix) with ESMTP id 999AA999999DDD
	for <myemail@mydomain.com>; Mon, 28 Mar 2016 05:43:25 -0700 (PDT)
Received: from cron01.endurance.prod.tucows.net (unknown [64.99.53.70])
	by mx1.registrarmail.net (Postfix) with SMTP id B5999999E51
	for <myemail@mydomain.com>; Mon, 28 Mar 2016 12:43:24 +0000 (UTC)
Received: by cron01.endurance.prod.tucows.net (sSMTP sendmail emulation); Mon, 28 Mar 2016 08:43:24 -0400
X-MP-Host-Origin: front04.endurance.prod.tucows.net
Message-Id: <999999.0.28Mar2016084324-osrs-registrant_verification-999999@endurance.registrarmail.net>
Date: Mon, 28 Mar 2016 08:43:24 -0400 (EDT)
X-OSRS-Id: osrs-registrant_verification-999999
From: "Domain Registrar" <support@registrar.com>
To: <myemail@mydomain.com>
Subject: Important: Please validate your domain name

The original sender is tucows.net? There’s no way a real company would be using such a site to send these emails. After all, that’s some lonely script kiddie in their mom’s basement BS. This had to be phishing.

One last check. I did a dig on verify.domain.com and compare that to the www for the company. Two very different IP spaces, but crucially the nameservers have “dyn” in the name which red flagged that it was one of those dynamic DNS services so it could be anything anywhere. Definitely not legitimate.

So I go to the registrar’s site to report this phishing and look at my domain’s record to see if anything really had changed. It had not, but I noticed there was a phone number I’ve not used since 2003, so I update the record. There is a notice that they need me to verify the information. I go looking for it and see… another copy of the phishing email at the time I updated the record. At this point, I suspect maybe I am completely wrong. Since the risk seems low, I do click the link and verify button and go back to the registrar’s site to see if the warning about needing to verify my information cleared. It did. Dammit!

Turns out the phishy email is actually ICANN not the registrar.

Posting To Your WP From Foreign Sites

(This assumes a WordPress.org site not one on Wordress.com hosting.)

Placing your username and password in the database of third party sites is not very good. If the account provided is the WordPress administrator account, then that means credentials for the most important account are potentially exposed. The password is going to be kept in the clear or in a form decryption is easy so it can be used to post to WordPress.

Better instead is to create a limited user with the Author role for this purpose. These accounts are so easy to create that I make one for every site I use to post to this blog. If any of these sites are hacked or the credentials otherwise given to others, then the potential damage is just the posts belonging to that user.

One stumbling block for this is WordPress.org installs want a unique email address for each account. A workaround I use is either generating email accounts via my hosting provider or the +anything for Gmail.

Also, it makes easy identifying the posts which came from the foreign source. My Goodreads posts are an example where that site is setup to post for an account I specially created for that purpose.

Phish-ish Legit Email

Part of the problem of getting people not to succumb to phishing attempts is the poor practices used in legitimate emails.

Google sent me an email saying something was going to expire in a month because of inactivity. I needed to click on a link and verify my information. You know, exactly the same kind of things a phisher would wrote.

I spent half an hour looking at the HTML to verify the links and the headers to see if there was anything suspicious. Eventually, I decided it was legitimate. But even then I was still very careful. Few people I know would be this careful because they would not know how.

Sadly, in the many years where phishing attempts have become so common, few people care enough about changing their bad email practices that contribute to end users becoming victims.