News items for tag security - Koos van den Hout

I'm personally not a huge fan of wildcard TLS certificates (risks with reuse of the private key) so I didn't try those yet, but based on my experiences with certificates with multiple names with zerossl I got a response: Stephen Harris on Twitter: Do they support wildcards and I just had to try. And it works! I requested a certificate:

        Requested Extensions:
            X509v3 Subject Alternative Name:
                DNS:gosper.idefix.net, DNS:*.gosper.idefix.net

And indeed it worked:

        Issuer: C = AT, O = ZeroSSL, CN = ZeroSSL ECC Domain Secure Site CA
        Validity
            Not Before: Sep  1 00:00:00 2021 GMT
            Not After : Nov 30 23:59:59 2021 GMT
        Subject: CN = gosper.idefix.net
[..]
            X509v3 Subject Alternative Name: 
                DNS:gosper.idefix.net, DNS:*.gosper.idefix.net

So that works too! The choice for gosper.idefix.net is because I already had dns records setup for dns-01 based verification of that name.

I assumed the free tier of zerossl doesn't allow for certificates with multiple names but I guess I assumed wrong, because I just got issued a certificate with multiple names.

After debugging my earlier issues with zerossl and finding out I forgot the CAA record this time I tried a certificate with the subjectAltName extension in use with more than one name.

$ openssl req -in httprenewable/webserver-devvirtualbookcase.csr -noout -text
[..]
        Attributes:
        Requested Extensions:
            X509v3 Subject Alternative Name:
                DNS:developer.virtualbookcase.com, DNS:perl.virtualbookcase.com

And the certificate dance went fine with dehydrated:

$ ./dehydrated/dehydrated --config /etc/dehydrated/config.zerossl -s httprenewable/webserver-devvirtualbookcase.csr > tmp/certificate.crt
 + Requesting new certificate order from CA...
 + Received 2 authorizations URLs from the CA
 + Handling authorization for developer.virtualbookcase.com
 + Handling authorization for perl.virtualbookcase.com
 + 2 pending challenge(s)
 + Deploying challenge tokens...
 + Responding to challenge for developer.virtualbookcase.com authorization...
 + Challenge is valid!
 + Responding to challenge for perl.virtualbookcase.com authorization...
 + Challenge is valid!
 + Cleaning challenge tokens...
 + Requesting certificate...
 + Order is processing...
 + Checking certificate...
 + Done!
$ openssl x509 -in tmp/certificate.crt -noout -text | less
[..]
            X509v3 Subject Alternative Name:
                DNS:developer.virtualbookcase.com, DNS:perl.virtualbookcase.com

The /etc/dehydrated/config.zerossl has the EAB_KID and EAB_HMAC_KEY values set to the ones associated with my account.

This means zerossl works as a complete secondary certificate issuer and I could switch over completely in case LetsEncrypt isn't available. Choice is good!

Based on the recent article Here's another free CA as an alternative to Let's Encrypt! I decided to check my options for having an alternative to LetsEncrypt.

Not because I have or had any problems with LetsEncrypt, but I like having a backup option. So I started with zerossl as option.

Sofar I did the whole registration and certificate request dance purely with the dehydrated client, but that gives an error on a certificate request:

 + Requesting new certificate order from CA...
 + Received 2 authorizations URLs from the CA
 + Handling authorization for developer.virtualbookcase.com
 + Handling authorization for perl.virtualbookcase.com
 + 2 pending challenge(s)
 + Deploying challenge tokens...
 + Responding to challenge for developer.virtualbookcase.com authorization...
 + Challenge is valid!
 + Responding to challenge for perl.virtualbookcase.com authorization...
 + Challenge is valid!
 + Cleaning challenge tokens...
 + Requesting certificate...
 + Order is processing...
ERROR: Order in status invalid

Creating a zerossl account with a webbrowser and setting the EAB_KID and EAB_HMAC_KEY to the values from my zerossl account also doesn't help, that also ends with

