Craig Hays wrote a fascinating article describing a phishing campaign his company had to deal with that had an ingenious method of propagating itself.
As we dug deeper and compared sign-in timestamps with email timestamps, it became clear what was happening. The phishing emails were being sent as replies to genuine emails. Emails exchanged between our people and our suppliers, our customers, and even internally between colleagues.
A typical phishing email comes from an email address you’ve never seen before. Granted, it might be similar to a real address you’d expect to see such as rnicrosoft.com instead of microsoft.com, but it’s rare for an address you trust to send you anything suspicious. When someone you know does send you something suspicious it’s usually rather obvious. When it happens we contact them directly to let them know there’s a problem. ‘Looks like you’ve been hacked, mate.’ We don’t fall for the scam.
In this attack, however, all of the phishing links were sent as replies to emails in the compromised account’s mailbox. This gave every email an inherited sense of trust. ‘You asked for this thing, here it is: link to phishing page’. When I realised what was happening, I was in awe. Whether done by deliberate design or not, the outcome was incredible. The conversion rates one these emails would make even the greatest of email marketers envious!
Unfortunately, this is likely to prove a bit more challenging than HTTPS Everywhere because of issues with STARTTLS,
Although many mailservers enable STARTTLS, most still do not validate certificates. Without certificate validation, an active attacker on the network can read and even modify emails sent through your supposedly “secure” connection. Since it’s not common practice to validate certificates, there’s often little incentive to present valid certificates in the first place. A brief experiment on Censys shows that about half of the mailservers that support STARTTLS use self-signed certificates.
. . .
When two mailservers support STARTTLS, their insecure connection is opportunistically upgraded to a secure one. In order to make that upgrade, the two mailservers ask each other if they support STARTTLS. Since this initial negotiation is unencrypted, network attackers can alter these messages to make it seem like neither server supports STARTTLS, causing any emails to be sent unencrypted. ISPs in the U.S. and abroad have been caught doing exactly this, and in 2014, several researchers found that encryption on outbound email from several countries were being regularly stripped.
But you have to start somewhere, and the EFF should be commended for going beyond simply issuing policy prescriptions and recommendations, and doing a lot of the heavy lifting to improve end user security.
InboxIt – Share to Mail is an app for Android designed to improve how Android handles sharing links via email, primarily for emailing links to yourself that you want to read later.
There is no need to type your email address, email title or body. InboxIt with a ‘single click’.
In addition, InboxIt grabs website’s image and description for nicer and more readable emails, no more clicking on emails to figure what article this is, images & videos are also supported (up to 25mb).
The premium 99 cent version will also automatically add a +keyword label for sharing to Gmail addresses, which makes it easier to sort these “read later” emails from other emails.
I have a variety of ways to track stuff I want to read later, and tend to email myself links that I need to follow-up on in the near future. InboxIt just makes those emails all the more useful.
Every so often on Twitter, a silly mantra goes around: it’s borderline insane to run your own email server. As Daniel Miessler sums up the case against running your own email server,
Email is complex. It’s hard to secure. Unless you’re the end-all, be-all of email administration, you’re likely to do a far worse job at it than Google, Yahoo!, Comcast, or whoever provides you the service today.
At the time Miessler wrote his response to this argument in 2016, he indicated that he no longer ran his own mail server but had done so for four very good reasons.
- It’s hard.
- You’re now running an internet-accessible service.
- You have more control.
- You have more privacy.
I still run my own email server largely for all of these reasons.
I do have to emphasize the first point, however. Running an email server correctly and securely is hard. Even if you have a good deal of technical skills, you are likely to completely f— something up at least once.
On the other hand, I have occasionally had to talk to people at different companies about configuring email in production systems, and while I did not have the same level of knowledge as the folks working in email every day, my experiences did enable to discuss these issues intelligently.
I ran into a ton of problems recently trying to configure SSL on my server’s Exim/Dovecot services.
To solve them, I relied on the excellent CheckTLS.com to give me detailed information about how my server’s security was failing. I probably wouldn’t have been able to troubleshoot my particular problems without this.
In my case, it turned out to be problems with the intermediate certificate. I tried a number of ways to fix this before stumbling upon an answer that I never would have guessed. I kept grabbing the intermediate certificate from my CA, but no matter what I tried it would not authenticate.
I was able to get it to work, however, by copying the content of the CA cert into the exim.cert file using:
$ echo '' >> /etc/exim.cert
$ cat /etc/exim.cacert >> /etc/exim.cert