Sendgrid, Mailgun et all: SPAM providers

Last month I got an email from OTTO.de asking me to attend a survey about customer satisfaction and the like. Bad for them: I use mutt and therefore it is obvious if an email is fake. So, what did OTTO.de do? They gave my email address (and I suspect those of all other customers) to an external "reasearch" company. This company then sent the email using the mail service of another company. All of this happened without my consent.

Now, the good news is, that OTTO.de responded quickly to my complaint and ordered both companies to delete my email address, however I cannot be sure if they actually DID delete it though. The other good news is that I create always an email address for every shop, forum or any other login site I use. That way, I can just drop "burned" email addresses and stop using the single service for which I created it.

But most peope do not operate their own mail server and create an alias for every site they use. For such peope a "burned" email address is a disaster. By "burned" I mean the email address is out of your control, you don't know who's using it anymore, you start to receive SPAM to this address. But if this is the only email address you possess and if you use it for everything, you're fucked. Changing an all-purpose email address, deposited on dozens or even hundreds of sites, is a nightmare.

I have this problem at work. One of our vendors, an israeli company, sends us notifications by email. At work I only have one email
address, it's associated with my name and I cannot change it. The israeli company sends those notifications by using the services of a company called Sendgrid. Now, sendgrid not only knows my name, my location, my employer, they also know what kind of job I have and that our company uses the services of this israeli company.

I never allowed them to do this. And I cannot change this, it already happened. My work email address is burned and I have to continue using it. This is more than annoying.

Much more annoying is the fact, that people using such services don't even think about it. I complained with the israeli company and they did not understand my problem at all. It was as if I am from mars trying to communicate with people from venus. They even nonchalantly closed the case.

What I tried to say to them was that Sendgrid is a SPAM sending service. And it is a US company, operating in a country with almost no privacy protection laws. They didn't get it. I suspect, young people don't even understand what SPAM is these days, I don't know.

The other day I stumbled upon the story about the operatos of vDOS, a DDoS service. It was a criminal enterprise and they used a mail sending service as well: Mailgun. Mailgun does the same as Sendgrid. It's a SPAM sender company. In order to understand the
nature of their business, look at the numbers:

Sending 5.000.000 emails costs 0.00015 Dollars.

How do they make profit, you ask? Well, look at this, which can be found in a job description:

We have a passion for solving hard problems – our services are
responsible for processing billions of messages each month and have to
not only scale, but be highly reliable.

I don't know who else needs to send such impossible amounts of emails than SPAMmers. And if all of their customers operate like OTTO.de or the mentioned israeli company, almost nobody agreed to this.

An email you receive from a sender you don't know, you don't have any relationship with, you don't do business with - is SPAM. Period.

The only difference to past times is that operating an email sending venture was an illegal operation while today it is perfectly okay for all parties, including their victims.

I've got to admit they are clearly geniuses. Converting a foul smelling "business" into something you get venture capital for, create APIs, get praised by managers AND developers is a coup I need to salute for.