$ ./dehydrated/dehydrated --ca zerossl --config /etc/dehydrated/config.zerossl -s httprenewable/webserver-devvirtualbookcase.csr > tmp/certificate.crt
 + Requesting new certificate order from CA...
 + Received 2 authorizations URLs from the CA
 + Handling authorization for developer.virtualbookcase.com
 + Handling authorization for perl.virtualbookcase.com
 + 2 pending challenge(s)
 + Deploying challenge tokens...
 + Responding to challenge for developer.virtualbookcase.com authorization...
 + Challenge is valid!
 + Responding to challenge for perl.virtualbookcase.com authorization...
 + Challenge is valid!
 + Cleaning challenge tokens...
 + Requesting certificate...
 + Order is processing...
ERROR: Order in status invalid

I realized a certificate for multiple names isn't supported by the free tier of zerossl. Removing one of the names from the certificate still made it end up in status 'invalid'.

Also re-creating the account in dehydrated after creating the zerossl account and setting the EAB_KID and EAB_HMAC_KEY variables correctly didn't solve things yet. The same request works fine with LetsEncrypt so the issue is something with dehydrated / zerossl.

Update: Sharing my woes gave a suggestion: Stephen Harris on Twitter: "@khoos You have a CAA record for virtualbookcase.com that might be blocking it." / Twitter and Stephen is absolutely right: I set up CAA records ages ago for all my domains. And the zerossl CAA document I can find absolutely agrees I need to add a CAA record allowing certificates by sectigo.com.

Updated: And after waiting for DNS propagation and trying again I now have a zerossl.com certificate:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            4e:7b:c8:e9:ad:fd:14:ad:5c:ae:a2:57:fe:45:d9:41
        Signature Algorithm: ecdsa-with-SHA384
        Issuer: C = AT, O = ZeroSSL, CN = ZeroSSL ECC Domain Secure Site CA
        Validity
            Not Before: Aug 19 00:00:00 2021 GMT
            Not After : Nov 17 23:59:59 2021 GMT
        Subject: CN = perl.virtualbookcase.com

Yet another bitcoin extortion scammer, this time using address 1Gkg3g7GGbsKktkkbgKNfL6MMGZ1xCoGJC. The reports read like she/he has tried it in multiple languages. Until this moment no bitcoins have ended up with the scammer.

Earlier items about bitcoin extortion scams: Earlier, earlier, earlier, earlier, earlier, earlier (although I think bitcoin is generally a really bad idea and a huge scam)

Yesterday I switched to a different Internet provider and now the phishing trying to convince me I need to give my account details for the old account to avoid the account being closed is extra funny!

And although they all state they are the kzdoos.xs4all.nl webmail there is no such thing for the abusers to try any login credentials at.

I was digging for leaked addresses in my spambox and found a fast way to find a lot of them: by searching for bitcoin extortion spam. A pattern emerges:

Obviously, I have easily managed to log in to your email account (ambe.at. domain).
Obviously, I have easily managed to log in to your email account (chellinger.org.at. domain).
Obviously, I have easily managed to log in to your email account (eenheld.at. domain).
Obviously, I have easily managed to log in to your email account (owelladjecroecvn.at. domain).
Obviously, I have easily managed to log in to your email account (ubmitwolfn.at. domain).
Obviously, I have easily managed to log in to your email account (ubmitwolf.at. domain).
Obviously, I have easily managed to log in to your email account (ambecomment.at. domain).
Obviously, I have easily managed to log in to your email account (ziggo.nl.at. domain).
Obviously, I have easily managed to log in to your email account (wisecommunications.at. domain).

There is very little spread in buttcoin wallets:

$ grep -h 'bitcoin wallet' * | sort | uniq -c
      2 Here is my bitcoin wallet: 12kieSEdCV4ikxdXXXC23ZsDcNmmKrRmwA (over 16600 dollar received)
     19 Here is my bitcoin wallet: 1665CsfFELrfiiubFZtLsGHGuqbUz1wXcz (over 14300 dollar received)
      1 Here is my bitcoin wallet: 1CYBbByg3eXE9LRUwh6j7ZMtFrJJyFcAcP (over 2400 dollar received)
      3 Here is my bitcoin wallet: 1LjGz2WcECaNpK1ajWcpsPEQFSxrw5DxMM (over 14400 dollar received)

