iPhone/iPad gebuikers: security-tip!

Sinds iOS en iPadOS versie 18.2 heeft Safari (de standaard webbrowser, het blauwe kompas) een instelling die het openen van websites veiliger maakt, vooral als u van publieke WiFi gebruik maakt (restaurant, trein, hotels etc).

Sla hieronder gerust alle tekst over die u niet interessant lijkt. Maar zet die instelling aan, voor uw eigen bestwil (en doe dat ook bij uw ouders)!

Laatste update iOS/iPadOS
Controleer sowieso regelmatig of uw iPhone of iPad de laatste update geïnstalleerd heeft: open "Instellingen" (het grijze tandwieltje), open "Algemeen" en vervolgens "Software update" (doe dat alleen als u een WiFi-internetverbinding heeft, anders kan het ten koste gaan van uw telefoonrekening).

De laatste versie op dit moment is 18.3.

Nieuwe Safari instelling
Na het updaten en opnieuw opstarten opent u in "Instellingen" onderaan "Apps". Zoek naar "Safari" en open dat.

Scroll het scherm naar boven totdat u het lichtgrijze kopje "PRIVACY EN BEVEILIGING" ziet.

Daaronder zou moeten staan: "Waarschuwing voor onveilige verbindingen" (standaard staat die instelling uit).

Als u dat AAN zet toont Safari u een *waarschuwing* als er (ook tijdelijk) gebruik gemaakt wordt van een verbinding met
http://
in plaats van met
https://

Toelichting
Bij http:// weet u, vooral op een minder vertrouwd netwerk (zoals WiFi in een vliegveld, zie https://www.bleepingcomputer.com/news/security/australian-charged-for-evil-twin-wifi-attack-on-plane/), niet zeker of Safari echt een verbinding heeft met de server waarvan u de website-naam in de adresbalk van Safari ziet.

(Techneuten zeggen "domeinnaam" i.p.v. "website-naam").

Sterker, u kunt http:// vergelijken met wegwijzers die door vandalen in een andere richting kunnen worden gedraaid, waardoor u (als u geen moderne navigatie gebruikt) de verkeerde kant op kunt worden gestuurd.

Risico: omleiding naar nepsite
Vergelijkbaar, bij http:// kan een aanvaller Safari, zonder dat u gewaarschuwd wordt, doorsturen naar een nepwebsite (die als twee druppels op de echte lijkt) - doch met een iets afwijkende (of totaal andere) website-naam. Als die nepwebsite https:// ondersteunt, merkt u *niet* dat Safari naar een andere website is gestuurd dan door u bedoeld.

Waarom https:// wél veilig is
Bij het gebruik van uitsluitend https:// is "omleiden" nagenoeg onmogelijk. Als genoemde Safari-instelling AAN staat, maakt het niets uit of u bijvoorbeeld google.com of http://google.com intikt in de adresbalk: Safari: maakt daar dan automatisch https:// van vóórdat verbinding met de server wordt gemaakt.

Nadeel: thuisapparaten
Nadeel: sommige websites, vooral "smart" apparatuur in uw huis (waaronder de beheer-interface van uw modem, zoals de laatste van Ziggo) ondersteunt https:// vaak niet. Als u bijvoorbeeld http:⧸⧸192.168.178.1 moet openen, zal Safari u waarschuwen *voordat* de verbinding wordt gemaakt. Als u op "Ga verder" drukt, werkt alles als vanouds.

Nadeel: oude sites en "jumpsites"
Een ander voorbeeld zijn stompzinnige "jump sites" zoals http://gemeente.amsterdam (deze ondersteunt uitsluitend http:// en dat is, voor overheden, tegen de wet). Als het *goed* is stuurt bovenstaande link Safari door naar https://amsterdam.nl (die link begint wel met https://).

Risico: als u, op een onvertrouwd netwerk, http://gemeente.amsterdam opent, loopt u het risico dat Safari naar een nepwebsite wordt doorgestuurd, met bijvoorbeeld de naam
gemeenteamsterdam·com
of
amsterdam·top
en u geen enkele foutmelding ziet (en de getoonde pagina als twee druppels op de echte kan lijken). Nb. in die laatste twee websitenamen heb ik de laatste punt vervangen door · (een hoge punt) om onbedoeld openen te voorkómen.

Let op: "Ga verder" = http://
Als u genoemde instelling in Safari aanzet (wat ik 100% aanraad, dit zou m.i. een standaard-instelling moeten zijn in alle browsers), en u krijgt het waarschuwingsscherm te zien (zie het tweede plaatje): als u op "Ga verder" drukt, wordt meteen de onveilige http:// verbinding gemaakt (zonder verdere vragen). Let dan dubbel goed op de vervolgens in de adresbalk van Safari getoonde websitenaam!

Resetten
Als u een http:// verbinding heeft toegestaan (zoals met http://gemeente.amsterdam), onthoudt Safari dat een tijd (ik weet nog niet of dit tijdbegrensd is, waarschijnlijk wel). Als u Safari sluit, door de geopende app van het scherm te vegen, *lijkt* Safari alle toestemmingen te vergeten die u voor http:// verbindingen gegeven heeft.

Desnoods (dit raad ik af) kunt u Safari dwingen om onthouden toestemmingen te verwijderen door de gehele geschiedenis van Safari te wissen. Advies: vóór dat u dat doet, exporteer eerst alle website-data, want onthouden inloggegevens bent u ook kwijt als u de hele browsergeschiedenis wist. Met zo'n export kunt u terug naar de oude situatie door het export-bestand weer te importeren.

