News items for tag security - Koos van den Hout

Met zo'n onderwerpregel voor een e-mail bericht weet ik al zeker dat het een fraude poging is, maar het bleek dit keer een van de beruchte bitcoin afpersingspogingen te zijn. De tekst is weer behoorlijk goed nederlands:

Hallo! Helaas heb ik slecht nieuws voor je. Enkele maanden geleden heb ik toegang gekregen tot de apparaten waarmee je op het internet surft. Vervolgens heb ik je internetactiviteiten nagetrokken. Hieronder volgt een overzicht van de gebeurtenissen die hiertoe hebben geleid: Eerst heb ik van hackers toegang gekocht tot talrijke e-mail accounts (tegenwoordig is dat een heel simpele klus die gewoon online kan worden gedaan). Zonder enige moeite heb ik vervolgens kunnen inloggen op jouw e-mail account (xxxx @ yyyyyyy). Een week later heb ik het voor elkaar gekregen een Trojaans virus te installeren op besturingssystemen van al je apparaten die voor e-mail toegang gebruikt worden. Eigenlijk was dat heel eenvoudig (want je klikte op de links in je inbox emails).

En zo nog een heleboel tekst verder, maar het belangrijke deel:

Schrijf 1750€ naar mijn rekening (bitcoin equivalent op basis van de wisselkoers tijdens je overschrijving) over

Hieronder staat mijn Bitcoin wallet: 1HvuQda3pzxyCnTJVpb1TpADMF2s3GB6g6 Je krijgt precies 48 uur de tijd nadat je deze e-mail geopend hebt (2 dagen om precies te zijn).

Bitcoin wallet 1HvuQda3pzxyCnTJVpb1TpADMF2s3GB6g6 was al bekend bij bitcoinabuse en heeft zo te zien helaas al een bedrag ontvangen in de buurt van 1750 euro.

Trap hier niet in, het is echt complete onzin wat er beweerd wordt en alleen maar een manier om geld afhandig te maken. Lees ook: Ik word per mail gechanteerd - Fraudehelpdesk.nl

This morning I had DMARC reports in my mail from xs4all. With all the testing of DMARC, DKIM and SPF I did yesterday I was confused for a while what caused this since my domain names shouldn't be linked to xs4all anymore in any way.

First I thought one of the DMARC testing autoresponders I tried was linked to xs4all or maybe somehow my domains still show some link to xs4all, but after a while it dawned on me that all the testing of DKIM was done via a forward that is still active on my now closed xs4all account.

My DMARC record currently says I want reports of problems, so I am getting those. Anyway, I guess it's all working and I'm seeing no new problems.

Oh and outlook[.]com is still rejecting my e-mail so no progress there. But then again Microsoft and not handling Internet e-mail standards correctly was something I ranted about before: 17 and a half years ago. Not a lot of improvement.

In debugging mail from the shell server I noticed something in the headers:

Authentication-Results: xs4all.nl; spf=none smtp.mailfrom=gosper.idefix.net;
        dkim=pass header.d=idefix.net; dmarc=pass header.from=idefix.net

The shell server sees itself as gosper.idefix.net and uses this on locally generated outgoing mail. I only had an SPF record for idefix.net so setting one up for gosper.idefix.net too can help fix things. I also need a DMARC policy allowing mail from subdomains of idefix.net, with more specific DMARC policies for active subdomains.

After getting DKIM signing running with sendmail and opendkim I generated DKIM keys for idefix.net, configured them in the mailserver with opendkim and published them in DNS. The next thing to publish is a policy record showing that all outgoing mail for these domains should be signed.

I started with a policy that shows mail should be signed but to not reject it when it isn't, but report it to me as unsigned.

;; QUESTION SECTION:
;_dmarc.camp-wireless.com.      IN      TXT

;; ANSWER SECTION:
_dmarc.camp-wireless.com. 86400 IN      TXT     "v=DMARC1;p=none;sp=reject;pct=100;rua=mailto:dmarcreports at camp-wireless.com;"

With a similar policy for idefix.net. Mail with problems shouldn't be rejected yet: DNS propagation isn't instantaneous and testing first.

