Within just a few days, the German EU Representation warns people about phishing emails.1 This is the 4th warning regarding data theft since July 20202 by Reinhard Hönighaus, press spokesman and head of the press and media office. Obviously there is an urgent need for action.
In his current warning dated 26.11.2020, only two days after the previous one, he identifies T-Online users as targeted by phishing mails and also provides the explanation:
Like some other providers, the recipient infrastructure behind @t-online.de does not perform SPF checks.
This is not surprising that mass hosters configure their mail servers laxly. Ultimately, even the digitally inexperienced should be able to receive e-mails in uncharted territory, in “Neuland” we used to say here in Germany.
Sender Policy Framework3 is a security feature and must be configured by mail server operators. However, it is not a miracle cure by itself. Only a combination with further security features standardised in RFCs such as DMARC4, MTA-STS5, TLS-RPT6 or DANE7 prevents phishing mails. Looking at the mail server behind the email address of Reinhard Hönighaus, I start to wonder: Who is really the one to blame here?
Let’s just skip the crude construction of the mail cluster of ec.europa.eu, where not hostnames of the same name are used like mail.europa.eu but instead servers like mxa-00244802.gslb.pphosted.com. At first glance there is no obvious connection to Europe. If the DNS wouldn’t tell me any better, I’d consider the host as spam slingshot. In reality it’s the domain of the US company Proofpoint, which sells email security. Well let’s also have both eyes closed regarding the TLS configuration errors the Hardenize scanners see: No Forward Secrecy, TLS 1.0/1.1 and SSL3. At least for some servers identified by the scanner in the EU mailcluster. From the outside it is impossible to tell which one without further tests.
Apropos Scanner: The well-known SSL-Labs online test tool is actively blocked. Transparency is different.
However, the most serious problem is the faulty DMARC policy in the DNS in _dmarc.ec.europa.eu
_dmarc.ec.europa.eu. 900 TXT v=DMARC1; p=none; rua=mailto:email@example.com; fo=s; adkim=s; aspf=s; sp=none
Formally and syntactically correct, effectively completely meaningless if not set to “reject”. Every mail server receiving an email with a fake europa.eu sender may recognise it as a phishing email correctly, but because of this DMARC entry it will still forward it.
The misconfiguration on the EU side makes phishing in fact possible.
Reinhard Hönighaus was obviously poorly or not entirely informed by his IT department. At least in a statement of the article sent to him in advance he replies:
My IT colleagues are indeed taking the incident as an opportunity to review our DMARC policy and develop it further if necessary. (…) It was important to me that T-Online customers are warned. I am not blaming anyone, I just note that I am currently receiving calls from T-Online users every minute.
In a joint phone conversation he mentioned a figure of over 9,000 from mostly T-Online users. In the meantime, the T-Online portal is specifically addressing T-Online customers.8 This fiasco could have been avoided for the involved ones and for himself with properly configured servers and some expertise. We will see if and how this will be addressed in the future.
But another consideration is still haunting me: Why is it quite normal for the actors to disclose personal data and economic figures for Corona Aid in non encrypted form? Looking at the contact page9 of the German EU Representation, I do not see any confidential and encrypted communication channel via PGP or S/MIME email.