Every five years or so, I think it’s time to review my e-mail flow. (Oh no!) I run my own mail server, and you should too, but this means that I get to figure out managing and searching and archiving and indexing it all by myself. (Yippee!)
And I’ll be honest — sometimes I’m a bit of a luddite. I actually, literally have been using Mutt, or its derivative NeoMutt for maybe fifteen years, after a decade or so of mouse-intensive graphical mail readers. If e-mail is about typing words, and maybe attaching the occasional image, nothing beats a straight-up text interface. But what a lot of these simple mail clients lack is good search. So I decided to take that seriously.
Notmuch is essentially an e-mail database. It’s an e-mail searcher, tagger, and indexer, but it’s not much else. The nice thing is that it’s brutally fast. Searches and extraction of tagged subsets are faster than sending the same data back and forth to the Big G, and I have a ton more flexibility. It’s awesome. Of course good ol’ Mutt can work with Notmuch. Everything can. It’s Linux/UNIX. Continue reading “Wreck Your Mail Before You Check Your Mail”→
All of us have seen our share of phishing emails, but there are a lot more that get caught by secure email gateways and client filters. Threat actors are constantly coming up with new ways to get past these virtual gatekeepers. [BleepingComputer] investigated a new phishing attack that used some old tricks by hiding the malicious script tags as morse code.
The phishing attack targets Microsoft account login credentials with an HTML page posing as an Excel invoice. When opened, it asks the user to re-enter their credentials before viewing the document. Some external scripts are required to render the fake invoice and login window but would be detected if the links were included normally. Instead, the actor encoded the script links using dots and dashes, for example, “.-” equals “a”. A simple function (creatively named “decodeMorse”) is used to decode and inject the scripts when it runs in the victim’s browser.
Despite the popularity of social media, for communication that actually matters, e-mail reigns supreme. Crucial to the smooth operation of businesses worldwide, it’s prized for its reliability. Google is one of the world’s largest e-mail providers, both with its consumer-targeted Gmail product as well as G Suite for business customers [Jeffrey Paul] is a user of the latter, and was surprised to find that URLs in incoming emails were being modified by the service when fetched via the Internet Message Access Protocol (IMAP) used by external email readers.
This change appears to make it impossible for IMAP users to see the original email without logging into the web interface, it breaks verification of the cryptographic signatures, and it came as a surprise.
For a subset of users, it appears Google is modifying URLs in the body of emails to instead go through their own link-checking and redirect service. This involves actually editing the body of the email before it reaches the user. This means that even those using external clients to fetch email over IMAP are affected, with no way to access the original raw email they were sent.
The security implications are serious enough that many doubted the initial story, suspecting that the editing was only happening within the Gmail app or through the web client. However, a source claiming to work for Google confirmed that the new feature is being rolled out to G Suite customers, and can be switched off if so desired. Reaching out to Google for comment, we were directed to their help page on the topic.
The stated aim is to prevent phishing, with Google’s redirect service including a link checker to warn users who are traveling to potentially dangerous sites. For many though, this explanation doesn’t pass muster. Forcing users to head to a Google server to view the original URL they were sent is to many an egregious breach of privacy, and a security concern to boot. It allows the search giant to further extend its tendrils of click tracking into even private email conversations. For some, the implications are worse. Cryptographically signed messages, such as those using PGP or GPG, are broken by the tool; as the content of the email body is modified in the process, the message no longer checks out with respect to the original signature. Of course, this is the value of signing your messages — it becomes much easier to detect such alterations between what was sent and what was received.
Understandably, many were up in arms that the company would implement such a measure with no consultation or warning ahead of time. The content of an email is sacrosanct, in many respects, and tampering with it in any form will always be condemned by the security conscious. If the feature is a choice for the user, and can be turned off at will, then it’s a useful tool for those that want it. But this discovery was a surprise to many, making it hard to believe it was adequately disclosed before roll-out. The question unfolded in the FAQ screenshot above hints at this being part of Google’s A/B test and not applied to all accounts. Features being tested on your email account should be disclosed yet they are not.
Protecting innocent users against phishing attacks is a laudable aim, and we can imagine many business owners enabling such a feature to avoid phishing attacks. It’s another case where privacy is willingly traded for the idea of security. While the uproar is limited due to the specific nature of the implementation thus far, we would expect further desertion of Google’s email services by the tech savvy if such practices were to spread to the mainstream Gmail product. Regardless of what happens next, it’s important to remember that the email you read may not be the one you were sent, and act accordingly.
Update 30/10/2020: It has since come to light that for G Suite users with Advanced Protection enabled, it may not be possible to disable this feature at all.
There have been many news stories lately about companies misusing your data, including your e-mails. What’s more, these giant repositories of data are favorite targets for hackers. Even if you trust the big corporations, you are also betting on their security. Criptext claims they have (possibly) the most private e-mail service ever. It uses the open Signal protocol and stores private keys and encrypted mail only on your device. All the applications to access your mail are open source, so presumably, someone would eventually spot any backdoors or open holes.
At the moment the service is free and the company reports that even when a paid offering is ready, there will still be a free tier. Of course, you can send and receive normal e-mail, too. You can also use a passphrase you send to someone else (presumably not by e-mail) so they can read an encrypted message.
From the gaping maw of the infosec Twitterverse comes horrifying news. PGP is broken. How? We don’t know. When will there be any information on this vulnerability? Tomorrow. It’s the most important infosec story of the week, and it’s only Monday. Of course, this vulnerability already has a name. Everyone else is calling it eFail, but I’m calling it Fear, Uncertainty, and Doubt.
Update 2: The report mentions two attacks. The Direct Exfiltration attack wraps the body of a PGP-encrypted email around an image tag. If a mail client automatically decrypts this email, the result will be a request to a URL containing the plaintext of the encrypted email. The second attack only works one-third of the time. Mitigation strategies are to not decrypt email in a client, disable HTML rendering, and in time, update the OpenPGP and S/MIME standards. This is not the end of PGP, it’s a vulnerability warranting attention from those with a very specific use case.
[Sebastian Schinzel] announced on Twitter today he will be announcing a critical vulnerability in PGP/GPG and S/MIME email encryption. This vulnerability may reveal the plaintext of encrypted emails. There are currently no fixes — but there’s no proof of concept, or any actual publication of this exploit either. The only thing that’s certain: somebody on Twitter said encrypted email is broken.
The EFF has chimed in on this exploit and advises everyone to immediately disable and uninstall tools that automatically decrypt PGP-encrypted email. It also looks like the EFF came up with a great little logo for eFail as well so kudos on that.
While there are no details whatsoever concerning eFail aside from a recommendation to not use PGP, a few members of the community have seen a pre-press of the eFail paper. [Werner Koch] of GnuPG says eFail is simply using HTML as a back channel. If this is true, PGP is still safe; you just shouldn’t use HTML emails. If you really need to read HTML emails, use a proper MIME parser and disallow access to external links. It should be noted that HTML in email is already an attack vector and has been for decades. You don’t need to bring PGP into this.
Should you worry about a vulnerability in PGP and email encryption? Literally no one knows. European security researchers are working on a publication release right now, but other experts in the field who have seen the paper think it’s not a big deal. There is no consensus from experts in the field, and there is no paper available right now. That last point will change in a few hours, but for now eFail just stands for Fear, Uncertainty, and Doubt.
My son approached me the other day with his best 17-year-old sales pitch: “Dad, I need a bucket of cash!” Given that I was elbow deep in suds doing the dishes he neglected to do the night before, I mentioned that it was a singularly bad time for him to ask for anything.
Never one to be dissuaded, he plunged ahead with the reason for the funding request. He had stumbled upon a series of YouTube videos about paramotoring, and it was love at first sight for him. He waxed eloquent about how cool it would be to strap a big fan to his back and soar with the birds on a nylon parasail wing. It was actually a pretty good pitch, complete with an exposition on the father-son bonding opportunities paramotoring presented. He kind of reminded me of the twelve-year-old version of myself trying to convince my dad to spend $600 on something called a “TRS-80” that I’d surely perish if I didn’t get.
Needless to say, the $2500 he needed for the opportunity to break his neck was not forthcoming. But what happened the next day kind of blew my mind. As I was reviewing my YouTube feed, there among the [Abom79] and [AvE] videos I normally find in my “Recommended” queue was a video about – paramotoring. Now how did that get there?
If you’re waiting for a much sought-after letter, checking your mailbox every five minutes can be a roller-coaster of emotion — not to mention time-consuming. If you fall into this trap, Hackaday.io user [CuriosityGym] as whipped up a mailbox that will send off an email once the snail-mail arrives.
The project uses an Arduino Uno, an ESP 8266 wifi module, and an idIoTware shield board — making specific use of its RGB LED and light dependent resistor(LDR). Configuring the RGB LED on the idIoTware board to a steady white light sets the baseline for the LDR, and when a letter is dropped in the box, the change in brightness is registered by the LDR, triggering the Arduino to send off the email.