My recent issues with getting my e-mail delivered made me look at DKIM signing of outgoing e-mail messages. To not break things I have started testing this with outgoing e-mail from camp-wireless.com which normally publishes it doesn't send mail at all, so the first steps were to change that policy: changing the MX record and SPF record.

I started reading into configuring sendmail with dkim and found OpenDKIM which can work as a sendmail milter.

Based on How to configure DKIM & SPF & DMARC on Sendmail for multiple domains on CentOS 7 I took the same steps for my Devuan installation.

In Devuan (and probably Debian/Ubuntu) there is a opendkim package for the service and a opendkim-tools package for the associated tools. I needed the second one to get the opendkim-genkey command. I can imagine keys being generated/managed on a different system than the actual signing server.

After configuring this for camp-wireless.com including generating a keypair and publishing the public key via DNS I started sending test messages but had no luck. It turned out the sending host has to be in the InternalHosts table of opendkim. I added the address ranges and after that things started to work.

After fixing that I got the results I wanted:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=camp-wireless.com;
        s=gosper; t=1637408594;
        bh=YewDlohOT9RvALNQw4cVukwSpmAm5tXtGWJxLDUJZa4=;
        h=To:From:Subject:Date:From;
        b=GGMEeCY5xmgFDBQ5NzgZfAVvyr+ctBKOTGpwMqq1W/tgJYMY8WyzaM5XfEiWijGKr
        abBN5WLbiyoXsd62lNVxcDOBUYWzkOnwZCw5WgdlzZJSIxgRdnWMQLxL1E9BJdudwR
        zriX1/vAaR34RFM1kiSVp0dqa98/Kxfdp2DPPRDsAVJ6sdxqz1YHD4odveDcLEQQZv
        jUMNPVmQps90mZORtdKtOOWQP0RYkZvmjNsJZuwIrRkFvUzOmAVT6MDDf4kZ35lbes
        oAp0me8tQgoffNLRQpO7akSKhbh1Kn5fAv50WILhM0rK/ChkWqvOrcfgIwbSSPduzM
        DI1w23jCnwaKQ==

And a verification:

Authentication-Results: xs4all.nl; spf=pass smtp.mailfrom=camp-wireless.com;
dkim=pass header.d=camp-wireless.com

I was wondering about roaming users who authenticate to my mailserver and send messages that way. In a first test those messages get signed too. That means I can start signing mail from idefix.net and other production domain names!

I was working on a new site for a project and requested a certificate for it. The time between the certificate being generated and the first attack was 3 minutes and 7 seconds.

15:12:10 UTC: certificate generated and published on the certificate transparancy log

15:15:17 UTC:
185.67.34.1 - - [19/Nov/2021:16:15:17 +0100] "GET /restapi.php HTTP/1.1" 404 1008 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:84.0) Gecko/20100101 Firefox/84.0"
15:15:18 UTC:
185.67.34.1 - - [19/Nov/2021:16:15:18 +0100] "POST /gate.php HTTP/1.1" 404 1008 "-" "Dalvik/2.1.0 (Linux; U; Android 6.0.1; SM-J700F Build/MMB29K)"

Someone mailed me a few days ago with an interesting question. So I typed a reasonably long answer. But upon sending this answer I received the following error message:

   ----- The following addresses had permanent fatal errors -----