Over de plaatjes hieronder
Meer informatie ziet u door op "Alt" in het plaatje te drukken. Het linkerplaatje laat de nieuwe instelling voor Safari zien.
Voor het rechterplaatje heb ik http://http.badssl.com gekozen. Dat heb ik gedaan omdat ik wat wisselende ervaringen had met http://gemeente.amsterdam.

(Voor techneuten: Safari onthoudt onder mij nog onbekende omstandigheden dat het om een jumpsite gaat. In een export van de browsergeschiedenis zag ik in "Geschiedenis.json", onder "http://gemeente.amsterdam" o.a. een regel:
"destination.url" : "https://www.amsterdam.nl" - als de browser dat benut wordt er geen http gebruikt).

Over http://http.badssl.com
De website https://badssl.com bevat allerlei pagina's en sub-website-namen om browsers te testen, en is -voor zover ik weet- betrouwbaar. Niet alles is up-to-date (bijv. het certificaat van https://extended-validation.badssl.com/ is verlopen).

Andere testsites
In plaats van te testen met http://gemeente.amsterdam kunt u ook testen met bijv. http://http.badssl.com en http://www.buitenhoftv.nl.

M.b t. die laatste: als u 2x op more/meer drukt in https://youtube.com/watch?v=WalOiq0mrNw ziet u onder:
"Meer van Buitenhof:
» Vind"
een https:// link naar www.buitenhoftv.nl - maar u wordt belazerd (die jumpsite ondersteunt uitsluitend http). Precies daarom raad ik aan om deze Safari instelling aan te zetten. Ook sommige QR-codes bevatten http-links terwijl de site óók https ondersteunt.

Met enorme dank aan Thomas Bosboom
(@thomasbosboom) die mij op deze instelling wees in https://infosec.exchange/@thomasbosboom/113945617133456130!

it only takes 2 DNS records to fully disallow sending email as your domain to protect yourself from forgery

TXT record . ( example.com ) - "v=spf1 -all"
TXT record _dmarc ( _dmarc.example.com ) - "v=DMARC1;p=reject;rua=mailto:<your email>;adkim=s;aspf=s;sp=reject"

yall should do it

• the SPF record indicates that no mail servers are authorized to send emails on behalf of your domain ( the -all specifies a hard fail, meaning that any email sent from this domain will be rejected )
• the DMARC record instructs receiving mail servers to reject any emails that fail DMARC checks ( the p=reject policy ensures that unauthorized emails are not delivered, rua tag allows you to receive reports about any failed authentication attempts ( which are optional and you can remove it if you dont want it ), while adkim=s and aspf=s enforce strict alignment for DKIM and SPF )

it can always be undone later, but if you dont have an email server running, its a smart idea to disable emails though these dns records

Interesting. Hackers are mistaking Mastodon user profile account addresses for email addresses and sending fake roundcube phishing emails to the few accounts I have on my self-hosted instance in hopes of getting credentials.

"Roundcube Found Several Undelivered Messages"

I only received it because my domain has catch-all email turned on that will forward any email for email accounts that don't exist to a special email address.

The emails come from "Restoredesk.oldfriends.live <info@ecmtincinc.live>", pass spf and ip 79.141.160.47. Link below, which is Dropbox owned "DocSendDotCom"

Be careful if you host your own instance and have catch-all email setup and this slips past your little grey cells.

This Week in Security: Quantum RSA Break, Out of Scope, and Spoofing Packets - Depending on who you ask, the big news this week is that quantum computing researc... - https://hackaday.com/2024/10/18/this-week-in-security-quantum-rsa-break-out-of-scope-and-spoofing-packets/ #thisweekinsecurity #hackadaycolumns #securityhacks #spoofing #quantum #news

Hackaday Links: March 17, 2024 - A friend of ours once described computers as “high-speed idiots.” It was true in t... - https://hackaday.com/2024/03/17/hackaday-links-march-17-2024/ #industrialautomation #promptengineering #extraterrestrial #hackadaycolumns #hackadaylinks #architecture #spingravity #coriolis #spoofing #starship #aviloeb #blender #seismic #slider #gemini #google #sr-71 #wifi #ai

In the short time I've been the #Mastodon #Fediverse so far, I've talked a lot about how #DMARC can help prevent #spoofed #emails from being delivered to their targets, in light of a wave of Mastodon-themed phishing. That made me wonder, "How many Mastodon instances have a DMARC record on their domain? How many of those are set up to properly?" For their own security Users should join servers with an enforced DMARC policy, and instance admins should enforce DMARC on their domains to protect users and attract a security conscious userbase.

I wrote a script that queries instances.social for the 1000 top Mastodon instances based on the number of active users, feeds that list to #checkdmarc to query for, parse, and validate DMARC #DNS records. Here are the results.

https://github.com/seanthegeek/mastodon-dmarc-survey

As of earlier today, 148 instances with a combined 295, 975 active users had an enforced DMARC policy (p=quarantine or p=reject). 113 instances with a combined 168,965 active users have deployed a monitor only policy, 3 instances with a combined 577 active users have an invalid DMARC record, and 113 instances with a combined 486,972 active users don't have any DMARC record.

As I looked through the list of instances, I noticed that infosec.exchange is now the 7th largest Mastodon instance on the public internet, with 18,328 active users (and counting. Thanks @jerry!

As I reply to threads about #phishing to talk about the benefits of using #DMARC to prevent unauthorized #email from address #spoofing, I once again feel like I'm doing the equivalent of going door door and saying "Have you heard the Good News of DMARC? It will save you from the peril of eternal spoofing."

https://infosec.exchange/@seanthegeek/109607798252156989