News items for tag security - Koos van den Hout

Buttcoins have had some interesting price changes recently and while I normally only associate bitcoin with sextortion scams I'm now receiving spam about 'getting rich from bitcoin'. Most notably from the mails:

Don't like these emails? Unsubscribe. a Company or Organization Name | Latvia

Wahnsinnig reich werden Wahnsinnig reich werden Don't like these emails? Unsubscribe. a Organization Name | France Unsubscribe {recipient's email} Update Profile | About our service provider

I guess they are abusing some cheap spam provider (probably known to themselves as "e-mail marketing company").

The bitcoin sextortion scams continue in this year. The one I got today tries to avoid spam filters that trigger on bitcoin addresses:

Ok! So.. to get some coins go and search on Google for "Buy BIT C0lN instantly"
and send to this address:

Address: 1 L 2 U a v M T r h p C X W n 9 L v q h C q R S v x Y z f Q s B w 4
Amount: 0.027

The address 1L2UavMTrhpCXWn9LvqhCqRSvxYzfQsBw4 is valid according to 1L2UavMTrhpCXWn9LvqhCqRSvxYzfQsBw4 - blockchain explorer but not yet known at BitcoinAbuse.

I hope some day one of these scammers is brought to justice.

Update 2021-01-10: More of the same, with reasonably good Dutch language writing. New bitcoin addresses: 1Emh6CsbF4eo425ph3sSCNZ2aGCWerRB7w 1JakpfFpX4HFyiuv7WKviV5xAanMwknArV 1Emh6CsbF4eo425ph3sSCNZ2aGCWerRB7w and the criminal wants 1500 US Dollar in buttcoins to not publish the videos.

Update 2021-01-13: More good Dutch although I am sure it's a translation because of the familiairity in the writing style. Bitcoin address Eu8sHWG2Uzvd1ukxumae5ctfSNWWtsFkS. The amount has changed to 1400 Euro in buttcoins.

I also note bitcoin address 1JakpfFpX4HFyiuv7WKviV5xAanMwknArV has received 2 incoming transactions of somewhat above 1500 dollars so it seems this crime pays.

Interesting find in the logs: SMTP authentication brute force.

Dec 20 20:57:22 gosper saslauthd[1616]:                 : auth failure: [user=iknidcam1974] [service=smtp] [realm=camp-wireless.org] [mech=pam] [reason=PAM auth error]
Dec 20 20:57:26 gosper saslauthd[1613]:                 : auth failure: [user=iknidcam1974] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error]
Dec 20 21:54:42 gosper saslauthd[1615]:                 : auth failure: [user=iknikieh] [service=smtp] [realm=camp-wireless.org] [mech=pam] [reason=PAM auth error]
Dec 20 21:54:47 gosper saslauthd[1617]:                 : auth failure: [user=iknikieh] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error]
Dec 20 21:57:14 gosper saslauthd[1614]:                 : auth failure: [user=iknikieh] [service=smtp] [realm=camp-wireless.org] [mech=pam] [reason=PAM auth error]
Dec 20 21:57:23 gosper saslauthd[1615]:                 : auth failure: [user=iknikieh] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error]

With lots more for different names. The last one is probably this session:

Dec 20 21:57:16 gosper sm-mta[15854]: STARTTLS=server, relay=[5.188.206.203], version=TLSv1.2, verify=NOT, cipher=ECDHE-RSA-AES256-GCM-SHA384, bits=256/256
Dec 20 21:57:24 gosper sm-mta[15854]: 0BKKvEuN015854: [5.188.206.203] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA-SSL

Due to the fact that they abort the session when they can't log in the IP is seen as annoying by fail2ban and added to the deny list. But that list grows (suggesting a distributed attack) and is at this moment at 142 currently blocked hosts.

I noticed the certificate for idefix.net was expired according to my webbrowser. I dug up the reason and found out the scripts to maintain the ocsp files managed to confuse the Makefile to keep the haproxy certificates updated.

The ocsp responses have more updates than the certificates, but a certificate update needs to be processed anyway.

So I updated the Makefile in the previous post. The dependency is now certificate-stamp depends on installed certificates, installed certificates depend on copied certificates. And installing the certificate also updates the ocsp response.

Interesting scam e-mail today, I guess it tries all possible scams and hopes to find out which one(s) work. Sent using the invite option of google forms, which seems to be popular with scammers recently.

I've invited you to fill out a form:
Attention Dear Customer
Attention Dear Customer,

We attempted to dispatch your item at 11:29 AM GMT+1 on the 19th of November, 2020 [11-19-2020].

Your delivery attempted to be delivered was affirmed to be among the list of deliveries abandoned in our delivery factory loft in the category

of the delivery file cases that consist of Stimulus Payment, Lottery Winners/Contract payments, Compensation & Inheritance Payments and