<????????@outlook.com>
    (reason: 550 5.7.1 Unfortunately, messages from [45.83.232.134] weren't sent. Please contact your Internet se...ail.live.com/mail/troubleshooting.aspx#errors. [HE1EUR04FT003.eop-eur04.prod.protection.outlook.com])

   ----- Transcript of session follows -----
... while talking to outlook-com.olc.protection.outlook.com.:
>>> MAIL From:<?????? .at. idefix.net> SIZE=4837 BODY=8BITMIME
<<< 550 5.7.1 Unfortunately, messages from [45.83.232.134] weren't sent. Please contact your Internet service provider since part of their network is on our block list (S3150). You can also refer your provider to http://mail.live.com/mail/troubleshooting.aspx#errors. [HE1EUR04FT003.eop-eur04.prod.protection.outlook.com]
554 5.0.0 Service unavailable

Trying to get my IPv4 address allowed didn't work. The form for getting IP addresses whitelisted did not allow for IPv6 addresses, but then again outlook.com has no IPv6 addresses listed for its MX record. I would think microsoft would do something with IPv6 to support innovations in Internet but I guess they only do that to win contracts.

After a while I got a response with a ticket number and an hour later a response that looked like maybe a person had taken a look at it, with "Our investigation has determined that the above IP(s) do not qualify for mitigation." So that leaves me with possible mails from outlook[.]com that I can't answer, making me look bad because I don't seem to reply at all.

I'm convinced the mail setup is correct on my end. The domain idefix.net has an SPF record and the mail was sent out via the approved route.

The only solution I can think of at the moment is blocking mail from outlook.com at the protocol level with an error message pointing at a webpage what the problem is, so when someone sends an e-mail from outlook[.]com to one of my domains they will get an error message with an embedded hint what they should do, namely We cannot reply to your mail, please send us mail from a different domain, see https://idefix.net/mailreject.html for an explanation. About the same as microsoft does, although the careful reader might have noticed the error code S3150 is not mentioned at http://mail.live.com/mail/troubleshooting.aspx#errors.

Noticed this in the logs:

Sep 30 14:02:04 wozniak sendmail[25878]: STARTTLS=client, relay=postbode.idefix.net., version=TLSv1.3, verify=OK, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
Sep 30 15:02:04 wozniak sendmail[27149]: STARTTLS=client, relay=postbode.idefix.net., version=TLSv1.3, verify=OK, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
Sep 30 16:02:04 wozniak sendmail[28400]: STARTTLS=client, relay=postbode.idefix.net., version=TLSv1.3, verify=FAIL, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
Sep 30 17:02:04 wozniak sendmail[29654]: STARTTLS=client, relay=postbode.idefix.net., version=TLSv1.3, verify=FAIL, cipher=TLS_AES_256_GCM_SHA384, bits=256/256

This is exactly the expiry of the DST Root CA:

koos@wozniak:/usr/share/ca-certificates/mozilla$ openssl x509 -in DST_Root_CA_X3.crt -noout -startdate -enddate
notBefore=Sep 30 21:12:19 2000 GMT
notAfter=Sep 30 14:01:15 2021 GMT

But now to find out where this goes wrong...

Uit de inbox, weer een 'WoningNet' verhaal, zie ook Spam/phishing/fraude woningnet. Bekend natuurlijk al bij FraudeHelpdesk: Laatste Herinnering - Fraudehelpdesk.

   U heeft een inschrijving bij WoningNet.
   Over 2 weken verloopt uw inschrijving.
   Uw inschrijving verlengen wij met een jaar als u de verlenginskosten
   van €8,00
   betaalt.
   U kunt betalen via iDEAL.
   Via de onderstaande link word u automatisch doorverwezen naar onze
   betaalpagina

   Als u niet binnen 2 weken betaalt, schrijven wij u uit.
   Uw opgebouwde inschrijfduur en eventuele reacties komen dan te
   vervallen.

Het pad van URLs:

• hxxps://t9y.me/Q2Su
• hxxps://rplg.co/d9b377a0
• hxxps://lucid-wu.45-88-108-231.plesk.page/woningnet
• hxxps://lucid-wu.45-88-108-231.plesk.page/woningnet/
• Kies ING → hxxps://lucid-wu.45-88-108-231.plesk.page/ing/ En dan een volle phishing kit voor Mijn ING credentials.

De methode is al bekend (berucht) bij de fraudehelpdesk. Ook even getest met lucid-wu.45-88-108-231.plesk.page - urlscan.io en gemeld bij google safe browsing.

En dan

Take a second to rejoice merrily for doing your part in making the web a safer place.

I have a lot of control over the software that runs on systems at home but there are limits to what I can fix and sometimes things are insecure.

Things like the recent wordpress brute force attacks show that random 'loud' attackers who don't care about the chance of getting noticed will try. I sometimes do worry about the silent and more targeted attackers.

So recently I updated my home network and I now have a DMZ network. At this moment it is a purely virtual network as it doesn't leave the KVM server. Hosts in the DMZ have a default-deny firewall policy to the other inside networks. Specific services on specific hosts have been enabled.

I first moved the development webserver, which allowed me to tune those firewall rules and fix some other errors.

Now other webservers and other servers offering things to the outside world have moved.