Who says crime doesn't pay? Again, the author has no idea who pays, but likes a filled bitcoin wallet.

This also shows that spammers maintain really old address lists and don't mind adding more addresses by using databreaches or adding or removing letters from e-mail addresses.

Time to do a zone signing key (ZSK) rollover. That rollover is relatively easy because I don't need to synchronize it with the DS key in the parent zone.

I generated a 'successor' key for camp-wireless.com and set a short-notice publication date. The old ZSK has keytag 02908 and the new one has keytag 25619. There is an overlap of a month in which both keys are seen as valid because caching of DNS answers mean there can be signatures created with the old ZSK in caches.

Generating a signed zone after the validity of the new ZSK has started shows both ZSKs signed as valid. Old and new zone signing key:

; This is a zone-signing key, keyid 2908, for camp-wireless.com.
; Created: 20190704113915 (Thu Jul  4 13:39:15 2019)
; Publish: 20190704113915 (Thu Jul  4 13:39:15 2019)
; Activate: 20190704113915 (Thu Jul  4 13:39:15 2019)
; Inactive: 20210705000000 (Mon Jul  5 02:00:00 2021)
; Delete: 20210805000000 (Thu Aug  5 02:00:00 2021)
camp-wireless.com. IN DNSKEY 256 3 13 lXntnbvQqHy+OSG/2RpHEbcYzeUAB2tFE+d5Us9M07Ndw7TI2DF2TIDx vC3bPomCE2102FJSr8/DnzoRiMHreg==
; This is a zone-signing key, keyid 25619, for camp-wireless.com.
; Created: 20210702115321 (Fri Jul  2 13:53:21 2021)
; Publish: 20210703000000 (Sat Jul  3 02:00:00 2021)
; Activate: 20210705000000 (Mon Jul  5 02:00:00 2021)
camp-wireless.com. IN DNSKEY 256 3 13 kJpmrljuP7PncZij7G1Yn9xngKe1xUpuONG2XAx8AYXu//qXClAbgg3B bmzyeDpFAw2gDRhjQ7f5o20c1QK9OA==

So I generated the key on 2 July 2021, with a set publication date of 3 July 2021. I shortened the prepublication period to avoid problems with other things happening in the near future and today it changed to published. If I generate new signatures again on 5 July 2021 those will use the new key.

DNSSEC is a process with lots of things to get your brains around, and a key rollover is one of those things. A key signing key rollover is even harder because uploading of the public key to the registrar has to be kept synchronized with the published information. That is why I am testing all this on camp-wireless.com where it is not a major problem if something fails.

I sort of forgot I had zigbee2mqtt running since 18 June and the network enhanced itself with two devices: a 'lidl smart plug' and a 'power supply/relay/dimmer'. The Lidl Silvercrest smart plug (EU, CH, FR, BS, DK) (HG06337) left the network by itself but the Busch-Jaeger Zigbee Light Link power supply/relay/dimmer (6735/6736/6737) was actively reporting and I was able to switch the light on and off.

After resetting it to the state I found it in I tried to remove it from the network (by sending a 'remove' message to zigbee2mqtt) but it came back right away. So I stopped zigbee2mqtt, set permit_join to false and restarted it. After that I gave the 'remove' command again and that worked and it hasn't come back.

Log from zigbee2mqtt with the device id removed:

Zigbee2MQTT:info  2021-07-03 15:59:04: MQTT publish: topic 'zigbee2mqtt/0xd85def11a1004f69', payload '{"brightness_relay":254,"linkquality":33,"state_relay":"OFF"}'
Zigbee2MQTT:info  2021-07-03 15:59:08: Removing '0x****************'
Zigbee2MQTT:info  2021-07-03 15:59:08: Successfully removed 0x****************
Zigbee2MQTT:info  2021-07-03 15:59:08: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"0x****************","type":"device_removed"}'
Zigbee2MQTT:warn  2021-07-03 15:59:08: Device '0x****************' left the network
Zigbee2MQTT:info  2021-07-03 15:59:08: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"ieee_address":"0x****************"},"type":"device_leave"}'
Zigbee2MQTT:info  2021-07-03 15:59:08: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"left_network","meta":{"friendly_name":"0x****************"},"type":"device_removed"}'
Zigbee2MQTT:warn  2021-07-03 15:59:08: Device '0x****************' left the network
Zigbee2MQTT:info  2021-07-03 15:59:08: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"ieee_address":"0x****************"},"type":"device_leave"}'
Zigbee2MQTT:info  2021-07-03 15:59:08: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"left_network","meta":{"friendly_name":"0x****************"},"type":"device_removed"}'