unclaimed consignments(concealed funds) From 2017 - 2020 and was abandoned due to the the COVID-19 (Coronavirus) pandemic that has

caused the lockdown in the country at large including the Holiday that has stopped it from getting to you respectively.

The shipping charge of this delivery has been paid & covered, so this notification has been automatically sent to notify you of this parcel

because if the parcel is not re-scheduled for delivery or picked up within 72 hours, it will be cancelled/confiscated along with the Tracking

details which will be null & void.

Yours sincerely,
Bruce Springs
404-666-6485
fedexpress109@hotmail.com
Secretary, FedEx Factory Loft


**************************
The content of this email is confidential and intended for the recipient specified in this message only. It is strictly forbidden to share any

part of this message with any third party, without a written consent of the sender. If you received this message by mistake, please reply to

this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future.
************************************************************

1006205-4-9-US-EN-80147623


©2020 FedEx. The content of this message is protected by copyright and trademark laws under U.S. a

I have one Apache server exposed to the outside world for IPv6 clients (because of a history in hostnames going back to the 20th century). So after enabling OCSP for haproxy I decided to have a look at OCSP stapling for Apache 2.4. That's even easier than haproxy since Apache 2.4 will fetch the ocsp data itself. I followed Apache 2.4 SSL/TLS Strong Encryption: How-To OCSP Stapling and it works.

So now the current score at the Qualys SSL server test for koos.idefix.net is A+ both via IPv4 and IPv6.

On my to-do list was the idea to look at OCSP stapling for haproxy. OCSP is Online Certificate Status Protocol which wraps the revocation status of a certificate in the certificate negotiation. This speeds up the TLS setup a bit since the client doesn't have to make an extra connection to the OCSP responder of the certificate issuer and it adds a bit of privacy because the certificate issuer doesn't see which client requests the status of a certificate.

Finding the right way to get the ocsp updates to haproxy was a bit of work, eventually made some modifications to the script in HAProxy OCSP stapling. I also used the remarks in OCSP stapling with HAProxy. From pitfall to euphoria because I saw the "OCSP single response: Certificate ID does not match any certificate or issuer" error message. I had to restart haproxy first to make it enable ocsp processing (because now each server certificate has its own .ocsp file) and now it accepts the "set ssl ocsp-response" command.

Update: I'm not completely happy yet: after a certificate was renewed haproxy complained about the .ocsp file being out of date. Which is fully correct, since that .ocsp file was about a previous version of the certificate. This needs more work. Ideally I would check the validity of the .ocsp file before deciding to renew it. And fetch the new ocsp data before reloading a renewed certificate.

Anyway, the 'TLS setup' part of connecting to sites like idefix.net goes from 20-21 milliseconds to 5-8 milliseconds. Not a blinding fast improvement but all bits help and I like to have optimal security and privacy.

I had a look at some weblogs and after removing the entries caused by webbots most of the rest of the traffic was attacks. All on stuff I don't have (usually wordpress), but one thing was noticeable:

37.59.47.61 - - [13/Oct/2020:00:17:34 +0200] "GET ////nette.micro?callback=shell_exec&cmd=ifconfig HTTP/1.1" 404 747 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.90 Safari/537.36"
37.59.47.61 - - [13/Oct/2020:00:17:41 +0200] "GET /////nette.micro?callback=shell_exec&cmd=ifconfig HTTP/1.1" 301 715 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.90 Safari/537.36"
37.59.47.61 - - [13/Oct/2020:00:17:43 +0200] "GET /nette.micro?callback=shell_exec&cmd=ifconfig HTTP/1.1" 404 747 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.90 Safari/537.36"

From what I've found about the 'nette microframework' there are callbacks, but none of those is called shell_exec.

Yesterday I read about changes at LetsEncrypt that influence LetsEncrypt intermediate certificates and DANE and had a look at my own DANE record set up in december 2019.

I decided to change the 'usage' value to 1, meaning 'EE match validated by public CA' because it's linked to a known public CA, and the old value 3 meaning 'private EE' wasn't completely true because it's linked to a known public CA.

But I received a notification this morning, with:

Only certificate usages DANE-TA(2) and DANE-EE(3) are supported with SMTP.

With references to rfc 7672 section 3.1.1 and further which makes a valid point about CA validation in SMTP sessions.

So the validation chain is purely based on DNSSEC.

After mention of the internet.nl tests at work I tested my webserver with the test from internet.nl and got a failed for the cipher order test. I do have the 'best' configuration according to the Mozilla SSL Configuration Generator but the test at internet.nl disagrees on this point because of the ordering of the ciphers. So with a lot of checking I now have:

ssl-default-bind-ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256

Which is not the order Mozilla suggests, but gives me an A+ on the Qualys SSL Server test and a good result on the standards test at internet.nl.

I also found out generating my own Diffie-Hellman parameters is not good for parameter sizes of 2048 bits and up. I changed to a known-good group of 4096 bits.