Spoofing e-mails from BE government domains

After reading about some journalists discovering how easy it is to spoof mail addresses of certain positions within the Dutch government, I decided to check what the situation was in Belgium.

Spoofing a mail address is a technique/prank as old as the internet itself  – the most popular mail protocol (SMTP) offers no form of authentication/verification – but in the recent years, crowdsourced spam filters, heuristic techniques and a couple of additional easy-implementable technologies (SPF & DKIM) made it harder to craft a spoofed e-mail that actually makes it to the target’s inbox, instead of being tossed into a junk folder by mainstream e-mail clients.

I wondered if I could craft an e-mail that would make it straight to the inbox of various mail providers that I could test / agreed to test with me (Gmail, Telenet and a couple of mailboxes at the VRT).

Ideally, we want our crafted e-mail to have the following properties:

  • No valid SPF records for the domain to be spoofed / No DKIM verification active
    • The following domains didn’t have valid SPF records (in the beginning of October 2017): fed.be, fgov.be, dekamer.be, vlaamsparlement.be (possibly more, but I only tested these)
    • Some good online SPF record testers can be found here and here.
  • Mail headers correctly formed and up to spec
  • No obvious red flags in headers (localhost / known spam server IP’s)
  • Sent from a server that uses some form of TLS
  • Offered again after a set timeout if receiving server greylists you because there is no SPF record. This is a feature that a lot of SMTP servers have by default, because spammers often don’t wait for a retry – not worth it when you’re spamming millions of mail addresses a day.

In order to send the spoofed mails reported in the media (news articles: link, link) today, I performed the following relatively easy steps:

Order a cheap VPS with a valid IPv4 and IPv6 IP in a non-blacklisted range (any of the popular low-cost VPS providers will do: Digitalocean, Vultr, Linode, … See LowEndBox for listings.) and install any flavor of Linux (using Ubuntu 16.10 in this example). Install and configure postfix and associated mail utilities.

sudo apt-get install mailutils

Select “Internet Site” in the dpkg-configure wizard when configuring the postfix package. Register a domain name at a free dns provider (like afraid.org) and use it as the FQDN for your mailserver. Postfix will run an SMTP server on port 25, wide open to the internet.

In order to avoid getting turned into a spamhost yourself, configure postfix to only accept connections from your local network. Avoid using names like “localhost” when configuring outbound properties, this is often a red flag for spam detection systems. A good postfix config guide is this one.

Next, generate keys and a certificate for outbound TLS connections (info from Ubuntu Wiki):

touch smtpd.key
chmod 600 smtpd.key
openssl genrsa 1024 > smtpd.key
openssl req -new -key smtpd.key -x509 -days 3650 -out smtpd.crt # has prompts
openssl req -new -x509 -extensions v3_ca -keyout cakey.pem -out cacert.pem -days 3650 # has prompts
sudo mv smtpd.key /etc/ssl/private/
sudo mv smtpd.crt /etc/ssl/certs/
sudo mv cakey.pem /etc/ssl/private/
sudo mv cacert.pem /etc/ssl/certs/

And configure postfix to use them:

sudo postconf -e 'smtp_tls_security_level = may'
sudo postconf -e 'smtpd_tls_security_level = may'
sudo postconf -e 'smtpd_tls_auth_only = no'
sudo postconf -e 'smtp_tls_note_starttls_offer = yes'
sudo postconf -e 'smtpd_tls_key_file = /etc/ssl/private/smtpd.key'
sudo postconf -e 'smtpd_tls_cert_file = /etc/ssl/certs/smtpd.crt'
sudo postconf -e 'smtpd_tls_CAfile = /etc/ssl/certs/cacert.pem'
sudo postconf -e 'smtpd_tls_loglevel = 1'
sudo postconf -e 'smtpd_tls_received_header = yes'
sudo postconf -e 'smtpd_tls_session_cache_timeout = 3600s'
sudo postconf -e 'tls_random_source = dev:/dev/urandom'
sudo postconf -e 'myhostname = server1.example.com' # remember to change this to yours

Restart postfix. Now, you should be able to ssh into your server, then telnet into the SMTP server on port 25 and craft an e-mail using the known techniques.

jeroen@REDACTED:~$ telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 dystopia ESMTP Postfix (Ubuntu)
helo REDACTED
250 REDACTED
MAIL FROM:[email protected]
250 2.1.0 Ok
RCPT TO:[email protected]
250 2.1.5 Ok
data
354 End data with .
Subject: Your subject line
From: Charles Michel <[email protected]>
To: Target Name <[email protected]>
Msg content here
.
250 2.0.0 Ok: queued as 823AB120424

You can monitor /var/log/mail.log for message delivery.

If you see this message, a server is greylisting you. Postfix will retry until the message passes:

Oct 26 03:50:08 dystopia postfix/smtp[11076]: 787E01204AD: to=, relay=mailrelay2.cs.kuleuven.be[134.58.40.2]:25, delay=73, delays=70/0.02/3/0.1, dsn=4.7.1, deferred (host mailrelay2.cs.kuleuven.be[134.58.40.2] said: 451 4.7.1 Greylisting in action, please come back in 00:01:59 (in reply to RCPT TO command))
Oct 26 03:56:15 dystopia postfix/qmgr[11038]: 787E01204AD: from=<[email protected]>, size=438, nrcpt=1 (queue active)
Oct 26 03:56:17 dystopia postfix/smtp[11092]: 787E01204AD: to=, relay=mailrelay.cs.kuleuven.be[134.58.40.3]:25, delay=442, delays=441/0.03/1.2/0.05, dsn=2.0tus=sent (250 2.0.0 v9Q7uF9i005698 Message accepted for delivery)

If you try to spoof a domain that has valid SPF records (eg [email protected]), you will get a message that your host is not allowed to send mail for that domain, and the message was dropped.

This is a mail header from an example spoof e-mail: as you can see, since there’s no SPF record for fed.be, the recommendation is “neutral”, so the mail gets through. I’ve tried this with @gmail.com, @vrt.be, @outlook.com, @kuleuven.be and @telenet.be target mailboxes. In all instances, the spoofed e-mail made it straight to the inbox.

ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=date:message-id:to:from:subject:arc-authentication-results;
        bh=j4Xj2A+qhvxCjKTWuH/iEuxGtomqvlQIyfOST1UF3do=;
        b=TaafLrcxQWgzifntUI56A7nXENWiM677HcH3ABZO/RyAXUN3ZfqsSkHLXKFY50sZFs
         50mY6BRoWX1M73Q0R94nCkEsErSEP9YeluGfqbm+32t8EC+eNq/PBqhmEj9fYBoleGQa
         ftoaTtUqhxG9dAbzZUWzMrJJD6OYjME3b18TioxtBA/nH+gAcN5q14ZJp72ahGMKrI1W
         +mH+UAA6wyd3lLIs3cP8xT3rzY+emasFlms6pcowwlMdoHBPDV6dg6krOd9ef2hYvbpZ
         X/I9jvxMtPqqAJh+VXnlTfzcI5Ts/XaVc+rjL1+PCaRhx6uwx2LmDkaukjTQbvBCPrAX
         3smw==
ARC-Authentication-Results: i=1; mx.google.com;
       spf=neutral (google.com: 178.62.9.153 is neither permitted nor denied by best guess record for domain of [email protected]) [email protected]

The whole point of this test was not to claim that e-mail spoofing is a new and hyperdangerous technique, but to point out that even the most basic form of protection was not configured on several key government domains. The issue has been reported and is hopefully (being) fixed.