Sorry to whoever in the neighbourhood wasn't able to get their new lightswitch/dimmer working with their own hub. It should work now.

I checked the documentation and it's perfectly possible to tell zigbee2mqtt to allow/deny joins (even for a set time) via a message delivered via mqtt: MQTT topics and message structure: zigbee2mqtt/bridge/request/permit_join. I will leave the fixed configuration to joins disabled and will allow a join by hand when there is an actual device to join.

Diverse media die ik volg berichtten vanmorgen over een artikel in Trouw: 'Tientallen websites overheid voldoen niet aan veiligheidsrichtlijnen' - nos.nl en ‘Tientallen overheidswebsites zijn onvoldoende beschermd tegen hackers’ - volkskrant.nl.

De aanname in het originele artikel (achter betaalmuur) is dat omdat een website van een overheidsinstantie gebruik maakt van wordpress waar je prima de beheer login pagina kunt vinden deze websites automatisch allemaal kwetsbaar zijn. En voor het gemak wordt dan even de link gelegt met de inbraak bij de gemeente Hof van Twente.

Hiermee worden zo'n hoop stappen overgeslagen in beveiliging en gereduceerd tot 'openbare login dus onveilig'. Ik weet dat wordpress bekend en berucht is om onveiligheden en dat elke wp-login pagina constant geprobeerd wordt en als die er is bruteforce aanvallen krijgt. Deze website draait geen wordpress en ik zie 5-11 pogingen per dag om de wp-login pagina te vinden. Een andere site waar ik de hosting voor verzorg draait wel wordpress en met een heel strak afgesteld filter wat herhaalde login pogingen blokkeert zie ik 500 tot 1300 pogingen per dag om in te loggen. Zo'n login pagina is dus een bekend risico en daar moet iets mee. Daar neem je maatregelen zoals beperkingen van het aantal login pogingen per bron en sterke wachtwoorden. Daarnaast moet dus wordpress zelf goed beheed worden en bij eventuele kwetsbaarheden snel bijgewerkt worden.

Ik denk ook dat sommige van de genoemde websites juist expres voor een externe wordpress gebaseerde site hebben gekozen na een goede risico-afweging. De site kan dan zeer eenvoudig compleet losgekoppeld zijn van de verdere computersystemen van de overheidsdienst waar het om gaat. En gebeurt er iets met die wordpress website dan gooi je die weg en bouwt de site opnieuw op.

Het artikel mist al dit soort overwegingen en nuances. Er wordt nog even een link gelegd naar het slechte wachtwoord wat aan de bron lag van de ransomware aanval op de gemeente Hof van Twente. Maar dat slechte wachtwoord gaf zonder 2e factor toegang tot het interne netwerk van die gemeente via remote desktop. Onbevoegde toegang tot een besturingssysteem middels remote desktop is in veel gevallen een veel groter risico dan beheerrechten op een wordpress site.

Ik vind het een slecht artikel en het is jammer dat diverse andere media het zonder al te kritisch te zijn overnemen.

Voor de goede orde: ook al werk ik in de informatiebeveiliging, dit is mijn persoonlijke opinie en heeft niets te maken met werkgevers.

The zigbee stick I ordered for environmental monitoring at home is making its way over here and I received an sms about the duty and tax to be paid for importing it from the United Kingdom. Indeed, since brexit taxes have to be paid.

My first reaction when receiving an sms about a package was to think of malware attempts since that has been in the news recently. So I checked carefully. It's good dpd also sends an e-mail with the same information, and I can check the validity of the links and the source of the e-mail a lot better on a computer.