But how much all those hipsters, ruby-on-rail-loosers and java-scriptsters love services like Mailgun or Sendgrid: what they do stinks, it violates peoples privacy without asking (and I didn't even talk about their tracing features!) and in the end burns peoples 
productive email addresses.

I can't even imagine how such a company can be a legal business. This is incomprehensible.



Update 2016-10-02:

And yet another one:

[..]
Received: from m69-130.mailgun.net (m69-130.mailgun.net [166.78.69.130])
From: noreply@shop.drak.de
[..]

This time, DRAK an aquaristic vendor, uses Mailgun, to send unsolicited SPAM mails to me In this case as well I didn’t give my consent. In the case of DRAK, even their TOS claims that they’d not do such things (that is, give customer data to a third party without consent).<p>Update 2016-09-16:</p>Here’s another example:

[..]
Received: from mailer212.agnitas.de (mailer212.agnitas.de [87.119.210.180])
From: voelkner - direkt günstiger <info@reply.voelkner.de> 
[..]

Agnitas.de, yet another SPAM sending venture, sends mails in the name of Voelkner (also known as fake mails) to me. So, Voelkner gave them my email address without my consent. </p><p> What the fuck?!

11 September 2016 | #unfassbar

 

Hamburger Buns

Ich habe gestern diese Hamburger Brioche Buns hergestellt. Zur Abwechslung habe ich mich präzise an das Rezept gehalten, keine anderen Mehlsorten, kein LM usw. Einzige Änderung: Teig nach Bertinet bearbeitet und nicht geknetet. Und was soll ich sagen: Die Brötchen waren der Hammer und die Hamburger sensationell.

Wir haben gefressen. Alter war das geil.

Bilder:

2016-09-04 - Sowas von!:

2016-09-04 - Profi-Patties: Rindsgulasch fein, Rinderfilet und Entrecote grob, 2 Finger dick Schweineschwarte, Salz, Pfeffer, bischen Semmel mit Milch, wenig Ei: Boah ey!:

2016-09-04 - Wie vorhergesagt erfüllen die Brötchen alle Anforderungen an ein Hamburgerbrötchen. Top! Übrigens erkennt man an der nicht ganz so regelmäßigen Porung die andere Teigbearbeitungsmethode.:

2016-09-04 - Die Brötchen. Guck Dir das mal an!:

04 September 2016 | #kochen

 

Mamelade!

Das erste Mal im Leben hab ich Marmelade gemacht: Pflaumenmuß und Holundermarmelade.  Mit Rezepten aus dem 19ten Jahrhundert. Und die Sachen sind wirklich lecker. Nur ein bischen viel ist es geworden.

Bilder:

2016-08-28 - Holunderbeeren: 4 Stunden Arbeit für diese Schüssel:

2016-08-28 - Ein bischen Kompott ging auch noch:

2016-08-28 - 38 Gläser Pflaumenmuß, haha!:

2016-08-28 - Aber: 18 Gläser Marmelade waren es wert:

2016-08-28 - Pflaumen in rauen Mengen:

28 August 2016 | #kochen

 

Fahrradtour am Main

Ich war mal wieder in Frankfurt und habe mir diesmal die Zeit mit einer schönen Fahrradtour vertrieben:

 

25 August 2016 | #draussengewesen

 

How to backdoor store-and-forward public key crypto?

So, the german and french government want to break cryptography. Now they "only" want to be able to decrypt messaging apps. If they get their law - and since there's not much sanity left in the corrupt EU this will likely happen - what will be next?

I think store and forward crypto systems are the first to come into mind, that is: PGP. Happily I am the maintainer of some nice but working play store and forward crypto software: PCP. Of course it is not PGP but uses comparable features. So, after reading the news the other day I thought to myself:

How would I implement such a backdoor in PCP, if I had to?

As it turned out the answer is hillariously simple! PCP, as GNUPG, supports encrypting data for multiple recipients. Therefore the task is easy: create a "government key pair", hardcode its public key into the encryption code and encrypt everything for this recipient as well.

Here's the backdoor patch.

The patch includes the "government's" secret key. Here's how to use it:

  1. Compile the patched pcp source as usual, install the binary as pcp1-backdoored or something like that.
  2. Create a test user on your system, say "spook".
  3. As user "spook" import said secret key, the import passphrase is "gov".
  4. As another user on the same system export your public key.
  5. Import that key as user "spook".
  6. Now as the regular user, encrypt some file asymmetrically for someone else (e.g. import one of the public key files in the tests/ directory of the source code) using the backdoored binary.
  7. As user "spook" decrypt the encrypted file as if you'd be the intended recipient.
  8. Et voilá.

Demo:

[24.Aug 17:09:05] --- [~] ---
tom@vm: % src/pcp1 -V spiedsender.vault -l
Key ID               Type             Creation Time        Owner
0x5C77C305F0BF8333   primary secret   2016-08-24T15:13:02  Freddy Victim <victim@gmail.foo>
0x616BDDA58845987B   valid public     2015-04-17T17:08:19  Bobby <bobby@local>

[24.Aug 17:15:29] --- [~] ---
tom@vm: % src/pcp1 -V backdoor.vault -l
Key ID               Type             Creation Time        Owner
0xF93E7016447D28CC   primary secret   2016-08-24T14:54:28  The Government <spooks@the.gov>
0x5C77C305F0BF8333   valid public     2016-08-24T15:13:02  Freddy Victim <victim@gmail.foo>

[24.Aug 17:15:43] --- [~] ---
tom@vm: % echo "for bobbys eyes only" | src/pcp1 -V spiedsender.vault -i 0x616BDDA58845987B -e -O encrypted-for-bobby.asc
Enter passphrase to decrypt your secret key: 
Encrypted 242 bytes for:
  0x616BDDA58845987B - Bobby <bobby@local>

[24.Aug 17:16:14] --- [~] ---
tom@vm: % src/pcp1 -V backdoor.vault -I encrypted-for-bobby.asc -d
Enter passphrase to decrypt your secret key: 
for bobbys eyes only
Decrypted 21 bytes successfully

There you go. Freddy Victim encrypted some message for Bobby, but the "government" could read it anyway, it only had to import Bobby's public key (which is the difference to PGP, but it's public and much easier to retrieve).

Also note that the "government" just uses regular PCP features, it doesn't even need to use a patched binary, the vanilla one would do. That's because the backdoor is not really a cryptographic backdoor (which is, as many cryptographers already said, impossible). Instead it just adds another recipient. The result looks pretty normal to the uninitiated, just some encrypted file decryptable by two recipients instead only one.

So, as you can see, it couldn't be easier to implement this backdoor. I could even commit this code to Github and I'm pretty sure, no one would take notice (and of course in that case I'd obfuscate it a little to disguise a casual reader). Also, the government could distribute the patched binary. That'd be pretty easy as well, since almost all Open Source systems use binary packaging.

Finally, one question remains though:

How could I determine of an encrypted file has a "hidden" recipient?

I'm not sure. In the case of PCP, I added a debug print statement to the decryption code (git commit) which tells the number of recipients during decryption if -v have been supplied on the command line. Maybe GPG already includes such a function. But of course this could be easily patched away by a backdoored version. So to check if an encrypted file contains more recipients than expected you'd need to check out the source code, compile it manually and then do the checks.

Yes, evil and scary stuff. But as the README of PCP says loud and clearly: Do not use PCP for anything productive or important. However, for real live public key crypto systems the scheme to add a government recipient to all encrypted data could be a realistic possiblity.

 

24 August 2016 | #source